資料分析處理需求分類

1 事務型處理

在我們實際生活中，事務型資料處理需求非常常見，例如：淘寶網站交易系統、12306網站火車票交易系統、超市POS系統等都屬於事務型資料處理系統。

這類系統資料處理特點包括以下幾點：

一是事務處理型操作都是細粒度操作，每次事務處理涉及資料量都很小。

二是計算相對簡單，一般只有少數幾步操作組成，比如修改某行的某列;

三是事務型處理操作涉及資料的增、刪、改、查，對事務完整性和資料一致性要求非常高。

四是事務性操作都是實時互動式操作，至少能在幾秒內執行完成;

五是基於以上特點，索引是支撐事務型處理一個非常重要的技術。

在資料量和併發交易量不大情況下，一般依託單機版關係型資料庫，例如ORACLE、MYSQL、SQLSERVER，再加資料複製(DataGurad、 RMAN、MySQL資料複製等)等高可用措施即可滿足業務需求。

在資料量和併發交易量增加情況下，一般可以採用ORALCE RAC叢集方式或者是通過硬體升級(採用小型機、大型機等，如銀行系統、運營商計費系統、證卷系統)來支撐。

事務型操作在淘寶、12306等網際網路企業中，由於資料量大、訪問併發量高，必然採用分散式技術來應對，這樣就帶來了分散式事務處理問題，而分散式事務處理很難做到高效，因此一般採用根據業務應用特點來開發專用的系統來解決本問題。

2 資料統計分析

資料統計主要是被各類企業通過分析自己的銷售記錄等企業日常的運營資料，以輔助企業管理層來進行運營決策。典型的使用場景有：週報表、月報表等固定時間提供給領導的各類統計報表;市場營銷部門，通過各種維度組合進行統計分析，以制定相應的營銷策略等。

資料統計分析特點包括以下幾點：

一是資料統計一般涉及大量資料的聚合運算，每次統計涉及資料量會比較大。

二是資料統計分析計算相對複雜，例如會涉及大量goupby、 子查詢、巢狀查詢、視窗函式、聚合函式、排序等;有些複雜統計可能需要編寫SQL指令碼才能實現。

三是資料統計分析實時性相對沒有事務型操作要求高。但除固定報表外，目前越來越多的使用者希望能做做到互動式實時統計;

傳統的資料統計分析主要採用基於MPP並行資料庫的資料倉庫技術。主要採用維度模型，通過預計算等方法，把資料整理成適合統計分析的結構來實現高效能的資料統計分析，以支援可以通過下鑽和上卷操作，實現各種維度組合以及各種粒度的統計分析。

另外目前在資料統計分析領域，為了滿足互動式統計分析需求，基於記憶體計算的資料庫倉庫系統也成為一個發展趨勢，例如SAP的HANA平臺。

3 資料探勘

資料探勘主要是根據商業目標，採用資料探勘演算法自動從海量資料中發現隱含在海量資料中的規律和知識。

資料探勘主要過程是：根據分析挖掘目標，從資料庫中把資料提取出來，然後經過ETL組織成適合分析挖掘演算法使用寬表，然後利用資料探勘軟體進行挖掘。傳統的資料探勘軟體，一般只能支援在單機上進行小規模資料處理,受此限制傳統資料分析挖掘一般會採用抽樣方式來減少資料分析規模。

資料探勘的計算複雜度和靈活度遠遠超過前兩類需求。一是由於資料探勘問題開放性，導致資料探勘會涉及大量衍生變數計算，衍生變數多變導致資料預處理計算複雜性;二是很多資料探勘演算法本身就比較複雜，計算量就很大，特別是大量機器學習演算法，都是迭代計算，需要通過多次迭代來求最優解，例如K-means聚類演算法、PageRank演算法等。

因此總體來講，資料分析挖掘的特點是:

1、資料探勘的整個計算更復雜，一般是由多個步驟組成計算流，多個計算步驟之間存在資料交換，也就是會產生大量中間結果，難以用一條sql語句來表達。

2、計算應該能夠非常靈活表達，很多需要利用高階語言程式設計實現。

二 大資料背景下事務型處理系統相關技術

在google、facebook、taobao等大網際網路公司出現之後，這些公司註冊和線上使用者數量都非長大，因此該公司交易系統需要解決“海量資料+高併發+資料一致性+高可用性”的問題。

為了解決該問題，從目前資料來看，其實沒有一個通用的解決方案，各大公司都會根據自己業務特點定製開發相應的系統,但是常用的思路主要包括以下幾點：

(1)資料庫分片，結合業務和資料特點將資料分佈在多臺機器上。

(2)利用快取等機制，儘量利用記憶體，解決高併發時遇到的隨機IO效率問題。

(3)結合資料複製等技術實現讀寫分離，以及提高系統可用性。

(4)大量採用非同步處理機制，對應高併發衝擊。

(5)根據實際業務需求，儘量避免分散式事務。

1相關係統介紹

1. 阿里CORBAR系統

阿里COBAR系統是一個基於MYSQL資料庫的分散式資料庫系統，屬於基於分散式資料庫中介軟體的分散式資料庫系統。該系統是前身是陳思儒開發的“變形蟲”系統(以前調研過)，由於陳思儒離開阿里去了盛大，阿里當心“變形蟲”穩定性等問題，重新開發該專案。

該系統主要採用資料庫分片思路，實現了：資料拆分、讀寫分離、複製等功能。由於此係統只需要滿足事務型操作即可，因此相對真正並行資料庫叢集(例如TeraData等)，此類系統提供操作沒有也不需要提供一些複雜跨庫處理，因此該系統存在以下限制：

(1)不支援跨庫的join、分頁、排序、子查詢。

(2)insert等變更語句必須包括拆分欄位等。

(3)應該不支援跨機事務(以前變形蟲不支援)。

說白了此類系統不具備平行計算能力,基本上相當於資料庫路由器!

另外此類系統的在實際應用的關鍵問題是，根據什麼對資料進行切分，因為切分不好會導致分散式的事務問題。

2. 阿里OceanBase系統

該系統也是淘寶為了解決高併發、大資料環境下事務型處理而定製開發的一個系統。該系統主要思路和特點如下：

(1)他們發現在實際生成環境中，每天更新的資料只佔總體資料的1%不到，因此他們把資料分為：基線資料和增量更新資料。

(2)基線資料是靜態資料，採用分散式儲存方式進行儲存。

