一文讀懂大數(shù)據(jù)計算框架與平臺

來源：THU數(shù)據(jù)派 時間：2017-05-02 16:48:57 作者：王小鑒

　　1.前言

　　計算機的基本工作就是處理數(shù)據(jù)，包括磁盤文件中的數(shù)據(jù)，通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流或數(shù)據(jù)包，數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)等。隨著互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等技術(shù)得到越來越廣泛的應(yīng)用，數(shù)據(jù)規(guī)模不斷增加，TB、PB量級成為常態(tài)，對數(shù)據(jù)的處理已無法由單臺計算機完成，而只能由多臺機器共同承擔計算任務(wù)。而在分布式環(huán)境中進行大數(shù)據(jù)處理，除了與存儲系統(tǒng)打交道外，還涉及計算任務(wù)的分工，計算負荷的分配，計算機之間的數(shù)據(jù)遷移等工作，并且要考慮計算機或網(wǎng)絡(luò)發(fā)生故障時的數(shù)據(jù)安全，情況要復雜得多。

　　舉一個簡單的例子，假設(shè)我們要從銷售記錄中統(tǒng)計各種商品銷售額。在單機環(huán)境中，我們只需把銷售記錄掃描一遍，對各商品的銷售額進行累加即可。如果銷售記錄存放在關(guān)系數(shù)據(jù)庫中，則更省事，執(zhí)行一個SQL語句就可以了。現(xiàn)在假定銷售記錄實在太多，需要設(shè)計出由多臺計算機來統(tǒng)計銷售額的方案。為保證計算的正確、可靠、高效及方便，這個方案需要考慮下列問題：

　　如何為每臺機器分配任務(wù)，是先按商品種類對銷售記錄分組，不同機器處理不同商品種類的銷售記錄，還是隨機向各臺機器分發(fā)一部分銷售記錄進行統(tǒng)計，最后把各臺機器的統(tǒng)計結(jié)果按商品種類合并？

　　上述兩種方式都涉及數(shù)據(jù)的排序問題，應(yīng)選擇哪種排序算法？應(yīng)該在哪臺機器上執(zhí)行排序過程？

　　如何定義每臺機器處理的數(shù)據(jù)從哪里來，處理結(jié)果到哪里去？數(shù)據(jù)是主動發(fā)送，還是接收方申請時才發(fā)送？如果是主動發(fā)送，接收方處理不過來怎么辦？如果是申請時才發(fā)送，那發(fā)送方應(yīng)該保存數(shù)據(jù)多久？

　　會不會任務(wù)分配不均，有的機器很快就處理完了，有的機器一直忙著？甚至，閑著的機器需要等忙著的機器處理完后才能開始執(zhí)行？

　　如果增加一臺機器，它能不能減輕其他機器的負荷，從而縮短任務(wù)執(zhí)行時間？

　　如果一臺機器掛了，它沒有完成的任務(wù)該交給誰？會不會遺漏統(tǒng)計或重復統(tǒng)計？

　　統(tǒng)計過程中，機器之間如何協(xié)調(diào)，是否需要專門的一臺機器指揮調(diào)度其他機器？如果這臺機器掛了呢？

　?。蛇x）如果銷售記錄在源源不斷地增加，統(tǒng)計還沒執(zhí)行完新記錄又來了，如何保證統(tǒng)計結(jié)果的準確性？能不能保證結(jié)果是實時更新的？再次統(tǒng)計時能不能避免大量重復計算？

　?。蛇x）能不能讓用戶執(zhí)行一句SQL就可以得到結(jié)果？

　　上述問題中，除了第1個外，其余的都與具體任務(wù)無關(guān)，在其他分布式計算的場合也會遇到，而且解決起來都相當棘手。即使第1個問題中的分組、統(tǒng)計，在很多數(shù)據(jù)處理場合也會涉及，只是具體方式不同。如果能把這些問題的解決方案封裝到一個計算框架中，則可大大簡化這類應(yīng)用程序的開發(fā)。

