• 概念
  • 框架與引擎
  • 批處理框架
  • 流處理框架
  • 混合處理框架
• MapReduce
• Hadoop
  • 基本處理過程
  • 優(yōu)勢和局限
• Spark
  • Spark的批處理模式
  • Spark的流處理模式
  • 優(yōu)勢和局限
  • 總結
• MPI
  • MPI的優(yōu)點
  • MPI的缺點
• OpenMP
• CUDA
  • Cpu與Gpu
  • CUDA框架
• GraphLab
  • GraphLab的優(yōu)點
  • GraphLab和MapReduce的對比
  • GraphLab并行框架
    • Graph的構造
    • GraphLab的執(zhí)行模型

概念

框架與引擎

處理框架和處理引擎負責對數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)進行計算。雖然“引擎”和“框架”之間的區(qū)別沒有什么權威的定義，但大部分時候可以將前者定義為實際負責處理數(shù)據(jù)操作的組件，后者則可定義為承擔類似作用的一系列組件。例如Apache Hadoop可以看作一種以MapReduce作為默認處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop并取代MapReduce。

批處理框架

批處理主要操作大容量靜態(tài)數(shù)據(jù)集，并在計算過程完成后返回結果。批處理模式中使用的數(shù)據(jù)集特征：

• 有界：批處理數(shù)據(jù)集代表數(shù)據(jù)的有限集合
• 持久：數(shù)據(jù)通常始終存儲在某種類型的持久存儲位置中
• 大量：批處理操作通常是處理極為海量數(shù)據(jù)集的唯一方法

批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數(shù)和平均數(shù)時，必須將數(shù)據(jù)集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中數(shù)據(jù)維持自己的狀態(tài)。大量數(shù)據(jù)的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。

批處理框架應用：Apache Hadoop

流處理框架

流處理會對隨時進入系統(tǒng)的數(shù)據(jù)進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數(shù)據(jù)集執(zhí)行操作，而是對通過系統(tǒng)傳輸?shù)拿總€數(shù)據(jù)項執(zhí)行操作。

流處理中的數(shù)據(jù)集是“無邊界”的，這就產(chǎn)生了幾個重要的影響：

• 完整數(shù)據(jù)集只能代表截至目前已經(jīng)進入到系統(tǒng)中的數(shù)據(jù)總量。
• 工作數(shù)據(jù)集也許更相關，在特定時間只能代表某個單一數(shù)據(jù)項。
• 處理工作是基于事件的，除非明確停止否則沒有“盡頭”。處理結果立刻可用，并會隨著新數(shù)據(jù)的抵達繼續(xù)更新。

流處理系統(tǒng)可以處理幾乎無限量的數(shù)據(jù)，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）數(shù)據(jù)，不同記錄間只維持最少量的狀態(tài)。雖然大部分系統(tǒng)提供了用于維持某些狀態(tài)的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優(yōu)化。

功能性操作主要側重于狀態(tài)或副作用有限的離散步驟。有近實時處理需求的任務很適合使用流處理模式。分析、服務器或應用程序錯誤日志，以及其他基于時間的衡量指標是最適合的類型，因為對這些領域的數(shù)據(jù)變化做出響應對于業(yè)務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，并且關注一段時間內變化趨勢的數(shù)據(jù)。

流處理框架應用：Apache Storm，Apache Samza

混合處理框架

一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數(shù)據(jù)，借此讓不同的處理需求得以簡化。

雖然側重于某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數(shù)據(jù)處理的通用解決方案。這種框架不僅可以提供處理數(shù)據(jù)所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、交互式查詢等多種任務。

混合處理框架應用：Apache Spark，Apache Flink

MapReduce

MapReduce是Google提出的一個軟件架構，用于大規(guī)模數(shù)據(jù)集的并行運算。

MapReduce的處理過程分為兩個步驟：map（映射）和reduce（歸納）。每個階段的輸入輸出都是key-value的形式，類型可以自行指定。map階段對切分好的數(shù)據(jù)進行并行處理，處理結果傳輸給reduce，由reduce函數(shù)完成最后的匯總。Reduce又可以作為一個Map為下一級Reduce作準備，以此迭代。