(3)只在一臺伺服器上儲存和處理增量更新資料，並且是在記憶體中儲存和處理更新資料。

(4)在系統負載輕的時候，把增量更新批量合併到基線資料中。

(5)資料訪問時同時訪問基線資料和增量更新資料併合並。

因此這樣好處是：

(1)讀事務和寫事務分離

(2)通過犧牲一點擴充套件性(寫是一個單點)，來避免分散式事務處理。

說明：該系統雖然能處理高併發的事務型處理，號稱很牛逼，但其實也只是根據電商的事務處理來定製開發的專用系統，個人認為其技術難度小於oracle等通用型的資料庫。該系統無法應用到銀行或者12306等，因為其事務處理的邏輯遠遠比電商商品買賣處理邏輯複雜。

在目前的大資料時代，一定是基於應用定製才能找到好的解決方案!

3. 基於Hbase的交易系統

在hadoop平臺下，HBASE資料庫是一個分散式KV資料庫，屬於實時資料庫範疇。支付寶目前支付記錄就是儲存在HBASE資料庫中。

HBASE資料庫介面是非SQL介面，而是KV操作介面(基於Key的訪問和基於key範圍的scan操作)，因此HBASE資料庫雖然可擴充套件性非常好，但是由於其介面限制導致該資料庫能支援上層應用很窄。基於HBASE應用的設計中，關鍵點是key的設計，要根據需要支援的應用來設計key的組成。

可以認為HBASE資料庫只支援作為KEY的這一列的索引。雖然目前HBASE有支援二級索引的方案，二級索引維護將會比較麻煩。

2併發和並行區別

併發是指同時執行通常不相關的各種任務，例如交易型系統典型屬於高併發系統。

並行是通過將一個很大的計算任務，劃分為多個小的計算任務，然後多個小計算任務的並行執行，來縮短該計算任務計算時間。

兩者主要區別在於：

(1)通訊與協調方面：在平行計算中，由於多個小任務同屬一個大的計算任務，因此小任務之間存在依賴關係，小任務之間需要大量通訊和協調;相反，併發中的多個任務之間基本相互獨立，任務與任務之間相關性很小。

(2)容錯處理方面：由於併發任務之間相互獨立，某個任務執行失敗並不會影響其它的任務。但是平行計算中的多個任務屬於一個大任務，因此某個子任務的失敗，如果不能恢復(粗粒度容錯與細粒度容錯)，則整個任務都會失敗。

3本章總結

資料量大不一定需要平行計算，雖然資料量大，資料是分佈儲存，但是如果每次操作基本上還是針對少量資料，因此每次操作基本上都是在一臺伺服器上完成，不涉及平行計算。只是需要通過資料複製、資料快取、非同步處理等方式來支撐高併發訪問量

三 大資料背景下資料統計分析技術介紹

隨資料量變大，和事務處理不同的是，單個統計分析涉及資料量會非常大，單個統計分析任務涉及資料會分散在多臺伺服器上，且由於計算量大，採用單臺伺服器進行計算，會導致計算時間非常長，單個統計分析任務必須採用平行計算方式來加快單個統計分析任務執行速度。

1並行查詢與平行計算技術介紹

在大資料背景下的資料統計分析技術門類很多，常見的有：

n MPP並行資料庫 : TeraData、GreenPlum、Vertica等。

n 基於MapReduce平行計算框架的資料倉庫：

HIVE(Hadoop平臺) 、Tenzing(Google公司)

n 基於Hbase的Phoenix系統

n HadoopDB系統

n EMC公司的hapt系統

n MPP分散式查詢引擎： Dremel、Impala、Presto、Shard query、Citusdb。

n 基於SPARK的Shark、基於Dryad的SCOPE、基於Tez的stinger。

n 基於hadoop+index的JethroData系統

n 基於記憶體計算的Druid系統

這些系統都解決了海量資料下的資料統計分析的問題，並且這些系統另外一個共同特點是都提供了SQL或者類SQL介面。

為了能夠較好研究這些系統，我們需要對並行查詢與平行計算的相關技術做一個簡要的介紹。

首先所有的系統都可以分為三個層次: 語義層、平行計算引擎層、分散式儲存層。語義層提供一個程式設計介面讓使用者表達所需要計算，並負責把該計算翻譯成底層平行計算引擎可以執行的執行計劃，並由平行計算引擎來執行，最下面一層是分散式儲存層。

對於提供類SQL介面平行計算系統，語義層可以認為是SQL解析層。

1. 語義層

SQL語言是一種聲名式語言，SQL只是表達了要做什麼，而沒有表達怎麼做。為此，SQL解析層主要作用是：將使用者提交的基於SQL的統計分析請求，轉化為底層計算引擎層可以執行的執行計劃。也就是解決“怎麼做”的問題。

SQL解析層工作主要包括兩個大方面:

(1) 通過語法分析技術來理解要做什麼。在關係資料庫中，一般會把SQL語言分析後，形成樹型結構的執行計劃。

(2) 在語法分析技術上，利用各種優化技術和演算法，找出一種最經濟物理執行計劃。

優化可以分為兩個方面：一是邏輯層面優化、二是物理執行層面優化。

(1) 邏輯層優化

邏輯層面個人認為主要是因為同樣表達一個分析請求，有的人SQL寫的好，有的人SQL寫的爛，因此在邏輯層面可以通過一些等價關係代數變換，實現查詢重寫，將寫的比較爛的sql變換為好的寫法。

比較典型優化是：“把投影和過濾下沉，先執行過濾和投影操作”，減少中間結果。

(2) 物理層優化

物理層面優化是在邏輯優化後，結合實際物理執行過程，找出最優的物理執行計劃。生成物理查詢計劃的工作包括:

ü 增加一些操作符： 包括掃描和排序等。

ü 確定各個操作符實現演算法。例如掃描是全表掃描還是利用索引;Join是採用HASH連線、索引連線、合併排序等實現演算法中的那一種。

ü 確定操作符之間的資料流轉方法：物化還是流水線方式。

ü 採用基於代價估算方法確定最優的物理執行計劃，目前代價估算主要是以估算該物理計劃需要的IO量。另外對於並行資料庫，則還要考慮通訊代價，即儘量減少資料在各個機器之間的傳遞。

在物理層優化的代價估算過程中，代價估算需要依靠很多統計資訊，如表有多大，表中相關列的值分佈是什麼樣子等。傳統資料庫在資料Load過程中會事先計算好這些統計資訊。平行計算中還需要考慮通訊代價。