　　2004年前后，Google先后發(fā)表三篇論文分別介紹分布式文件系統(tǒng)GFS、并行計算模型MapReduce、非關(guān)系數(shù)據(jù)存儲系統(tǒng)BigTable，第一次提出了針對大數(shù)據(jù)分布式處理的可重用方案。在Google論文的啟發(fā)下，Yahoo的工程師DougCutting和MikeCafarella開發(fā)了Hadoop。在借鑒和改進Hadoop的基礎(chǔ)上，又先后誕生了數(shù)十種應(yīng)用于分布式環(huán)境的大數(shù)據(jù)計算框架。本文在參考業(yè)界慣例的基礎(chǔ)上，對這些框架按下列標準分類：

　　如果不涉及上面提出的第8、9兩個問題，則屬于批處理框架。批處理框架重點關(guān)心數(shù)據(jù)處理的吞吐量，又可分為非迭代式和迭代式兩類，迭代式包括DAG（有向無環(huán)圖）、圖計算等模型。

　　若針對第8個問題提出來應(yīng)對方案，則分兩種情況：如果重點關(guān)心處理的實時性，則屬于流計算框架；如果側(cè)重于避免重復計算，則屬于增量計算框架。

　　如果重點關(guān)注的是第9個問題，則屬于交互式分析框架。

　　本文下面分別討論批處理、流計算、交互式分析三種類別的框架，然后簡要介紹大數(shù)據(jù)計算框架的一些發(fā)展趨勢。文章最后介紹這一領(lǐng)域的學習資料。

　　圖1.大數(shù)據(jù)計算框架全景圖

　　2.批處理框架

　　2.1.Hadoop

　　Hadoop最初主要包含分布式文件系統(tǒng)HDFS和計算框架MapReduce兩部分，是從Nutch中獨立出來的項目。在2.0版本中，又把資源管理和任務(wù)調(diào)度功能從MapReduce中剝離形成YARN，使其他框架也可以像MapReduce那樣運行在Hadoop之上。與之前的分布式計算框架相比，Hadoop隱藏了很多繁瑣的細節(jié)，如容錯、負載均衡等，更便于使用。

　　Hadoop也具有很強的橫向擴展能力，可以很容易地把新計算機接入到集群中參與計算。在開源社區(qū)的支持下，Hadoop不斷發(fā)展完善，并集成了眾多優(yōu)秀的產(chǎn)品如非關(guān)系數(shù)據(jù)庫HBase、數(shù)據(jù)倉庫Hive、數(shù)據(jù)處理工具Sqoop、機器學習算法庫Mahout、一致性服務(wù)軟件ZooKeeper、管理工具Ambari等，形成了相對完整的生態(tài)圈和分布式計算事實上的標準。

　　圖2.Hadoop生態(tài)圈（刪減版）

　　MapReduce可以理解為把一堆雜亂無章的數(shù)據(jù)按照某種特征歸并起來，然后處理并得到最后的結(jié)果?；咎幚聿襟E如下：

　　把輸入文件按照一定的標準分片，每個分片對應(yīng)一個map任務(wù)。一般情況下，MapReduce和HDFS運行在同一組計算機上，也就是說，每臺計算機同時承擔存儲和計算任務(wù)，因此分片通常不涉及計算機之間的數(shù)據(jù)復制。

　　按照一定的規(guī)則把分片中的內(nèi)容解析成鍵值對。通常選擇一種預定義的規(guī)則即可。

　　執(zhí)行map任務(wù)，處理每個鍵值對，輸出零個或多個鍵值對。

　　MapReduce獲取應(yīng)用程序定義的分組方式，并按分組對map任務(wù)輸出的鍵值對排序。默認每個鍵名一組。

　　待所有節(jié)點都執(zhí)行完上述步驟后，MapReduce啟動Reduce任務(wù)。每個分組對應(yīng)一個Reduce任務(wù)。

　　執(zhí)行reduce任務(wù)的進程通過網(wǎng)絡(luò)獲取指定組的所有鍵值對。

　　把鍵名相同的值合并為列表。

　　執(zhí)行reduce任務(wù)，處理每個鍵對應(yīng)的列表，輸出結(jié)果。