MapReduce進程間的通信純粹是用文件去聯(lián)系的，每個進程做的事情就是去讀取上一級進程生成的數(shù)據(jù)，然后處理后寫入磁盤讓下一級進程進行讀取。這個特性使得MapReduce有著良好的容錯性，當某一級的某一個進程出錯了，JobMaster會重新調度這個進程到另外一個機器上重新運行。壞處是每當Map-Reduce的某一個步驟運行完后，需要重新調度下一級任務，調度產(chǎn)生的開銷會非常的大（網(wǎng)絡傳輸，文件讀寫磁盤IO）。

MapReduce通過把對數(shù)據(jù)集的大規(guī)模操作分發(fā)給網(wǎng)絡上的每個節(jié)點實現(xiàn)可靠性；每個節(jié)點會周期性的把完成的工作和狀態(tài)的更新報告回來。如果一個節(jié)點保持沉默超過一個預設的時間間隔，主節(jié)點記錄下這個節(jié)點狀態(tài)為死亡，并把分配給這個節(jié)點的數(shù)據(jù)發(fā)到別的節(jié)點。每個操作使用命名文件的不可分割操作以確保不會發(fā)生并行線程間的沖突；當文件被改名的時候，系統(tǒng)可能會把他們復制到任務名以外的另一個名字上去。（避免副作用）。

歸納操作工作方式很類似，但是由于歸納操作在并行能力較差，主節(jié)點會盡量把歸納操作調度在一個節(jié)點上，或者離需要操作的數(shù)據(jù)盡可能近的節(jié)點上了。

Hadoop

Apache Hadoop是一款支持數(shù)據(jù)密集型分布式應用程序的開源批處理框架，包含多個組件，即多個層，通過配合使用可處理批數(shù)據(jù)：

• HDFS：（Hadoop Distributed File System分布式文件系統(tǒng)層）可對集群節(jié)點間的存儲和復制進行協(xié)調。HDFS確保了無法避免的節(jié)點故障發(fā)生后數(shù)據(jù)依然可用，可將其用作數(shù)據(jù)來源，可用于存儲中間態(tài)的處理結果，并可存儲計算的最終結果。
• YARN：（Yet Another Resource Negotiator另一個資源管理器）可充當Hadoop堆棧的集群協(xié)調組件。該組件負責協(xié)調并管理底層資源和調度作業(yè)的運行。通過充當集群資源的接口，YARN使得用戶能在Hadoop集群中使用比以往的迭代方式運行更多類型的工作負載。
• MapReduce：Hadoop的原生批處理引擎。

基本處理過程

• 從HDFS文件系統(tǒng)讀取數(shù)據(jù)集
• 將數(shù)據(jù)集拆分成小塊并分配給所有可用節(jié)點
• 針對每個節(jié)點上的數(shù)據(jù)子集進行計算（計算的中間態(tài)結果會重新寫入HDFS）
• 重新分配中間態(tài)結果并按照鍵進行分組
• 通過對每個節(jié)點計算的結果進行匯總和組合對每個鍵的值進行“Reducing”
• 將計算而來的最終結果重新寫入 HDFS

優(yōu)勢和局限

由于每個任務需要多次執(zhí)行讀取和寫入操作，因此速度相對較慢。但另一方面由于磁盤空間通常是服務器上最豐富的資源，這意味著MapReduce可以處理非常海量的數(shù)據(jù)集。同時也意味著相比其他類似技術，Hadoop的MapReduce通常可以在廉價硬件上運行，因為該技術并不需要將一切都存儲在內存中。MapReduce具備極高的縮放潛力，生產(chǎn)環(huán)境中曾經(jīng)出現(xiàn)過包含數(shù)萬個節(jié)點的應用。與其他框架和引擎的兼容與集成能力使得Hadoop可以成為使用不同技術的多種工作負載處理平臺的底層基礎。

Spark

Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapReduce引擎基于各種相同原則開發(fā)而來的Spark主要側重于通過完善的內存計算和處理優(yōu)化機制加快批處理工作負載的運行速度。Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成并取代MapReduce引擎。

Spark的批處理模式

與MapReduce不同，Spark的數(shù)據(jù)處理工作全部在內存中進行，只在一開始將數(shù)據(jù)讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態(tài)的處理結果均存儲在內存中。

雖然內存中處理方式可大幅改善性能，Spark在處理與磁盤有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現(xiàn)更完善的整體式優(yōu)化。為此Spark可創(chuàng)建代表所需執(zhí)行的全部操作，需要操作的數(shù)據(jù)，以及操作和數(shù)據(jù)之間關系的Directed Acyclic Graph（有向無環(huán)圖），即DAG，借此處理器可以對任務進行更智能的協(xié)調。