需要指出是，由於imapla、Presto、HIVE等系統只是一個查詢引擎，它們可以直接查詢以普通檔案方式儲存在HDFS系統上的檔案，因此這些系統一般無法使用索引和各種統計資訊來進行物理執行計劃的優化，這些系統一般只能在邏輯層進行一些基於規則靜態優化。根據SHARK論文，SHARK系統支援根據前面一些節點計算獲得的資訊，來動態優化後面執行計劃。

(3) 物化與流水線執行方法

一條SQL語句對開發人員而言，感覺只是一次呼叫，但是實際上在資料庫內部，一條SQL語句執行其實是有多個操作符組合而成的的樹型結構計算流。如下圖： 針對該計算流有兩種執行方式：一是基於物化或者是實體化執行方式，另外一種是基於資料流的執行方式。

第一種方法的過程是： 把各個操作運算排序，並把每個操作運算的輸出的中間結果儲存在磁碟上，直到被另外一個操作運算所讀取。

另外一種方法是同時交錯進行多個運算，由一個運算產生每個元組直接傳遞給下一個運算，而不將中間結果儲存到磁碟，也不用等到前一個運算全部運算完畢。

例如： 兩個表連線後，再進行投影操作。如果採用第一種方法，則需要

把兩表連線中間結果臨時寫入磁碟，然後再讀取該結果執行投影操作。而如果採用第二種方法，則連線操作一旦產生一個元組就可以立刻送到投影操作去進行投影操作。

流水線方法可以極大避免大量的中間結果磁碟IO。因此資料庫一般會採取流水線方法來執行。流水執行方法有兩種模式：一種是需求驅動流水線，也就是從上層主動向下層要求元組，另外一種是生產者驅動流水線執行方式，由低層主動產生元組，由下層向上層推。

目前大部分資料庫引擎採用的是需求驅動流水線，實現方式採用基於Graefe提出的迭代器模型。該模型把每個操作都表達為由三個介面： open() , getnext(), close()。每個操作被呼叫open() 進行準備工作，然後通過反覆迭代被呼叫getnext來獲取下一個元組，最後被呼叫close來進行清理工作。 通過構建迭代器網路，也就是迭代器之間的互相呼叫，就可以實現需求驅動流水線。

當然不是任何操作都可以流水執行，流水執行條件是：操作要滿足在接收輸入元組時可以輸出元組。例如排序操作就無法進行流水操作，在執行排序操作前都必須進行實體化。

(4) SQL解析層與平行計算引擎層

由於不同平行計算引擎層的執行計劃表達不同，因此不同系統需要將SQL解析成不同的形式物理執行計劃，例如：

MPP關係資料庫一般是把SQL解析成樹狀結構的物理執行計劃。

HIVE、Tezning資料庫是把SQL解析成DAG結構的多個MAPREDUCE組合。

DRemel等則類似MPP關係資料庫，把SQL解析成一個樹狀結構執行計劃。

微軟SCOPE則需要把類SQL解析成DAG結構的Dryad可執行的執行計劃。

SHARK則需要把SQL解析成基於scala語言的DAG結構執行計劃。

併發

並行

2. 平行計算引擎層

(1) 平行計算形式

並行化可以分為水平並行(無依賴並行)與垂直並行(流水線並行)兩類。如下圖：

如果兩個操作OP1、OP2 無相互依賴關係，則稱這兩個操作相互獨立。水平並行化指的是互相獨立的多個操作或者一個操作內互相獨立的多個子操作分別由不同的處理機並行執行的形式。例如，排序操作、掃描操作由不同處理機並行執行就是水平並行化的例項。

水平並行中一個非常常見的就是基於資料劃分的並行，例如MAPREDUCE，就是通過將資料劃分到多臺伺服器上，並行執行MAP和Reduce來進行並行運算。也有人把這種基於資料劃分並行與操作獨立並行區分開。

垂直並行化則是指存在流水線方式依賴關係的操作分別由不同處理機並行執行的形式。流水線方式依賴：如果OP2無需等待OP1執行完畢即可在另一處理機上開始執行。由於一般情況下，流水的級數遠小於處理的資料條目，因此流水並行主要意義是在可以避免中間結果磁碟IO操作，對並行度的貢獻相對較小。

(2) 平行計算面臨的問題與平行計算框架

平行計算需要解決的問題主要包括幾下幾個方面：自動並行化、通訊、任務排程、併發控制、容錯、資源管理。由於平行計算面向上述一系列問題，因為業界為了簡化並行程式開發，提供了一系列的平行計算底層庫或者框架。

在高效能運算領域，最常用於平行計算程式設計的庫是MPI庫，但是該庫主要只是解決通訊問題。這導致容錯、資源管理、任務排程、並行化等方面問題需要程式設計師來解決，因此利用MPI開發並行程式相對比較困難。

最近一些年，各大型網際網路公司開發開發了一系列的通用平行計算框架。包括谷歌公司的MAPREDUCE框架、微軟公司的Dryad框架(目前微軟已經停止該專案開發，轉而支援hadoop)、谷歌公司基於BSP模型的Pregel框架、Twitter公司的Storm框架、Yahoo公司S4框架、HortonWorks公司的Tez框架、Berkeley大學的spark框架等通用平行計算框架。

有了這些框架了，程式開發時只需要編寫序列執行程式即可，而且也不用考慮任務與任務之間的併發控制以及通訊等問題，其它所有問題都有框架來解決 ，這樣就大大簡化並行程式開發難度。例如採用MAPREDUCE框架，我們只需要提供MAP函式和Reduce函式，這些函式對程式設計師而言，都只是對本地資料操作。

目前雖然平行計算框架很多，但是可以把它們分成幾個大類(基於BSP並行圖計算引擎請參考第四章)：

流資料平行計算框架

Storm、S4是屬於流資料平行計算框架，適合對流資料實時處理，也就是在資料寫入磁碟前對資料進行實時併發運算。這類特點是計算不變，資料一直在變化。在上一個文件中，對此框架做過詳細介紹，這裡不再詳細介紹。

基於DAG通用批處理平行計算框架

MapReduce、Tez、Dryad、Spark等屬於基於DAG(有向無環圖)的通用批處理平行計算框架。這類框架是針對儲存在儲存裝置上的一批資料進行分析處理，而且把分析處理流程利用DAG模型來表達。

在這些框架中MAPREDUCE是最早出現的框架，而後面出現的一系列框架都為了改進MR框架不足而出現的升級版本。

