作者：朱賽凡

2) 平行計算引擎層

(1) 平行計算形式

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

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

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

垂直並行化則是指存在流水線方式依賴關係的操作分別由不同處理機並行執行的形式。流水線方式依賴：如果OP2無需等待OP1執行完畢即可在另一處理機上開始執行

(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數目更合理。