　　圖3.MapReduce處理過程

　　在上面的步驟中，應(yīng)用程序主要負責設(shè)計map和reduce任務(wù)，其他工作均由框架負責。在定義map任務(wù)輸出數(shù)據(jù)的方式時，鍵的選擇至關(guān)重要，除了影響結(jié)果的正確性外，也決定數(shù)據(jù)如何分組、排序、傳輸，以及執(zhí)行reduce任務(wù)的計算機如何分工。前面提到的商品銷售統(tǒng)計的例子，可選擇商品種類為鍵。MapReduce執(zhí)行商品銷售統(tǒng)計的過程大致如下：

　　把銷售記錄分片，分配給多臺機器。

　　每條銷售記錄被解析成鍵值對，其中值為銷售記錄的內(nèi)容，鍵可忽略。

　　執(zhí)行map任務(wù)，每條銷售記錄被轉(zhuǎn)換為新的鍵值對，其中鍵為商品種類，值為該條記錄中商品的銷售額。

　　MapReduce把map任務(wù)生成的數(shù)據(jù)按商品種類排序。

　　待所有節(jié)點都完成排序后，MapReduce啟動reduce任務(wù)。每個商品種類對應(yīng)一個reduce任務(wù)。

　　執(zhí)行reduce任務(wù)的進程通過網(wǎng)絡(luò)獲取指定商品種類的各次銷售額。

　　MapReduce把同一種商品下的各次銷售額合并到列表中。

　　執(zhí)行reduce任務(wù)，累加各次銷售額，得到該種商品的總銷售額。

　　上面的過程還有優(yōu)化的空間。在傳輸各種商品每次的銷售額數(shù)據(jù)前，可先在map端對各種商品的銷售額進行小計，由此可大大減少網(wǎng)絡(luò)傳輸?shù)呢摵伞apReduce通過一個可選的combine任務(wù)支持該類型的優(yōu)化。

　　2.2.DAG模型

　　現(xiàn)在假設(shè)我們的目標更進一步，希望知道銷售得最好的前10種商品。我們可以分兩個環(huán)節(jié)來計算：

　　統(tǒng)計各種商品的銷售額。通過MapReduce實現(xiàn)，這在前面已經(jīng)討論過。

　　對商品種類按銷售額排名?？梢酝ㄟ^一個排序過程完成。假定商品種類非常多，需要通過多臺計算機來加快計算速度的話，我們可以用另一個MapReduce過程來實現(xiàn)，其基本思路是把map和reduce分別當作小組賽和決賽，先計算各分片的前10名，匯總后再計算總排行榜的前10名。

　　從上面的例子可以看出，通過多個MapReduce的組合，可以表達復雜的計算問題。不過，組合過程需要人工設(shè)計，比較麻煩。另外，每個階段都需要所有的計算機同步，影響了執(zhí)行效率。

　　為克服上述問題，業(yè)界提出了DAG（有向無環(huán)圖）計算模型，其核心思想是把任務(wù)在內(nèi)部分解為若干存在先后順序的子任務(wù)，由此可更靈活地表達各種復雜的依賴關(guān)系。MicrosoftDryad、GoogleFlumeJava、ApacheTez是最早出現(xiàn)的DAG模型。Dryad定義了串接、全連接、融合等若干簡單的DAG模型，通過組合這些簡單結(jié)構(gòu)來描述復雜的任務(wù)，F(xiàn)lumeJava、Tez則通過組合若干MapReduce形成DAG任務(wù)。

　　圖4.MapReduce（左）與Tez（右）

　　執(zhí)行復雜任務(wù)時對比

　　MapReduce的另一個不足之處是使用磁盤存儲中間結(jié)果，嚴重影響了系統(tǒng)的性能，這在機器學習等需要迭代計算的場合更為明顯。加州大學伯克利分校AMP實驗室開發(fā)的Spark克服了上述問題。Spark對早期的DAG模型作了改進，提出了基于內(nèi)存的分布式存儲抽象模型RDD（ResilientDistributedDatasets，可恢復分布式數(shù)據(jù)集），把中間數(shù)據(jù)有選擇地加載并駐留到內(nèi)存中，減少磁盤IO開銷。與Hadoop相比，Spark基于內(nèi)存的運算要快100倍以上，基于磁盤的運算也要快10倍以上。