MR框架主要不足是兩個方面：

一是程式設計介面太簡單，表現在單個MAPREDUCE無法表達複雜運算，所以在實際應用環境中都是通過多個MR作業組合來完成一個任務。為了簡化MR作業組合，在早期出現了一系列專案來執行組和式MR作業，例如Cascading專案。另外一個方面所有問題都必須轉換為MAP和REDUCE模式，導致程式編寫比較麻煩。

二是MR只支援基於資料分割槽並行方式，不支援流水線並行，採用是步步物化策略來提高可靠性，當是這種導致大量中間結果物化，IO開銷非常大。

因此Tez、Dryad、Spark等後續框架改進主要針對以下兩點進行改進：

一是直接支援基於DAG結構表達方法，DAG使得使用者能夠非常清晰地寫出非常複雜的業務邏輯;

二是通過支援流水線並性方式或者是儘量將中間結果放記憶體等方式，解決中間結果物化導致的IO開銷問題。Dryad和Spark框架在執行運算時，都會自動識別可以採取流水線方式執行的計算步驟，並儘量採用流水線執行方式來執行。

容錯：由於支援流水線並行或者採取把中間結果放記憶體的方式，因此要必須考慮容錯的問題。由於這些框架都採用的是DAG結構，DAG中一個節點所代表計算的執行是不會對輸入進行修改(所謂函數語言程式設計)，因此可以多次重複執行不會影響計算。因此如果某個節點計算失敗，它可以根據輸入重複計算，而如果輸入資料也消失了，則讓前一個節點重新計算。所有這一切都是由框架自動執行。

當然需要指出的是對一些流水線執行的多個計算步驟，如果某個計算節點失敗，則只能整個流水線整體失敗。

基於Tree結構的MPP並行查詢引擎

MPP並行資料庫與Dremel、impala、Presto、Shard query、Citusdb都採用的是基於Tree結構並行查詢引擎。此類平行計算引擎共同特點是：

一是針對SQL專用平行計算引擎，只支援SQL或者類SQL語義。

二是執行計劃都是樹狀結構;

三是以流水線或者將中間結果放入記憶體方式來實現快速計算。

四是粗粒度容錯機制。

它們之間不同點：

一 MPP並行資料庫中並行查詢引擎與底層儲存是緊耦合的，導致如果採用MPP並行資料庫，則只能通過SQL來訪問資料，無法採用其他計算引擎直接處理儲存在資料庫中的資料。

二 Impala、Presto都只是一個並行查詢引擎，它們可以直接查詢以檔案方式儲存在HDFS上的資料,這樣同一份資料既可以利用這些引擎來實現互動式查詢，也可以支援利用其他計算框架進行更深入分析。

三 Dremel 只支援Google自己的基於巢狀結構列式儲存(Column IO)。該引擎也主要適合於聚合型計算，不支援join操作。

四 上述引擎中只有MPP並行資料庫可以利用索引以及各種統計資訊來優化物理執行過程，因此該系統執行效率應該是最高。

五 Dremel、impala都只適合中間結果越來越小的查詢，因為這些系統都是把中間結果放在記憶體，一旦某個中間節點輸出結果超過記憶體，則整個任務會失敗，例如大表之間Join。

六 shard query和citusdb 都是在單機版本關係資料庫基礎上，採用增加一層中介軟體方式來支援並行查詢。

n基於Tree平行計算引擎與基於DAG平行計算引擎本質區別

基於Tree結構平行計算引擎與基於DAG平行計算引擎從表面上看，它們之間的主要區別是在於語義層面：前者主要專用與SQL類，而後者更通用。

但是MPP並行關係資料庫引擎、Imapla等都會支援通過UDF來擴充套件和解決標準SQL語言表達能力，另外SQL語言本身可以通過巢狀查詢、子查詢、union等各種方法表達很複雜的計算過程，因此從語義表達層面來講他們之間不存在本質區別。

這兩者之間主要區別還是在於表達執行計劃結構方面：樹結構是一個逐步匯聚的一個計算過程，無法表達split結構，因此基於DAG表達結構更靈活和通用。個人認為：樹型結構可能更加適合採用迭代器模型來實現流水線式的操作(只有樹結構才有上下層的關係，因此方便實現上層操作符巢狀呼叫下層操作符)。

所以不是所有計算都可以通過一個複雜SQL語句來表達!

(5) 自動並行化、資料重分佈、本地排程

平行計算引擎最重要的一個職責是自動並行。根據前面的平行計算基礎知識，平行計算的形式主要包括：基於資料劃分水平並行、基於流水線垂直並行、基於無依賴水平並行三種方式。

大資料屬於資料密集型計算，資料數量遠遠超過計算步驟數量。因此基於資料劃分並行方式是最有效的一種平行計算方法。在整個平行計算過程中，基於資料劃分中涉及資料可以分為兩大類：原始資料與中間結果資料。

n 原始資料劃分以及SN、SD架構討論

原始資料則可能存在兩種情況：一是在Shared-nothing架構中，原始資料本身就已經劃分好了，例如HDFS或者SN架構 MPP資料庫;另外一種情況如shared-disk結構中，原始資料沒有劃分。

第一種情況下針對原始資料劃分平行計算，就要受該劃分的限制。例如在MAPREDUCE中，map輸入是儲存在HDFS上的資料檔案，因此MAP例項個數一是不能少於該資料檔案分片數，二是MAP例項最好執行在該資料檔案所在機器，也就是要求任務排程時，能把該任務排程到特定機器上，即所謂“本地排程”，將計算儘量移動到資料。

第二種情況下，由於所有計算節點都可以看到所有資料，因此此時可以根據計算特點靈活選擇：資料劃分粒度、並行度、參與計算的節點。例如在ORALCE並性機制中，ORALCE可以針對某張表，按block或者partition 為單位進行劃分。

根據上述分析我們可以發現SD架構相對SN架構，在針對原始資料第一級並性計算時，SD架構更靈活，SN架構面臨的一個缺陷就是如果原始資料分佈不均衡，則存在計算傾斜問題。

但是現在大部分大的資料庫廠商的MPP資料庫還是採用了SN架構。根據網上所查資料來看,主要原因有兩點：

一是SD架構下，磁碟是一個共享資源，計算節點越多磁碟爭搶概率越大(和RAID隨機IO衝突道理一樣)，導致該架構可擴充套件性不夠好，也就是可能計算節點越多，效率相反不會提高。

