MPP架構和批處理

目錄

資料庫構架

MPP和批處理

MPP概念

MPP的設計缺陷

將MPP和Batch進行結合

MPP例子

 Hadoop解決的問題

MPP和Hadoop的區別

小結

---

資料庫構架

---

資料庫構架設計中主要有Shared Everthting、Shared Nothing、和Shared Disk：

Shared Everthting:一般是針對單個主機，完全透明共享CPU/MEMORY/IO，並行處理能力是最差的，典型的代表SQLServer

Shared Disk：各個處理單元使用自己的私有 CPU和Memory，共享磁碟系統。典型的代表Oracle Rac， 它是資料共享，可通過增加節點來提高並行處理的能力，擴充套件能力較好。其類似於SMP（對稱多處理）模式，但是當儲存器介面達到飽和的時候，增加節點並不能獲得更高的效能 。

Shared Nothing：各個處理單元都有自己私有的CPU/記憶體/硬碟等，不存在共享資源，類似於MPP（大規模並行處理）模式，各處理單元之間通過協議通訊，並行處理和擴充套件能力更好。典型代表DB2 DPF和hadoop ，各節點相互獨立，各自處理自己的資料，處理後的結果可能向上層彙總或在節點間流轉。

我們常說的 Sharding 其實就是Share Nothing架構，它是把某個表從物理儲存上被水平分割，並分配給多臺伺服器（或多個例項），每臺伺服器可以獨立工作，具備共同的schema，比如MySQL Proxy和Google的各種架構，只需增加伺服器數就可以增加處理能力和容量。

MPP和批處理

批處理系統 - 使用場景分鐘級、小時級以上的任務，目前很多大型網際網路公司都大規模執行這樣的系統，穩定可靠，低成本。

MPP系統 - 使用場景秒級、毫秒級以下的任務，主要服務於即席查詢場景，對外提供各種資料查詢和視覺化服務。

MPP概念

---

MPP即大規模並行處理（Massively Parallel Processor ）。 在資料庫非共享叢集中，每個節點都有獨立的磁碟儲存系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連線，彼此協同計算，作為整體提供資料 庫服務。非共享資料庫叢集有完全的可伸縮性、高可用、高效能、優秀的價效比、資源共享等優勢。

 

 

MPP DBMS是基於此方法構建的資料庫管理系統，在這些系統中，您所注視的每個查詢都被拆分為由MPP網格節點並行執行的一組協調程式，將計算拆分為比傳統SMP RDBMS系統執行速度更快的方式。

MPP解決方案的最原始想法就是消除共享資源。每個執行器有單獨的CPU，記憶體和硬碟資源。一個執行器無法直接訪問另一個執行器上的資源，除非通過網路上的受控的資料交換。這種資源獨立的概念，對於MPP架構來說很完美的解決了可擴充套件性的問題。

為了能夠處理大量資料，這些解決方案中的資料通常按每個節點僅處理其本地資料的方式在節點之間拆分（分片）。這進一步加快了資料的處理速度，因為將共享儲存用於這種設計將是一個巨大的過大殺傷力–更復雜，更昂貴，擴充套件性更差，網路利用率更高，並行性更低。這就是為什麼大多數MPP DBMS解決方案都是不共享的，並且不能在DAS儲存或在小型伺服器組之間共享的一組儲存架上工作的原因

MPP的第二個主要概念就是並行。每個執行器執行著完全一致的資料處理邏輯，使用著本地儲存上的私有資料塊。在不同的執行階段中間有一些同步點(我的理解：瞭解Java Gc機制的，可以對比GC中stop-the-world,在這個同步點，所有執行器處於等待狀態)，這些同步點通常被用於進行資料交換(像Spark和MapReduce中的shuffle階段)。這裡有一個經典的MPP查詢時間線的例子： 每個垂直的虛線是一個同步點。例如：同步階段要求在叢集中”shuffle”資料以用於join和聚合(aggregations)操作,因此同步階段可能執行一些資料聚合，表join，資料排序的操作，而每個執行器執行剩下的計算任務。

 