　　圖5.MapReduce與Spark中間結(jié)果

　　保存方式對比

　　Spark為RDD提供了豐富的操作方法，其中map、filter、flatMap、sample、groupByKey、reduceByKey、union、join、cogroup、mapValues、sort、partionBy用于執(zhí)行數(shù)據(jù)轉(zhuǎn)換，生成新的RDD，而count、collect、reduce、lookup、save用于收集或輸出計算結(jié)果。如前面統(tǒng)計商品銷售額的例子，在Spark中只需要調(diào)用map和reduceByKey兩個轉(zhuǎn)換操作就可以實現(xiàn)，整個程序包括加載銷售記錄和保存統(tǒng)計結(jié)果在內(nèi)也只需要寥寥幾行代碼，并且支持Java、Scala、Python、R等多種開發(fā)語言，比MapReduce編程要方便得多。下圖說明reduceByKey的內(nèi)部實現(xiàn)。

　　圖6.RDDreduceByKey內(nèi)部實現(xiàn)

　　RDD由于把數(shù)據(jù)存放在內(nèi)存中而不是磁盤上，因此需要比Hadoop更多地考慮容錯問題。分布式數(shù)據(jù)集的容錯有兩種方式：數(shù)據(jù)檢查點和記錄數(shù)據(jù)的更新。處理海量數(shù)據(jù)時，數(shù)據(jù)檢查點操作成本很高，因此Spark默認選擇記錄更新的方式。不過如果更新粒度太細太多，記錄更新成本也不低。因此，RDD只支持粗粒度轉(zhuǎn)換，即只記錄單個塊上執(zhí)行的單個操作，然后將創(chuàng)建RDD的一系列變換序列記錄下來，類似于數(shù)據(jù)庫中的日志。

　　當RDD的部分分區(qū)數(shù)據(jù)丟失時，Spark根據(jù)之前記錄的演變過程重新運算，恢復丟失的數(shù)據(jù)分區(qū)。Spark生態(tài)圈的另一項目Alluxio（原名Tachyon）也采用類似的思路，使數(shù)據(jù)寫入速度比HDFS有數(shù)量級的提升。

　　下面總結(jié)Spark對MapReduce的改進：

　　MapReduce抽象層次低，需要手工編寫代碼完成；Spark基于RDD抽象，使數(shù)據(jù)處理邏輯的代碼非常簡短。

　　MapReduce只提供了map和reduce兩個操作，表達力欠缺；Spark提供了很多轉(zhuǎn)換和動作，很多關(guān)系數(shù)據(jù)庫中常見的操作如JOIN、GROUPBY已經(jīng)在RDD中實現(xiàn)。

　　MapReduce中，只有map和reduce兩個階段，復雜的計算需要大量的組合，并且由開發(fā)者自己定義組合方式；Spark中，RDD可以連續(xù)執(zhí)行多個轉(zhuǎn)換操作，如果這些操作對應(yīng)的RDD分區(qū)不變的話，還可以放在同一個任務(wù)中執(zhí)行。

　　MapReduce處理邏輯隱藏在代碼中，不直觀；Spark代碼不包含操作細節(jié)，邏輯更清晰。

　　MapReduce中間結(jié)果放在HDFS中；Spark中間結(jié)果放在內(nèi)存中，內(nèi)存放不下時才寫入本地磁盤而不是HDFS，這顯著提高了性能，特別是在迭代式數(shù)據(jù)處理的場合。

　　MapReduce中，reduce任務(wù)需要等待所有map任務(wù)完成后才可以開始；在Spark中，分區(qū)相同的轉(zhuǎn)換構(gòu)成流水線放到同一個任務(wù)中運行。

　　3.流計算框架

　　3.1.流計算概述