二是從快取角度來看，SD架構下每個機器快取都要面向全資料庫，會導致命中概率底下;目前ORACLE-RAC開發一個fusion cache技術，實現了一個全域性共享快取來解決上述問題，但是可想而知這會影響系統可擴充套件性。

因此超過一定規模資料分析系統，都是採用SN架構。

中間結果資料劃分與資料重分佈

中間結果是由各個計算節點產生的，因此中間結果生成是就是分佈在各個參與計算節點之上的，因此：

一 ：SD架構下資料共享好處，對中間結果無效。

二 ：如果由於計算任務之間需要，需要在任務之間傳遞中間結果，則即使是SD架構也存在資料重分佈的問題，主要是中間結果重分佈，也就是中間結果傳輸。

另外從該過程我們還可以得出另外一個結論：

一： 對於複雜的資料處理，索引只能影響第一級計算，對於中間結果，由於只使用一次，因此沒有必要去針對中間結果建立索引。也就是即使我們將資料儲存在關係型資料庫中，也只有第一級計算能有效利用資料庫索引。

二：即使採用並行資料庫，如果我們的整個計算過程不能用一個SQL語句來表達，則我們必須自己解決中間結果的劃分與並性計算的問題。

(6)平行計算引擎架構與資源管理

所有平行計算引擎實現基本上都是主從結構，即一個MASTER + 多個slave節點的結構。由client向MASTER提交一個job,然後由Master負責將邏輯執行計劃變成實際執行計劃，並由Master負責將各個任務分發到各個slave中，並負責各個任務的排程。

MPP資料庫查詢引擎架構

MAPREDUCE架構和該架構缺點

Mapreduce框架中，JobTracker承當MASTER的職責，一般和HDFS中的NadeNode節點安裝在一個伺服器上。TaskTracker安裝在各個DataNode上，承擔Slave的角色。

流程如下：

(1)首先使用者程式(Client Program)提交了一個job，job的資訊會發送到Job Tracker中，Job Tracker是Map-reduce框架的中心，他需要與叢集中的機器定時通訊(heartbeat), 需要管理哪些程式應該跑在哪些機器上，需要管理所有job失敗、重啟等操作。

(2)TaskTracker是Map-reduce叢集中每臺機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況(資源的表示是“本機還能起多少個map-task，多少個reduce-task”，每臺機器起map/reduce task的上限是在建立叢集的時候配置的)，另外TaskTracker也會監視當前機器的tasks執行狀況。

(3)TaskTracker需要把這些資訊通過heartbeat傳送給JobTracker，JobTracker會蒐集這些資訊以給新提交的job分配執行在哪些機器上。

MAPREDUCE結構存在以下缺點：

(1) jobtracker只能安裝在一臺伺服器上，集中式作業控制導致可擴充套件性不好，另外JobTracker負責事情太多，容易成為效能瓶頸。

(2) 資源排程與程式設計模型緊耦合，只支援MAPREDUCE一種程式設計模型。

(3) 資源劃分太簡單，每個TaskTracker只是簡單把整個機器資源按map task slot和reduce task slot來劃分，而沒有考慮不通任務所需的記憶體和CPU等的資源不同。

針對上述特點，hadoop平臺開發通用的資源管理器yarn，只負責資源管理和分配，即通過把jobtrack中的資源管理分配自和並行應用程式排程與控制分離，從而實現雙層排程框架：由yarn把資源分配給各計算引擎MASTER，再由MASTER分配給各個TASK。

資源管理器YARN

流程如下：

1. client 通過一個CLC (container launch context )向ResourceManager提交一個應用

2)RM 啟動該應用的 AplicationMaster。 AplicationMaster啟動後先向ResourceManager註冊，並利用心跳資訊，定期向ResourceManager報告自己存活性和資源分配請求

3)ResourceManager分配一個container(container包括CPU個數和所需記憶體數量)時， AplicationMaster構造一個CLC,並在該container對應機器上Nodemanager上啟動該container。AplicationMaster 監控該container的執行狀態，並且該資源需要被回收時，由AplicationMaster停止該container。 監控container內部的作業的執行進度是AplicationMaster的職責。

4)一旦整個執行完畢，AM從RM中解除註冊，並且乾淨退出。

這種架構優點是：

優點一：減小了JobTracker(也就是現在的ResourceManager)的資源消耗，並且讓監測每一個Job子任務(tasks)狀態的程式分散式化了，更安全、更優美。也就是ApplicationMaster是每個應用一個，並且不通應用對應的ApplicationMaster的例項可以執行在不同伺服器上。

優點二：能夠支援不同的程式設計模型ApplicationMaster是一個可變更的部分，使用者可以對不同的程式設計模型寫自己的ApplicationMaster，讓更多型別的程式設計模型能夠跑在Hadoop叢集中。

優點三：對於資源的表示比之前以剩餘slot數目更合理。

3. 儲存層

資料儲存層主要包括以下幾類：

一類是基於MPP資料庫叢集，這類系統特點是儲存層與上層並型計算引擎是緊耦合，屬於封閉性的系統。

二是採用分散式檔案系統，例如SharK、Stinger、HIVE、Impala、Scope等。Shark、Stinger、Hive、Imapla都採用HDFS檔案系統作為儲存層，Scope採用微軟自己開發的分散式檔案系統。此類系統特點是儲存層與上層計算引擎層之間是鬆耦合關係。

三是儲存層基於單機版本關係資料庫，例如CitusDB採用PostSQL資料庫系統、shardquery採用Mysql資料庫系統。此類系統類似於一箇中間件，也可以認為上層和底層儲存層屬於鬆耦合關係。

四是可以支援各種異構的儲存系統，例如Presto、Tenzing。Presto設計即支援HDFS也支援儲存在Mysql中的資料，但是目前只支援HDFS;Tenzing底層支援：Google File System、MySQL、Bigtable。

不同儲存系統對上層計算有一些影響，典型如Tenzing系統會利用底層儲存系統的一些特性：

(1)例如如果低層是mysql資料庫，則可以直接利用mysql索引來過濾

(2)如果底層是bigtable資料庫，則可以直接利用bigtable 範圍scan來過濾

(3)如果底層是列儲存系統，則可以只掃描需要掃描的列。

(4)如果底層是列儲存系統，且標頭檔案裡面有該列最大值和最小值，則可以利用該資訊直接跳過某些檔案的掃描。