MPP的設計缺陷

---

但是，這樣的設計對於所有的MPP解決方案來說都有一個主要的問題——短板效應。如果一個節點總是執行的慢於叢集中其他的節點，整個叢集的效能就會受限於這個故障節點的執行速度(所謂木桶的短板效應)，無論叢集有多少節點，都不會有所提高。這裡有一個例子展示了故障節點(下圖中的Executor 7)是如何降低叢集的執行速度的。

大多數情況下，除了Executor 7 其他的所有執行器都是空閒狀態。這是因為他們都在等待Executor 7執行完成後才能執行同步過程，這也是我們的問題的根本。比如，當MPP系統中某個節點的RAID由於磁碟問題導致的效能很慢，或者硬體或者系統問題帶來的CPU效能問題等等，都會產生這樣的問題。所有的MPP系統都面臨這樣的問題。

如果你看一下Google的磁碟錯誤率統計報告，你就能發現觀察到的AFR(annualized failure rate,年度故障率)在最好情況下，磁碟在剛開始使用的3個月內有百分之二十會發生故障。

 

如果一個叢集有1000個磁碟，一年中將會有20個出現故障或者說每兩週會有一個故障發生。如果有2000個磁碟，你將每週都會有故障發生，如果有4000個，將每週會有兩次錯誤發生。兩年的使用之後，你將把這個數字乘以4，也就是說，一個1000個磁碟的叢集每週會有兩次故障發生。

事實上，在一個確定的量級，你的MPP系統將總會有一個節點的磁碟佇列出現問題，這將導致該節點的效能降低，從而像上面所說的那樣限制整個叢集的效能。這也是為什麼在這個世界上沒有一個MPP叢集是超過50個節點伺服器的。

MPP和批處理方案如MapReduce之間有一個更重要的不同就是併發度。併發度就是同一時刻可以高效執行的查詢數。MPP是完美對稱的，當查詢執行的時候，叢集中每個節點併發的執行同一個任務。這也就意味著MPP叢集的併發度和叢集中節點的數量是完全沒有關係的。比如說，4個節點的叢集和400個節點的叢集將支援同一級別的併發度，而且他們效能下降的點基本上是同樣。下面是我所說情況的一個例子。

正如你所見，10-18個並行查詢會話產生了整個叢集最大的吞吐量。如果你將會話數提高到20個以上的時候，吞吐量將慢慢下降到70%甚至更低。在此宣告，吞吐量是在一個固定的時間區間內(時間足夠長以產生一個代表性的結果)，執行的相同種類的查詢任務的數量。Yahoo團隊調查Impala併發度限制時產生了一個相似的測試結果。Impala是一個基於Hadoop的MPP引擎。因此從根本上來說，較低的併發度是MPP方案必須承擔的以提供它的低查詢延遲和高資料處理速度。

 

將MPP和Batch進行結合

---

我們現在可以看到兩個架構的優點和短板。MPP是更快的，但是有兩個關鍵痛點——短板效應和併發限制。而對於像MapReduce這樣的批處理系統，我們需要花費時間來儲存中間資料到磁碟上，但與此同時，我們獲得了更高的擴充套件度而因此可以獲得遠遠大於MPP的叢集規模。我們如何才能將兩者結合來獲得MPP低延遲和高速處理，使用batch-like的設計來降低短板效應和併發度低的問題？我想如果我告訴你答案是新的Apache HAWQ的架構你是不會驚訝的。