　　在大數(shù)據(jù)時代，數(shù)據(jù)通常都是持續(xù)不斷動態(tài)產(chǎn)生的。在很多場合，數(shù)據(jù)需要在非常短的時間內(nèi)得到處理，并且還要考慮容錯、擁塞控制等問題，避免數(shù)據(jù)遺漏或重復計算。流計算框架則是針對這一類問題的解決方案。流計算框架一般采用DAG（有向無環(huán)圖）模型。圖中的節(jié)點分為兩類：一類是數(shù)據(jù)的輸入節(jié)點，負責與外界交互而向系統(tǒng)提供數(shù)據(jù)；另一類是數(shù)據(jù)的計算節(jié)點，負責完成某種處理功能如過濾、累加、合并等。從外部系統(tǒng)不斷傳入的實時數(shù)據(jù)則流經(jīng)這些節(jié)點，把它們串接起來。如果把數(shù)據(jù)流比作水的話，輸入節(jié)點好比是噴頭，源源不斷地出水，計算節(jié)點則相當于水管的轉(zhuǎn)接口。如下圖所示。

　　圖7.流計算DAG模型示意圖

　　為提高并發(fā)性，每一個計算節(jié)點對應(yīng)的數(shù)據(jù)處理功能被分配到多個任務(wù)（相同或不同計算機上的線程）。在設(shè)計DAG時，需要考慮如何把待處理的數(shù)據(jù)分發(fā)到下游計算節(jié)點對應(yīng)的各個任務(wù)，這在實時計算中稱為分組（Grouping）。最簡單的方案是為每個任務(wù)復制一份，不過這樣效率很低，更好的方式是每個任務(wù)處理數(shù)據(jù)的不同部分。隨機分組能達到負載均衡的效果，應(yīng)優(yōu)先考慮。不過在執(zhí)行累加、數(shù)據(jù)關(guān)聯(lián)等操作時，需要保證同一屬性的數(shù)據(jù)被固定分發(fā)到對應(yīng)的任務(wù)，這時應(yīng)采用定向分組。在某些情況下，還需要自定義分組方案。

　　圖8.流計算分組

　　由于應(yīng)用場合的廣泛性，目前市面上已經(jīng)有不少流計算平臺，包括GoogleMillWheel、TwitterHeron和Apache項目Storm、Samza、S4、Flink、Apex、Gearpump。

　　3.2.Storm及Trident

　　在流計算框架中，目前人氣最高，應(yīng)用最廣泛的要數(shù)Storm。這是由于Storm具有簡單的編程模型，且支持Java、Ruby、Python等多種開發(fā)語言。Storm也具有良好的性能，在多節(jié)點集群上每秒可以處理上百萬條消息。Storm在容錯方面也設(shè)計得很優(yōu)雅。下面介紹Storm確保消息可靠性的思路。

　　在DAG模型中，確保消息可靠的難點在于，原始數(shù)據(jù)被當前的計算節(jié)點成功處理后，還不能被丟棄，因為它生成的數(shù)據(jù)仍然可能在后續(xù)的計算節(jié)點上處理失敗，需要由該消息重新生成。而如果要對消息在各個計算節(jié)點的處理情況都作跟蹤記錄的話，則會消耗大量資源。

　　Storm的解決思路，是為每條消息分派一個ID作為唯一性標識，并在消息中包含原始輸入消息的ID。同時用一個響應(yīng)中心（Acker）維護每條原始輸入消息的狀態(tài)，狀態(tài)的初值為該原始輸入消息的ID。每個計算節(jié)點成功執(zhí)行后，則把輸入和輸出消息的ID進行異或，再異或?qū)?yīng)的原始輸入消息的狀態(tài)。由于每條消息在生成和處理時分別被異或一次，則成功執(zhí)行后所有消息均被異或兩次，對應(yīng)的原始輸入消息的狀態(tài)為0。因此當狀態(tài)為0后可安全清除原始輸入消息的內(nèi)容，而如果超過指定時間間隔后狀態(tài)仍不為0，則認為處理該消息的某個環(huán)節(jié)出了問題，需要重新執(zhí)行。