另外需要指出的是，目前已上所有系統都有一個趨勢就是採用列式儲存。例如HIVE開發了行列混合的RCFILE檔案格式(先按行劃分，保證每行的資料不會垮機器儲存，然後再按劣儲存)，shark系統開發了記憶體中的列式儲存格式，citusDB開發了專用postSQL資料庫的列式儲存引擎。

3 Druid等專用系統簡單介紹

1. JethroData系統

JethroData的特點是hadoop+index。該系統對儲存在HDFS上的結構化資料建立索引，並把索引檔案也以普通檔案方式儲存在HDFS系統，並在查詢處理時採取以下過程：

(1) 查詢主節點負責分析SQL語句後，針對sql中的where條件部分，利用索引檔案來得到符合where過濾條件後的rowid集合。

(2) 該rowid集合涉及各datanode節點，採用併發方式來讀取資料。

(3) 所有資料彙總到查詢主節點，進行彙總與計算，並將最終結果返回給客戶端。

可以看出，由於該系統設計思路是希望通過索引來加速資料選擇，因此只適合每次查詢處理只涉及少量一部分資料。

2. Druid系統

本系統是美國metamarket公司開發的面向海量資料的實時統計分析系統，以實現針對上億級別海量資料統計分析的延遲在1秒以內。該系統於2012年10月開源。該系統可以認為是一個分散式的記憶體OLAP系統。

該系統主要分析的資料為交易記錄，每條交易記錄包括三個部分：交易發生的時間點、多個維度屬性、多個數值型度量屬性。例如：

該系統設計用來可以回答以下問題“有多少個針對Justin Bieber的編輯來自San Francisco? ”、“一個月內來自Calgary的增加編輯字數的平均數是多少?”。而且要求：能夠在高併發環境下，在1秒以內完成任意維度組合的統計，且保證系統高可用;還系統還要能夠具備實時資料分析能力，也就是能夠查詢分析到最新的資料，延時時間為秒級。

為了達到上述目標，該公司先後通過測試發現關係資料庫技術和NOSQL資料庫都無法滿足其需求。關係型資料庫由於磁碟io瓶頸導致效能無法滿足需求，而NOSQL資料庫雖然可以採用預計算方法來達到高效能，但是預計算無法滿足分析需求靈活多變。

為解決該問題，該公司自己開發DRUID系統，主要技術思路如下：

(1)將原始資料(alpha資料)進行一定粒度合併，合併成beta資料。

(2)將beta資料全部放入記憶體，並通過分散式記憶體方式解決單臺伺服器記憶體

上限問題。

(3) 針對緯度屬性建立索引，以加速資料的選取。

(4) 採用分散式方式進行並行統計，為了保證分散式統計高效，該系統不支援join，而且對聚合計算不支援中位數等無法分佈計算的聚合計算函式。

(5) 利用資料複製解決系統高可靠性問題。

4 本章總結

1. MPP並行資料庫得益於流水線的執行以及基於統計優化等方面，使得MPP並行資料庫的執行效率是最高的。但缺點包括：

n 資料匯入時間長，匯入時要做各種預處理，例如一些統計資訊;

n 執行引擎和儲存緊耦合導致資料難以被其他分析引擎進行分析;

n 基於樹型結構執行計劃，導致MPP並行資料庫表達能力有限，更適合做統計與查詢，而不適合資料分析處理;

n 容錯性差，特別是一個任務涉及資料量越大，該缺陷越明顯。

2)HIVE、Tenzing、Shark、SCOPE、Stinger等系統可以認為基本屬於同一類系統。這類系統共同特點是：”通用平行計算引擎框架+SQL解析層”。並且可以將HIVE、Tenzing看成是基於第一代系統，而Shark、Scope、Stinger是第二代系統。這一類系統特點如下：

n 儲存層、執行引擎層、SQL解析層三者分離，可以方便替換執行引擎，對使用者而言，同一份資料可以採用不同並行執行引擎來分析。

n 在執行效率方面，由於儲存和上層分離因此一半隻能具備邏輯優化能力，另外由於Tree結構執行計劃更容易採用流水線執行方式，因此這類系統執行效率總體來講不如MPP關係資料庫，它們之間排序是MPP資料庫 > 第二代系統 > 第一代系統。

n 在執行效率方面，另外一點是這類系統一般內建對索引的支援不是太好或者不支援。

n 在大規模計算容錯方面，這類系統要優於MPP關係資料庫。

3)Impala、Dremel等可以認為屬於同一類系統，此類系統介於前兩者系統之間。這類系統特點是：

n 和MPP資料庫類似，基於Tree結構執行計劃，專注於查詢統計，因此效率高於第二類系統，但是可能和第二類系統的第二代相當。

n 與MPP資料庫不同的是這類系統只是一個引擎，與儲存系統鬆耦合。也就是SQL解析層與執行層緊偶合，然後和儲存層鬆藕合。

n 只適合做中間結果越來越小查詢分析，中間結果都放記憶體，對記憶體要求較高，例如無法實現大表之間的join。

因此，在大型網際網路企業中，資料量太大，就會出現所謂“高價值、低密度”情況，反映到資料處理上，網際網路企業不會長期儲存原始資料，而是會把原始資料先經過一部分預處理，經過部分提煉後，把提煉後資料進行長期儲存和分析。也就是如下流程:

例如淘寶，把每天資料直接寫入Hadoop平臺，然後通過每天執行相對固定mapreduce作業來做ETL，然後在計算結果基礎上為提供各種分析功能。其中海量原始資料經過固定ETL後被刪除，由於只使用一次，因此沒有必要花很大精力把這些資料整理成適合分析與挖掘格式。例如在這種場景下，索引也沒有太大的價值，因此沒有必要花費大量代價來建立索引。

MPP並行資料庫，適合儲存高密度價值資料，並且是長期儲存和多次使用，所以MPP並行資料庫會花大量經歷在Load階段，把資料處理成適合分析格式 。

通過上述系統地介紹與比較，我們可以得出一個這樣結論：在大資料領域，沒有一個通用的解決方案，而需要根據具體業務場景，選擇合適的技術!

4)通過上述系統研究，我們可以發現一點就是Join操作，特別是大表之間join操作是最消耗資源，也是最優化難度較高的操作，特別是在並行join的實現難度較大。例如Druid和Dremel等都基本放棄了join操作。

因此個人認為應該從業務上和從資料預處理方面，通過適當資料冗餘來儘量避免在分析過程過程中執行join操作。

四 大資料背景下資料分析挖掘技術介紹

1　Mahout與MLlib專案