再一次提出問題，MPP的查詢是如何執行的？通過一定數量的平行執行的程式執行完全相同的程式碼，程式數目和叢集的節點數量是完全一致的，在每個節點上處理本地資料。但是，當我們介紹HDFS的時候，你不會把資料和本地Executor繫結在一起，這也就意味著你可以擺脫Executor數目的限制，你也就不需要在固定的節點上處理本地存在的資料(在傳統MPP上，你不能處理遠端節點的資料).為什麼？因為HDFS預設對同樣的block儲存3個備份，也就意味著叢集中至少有3個節點上，你可以選擇建立一個Executor並處理本地的資料。並且，HDFS支援遠端讀取資料，也就意味著至少有兩個機架上可以處理本地機架上的資料，這樣就可以通過最少的拓撲數來遠端獲取資料。

這也就是為什麼Apache HAWQ提出了”virtual segments”的概念——GreenPlum中的”segment” 是改進版的PostgreSQL資料庫中的一個單一例項，它在每個節點上存在一個，並且在每次查詢中產生”executor”程式。如果你有一個小的查詢，它可以被4個executors執行甚至是一個。如果你有一個大的查詢，你可以用100個甚至1000個executor執行。每個查詢仍然是以MPP風格對本地資料進行處理，而且不需要將中間資料寫入到HDD上，但是”virtual segments”允許executor執行在任何地方。下面是它的一個工作示例圖（不同顏色代表了不同的查詢，虛線代表了查詢中的shuffle操作）

這賦予了你以下的特性：

[1] 減輕MPP系統的短板問題：因為我們可以動態的新增節點和刪除節點。因此，嚴重的磁碟故障將不會影響整個叢集的效能，系統可以擁有比傳統MPP更大量級的叢集。現在，我們可以暫時的將一個故障節點從叢集中移除，那麼就不會有更多的executor在上面開始執行。並且，移除節點時不會有停機時間。

[2] 一次查詢現在被一個動態數量的executors進行執行，這也就帶來了更高的併發度，緩和了MPP系統的限制並加入了batch系統的靈活性。想象一下擁有50個節點的叢集，每個節點最多可以執行200個並行的程式。這就意味著你一共擁有了”50*200=10,000”個”execution slot”。你可以對20個查詢每個執行500個executor，也可以對200個查詢每個執行50個executor，甚至於你可以對1個查詢執行10000個executor。在這裡是完全靈活可控的。你也可能有一個大的查詢要使用4000個segments和600個小的查詢每個需要10個executors，這也是可以的。

[3] 資料管道的完美應用：實時的從一個executor中將資料轉移到另一個executor中。在執行階段，單獨的查詢仍然是MPP的，而不是batch。因此，不需要將中間資料儲存到本地磁碟中(無論何時，操作都允許資料管道)。這意味著我們離MPP的速度更近一步了。

[4] 像MPP那樣，我們仍然儘可能的使用本地資料來執行查詢，這一點可以通過HDFS的short-circuit read(當client和資料在同一節點上，可以通過直接讀取本地檔案來繞過DataNode，參考HDFS Short-Circuit Local Reads)來實現。每個executor會在擁有該檔案最多塊數的節點上建立並執行，這也最大化了執行效率。

MPP例子

Greenplum是一種基於PostgreSQL的分散式資料庫。其採用shared nothing架構（MPP），主機，作業系統，記憶體，儲存都是自我控制的，不存在共享。也就是每個節點都是一個單獨的資料庫。節點之間的資訊互動是通過節點網際網路絡實現。通過將資料分佈到多個節點上來實現規模資料的儲存，通過並行查詢處理來提高查詢效能。

這個就像是把小資料庫組織起來，聯合成一個大型資料庫。將資料分片，儲存在每個節點上。每個節點僅查詢自己的資料。所得到的結果再經過主節點處理得到最終結果。通過增加節點數目達到系統線性擴充套件。

elasticsearch也是一種MPP架構的資料庫，Presto、Impala等都是MPP engine，各節點不共享資源，每個executor可以獨自完成資料的讀取和計算，缺點在於怕stragglers，遇到後整個engine的效能下降到該straggler的能力，所謂木桶的短板，這也是為什麼MPP架構不適合異構的機器，要求各節點配置一樣。