　　圖9.Storm保證消息可靠性過程示意圖

　　Storm還實現(xiàn)了更高層次的抽象框架Trident。Trident以微批處理的方式處理數(shù)據(jù)流，比如每次處理100條記錄。Trident提供了過濾、分組、連接、窗口操作、聚合、狀態(tài)管理等操作，支持跨批次進行聚合處理，并對執(zhí)行過程進行優(yōu)化，包括多個操作的合并、數(shù)據(jù)傳輸前的本地聚合等。以微批處理方式處理數(shù)據(jù)流的框架還有SparkStreaming。

　　　　圖10.實時流處理與微批處理比較

　　下面是Storm、Trident與另外幾種流計算框架的對比：

　　4.交互式分析框架

　　4.1.概述

　　在解決了大數(shù)據(jù)的可靠存儲和高效計算后，如何為數(shù)據(jù)分析人員提供便利日益受到關(guān)注，而最便利的分析方式莫過于交互式查詢。這幾年交互式分析技術(shù)發(fā)展迅速，目前這一領(lǐng)域知名的平臺有十余個，包括Google開發(fā)的Dremel和PowerDrill，F(xiàn)acebook開發(fā)的Presto，Hadoop服務(wù)商Cloudera和HortonWorks分別開發(fā)的Impala和Stinger，以及Apache項目Hive、Drill、Tajo、Kylin、MRQL等。

　　一些批處理和流計算平臺如Spark和Flink也分別內(nèi)置了交互式分析框架。由于SQL已被業(yè)界廣泛接受，目前的交互式分析框架都支持用類似SQL的語言進行查詢。早期的交互式分析平臺建立在Hadoop的基礎(chǔ)上，被稱作SQL-on-Hadoop。后來的分析平臺改用Spark、Storm等引擎，不過SQL-on-Hadoop的稱呼還是沿用了下來。SQL-on-Hadoop也指為分布式數(shù)據(jù)存儲提供SQL查詢功能。

　　4.2.Hive

　　ApacheHive是最早出現(xiàn)的架構(gòu)在Hadoop基礎(chǔ)之上的大規(guī)模數(shù)據(jù)倉庫，由Facebook設(shè)計并開源。Hive的基本思想是，通過定義模式信息，把HDFS中的文件組織成類似傳統(tǒng)數(shù)據(jù)庫的存儲系統(tǒng)。Hive保持著Hadoop所提供的可擴展性和靈活性。Hive支持熟悉的關(guān)系數(shù)據(jù)庫概念，比如表、列和分區(qū)，包含對非結(jié)構(gòu)化數(shù)據(jù)一定程度的SQL支持。它支持所有主要的原語類型（如整數(shù)、浮點數(shù)、字符串）和復雜類型（如字典、列表、結(jié)構(gòu)）。它還支持使用類似SQL的聲明性語言HiveQueryLanguage(HiveQL)表達的查詢，任何熟悉SQL的人都很容易理解它。HiveQL被編譯為MapReduce過程執(zhí)行。下圖說明如何通過MapReduce實現(xiàn)JOIN和GROUPBY。

　　(1)實現(xiàn)JOIN

　　(2)實現(xiàn)GROUPBY

　　圖11.部分HiveQL操作的實現(xiàn)方式

　　Hive與傳統(tǒng)關(guān)系數(shù)據(jù)庫對比如下：

　　Hive的主要弱點是由于建立在MapReduce的基礎(chǔ)上，性能受到限制。很多交互式分析平臺基于對Hive的改進和擴展，包括Stinger、Presto、Kylin等。其中Kylin是中國團隊提交到Apache上的項目，其與眾不同的地方是提供多維分析（OLAP）能力。Kylin對多維分析可能用到的度量進行預計算，供查詢時直接訪問，由此提供快速查詢和高并發(fā)能力。Kylin在eBay、百度、京東、網(wǎng)易、美團均有應(yīng)用。

　　4.3.SQL引擎Calcite

