MPP與批處理設計（翻譯）

MPP設計

所有MPP解決方案的最初想法是消除共享資源。每個executor都有獨立的CPU、內存和磁碟資源。除了通過網路交換被管數據，一個executor是無法訪問另一個executor的資源。MPP解決方案的這一理念讓資源隔離得非常漂亮，並使高擴展性成為可能。

MPP的第二個理念是並行。每個executor運行完全相同的數據處理邏輯，處理從本地存儲載入的私有數據塊。在執行步驟間有一些為數據交換而實現的同步點（例如Apache Spark和MapReduce的shuffle步驟）。下面是一個典型MPP查詢執行時間軸——每條垂線都是一個同步點。具體來說，在集群內連接和聚合數據都要用到同步，其任務可能代表數據聚合、表連接、數據排序和其他分別經由每個集群節點執行的計算。

MPP設計的問題

但是，這種設計將導致所有MPP解決方案面對同樣的棘手問題——straggler。如果一個節點經常比其他節點執行得慢，那麼無論集群規模，整個引擎的性能都將受到這個故障節點的拖累。下面的例子說明了故障節點（Executor 7）是如何降低整個集群的性能：

大多數情況下，所有的executor都空閑下來，除了一個例外。它們在等著與Executor 7同步，問題根源就出在這裡。具體來說，由於磁碟故障引起RAID性能降低，又或是硬體、OS級問題導致的CPU性能低下等等之類的問題都會在MPP上發生。每個MPP系統都要面臨這些問題。

如果你能看看這份Google關於磁碟故障率的研究報告，通過觀察AFR（年均故障率）指標可以發現，新磁碟在最初3個月運行時間中，有至少2%的故障率：

在由1000塊磁碟組成的集群中，一年會遇到20塊故障磁碟，大約兩周就有一塊磁碟出故障；在由2000塊磁碟組成的集群中，每周都會遇到；那麼4000塊磁碟的集群每周遇到兩次。使用2年後，故障率將擴大4倍，這就意味著在由1000塊磁碟組成的集群中，每周會遇到兩次磁碟故障。

事實上，在某個特定的集群中，MPP系統總是會遇到磁碟故障節點，正如前面提到的，不但該節點性能受損，還會限制整個集群性能。這就是世界上幾乎沒有哪個單MPP集群超過50台伺服器的主要原因。

MPP方案和MapReduce批處理方案間另外一個區別是並發性。並發性是指有多少個查詢可以有效地被並行執行。MPP是完全對稱的——一旦開始執行，集群中的每個節點並行執行相同的任務。這意味著MPP方案的並發級別完全與集群節點的數量無關。具體來說，無論集群是4個節點還是400個節點，並發性是一樣的，它們的性能衰退也會在同一點體現。下面有個例子：

正如你所見，10-18個並行回話（查詢）達到了最大吞吐量，曲線圖上表明，如果達到20個以上的會話，吞吐量將緩慢衰退70%甚至更多。特別注意，這裡的吞吐量是在固定的時間範圍（足夠長的時間間隔得出結論）內執行特定數量的查詢（同類查詢）得出的。Yahoo團隊對Impala並發性限制調查也得出了類似的觀察結果。插一句：Impala是構建在Hadoop上的MPP引擎。基本上，低並發性是權衡MPP方案實現低查詢延遲和高速數據處理的重要指標。

（譯註：吞吐量這部分作者沒有交代在多少節點下得出的結論，請各位讀者注意。）

批處理設計

為應對批處理需求，一種新的解決方案應運而生——從MapReduce論文起步並發展壯大。該原理的代表作有Apache HadoopMapReduce和Apache Spark等等。主要思想是在兩個同步點之間的「step」被分成了若干個獨立「task」，task的數量和executor的數量完全沒有關係。具體來說，基於HDFS的MapReduce task數量等於輸入分片，通常等於輸入文件的HDFS塊數量。在同步點之間，根據executor的可用性，task被隨機分配給executor，相比之下，MPP的每個處理任務限定了具體的executor來處理數據分片。MapReduce的同步點包括job開始、shuffle和job結束。對於Apache Spark來說是job開始、shuffle、緩存數據集和job結束。下面介紹了處理過程是如何工作的——以Apache Spark為例，每個條帶代表獨立的「task」，每個executor並行處理三個task：

你可以看到executor3似乎有問題——所有任務的運行幾乎慢了2倍。但這不是問題——它只是被安排了較少的任務。如果這個問題變得更嚴重，預測執行將起效——慢節點上的task將在其他節點上重啟。

由於共享存儲，這種手段是可行的。為了處理一批數據，你無須將這批數據存儲在特定設備上。相反，你可以從遠端設備獲取這些數據。當然，遠端處理始終比本地處理開銷更大，因為數據必須移動——所以引擎也會儘力嘗試本地處理數據。在批處理的場景下遇到設備故障，預測執行機制將幫助故障節點，這在MPP方案中是完全不可能實現的。

順便說下，這裡有個學習雲環境下預測執行的好教材：

本圖是關於WordCount的性能。正如圖上所見，就算雲環境有臭名昭著的straggler問題，預測執行機制依然在雲環境下縮短了2.5倍的執行時間。結合共享存儲和更細粒度的調度，使得批處理系統在規模上更優於MPP方案——上千個節點上萬個磁碟。

批處理設計問題

但是，一切都有代價。MPP你無需把中間數據放在磁碟上，因為一個executor處理一個任務，能將數據流直接交給下一個執行任務。這種機制叫「pipelining」，會大大提高性能。批處理環境下，當你讓一個executor連續執行大量不相關的任務時，下一步需要用到上一步的數據你將無從選擇，只有把中間結果存在本地磁碟。這將拖慢整個系統。

根據我的經驗，主流MPP系統與Apache Spark比較性能的話——同樣硬體集群規模——Apache Spark通常會慢3-5倍。所以合理的把MPP集群規模限制在50台，將和250台規模的Apache Spark集群性能一致，但是呢Apache Spark可以超過250個節點，MPP就望塵莫及了。

原文鏈接：https://content.pivotal.io/blog/apache-hawq-next-step-in-massively-parallel-processing

文章中資料鏈接

Google關於磁碟故障率的研究報告：https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro_old.pdf

Yahoo團隊對Impala並發性限制調查：http://hortonworks.com/blog/impala-vs-hive-performance-benchmark/

MapReduce論文：http://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf

預測執行：https://en.wikipedia.org/wiki/Speculative_execution

雲環境下預測執行：https://www.usenix.org/legacy/event/osdi08/tech/full_papers/zaharia/zaharia.pdf

臭名昭著的straggler問題：http://blog.scalyr.com/2012/10/a-systematic-look-at-ec2-io/

中間結果存在本地磁碟：http://0x0fff.com/spark-architecture-shuffl

請注意！引用、轉貼本文應註明原譯者：Rosen Jiang 以及原文鏈接。