Pregel 計算過程是屬於 BSP Model：由一次又一次的 Supersteps 所組成，而且在 Superstep 執行完畢後機器之間會有 Message 的交換；相對的，本論文在 Map Phase 與 Reduce Phase 時各只會執行一次，也就是當 Job Assignment 完成後各計算節點便開始 執行分配的工作量，然後節點之間在 Map Phase 時並不會交換任何 Message，只有接 收來自 Master 的分配結果與向 Master 回報執行結果，所以說本論文不需要考慮計算節 點間 Message 交換的需求。
Pregel 在分割圖形時使用者是可以控制節點的分配，此外每台機器在執行時只會 執行分配到的 Graph Partition 所以說 Pregel 與本論文相同的地方在於：我們都要求節 點只處理本地儲存的資料，如此就能避免 Input Data 需要透過網路讀取所造成
Overhead。
15
第三節 Spark
A. 設計目的：
在 Pregel 提出之後，許多經典圖形演算法像是：Shortest Path, PageRank 等都已經 實際被開發出來也在企業中實際被運用。但是每次 Superstep 執行完畢後都需要將所有 節點的狀態寫入 Local Disk 中做 Check Pointing。下一次 Superstep 便從 Local Disk 中 讀取上次執行結果，並重覆先前的計算過程。不只是 Pregel，其他 Application 像是 Machine Learning 也需要對同一群資料進行多次 Iteration 的計算才能完成。但若是每次 執行結果都需要不斷從 Local Disk 讀取與寫入 Local Disk 是相當花費時間與空間，會 對效能產生相當大的影響，Spark[10]便被設計出來用以解決這些的問題。
B. 設計目標：
Spark 是一套分散式程式 Programming Framework，利用 RDD [11] (Resilient Distributed Dataset)資料結構將需要重複讀取資料存放在 Memory 當中，如此利用記憶 體的高速以省下不斷從硬碟存取的時間。
RDD 是由一群 Read Only 的物件所組成，RDD 內除了儲存需要重複存取的資料之 外，也有每次 Iteration 那些資料的變化過程。這些變化過程會是一群有順序的
Function Calls，代表著一步一步對於資料的操作，透過記錄變化過程以及 Iteration 次 數，當需要使用節點狀態時只用變化過程與 Iteration 次數去計算節點當前狀態。Spark 僅紀錄節點狀態的變化資訊不僅能夠減少儲存空間，當任何節點狀態遺失時亦能用快 速的重新計算回復；雖然 Pregel 也是能利用 Check Point 重新計算遺失 Partition 的狀 態，但是因為 Partition 需要其他 Incoming Edge 的 Message 作為 Input 所以不只從本地 端也要從包含 Incoming Edge 的 Partition 讀取 Messages。相比之下 Spark 只需要從本地 記憶體中讀取節點變化過程並重複執行數次就可以回復遺失的節點狀態，省去從硬碟 中讀取以及透過網路傳輸所造成的 I/O Overhead。
在[7]實驗中，將在 Spark 與 Hadoop 上執行 Logistic Regression，因為其需要不斷 重複對相同一群資料作計算，所以算是一種 Iterative Job，藉此作者想要知道 Spark 對 於 Iterative Job 能達到多少程度的加速。作者在 20 台 m1.xlarge 規格 EC2 機器所組成 的 Cluster 上對 29G 的資料進行 Logistic Regression 運算，我們可以從圖 8 中看到，雖 然在只有一次 Iteration 時 Spark 執行時間稍稍大於 Hadoop，但是當 Iteration 數量開始 增加時，相較於 Hadoop 上升幅度；Spark 每個 Iteration 只多花了 6 秒。根據這些數據
16
我們可以得知 Spark 對於 Iterative Jobs 有顯著的加速效果。
圖 8、Hadoop 與 Spark 執行不同次數下所需執行時間
C. 與本論文差異：
雖然本論文的計算模式並不是 BSP Model，但是本論文期望提供能與使用者互動 的系統，使用者可以不斷對相同資料下 Query，因此 Reduce Phase 將 BRT Partitions 合 併後應當存放在 Memory 中讓使用者能對同一群資料重複下 Query。像是剛開始可能 是比較廣域 (國家或 AS)的 Query，但是找出可疑對象後接下來的 Query 就可能針對個 別 CIDR 或 IP，當本論文將 BRT 儲存在記憶體後便能夠與使用者達到更佳的互動性。
17
第四節 Dremel
A. 設計目的：
Google 在搭建 GFS 後，不只搜尋引擎所需網頁資料需要儲存之外連其他業務資料 像是會員資訊或機器 Log 等等，也會共同儲存在 GFS 中。為了分析如此大量資料得利 用 MapReduce 才能進行，通常 MapReduce 得執行數十秒到幾分鐘才能完成，當使用 者需要重複對資料做操作時就得花費相當大量時間在等待 MapReduce 完成。而且 GFS 內資料並沒有強制規定儲存格式，因為格式不一致而沒有辦法統一使用相同的資料處 理方式；而且不支援巢狀 (Nested)格式也讓資料的表達方式不夠豐富。
B. 設計目標：
為了解決因為 MapReduce 導致過長的執行時間與檔案格式的問題，Dremel[12]提 出兩項設計：Hierarchical Server Structure 與自行定義 Data Model。
Dremel 將 Cluster 內機器組織成樹狀結構，以 Level 為 3 的樹為例：樹中有唯一的 根節點；根節點下有多個中間節點而每個中間節點也有多個葉節點。根節點接收來自 使用者的 Query，依據與 Query 相關的待處理資料其所在葉節點，將 Query 分配給負 責這些葉節點的中間節點；中間節點則進一步將 Query 切分成各個葉節點所需處理的 範圍，將葉節點回傳的結果 Aggregate 後回傳給根節點，最後根節點再一次 Aggregate 中間結果最後才回傳給使用者。藉由將機器組織成樹狀結構，Query 能夠快速的根據 資料所在位置切割成許多能夠同時進行的 Sub-Query，隨著 Sub-Query Granularity 的提 高，Query 就能在更多機器上運行而在更短的時間內完成。
然後 Dremel 提出的 Data Model 不僅支援巢狀格式以表達資料中更高層語意之 外，為了讓使用者可以直接存取 Model 中某個資料而模仿 OO 語言存取 Class 的方 式。例如有個 Model 叫 A，它有兩種屬性 B 跟 C；然後 B 又有兩種子屬性 D 跟 E，若 是我們想要讀取屬性 E 的話可以使用 A.B.E 的表示法直接存取。
在 Data Model 儲存方面，為了減少針對特定欄位查詢而需要讀取全部 Table 所花 費的時間，Dremel 採用 Column Storage 的策略。Column Storage 策略是讓一張 Table 依據 Column 切割為多張子 Table，而每個子 Table 都單獨儲存，如此一來當使用者只 需要查詢特定欄位時就可直接讀取相對應的子 Table，這樣就可以省下讀取其他不需要 Table 的時間。Dremel 則是讓不同的屬性儲存在不同的檔案中，讓葉節點直接從硬碟 讀取對應屬性的檔案做查詢；以先前的例子來說，A.B.E 與 A.B.D 會各別儲存在兩個
18
檔案中，若 Query 只有查詢 A.B.E 的欄位時只需讀取 A.B.E 對應的檔案，就不需理會 A.B.D 的檔案。
在[12]中，設計了一個實驗：目的是要看出當逐步採用 Nested Data Model with Column Storage 與 Hierarchical Structure 後，對於相同 Query 其效能的提升。根據圖 9，
我 們 可 以 很 明 顯 看 到 當 採 用 Nested Data Model with Column Storage 後 ， 原 本 的 MapReduce Job 執行時間下降了快一個 Order，說明了當我們能夠只讀取需要處理的資 料就能夠大幅度降低浪費在讀取與處理不必要資料的時間；然後到了 Dremel 又採用 Hierarchical Structure 後，執行時間又再次下降了一個 Order，正說明了把 Query 切割成 多個能夠同時執行的 Sub-Query 更能顯現出大量機器同時執行的加速程度。
圖 9、Dremel 於相同 Query 在採用不同改善方式下的執行時間
C. 與本論文差異：
與本論文相同的部分在於為了加速查詢時間都採用了 Column Storage，將資料依 照欄位儲存在不同檔案中，查詢時僅讀取所需欄位即可。但是，本論文需要完成 Query 的步驟較為複雜，因此除了 Master 機器外都會實際處理 Query 的情況下並沒有 階層架構的設計。然後因為本論文的研究對象只有網路流量，比起 Dremel 所需要處理 的單純許多，因此就沒有額外設計的 Data Model 來表達不同格式的資料。
19
第五節 Impala
A. 設計目的：
以往商業資料都儲存在 RDMS (Relational Database Management System)當中，當 我們需要分析 RDMS 內的資料企圖找出 Data Insight 時，已有許多現成 OLAP (On-Line Analytical Processing)工具可以使用。但隨著資料量增長，RDMS 已經不足以負荷大量 資料的處理，因此當資料便不再儲存於 Relational Database 而是儲存在 HDFS 中；當資 料不再以結構化格式儲存時，原先 OLAP 工具便不再適用。
Apache 提出兩套資料分析平台－Hive[13]與 Pig[14]來滿足 HDFS 上資料的分析需 求。兩者都有提供 SQL-Like 介面讓使用者能夠重覆下 Query 與資料進行互動，不過不 管是 Hive 還是 Pig 都是將 Query 轉換成一連串的 MapReduce Jobs 存取 HDFS 內的資 料做查詢，因此執行時間往往得花到數十分鐘到數小時。
B. 設計目標：
Cloudera Impala [15]同樣提供 SQL-Like 介面，Impala 實作了 Hive 支援 SQL 語言 的一個子集，因此 Hive 使用者可以很輕鬆的轉換到 Impala 上。為了避免轉換成 MapReduce 工作所造成多階段 (Split、Map、Collect & Sort…等)執行的 Overhead，
Impala 捨棄由單一 Master 指派工作的模式，反而採用 MPP (Massively Parallel Processing) 模式，在每台機器上運行 Impala Daemon－直接接收使用者所下達的 Query、存取 Local HDFS 資料並回傳 Query 結果給使用者。
圖 10、Impala 系統架構圖
20
圖 10 中，Impala 在每個 DataNode 上執行 Impala Daemon，而 Impala Daemon 主 要由三個 Module 所組成：Query Planner、Query Coordinator 與 Query Execution Engine。
(1) Query Planner：接收從 SQL 介面或 ODBC (Open Database Connectivity)來的 使用者 Query，並向儲存資料 Metadata 的 NameNode 要求資料的位置；找出 Query 需要在哪些機器上執行後把 Query Plan 送給 Query Coordinator 並將結 果回傳給使用者。
(2) Query Coordinator：依據 Query Plan 將 Query 同時交給不同機器上 Execution Engine 執行，並將各 Execution Engine 回傳結果整合後傳回 Query Planner。
在執行過程中 Coordinator 會確認 Execution Engine 是否持續執行，若是有任 何 Execution Engine 失去聯繫則在其他機器上重新執行。
(3) Query Execution Engine：從 HDFS 讀取 Local 檔案並執行 Query。Execution Engine 執行結果並不會儲存回檔案系統中而是直接回傳給 Coordinator，如此 就能夠避免 MapReduce 中不同階段需要將 Intermediate Result 儲存到檔案系 統的 Overhead。
Impala 的架構下與 Hive 最大不同在於：Impala 並沒有 Master 角色的存在，每個 Query Planner 都可以接收 Query；而 Query Coordinator 都可以接收 Query Plan 執行，
如此就能避免 Master/Slave 架構下 Single point of failure 的問題。此外利用 Apache Parquet，Impala 也支援 Column Storage。
圖 11、Impala 使用不同資料格式(一未壓縮、兩壓縮)下不同 Framework 的平均回應時 間
在[16]中，針對 Hive、Impala 做了相同 Query 的效能比較。圖 11 列出不同資料格 式下 Query 的平均回應時間。我們可以看到在未壓縮格式下 Impala outperform Hive 5 倍的速度；就算有了 Block level 的壓縮技術 (Snappy)，Impala 依舊 Outperform Hive 3
21
背的執行速度。與 Dremel 的實驗相同，都說明了 MapReduce 並不適合運用在互動式 資料分析，Dremel 與 Impala 同樣採用 Column Storage 來減少 Query 需要讀取資料，但
背的執行速度。與 Dremel 的實驗相同，都說明了 MapReduce 並不適合運用在互動式 資料分析，Dremel 與 Impala 同樣採用 Column Storage 來減少 Query 需要讀取資料，但