　　對于交互式分析，SQL查詢引擎的優(yōu)劣對性能的影響舉足輕重。Spark開發(fā)了自己的查詢引擎Catalyst，而包括Hive、Drill、Kylin、Flink在內(nèi)的很多交互式分析平臺及數(shù)據(jù)倉庫使用Calcite（原名optiq）作為SQL引擎。Calcite是一個Apache孵化項目，其創(chuàng)建者JulianHyde曾是Oracle數(shù)據(jù)庫SQL引擎的主要開發(fā)者。Calcite具有下列幾個技術(shù)特點：

　　支持標準SQL語言。

　　支持OLAP。

　　支持對流數(shù)據(jù)的查詢。

　　獨立于編程語言和數(shù)據(jù)源，可以支持不同的前端和后端。

　　支持關(guān)系代數(shù)、可定制的邏輯規(guī)劃規(guī)則和基于成本模型優(yōu)化的查詢引擎。

　　支持物化視圖（materializedview）的管理。

　　由于分布式場景遠比傳統(tǒng)的數(shù)據(jù)存儲環(huán)境更復雜，Calcite和Catalyst都還處于向Oracle、MySQL等經(jīng)典關(guān)系數(shù)據(jù)庫引擎學習的階段，在性能優(yōu)化的道路上還有很長的路要走。

　　5.其他類型的框架

　　除了上面介紹的幾種類型的框架外，還有一些目前還不太熱門但具有重要潛力的框架類型。圖計算是DAG之外的另一種迭代式計算模型，它以圖論為基礎(chǔ)對現(xiàn)實世界建模和計算，擅長表達數(shù)據(jù)之間的關(guān)聯(lián)性，適用于PageRank計算、社交網(wǎng)絡(luò)分析、推薦系統(tǒng)及機器學習。這一類框架有GooglePregel、ApacheGiraph、ApacheHama、PowerGraph、，其中PowerGraph是這一領(lǐng)域目前最杰出的代表。很多圖數(shù)據(jù)庫也內(nèi)置圖計算框架。

　　另一類是增量計算框架，探討如何只對部分新增數(shù)據(jù)進行計算來極大提升計算過程的效率，可應(yīng)用到數(shù)據(jù)增量或周期性更新的場合。這一類框架包括GooglePercolator、MicrosoftKineograph、阿里Galaxy等。

　　另外還有像ApacheIgnite、ApacheGeode（GemFire的開源版本）這樣的高性能事務(wù)處理框架。

　　6.總結(jié)與展望

　　從Hadoop橫空出世到現(xiàn)在10余年的時間中，大數(shù)據(jù)分布式計算技術(shù)得到了迅猛發(fā)展。不過由于歷史尚短，這方面的技術(shù)遠未成熟。各種框架都還在不斷改進，并相互競爭。

　　性能優(yōu)化毫無疑問是大數(shù)據(jù)計算框架改進的重點方向之一。而性能的提高很大程度上取決于內(nèi)存的有效利用。這包括前面提到的內(nèi)存計算，現(xiàn)已在各種類型的框架中廣泛采用。內(nèi)存資源的分配管理對性能也有重要影響，JVM垃圾回收在給開發(fā)人員帶來便利的同時，也制約了內(nèi)存的有效利用。另外，Java的對象創(chuàng)建及序列化也比較浪費資源。在內(nèi)存優(yōu)化方面做足功夫的代表是Flink。出于性能方面的考慮，F(xiàn)link很多組件自行管理內(nèi)存，無需依賴JVM垃圾回收機制。Flink還用到開辟內(nèi)存池、用二進制數(shù)據(jù)代替對象、量身定制序列化、定制緩存友好的算法等優(yōu)化手段。Flink還在任務(wù)的執(zhí)行方面進行優(yōu)化，包括多階段并行執(zhí)行和增量迭代。