為了實現(xiàn)內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數(shù)據(jù)集），即RDD的模型來處理數(shù)據(jù)。這是一種代表數(shù)據(jù)集，只位于內存中，永恒不變的結構。針對RDD執(zhí)行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，并最終回溯至磁盤上的數(shù)據(jù)。Spark可通過RDD在無需將每個操作的結果寫回磁盤的前提下實現(xiàn)容錯。

Spark的流處理模式

流處理能力是由Spark Streaming實現(xiàn)的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特征方面的差異，Spark實現(xiàn)了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數(shù)據(jù)流視作一系列非常小的“批”，借此即可通過批處理引擎的原生語義進行處理。

Spark Streaming會以亞秒級增量對流進行緩沖，隨后這些緩沖會作為小規(guī)模的固定數(shù)據(jù)集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。

優(yōu)勢和局限

使用Spark而非Hadoop MapReduce的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數(shù)據(jù)集。

Spark的另一個重要優(yōu)勢在于多樣性。既可作為獨立集群部署，亦可與現(xiàn)有Hadoop集群集成，可運行批處理和流處理，運行一個集群即可處理不同類型的任務。

除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態(tài)系統(tǒng)，可為機器學習、交互式查詢等任務提供更好的支持。相比MapReduce，Spark任務更是“眾所周知”地易于編寫，因此可大幅提高生產(chǎn)力。

為流處理系統(tǒng)采用批處理的方法，需要對進入系統(tǒng)的數(shù)據(jù)進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數(shù)據(jù)，提高整體吞吐率，但等待緩沖區(qū)清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。

由于內存通常比磁盤空間更貴，因此相比基于磁盤的系統(tǒng)，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數(shù)為資源付費的環(huán)境中，這一特性通常可以抵消增加的成本。

Spark內存計算這一設計的另一個后果是，如果部署在共享的集群中可能會遇到資源不足的問題。相比Hadoop MapReduce，Spark的資源消耗更大，可能會對需要在同一時間使用集群的其他任務產(chǎn)生影響。

總結

Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高內存占用為代價提供了無與倫比的速度優(yōu)勢。對于重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。

MPI

MPI（Message Passing Interface 消息傳遞接口）。是一個跨語言的并行計算接口，可以被fortran，c，c++等調用，常在超級電腦、電腦簇等分布式內存環(huán)境應用。MPI的目標是高性能，大規(guī)模性，和可移植性。目前MPI的實現(xiàn)非常多，開源的有Open MPI和MPICH。

MPI的優(yōu)點

• 允許靜態(tài)任務調度，程序的調度是一次性的，就是比如開始申請了50個進程，那這50個進程就會一起跑，同生同死。
• MPI的封裝，讓并發(fā)數(shù)據(jù)更操作變得非常的方便，顯示并行提供了良好的性能和移植性。
• 由于MPI是基于消息的，劃分計算任務，將任務映射到分布式進程集合中進行計算時，既可進行任務劃分，也可進行數(shù)據(jù)劃分，沒有任何限制。
• 用 MPI 編寫的程序可直接在多核集群上運行。集群的各節(jié)點之間可以采用 MPI 編程模型進行程序設計，每個節(jié)點都有自己的內存，可以對本地的指令和數(shù)據(jù)直接進行訪問，各節(jié)點之間通過互聯(lián)網(wǎng)絡進行消息傳遞。具有很好的可移植性，完備的異步通信功能，較強的可擴展性。

MPI的缺點

• MPI都沒有提供GFS系統(tǒng)，這個讓大文件的存放，讀取都成了一個問題，如果底層有一個GFS，再在上面搭一個MPI的系統(tǒng)，使用起來會非常的舒服。
• MPI的容錯性一般不容易做，因為程序是同生同死的，某一個進程掛了，整個任務就掛了。
• 并行化改進需要大量地修改原有的串行代碼，調試難度比較大。
• 通信會造成很大的開銷，為了最小化延遲，通常需要大的代碼粒度，細粒度的并行會引發(fā)大量的通信。
• 動態(tài)負載平衡困難。

OpenMP