資料分析挖掘主要涉及兩個方面：一是資料預處理;二是資料探勘。

在資料預處理方面，根據掌握資料來看，大型網際網路公司主要以MapReduce、Storm等計算框架為主，這些平臺可以較好解決大資料預處理面臨平行計算和處理靈活性的問題。但是個人認為spark、tez等屬於MapReduce升級版本，因此後面這些計算框架在這方面的應用會越來越廣泛。

在資料探勘演算法執行方面，主要問題解決資料探勘演算法平行計算問題。早期在資料探勘演算法並行化方面專案主要是Mahout專案，該專案基於MAPREDUC 平行計算框架實現了推薦、分類等常用資料探勘演算法的並行化。

但由於資料探勘演算法存在以下兩個方面特點導致基於MAPREDUCE框架來做資料資料探勘演算法執行引擎效率不高：一是機器學習演算法一般比較複雜，通常需要多次迭代計算，而MapReduce框架的步步物化導致中間結果會反覆的序列化和反序列化導致效率不高;二是資料與資料之間依賴特別多，在計算過程中機器與機器之間的通訊非常多，而MapReduce框架下Map與Reduce之間存在路障同步, 導致大量時間被消耗在同步等待上面，效率不高。

因此目前Mahout專案在2014年1月份在0.9版本釋出後，該專案拋棄了MAPREDUCE框架，轉而採用SPARK作為底層計算框架。

除Mahout專案外，SPARK自己採用SPARK專門針對機器學習領域開發MLlib專案。但是MLlib專案出現時間比較晚，因此在成熟度方面不如Mahout。

Mahout專案目前支援的資料探勘演算法如下：

MLLib支援的資料探勘演算法包括：

2　圖資料處理處理概述

在資料分析處理領域，隨社交網路興起，對圖資料處理的需求越來越多。例如像Facebook和Twitter這樣的社交網路，其資料天生就適合於圖表示法。對圖資料的處理和傳統資料庫處理一樣，也可以分為兩種型別的需求：

OLTP工作負載，能夠快速低延遲訪問小部分圖資料。

OLAP工作負載，能夠對圖物件中的大部分資料進行批量分析與處理。

1. 圖資料OLTP處理

(1) 圖資料庫分類

適合圖書據OLTP處理的系統，主要是各種圖資料庫。從目前來看圖資料庫主要可以分為兩類：

一是基於圖儲存模型的專用圖資料庫，如Neo4j、OrientDB、Infinite Graph等;

二是以通用KV儲存系統或者關係資料庫系統開發的圖資料庫，例如Titan系統(2013年推出)可以後端儲存可以基於HBASE或者是Cassandra，Twitter公司的FlockDB圖形資料庫和facebook公司Tao圖形資料庫是基於mysql來進行開發。根據報道美國NSA就是利用2011年開源的Apache Accumulo(屬於分散式KV資料庫)來儲存社會關係網路資料。

(2) 圖資料查詢

圖資料查詢其實就是”遍歷”圖(Traverse)。圖資料庫查詢語言可以使用Gremlin、Cypher等查詢語言來查詢圖。例如Neo4j就支援Cypher查詢語言。

Cyper查詢語言需要以一個節點來啟動(START)查詢，然後使用MATCH關鍵詞以WHERE關鍵字過濾節點或者關係的屬性，最後以RETRUN關鍵詞來指定查詢所返回的資料是節點、關係還是節點或者關係的屬性欄位。例如：

START barbara = node:nodeindex(name=”Barbara”);

MATCH(barbara)—(connected_node)

RETURNconnected_node.

(3) 兩類圖資料庫區別

第一類與第二類圖資料庫區別在於以下幾點：

查詢功能方面

第一類圖資料庫可以以非常高效率方式支援複雜查詢，既支援從指定起點開始，以任意深度來遍歷圖，並且還可以支援各種過濾。這樣就可以很方便的執行各種圖專用查詢任務，例如“查詢兩個節點間所有路徑或者最短路徑”等。相反第二類資料庫則只能支援較為簡單查詢，如FlockDB就只支援深度為1的關係遍歷(個人認為也可以實現，只是效率不高)。

可擴充套件性方面

大部分第一種圖形資料庫都不支援分佈，個人認為可能分佈後這種複雜查詢難以做到高效，因此可擴充套件性不好。而第二種由於只支援簡單的圖便歷，一般通過採取按“邊”切分的方法來進行分佈儲存，因此可擴充套件性較好。

2. 圖資料OLAP處理

對圖資料進行復雜分析，就需要分散式的批處理框架。例如大規模的PageRank計算。在這個領域出現並行圖計算框架常見有Apache Giraph、Apache Hama、GraphLab、Pregel、GraphX等。

Pregel是Google根據BSP平行計算模型開發的圖計算引擎，目前該系統沒有開源。GraphX是Spark專案組基於Spark框架開發的圖計算引擎;而GraphLab則是直接在MPI框架基礎上開發的專用圖計算引擎。

下面簡單介紹幾種主流並行圖計算引擎。

3　並行圖計算引擎

1. 基於BSP模型的Pregel引擎

簡介

Pregel是Google公司開發的並行圖計算引擎，主要用於實現各種機器學習演算法。Pregel的輸入是一個有向圖，該有向圖每一個頂點都有一個相應由String描述的頂點識別符號。每一個頂點都有一個與之對應可修改使用者自定義值。每一條有向邊都和其源頂點關聯，並且也擁有一個可修改的使用者自定義值，並同時還記錄了其目標頂點的識別符號。

Pregel可以採用多種檔案格式進行圖的儲存，比如可以用text檔案、關係資料庫、Bigtable。為了避免規定死一種特定檔案格式，Pregel將從輸入中解析出圖結構的任務從圖的計算過程中進行了分離。計算結果可以以任何一種格式輸出並根據應用程式選擇最適合的儲存方式。Pregel library本身提供了很多常用檔案格式的readers和writers，但是使用者可以通過繼承Reader和Writer類來定義他們自己的讀寫方式。

編寫一個Pregel程式需要繼承Pregel中已預定義好的一個基類——Vertex類。

使用者覆寫Vertex類的虛擬函式Compute()，該函式會在每一個超級步中對每一個頂點進行呼叫。預定義的Vertex類方法允許Compute()方法查詢當前頂點及其邊的資訊，以及傳送訊息到其他的頂點。Compute()方法可以通過呼叫GetValue()方法來得到當前頂點的值，或者通過呼叫MutableValue()方法來修改當前頂點的值。同時還可以通過由出邊的迭代器提供的方法來檢視修改出邊對應的值。