Spark SQL應該還是算做Batching Processing, 中間計算結果需要落地到磁碟，所以查詢效率沒有MPP架構的引擎（如Impala）高。

 Hadoop解決的問題

---

Hadoop儲存技術是基於完全不同的方法構建的。它不是基於某種金鑰對資料進行分片，而是將資料分塊成固定（可配置）大小的塊，並在節點之間進行拆分。塊很大，而且它們是隻讀的，也是整個檔案系統（HDFS）的。簡單地說，將100行的小表載入到MPP中會導致引擎根據表的鍵對資料進行切分，這樣在一個足夠大的叢集中，每個節點只儲存一行的可能性很大。相反，在HDFS中，整個小表將被寫入一個單獨的塊中，在datanode的檔案系統中它將被表示為一個檔案。

 

與MPP設計相比，Hadoop resource manager（YARN）為您提供了更細粒度的資源管理—與MPP相比，MapReduce作業不需要所有計算任務並行執行，因此，如果叢集的另一部分被完全利用，您甚至可以在單個節點上執行的一組任務中處理大量資料。它還具有一系列很好的特性，如可擴充套件性、支援長壽命容器等。但事實上，它比MPP資源管理器慢，有時在管理併發性方面不太好。

像Impala和HAWQ這樣的解決方案就在這個邊緣的另一邊，它們是Hadoop之上的MPP執行引擎，處理HDFS中儲存的資料。與其他MPP引擎一樣，它們可以為查詢提供更低的延遲和更短的處理時間，同時降低可伸縮性和穩定性：

 

SparkSQL是介於MapReduce和MPP與Hadoop方法之間的另一頭猛獸，它試圖從兩個世界中獲得最好的結果，但也有自己的缺點。與MR類似，它將工作分成一組單獨安排的任務，從而提供更好的穩定性。與MPP一樣，它嘗試在執行階段之間傳輸資料以加快處理速度。此外，它還使用MPP（及其impalad和HAWQ段）所熟悉的固定執行器概念來減少查詢的延遲。但是它也結合了這些解決方案的缺點——沒有MPP那麼快，沒有MapReduce那麼穩定和可伸縮。

MPP和Hadoop的區別

---

 

小結

---

MPP和Batch架構，正在逐漸走向融合，Batch架構確實在實時響應性方面是缺點，同樣的MPP架構由於擴充套件性和木桶效應導致叢集規模不能很大。

如果對擴充套件性有著更高要求，可以選擇Batch架構，如果你希望提供更快的查詢選擇MPP架構。我不想過多討論更多HAWQ(歷史包袱)，因為SQL on Hadoop已經出現太多失敗的專案，而HAWQ的出現給我們提供了新思路和方向，Batch+MPP融合架構。目前基於Hadoop發展起來的各種Batch/Stream/MPP系統都在努力解決問題，為未來新型資料分析方法提供更多樣化的解決方案。

包括一個很敏感的話題，Hadoop上雲，我們慢慢討論。

就因為忍受不了Batch系統，我才面帶領團隊研究DataFlow產品，解決Batch面對今天日益嚴峻的實時性資料分析響應問題，DataFlow產品會完全取代ETL，讓資料一直在流，流動中被處理，並且被高效處理、實時反饋。

我在Clickhouse似乎看到的新型OLAP資料倉儲的未來，雖然還有很多缺陷和問題需要解決完善.

目前OLAP分散式計算引擎系統發展的方向：

Batch    MapReduce -> Spark/Tez

Stream   SparkStreaming -> Flink Streams -> Kafka KSQL

Batch + MPP  Greenplum/HP Vertica -> Dremel -> Impala/Drill/PrestoDB/HAWQ

Real-time Storage(Search/KV)  Druid.io/ElesticSearch/CrateDB/Hbase

目前一分鐘上百萬資料實時入庫，實時查詢系統屬於Real-time Storage(Search/KV)場景。