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

概念

框架與引擎

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

批處理框架

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

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

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

批處理框架應用：Apache Hadoop

流處理框架

流處理會對隨時進入系統的數據進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。

流處理中的數據集是“無邊界”的，這就產生了幾個重要的影響：

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

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

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

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

混合處理框架

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

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

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

MapReduce

MapReduce是Google提出的一個軟件架構，用于大規模數據集的并行運算。

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

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

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

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

Hadoop

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

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

基本處理過程

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

優勢和局限

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

Spark

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

Spark的批處理模式

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

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

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

Spark的流處理模式

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

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

優勢和局限

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

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

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

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

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

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

總結

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

MPI

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

MPI的優點

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

MPI的缺點

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

OpenMP

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

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

CUDA

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

Cpu與Gpu

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

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

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

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

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

CUDA框架

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

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

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

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

GraphLab

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

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

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

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

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

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

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

GraphLab的優點

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

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

GraphLab和MapReduce的對比

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

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

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

GraphLab并行框架

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

Graph的構造

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

GraphLab的執行模型

每個頂點每一輪迭代經過gather->apple->scatter三個階段。

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

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

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

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

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

總結

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

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