基於BSP的執行模型

讀取輸入初始化該圖，當圖被初始化好後，執行一系列的超級步直到整個計算結束，這些超級步之間通過一些全域性的同步點分隔，輸出結果結束計算。

在每個超級步中，頂點的計算都是並行的，每個頂點執行相同的用於表達給定演算法邏輯的使用者自定義函式。每個頂點可以修改其自身及其出邊的狀態，接收前一個超級步(S-1)中傳送給它的訊息，併發送訊息給其他頂點(這些訊息將會在下一個超級步中被接收)，甚至是修改整個圖的拓撲結構。邊，在這種計算模式中並不是核心物件，沒有相應的計算執行在其上。

演算法是否能夠結束取決於是否所有的頂點都已經“vote”標識其自身已經達到“halt”狀態了。在第0個超級步，所有頂點都處於active狀態，所有的active頂點都會參與所有對應superstep中的計算。頂點通過將其自身的status設定成“halt”來表示它已經不再active。這就表示該頂點沒有進一步的計算需要執行，除非被再次被外部觸發，而Pregel框架將不會在接下來的superstep中執行該頂點，除非該頂點收到其它頂點傳送的訊息。如果頂點接收到訊息被喚醒進入active狀態，那麼在隨後的計算中該頂點必須顯式的deactive。整個計算在所有頂點都達到“inactive”狀態，並且沒有message在傳送的時候宣告結束。

2) graphLab

(1) 簡介

GraphLab一套基於c++的開源圖計算庫，提供了在共享記憶體情況下的非同步、動態和並行圖計算的高層抽象API。該庫採用MPI和TCPIP來實現程序間通訊，採用Pthreads實現程序內的多執行緒併發計算，支援從HDFS和標準檔案系統中讀取資料。GraphLab定義了多種用於儲存圖的檔案格式，包括"tsv",“snap”, “adj” “bintsv4”。

(2) 與Pregel的不同

GraphLab不是採用BSP的嚴格執行模型，GraphLab的基於BSP的Pregel的典型的改進是在更好的“非同步迭代計算”和“動態計算”。因此該框架計算效率比Pregel更好。

非同步計算：很多重要的MLDM演算法迭代更新一大批引數，圖結構導致引數更新依賴其它的引數。同步系統會以上一次更新的引數基礎上一次更新所有的引數(BSP模型中超級步之間市全域性路障同步)，而非同步系統則以最近的引數作為輸入來更新引數。非同步迭代更新可以極大加 快MLDM演算法的計算速度。因為如果採用同步計算，則存在木桶效應，整體速度取決於最慢的那臺機器。在大規模雲端計算環境下，負載不均衡、網路不均衡、硬體差異和多租戶等會導致不同 機器之間的速度存在差異。另外由於圖分割不均衡，以及計算複雜性等導致各個節點計算量也不均衡。

動態計算：很多MLDM演算法的迭代計算收斂都不對稱，例如在引數優化是，通常很多引數在很少幾次迭代中就會快速收斂，而剩下少數引數則即使經過多次迭代也會收斂很慢。因此如果我們等同更新所有的引數，則會浪費大量的時間在重複計算那些已近收斂的引數上。最近的一些計算框架部分支援動態計算，例如Pregel可以通過讓某些節點跳過一些超級步來部分支援動態計算。

(3) GraphLab的計算模型

graphLab包括三個部分：資料圖、更新函式、同步操作。資料圖表達使用者可修改 的程式狀態，儲存可變的使用者自定義資料和計算之間依賴。更新函式通過一個scope的資料變換來表達使用者對資料圖的計算和操作。同步操作併發維護全域性彙總。

一個點的scope代表儲存在這個點上的資料 和所有與這個點相鄰的點和邊上的所有資料。update f (v ,s(v) ) —> (s(v) , 邊集合) 。經過一個更新函式後，新計算出 的s(v) 會被寫回圖，並返回一個定點集合，針對該集合的每個點再執行 f(u ,s(u))

為了更高效的並行執行，GraphLab容許GraphLab框架動態的選擇執行順序，即RemoveNext(T)的返回值。因為很多MLDM演算法需要執行優先級別，因此也可以指定點的優先順序，這樣GraphLab會綜合考慮優先順序以及網路情況來排程。

(3) GraphLab的平行計算

根據領域知識，將圖分割為K份，K值遠大於機器數量。每個分割槽被稱為atom, 以一個檔案形式儲存類似HDFS的分散式檔案系統上。Atom中儲存的是增加點和變的操作記錄，可以通過回放的方式來重構圖。

採取把點著色的方法，先保證每個點和相鄰點之間的顏色都不相同。通過一個顏色一個顏色的併發執行，來實現邊一致性。把這種成為顏色步，與BSP的超步模型相對應。該引擎保證在執行下一個顏色步之前，所有的修改都被傳遞，實現顏色步之間的路障同步。

由Master根據atom索引來計算atom的位置，並負責機器與atom之間的分配關係。然後每個機器讀取atom檔案來載入圖。每個機器上有一個排程器負責排程屬於自己的子圖的點的計算。排程器負責把每個需要執行update 函式之前所需要的資料和鎖準備好後，放入一個流水處理佇列中，再由一個worker執行緒池來執行，通過一個分散式演算法來確定所有機器上的排程器中的T為空，也就是整個計算結束。

3)graphX

基於SPARK圖形計算引擎，GraphX提供的API可以很方便的表達各種針對的轉換、過濾和查詢操作，但是GraphX不能直接實現迭代並行圖計算演算法，但是可以基於這些API用來實現各種並行圖計算演算法。在GraphX論文中描述了利用GraphX來實現Pregel、PowerGraph的方法。

GraphX的優勢是可以很方便的與shark等進行整合，例如直接對shark查詢後的結果進行圖計算。

4. 總結

(1)上述計算引擎都可以以靈活方式來儲存圖，基本上都可以以檔案方式來儲存圖資料，實現計算引擎與儲存分離。

(2)圖計算引擎都根據MDML演算法特點採用專用計算模型，以提高效率。

(3) 所有圖計算引擎在計算時，基本都是需要把資料都載入到記憶體中。(來自preglel論文：當前整個的計算狀態都是駐留在記憶體中的。我們已經開始將一些資料存到本地磁碟，同時我們會繼續在這個方向進行深入的研究，希望可以支援規模太大以至於記憶體無法完全存下的情況。