　　擁抱機器學習和人工智能也是大數(shù)據(jù)計算的潮流之一。Spark和Flink分別推出機器學習庫SparkML和FlinkML。更多的平臺在第三方大數(shù)據(jù)計算框架上提供機器學習，如Mahout、Oryx及一干Apache孵化項目SystemML、HiveMall、PredictionIO、SAMOA、MADLib。這些機器學習平臺一般都同時支持多個計算框架，如Mahout同時以Spark、Flink、H2O為引擎，SAMOA則使用S4、Storm、Samza。在深度學習掀起熱潮后，又有社區(qū)探索把深度學習框架與現(xiàn)有分布式計算框架結(jié)合起來，這樣的項目有SparkNet、CaffeonSpark、TensorFrames等。

　　在同一平臺上支持多種框架也是發(fā)展趨勢之一，尤其對于那些開發(fā)實力較為雄厚的社區(qū)。Spark以批處理模型為核心，實現(xiàn)了交互式分析框架SparkSQL、流計算框架SparkStreaming（及正在實現(xiàn)的StructuredStreaming）、圖計算框架GraphX、機器學習庫SparkML。而Flink在提供低延遲的流計算的同時，批處理、關(guān)系計算、圖計算、機器學習，一個也沒落下，目標直奔大數(shù)據(jù)通用計算平臺。Google的BEAM（意為Batch+strEAM）則試圖把Spark、Flink、Apex這樣的計算框架納入自己制定的標準之下，頗有號令江湖之意。

　　圖12.BEAM的統(tǒng)一模型

　　7.學習資料

　　最后介紹一下大數(shù)據(jù)計算方面的學習資料。入門前的了解、知識面的拓展及知識的零散積累靠長期訪問相關(guān)的網(wǎng)站、論壇、微信訂閱號，問題解答則靠對搜索引擎的熟練駕馭。需要指出的是，網(wǎng)上的內(nèi)容良萎不齊，很多資料是過時的，以訛傳訛也是常有的事，要注意鑒別。

　　論壇首推知乎、Quora、StackOverflow，運氣好的話開發(fā)者親自給你解答。其他值得關(guān)注的網(wǎng)站或論壇包括煉數(shù)成金、人大經(jīng)濟論壇、CSDN、博客園、云棲社區(qū)、360大數(shù)據(jù)、推酷、伯樂在線、小象學院等。微信訂閱號中，InfoQ是最權(quán)威的，其他還有THU數(shù)據(jù)派、大數(shù)據(jù)雜談、CSDN大數(shù)據(jù)、數(shù)據(jù)猿、Hadoop技術(shù)博文等，各人根據(jù)偏好取舍。

　　若要進行系統(tǒng)的學習，則首先應(yīng)參考官方網(wǎng)站文檔。不少大數(shù)據(jù)平臺的官方文檔內(nèi)容都比較詳實，勝過多數(shù)教材。另外，官方文檔與產(chǎn)品通常同步更新，這個優(yōu)勢是其他資料無法做到的。不過要說可讀性，書籍或視頻教程要強得多。視頻資料可以從上文提到的部分網(wǎng)站論壇下載。

　　書籍方面，國外O'Reilly、Manning兩家出版社在大數(shù)據(jù)領(lǐng)域出版了不少優(yōu)秀書籍，特別是Manning的InAction系列和O'Reilly的DefinitiveGuide系列。前者側(cè)重提高動手能力，后者則知識比較全面。InAction和DefinitiveGuide系列的書籍很多已翻譯為中文，一般分別譯為xxx實戰(zhàn)、xxx權(quán)威指南。另外一家出版社Packt也值得關(guān)注。Packt的書比較薄，適合入門。至于中文原創(chuàng)書籍，推薦張俊林的《大數(shù)據(jù)日知錄》，該書是對大數(shù)據(jù)存儲和處理技術(shù)的全面梳理，系統(tǒng)性強。其他書籍不逐一點評，若想購買或閱讀可參考豆瓣對該書的評分。

　　圖13.部分推薦書籍

　　對希望對大數(shù)據(jù)框架內(nèi)部機制有深入的理解的讀者，建議首先檢索相關(guān)論文來閱讀。

　　Google的那幾篇論文這里就不一一列出了，網(wǎng)上很容易搜到。其他推薦的論文如下：

責任編輯：陳近梅