OpenMp是線程級別的，是針對單主機上多核/多CPU并行計算而設計的工具，支持目前所有平臺上的c,fortran等的共享內存式并行計算：
主線程(順序的執(zhí)行指令)生成一系列的子線程，并將任務劃分給這些子線程進行執(zhí)行。這些子線程并行的運行，由運行時環(huán)境將線程分配給不同的處理器。

OpenMp比較簡單，修改現(xiàn)有的大段代碼也容易。基本上OpenMp只要在已有程序基礎上根據(jù)需要加并行語句即可。而MPI有時甚至需要從基本設計思路上重寫整個程序，調試也困難得多，涉及到局域網(wǎng)通信這一不確定的因素。不過，OpenMp雖然簡單卻只能用于單機多CPU/多核并行，MPI才是用于多主機超級計算機集群的強悍工具，當然復雜。

CUDA

CUDA(Compute Unified Device Architecture)是一種由NVIDIA推出的通用并行計算架構，該架構使GPU能夠解決復雜的計算問題。它包含了CUDA指令集架構（ISA）以及GPU內部的并行計算引擎。

Cpu與Gpu

CPU擅長處理不規(guī)則數(shù)據(jù)結構和不可預測的存取模式，以及遞歸算法、分支密集型代碼和單線程程序。這類程序任務擁有復雜的指令調度、循環(huán)、分支、邏輯判斷以及執(zhí)行等步驟。例如，操作系統(tǒng)、文字處理、交互性應用的除錯、通用計算、系統(tǒng)控制和虛擬化技術等系統(tǒng)軟件和通用應用程序等等。

GPU擅于處理規(guī)則數(shù)據(jù)結構和可預測存取模式。例如，光影處理、3D 坐標變換、油氣勘探、金融分析、醫(yī)療成像、有限元、基因分析和地理信息系統(tǒng)以及科學計算等方面的應用。顯示芯片通常具有更大的內存帶寬。具有更大量的執(zhí)行單元。和高階 CPU 相比，顯卡的價格較為低廉。

目前設計GPU+CPU架構平臺的指導思想是：讓CPU的更多資源用于緩存，GPU的更多資源用于數(shù)據(jù)計算。

當代CPU的微架構是按照兼顧“指令并行執(zhí)行”和“數(shù)據(jù)并行運算”的思路而設計，就是要兼顧程序執(zhí)行和數(shù)據(jù)運算的并行性、通用性以及它們的平衡性。CPU的微架構偏重于程序執(zhí)行的效率，不會一味追求某種運算極致速度而犧牲程序執(zhí)行的效率。

GPU的微架構就是面向適合于矩陣類型的數(shù)值計算而設計的，大量重復設計的計算單元，這類計算可以分成眾多獨立的數(shù)值計算——大量數(shù)值運算的線程，而且數(shù)據(jù)之間沒有像程序執(zhí)行的那種邏輯關聯(lián)性。

CUDA框架

CUDA 是 NVIDIA 的 GPGPU 模型，它使用 C 語言為基礎，可以直接以大多數(shù)人熟悉的 C 語言，寫出在顯示芯片上執(zhí)行的程序，而不需要去學習特定的顯示芯片的指令或是特殊的結構。

從CUDA體系結構的組成來說，包含了三個部分：開發(fā)庫、運行期環(huán)境和驅動：

• 開發(fā)庫是基于CUDA技術所提供的應用開發(fā)庫。
• 運行期環(huán)境提供了應用開發(fā)接口和運行期組件，包括基本數(shù)據(jù)類型的定義和各類計算、類型轉換、內存管理、設備訪問和執(zhí)行調度等函數(shù)。
• 驅動部分基本上可以理解為是CUDA-enable的GPU的設備抽象層，提供硬件設備的抽象訪問接口。
• 應用領域例如游戲、高清視頻、衛(wèi)星成像等數(shù)據(jù)規(guī)模龐大的場景。

在 CUDA 的架構下，一個程序分為兩個部份：host 端和 device 端。Host 端是指在 CPU 上執(zhí)行的部份，而 device 端則是在顯示芯片上執(zhí)行的部份。Device 端的程序又稱為 “kernel”。通常 host 端程序會將數(shù)據(jù)準備好后，復制到顯卡的內存中，再由顯示芯片執(zhí)行 device 端程序，完成后再由 host 端程序將結果從顯卡的內存中取回。

GraphLab

一般的機器學習類算法有以下兩個特性:

• 數(shù)據(jù)依賴性很強。運算過程中參與計算的各個機器之間經(jīng)常需要交換大量的數(shù)據(jù)。
• 流處理復雜。主要表現(xiàn)在整個處理過程需要反復地迭代計算，數(shù)據(jù)處理分支很多，很難實現(xiàn)真正的并行。

而當前被廣泛使用的MapReduce 計算框架，Map階段集群的各臺機器各自完成負載較重的計算過程，數(shù)據(jù)并行度高，適合完成類似矩陣運算、數(shù)據(jù)統(tǒng)計等數(shù)據(jù)獨立性強的計算，任務執(zhí)行期間不需要相互之間進行數(shù)據(jù)通信，所以MapReduce 不適合數(shù)據(jù)依賴性強的任務，而且MapReduce 并行計算模型也不能高效表達迭代型算法。這種計算模型在處理如日志分析、數(shù)據(jù)統(tǒng)計等數(shù)據(jù)獨立性的任務時具有明顯的優(yōu)勢，但是在機器學習領域，MapReduce框架并不能很好地滿足機器學習計算任務。

另一個并行實現(xiàn)方案就是采用純MPI（Native MPI）的方式。純MPI實現(xiàn)通過精細的設計將并行任務按照MPI協(xié)議分配到集群機器上，并根據(jù)具體應用，在計算過程中進行機器間的數(shù)據(jù)通信和同步。純MPI的優(yōu)點是，可以針對具體的應用，進行深度優(yōu)化，從而達到很高的并行性能。但純MPI存在的問題是，針對不同的機器學習算法，需要重寫其數(shù)據(jù)分配、通信等實現(xiàn)細節(jié)，代碼重用率低，機器拓展性能差，對編程開發(fā)人員的要求高，而且優(yōu)化和調試成本高。因而，純MPI不適合敏捷的互聯(lián)網(wǎng)應用。

為解決機器學習的流處理，Google提出了Pregel框架，Pregel是嚴格的BSP模型(Bulk Synchronous Parallel，整體同步并行計算模型)，采用“計算-通信-同步”的模式完成機器學習的數(shù)據(jù)同步和算法迭代。Goolge曾稱其80%的程序使用MapReduce完成，20%的程序使用Pregel實現(xiàn)。因而，Pregel是很成熟的機器學習流處理框架，但Google一直沒有將Pregel的具體實現(xiàn)開源，外界對Pregel的模仿實現(xiàn)在性能和穩(wěn)定性方面都未能達到工業(yè)級應用的標準。

2010年，CMU的Select實驗室提出了GraphLab框架，GraphLab 是一個基于圖像處理模型的開源圖計算框架，框架使用C++語言開發(fā)實現(xiàn)。該框架是面向機器學習（ML）的流處理并行計算框架，可以運行在多處理機的單機系統(tǒng)、集群等多種環(huán)境下。

GraphLab 自成立以來就是一個發(fā)展很迅速的開源項目，GraphLab的設計目標是，像MapReduce一樣高度抽象，可以高效執(zhí)行與機器學習相關的、具有稀疏的計算依賴特性的迭代性算法，并且保證計算過程中數(shù)據(jù)的高度一致性和高效的并行計算性能。該框架最初是為處理大規(guī)模機器學習任務而開發(fā)的，但是該框架也同樣適用于許多數(shù)據(jù)挖掘方面的計算任務。在并行圖計算領域，該框架在性能上高出很多其他并行計算框架（例如，MapReduce、Mahout）幾個數(shù)量級。

GraphLab的優(yōu)點

GraphLab 作為一個基于圖處理的并行計算框架，能夠高效地執(zhí)行機器學習相關的數(shù)據(jù)依賴性強，迭代型算法，其設計具有如下特點和優(yōu)點。

• 統(tǒng)一的API 接口。對于多核處理器和分布式環(huán)境，采用統(tǒng)一的API 接口，一次編寫程序即可高效地運行在共享內存環(huán)境或者分布式集群上。
• 高性能。優(yōu)化C++執(zhí)行引擎，在大量多線程操作和同步I/O 操作之間進行了很好的平衡。
• 可伸縮性強。GraphLab 能夠智能地選擇存儲和計算的節(jié)點，原因是GraphLab 對于數(shù)據(jù)的存儲與計算都使用了精心設計的優(yōu)良算法。
• 集成HDFS。GraphLab 內置對HDFS 的支持，GraphLab 能夠直接從HDFS中讀數(shù)據(jù)或者將計算結果數(shù)據(jù)直接寫入到HDFS 中。
• 功能強大的機器學習類工具集。GraphLab 在自身提供的API 接口之上實現(xiàn)了大量的開箱即用的工具集。

GraphLab和MapReduce的對比

GraphLab 的出現(xiàn)不是對MapReduce 算法的替代，相反，GraphLab 借鑒了MapReduce 的思想，將MapReduce 并行計算模型推廣到了對數(shù)據(jù)重疊性、數(shù)據(jù)依賴性和迭代型算法適用的領域。本質上，GraphLab 填補了高度抽象的MapReduce 并行計算模型和底層消息傳遞、多線程模型（如MPI 和PThread）之間的空隙。

GraphLab 模擬了MapReduce 中的抽象過程：

• 對MapReduce的map操作，通過稱為更新函數(shù)（Update Function）的過程進行模擬，更新函數(shù)能夠讀取和修改用戶定義的圖結構數(shù)據(jù)集。用戶提供的數(shù)據(jù)圖代表了程序在內存中和圖的頂點、邊相關聯(lián)的內存狀態(tài)，更新函數(shù)能夠遞歸地觸發(fā)更新操作，從而使更新操作作用在其他圖節(jié)點上進行動態(tài)的迭代式計算。GraphLab 提供了強大的控制原語，以保證更新函數(shù)的執(zhí)行順序。
• 對MapReduce的reduce操作，通過稱為同步操作（Sync Operation）的過程進行模擬。同步操作能夠在后臺計算任務進行的過程中執(zhí)行合并（Reductions），和GraphLab 提供的更新函數(shù)一樣，同步操作能夠同時并行處理多條記錄，這也保證了同步操作能夠在大規(guī)模獨立環(huán)境下運行。

GraphLab并行框架

GraphLab將數(shù)據(jù)抽象成Graph結構，將算法的執(zhí)行過程抽象成Gather、Apply、Scatter三個步驟。其并行的核心思想是對頂點的切分。

Graph的構造

• 頂點是其最小并行粒度和通信粒度，邊是機器學習算法中數(shù)據(jù)依賴性的表現(xiàn)方式。
• 對于某個頂點，其被部署到多臺機器，一臺機器作為master頂點，其余機器上作為mirror。Master作為所有mirror的管理者，負責給mirror安排具體計算任務;mirror作為該頂點在各臺機器上的代理執(zhí)行者，與master數(shù)據(jù)的保持同步。
• 對于某條邊，GraphLab將其唯一部署在某一臺機器上，而對邊關聯(lián)的頂點進行多份存儲，解了邊數(shù)據(jù)量大的問題。
• 同一臺機器上的所有edge和vertex構成local graph,在每臺機器上，存在本地id到全局id的映射表。
• vertex是一個進程上所有線程共享的，在并行計算過程中，各個線程分攤進程中所有頂點的gather->apply->scatter操作。

GraphLab的執(zhí)行模型

每個頂點每一輪迭代經(jīng)過gather->apple->scatter三個階段。

Gather階段：工作頂點的邊 (可能是所有邊，也有可能是入邊或者出邊)從領接頂點和自身收集數(shù)據(jù)，記為gather_data_i，各個邊的數(shù)據(jù)graphlab會求和，記為sum_data。這一階段對工作頂點、邊都是只讀的。

Apply階段 ：Mirror將gather計算的結果sum_data發(fā)送給master頂點，master進行匯總為total。Master利用total和上一步的頂點數(shù)據(jù)，按照業(yè)務需求進行進一步的計算，然后更新master的頂點數(shù)據(jù)，并同步mirror。Apply階段中，工作頂點可修改，邊不可修改。

Scatter階段：工作頂點更新完成之后，更新邊上的數(shù)據(jù)，并通知對其有依賴的鄰結頂點更新狀態(tài)。這scatter過程中，工作頂點只讀，邊上數(shù)據(jù)可寫。

在執(zhí)行模型中，graphlab通過控制三個階段的讀寫權限來達到互斥的目的。在gather階段只讀，apply對頂點只寫，scatter對邊只寫。并行計算的同步通過master和mirror來實現(xiàn)，mirror相當于每個頂點對外的一個接口人，將復雜的數(shù)據(jù)通信抽象成頂點的行為。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的并行计算框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。