MPP大規模並行處理架構詳解

進入主頁，點擊右上角「設爲星標」web

比別人更快接收好文章面試

面試官：說下你知道的MPP架構的計算引擎？
sql

這個問題很多小夥伴在面試時都遇到過，由於對MPP這個概念瞭解較少，很多人都卡殼了，可是咱們經常使用的大數據計算引擎有不少都是MPP架構的，像咱們熟悉的Impala、ClickHouse、Druid、Doris等都是MPP架構。數據庫

採用MPP架構的不少OLAP引擎號稱：億級秒開。服務器

本文分爲三部分講解，第一部分詳解MPP架構，第二部分剖析MPP架構與批處理架構的異同點，第三部分是採用MPP架構的OLAP引擎介紹。微信

1、MPP架構

MPP是系統架構角度的一種服務器分類方法。網絡

目前商用的服務器分類大致有三種：架構

SMP（對稱多處理器結構）
NUMA（非一致存儲訪問結構）
MPP（大規模並行處理結構）

咱們今天的主角是 MPP，由於隨着分佈式、並行化技術成熟應用，MPP引擎逐漸表現出強大的高吞吐、低時延計算能力，有不少採用MPP架構的引擎都能達到「億級秒開」。併發

先了解下這三種結構：app

1. SMP

即對稱多處理器結構，就是指服務器的多個CPU對稱工做，無主次或從屬關係。SMP服務器的主要特徵是共享，系統中的全部資源（如CPU、內存、I/O等）都是共享的。也正是因爲這種特徵，致使了SMP服務器的主要問題，即擴展能力很是有限。

2. NUMA

即非一致存儲訪問結構。這種結構就是爲了解決SMP擴展能力不足的問題，利用NUMA技術，能夠把幾十個CPU組合在一臺服務器內。NUMA的基本特徵是擁有多個CPU模塊，節點之間能夠經過互聯模塊進行鏈接和信息交互，因此，每一個CPU能夠訪問整個系統的內存（這是與MPP系統的重要區別）。可是訪問的速度是不同的，由於CPU訪問本地內存的速度遠遠高於系統內其餘節點的內存速度，這也是非一致存儲訪問NUMA的由來。

這種結構也有必定的缺陷，因爲訪問異地內存的時延遠遠超過訪問本地內存，所以，當CPU數量增長時，系統性能沒法線性增長。

3. MPP

即大規模並行處理結構。MPP的系統擴展和NUMA不一樣，MPP是由多臺SMP服務器經過必定的節點互聯網絡進行鏈接，協同工做，完成相同的任務，從用戶的角度來看是一個服務器系統。每一個節點只訪問本身的資源，因此是一種徹底無共享（Share Nothing）結構。

MPP結構擴展能力最強，理論能夠無限擴展。因爲MPP是多臺SPM服務器鏈接的，每一個節點的CPU不能訪問另外一個節點內存，因此也不存在異地訪問的問題。

MPP架構圖：

每一個節點內的CPU不能訪問另外一個節點的內存，節點之間的信息交互是經過節點互聯網絡實現的，這個過程稱爲數據重分配。

可是MPP服務器須要一種複雜的機制來調度和平衡各個節點的負載和並行處理過程。目前，一些基於MPP技術的服務器每每經過系統級軟件（如數據庫）來屏蔽這種複雜性。舉個例子，Teradata就是基於MPP技術的一個關係數據庫軟件（這是最先採用MPP架構的數據庫），基於此數據庫來開發應用時，無論後臺服務器由多少節點組成，開發人員面對的都是同一個數據庫系統，而無需考慮如何調度其中某幾個節點的負載。

MPP架構特徵：

任務並行執行;
數據分佈式存儲(本地化);
分佈式計算;
高併發，單個節點併發能力大於300用戶;
橫向擴展，支持集羣節點的擴容;
Shared Nothing（徹底無共享）架構。

NUMA和MPP區別：

兩者有許多類似之處，首先NUMA和MPP都是由多個節點組成的；其次每一個節點都有本身的CPU，內存，I/O等；均可以都過節點互聯機制進行信息交互。

那它們的區別是什麼呢，首先是節點互聯機制不一樣，NUMA的節點互聯是在同一臺物理服務器內部實現的，MPP的節點互聯是在不一樣的SMP服務器外部經過I/O實現的。

其次是內存訪問機制不一樣，在NUMA服務器內部，任何一個CPU均可以訪問整個系統的內存，但異地內存訪問的性能遠遠低於本地內存訪問，所以，在開發應用程序時應該儘可能避免異地內存訪問。而在MPP服務器中，每一個節點只訪問本地內存，不存在異地內存訪問問題。

2、批處理架構和MPP架構

批處理架構（如 MapReduce）與MPP架構的異同點，以及它們各自的優缺點是什麼呢？

相同點：

批處理架構與MPP架構都是分佈式並行處理，將任務並行的分散到多個服務器和節點上，在每一個節點上計算完成後，將各自部分的結果彙總在一塊兒獲得最終的結果。

不一樣點：

批處理架構和MPP架構的不一樣點能夠舉例來講：咱們執行一個任務，首先這個任務會被分紅多個task執行，對於MapReduce來講，這些tasks被隨機的分配在空閒的Executor上；而對於MPP架構的引擎來講，每一個處理數據的task被綁定到持有該數據切片的指定Executor上。

正是因爲以上的不一樣，使得兩種架構有各自優點也有各自缺陷：

批處理的優點：

對於批處理架構來講，若是某個Executor執行過慢，那麼這個Executor會慢慢分配到更少的task執行，批處理架構有個推測執行策略，推測出某個Executor執行過慢或者有故障，則在接下來分配task時就會較少的分配給它或者直接不分配，這樣就不會由於某個節點出現問題而致使集羣的性能受限。

批處理的缺陷：

任何事情都是有代價的，對於批處理而言，它的優點也形成了它的缺點，會將中間結果寫入到磁盤中，這嚴重限制了處理數據的性能。

MPP的優點：

MPP架構不須要將中間數據寫入磁盤，由於一個單一的Executor只處理一個單一的task，所以能夠簡單直接將數據stream到下一個執行階段。這個過程稱爲pipelining，它提供了很大的性能提高。

MPP的缺陷：

對於MPP架構來講，由於task和Executor是綁定的，若是某個Executor執行過慢或故障，將會致使整個集羣的性能就會受限於這個故障節點的執行速度(所謂木桶的短板效應)，因此MPP架構的最大缺陷就是——短板效應。另外一點，集羣中的節點越多，則某個節點出現問題的機率越大，而一旦有節點出現問題，對於MPP架構來講，將致使整個集羣性能受限，因此通常實際生產中MPP架構的集羣節點不易過多。

舉個例子來講下兩種架構的數據落盤：要實現兩個大表的join操做，對於批處理而言，如Spark將會寫磁盤三次(第一次寫入：表1根據join key進行shuffle；第二次寫入：表2根據join key進行shuffle；第三次寫入：Hash表寫入磁盤)，而MPP只須要一次寫入(Hash表寫入)。這是由於MPP將mapper和reducer同時運行，而MapReduce將它們分紅有依賴關係的tasks(DAG),這些task是異步執行的，所以必須經過寫入中間數據共享內存來解決數據的依賴。

批處理架構和MPP架構融合：

兩個架構的優點和缺陷都很明顯，而且它們有互補關係，若是咱們能將兩者結合起來使用，是否是就能發揮各自最大的優點。目前批處理和MPP也確實正在逐漸走向融合，也已經有了一些設計方案，技術成熟後，可能會風靡大數據領域，咱們拭目以待！

3、 MPP架構的OLAP引擎

採用MPP架構的OLAP引擎有不少，下面只選擇常見的幾個引擎對比下，可爲公司的技術選型提供參考。

採用MPP架構的OLAP引擎分爲兩類，一類是自身不存儲數據，只負責計算的引擎；一類是自身既存儲數據，也負責計算的引擎。

1）只負責計算，不負責存儲的引擎

1. Impala

Apache Impala是採用MPP架構的查詢引擎，自己不存儲任何數據，直接使用內存進行計算，兼顧數據倉庫，具備實時，批處理，多併發等優勢。

提供了類SQL（類Hsql）語法，在多用戶場景下也能擁有較高的響應速度和吞吐量。它是由Java和C++實現的，Java提供的查詢交互的接口和實現，C++實現了查詢引擎部分。

Impala支持共享Hive Metastore，但沒有再使用緩慢的 Hive+MapReduce 批處理，而是經過使用與商用並行關係數據庫中相似的分佈式查詢引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分組成），能夠直接從 HDFS 或 HBase 中用 SELECT、JOIN 和統計函數查詢數據，從而大大下降了延遲。

Impala常常搭配存儲引擎Kudu一塊兒提供服務，這麼作最大的優點是查詢比較快，而且支持數據的Update和Delete。

2. Presto

Presto是一個分佈式的採用MPP架構的查詢引擎，自己並不存儲數據，可是能夠接入多種數據源，而且支持跨數據源的級聯查詢。Presto是一個OLAP的工具，擅長對海量數據進行復雜的分析；可是對於OLTP場景，並非Presto所擅長，因此不要把Presto當作數據庫來使用。

Presto是一個低延遲高併發的內存計算引擎。須要從其餘數據源獲取數據來進行運算分析，它能夠鏈接多種數據源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。

2）既負責計算，又負責存儲的引擎

1. ClickHouse

ClickHouse是近年來備受關注的開源列式數據庫，主要用於數據分析（OLAP）領域。

它自包含了存儲和計算能力，徹底自主實現了高可用，並且支持完整的SQL語法包括JOIN等，技術上有着明顯優點。相比於hadoop體系，以數據庫的方式來作大數據處理更加簡單易用，學習成本低且靈活度高。當前社區仍舊在迅猛發展中，而且在國內社區也很是火熱，各個大廠紛紛跟進大規模使用。

ClickHouse在計算層作了很是細緻的工做，竭盡所能榨乾硬件能力，提高查詢速度。它實現了單機多核並行、分佈式計算、向量化執行與SIMD指令、代碼生成等多種重要技術。

ClickHouse從OLAP場景需求出發，定製開發了一套全新的高效列式存儲引擎，而且實現了數據有序存儲、主鍵索引、稀疏索引、數據Sharding、數據Partitioning、TTL、主備複製等豐富功能。以上功能共同爲ClickHouse極速的分析性能奠基了基礎。

2. Doris

Doris是百度主導的，根據Google Mesa論文和Impala項目改寫的一個大數據分析引擎，是一個海量分佈式 KV 存儲系統，其設計目標是支持中等規模高可用可伸縮的 KV 存儲集羣。

Doris能夠實現海量存儲，線性伸縮、平滑擴容，自動容錯、故障轉移，高併發，且運維成本低。部署規模，建議部署4-100+臺服務器。

Doris3 的主要架構：DT（Data Transfer）負責數據導入、DS（Data Seacher）模塊負責數據查詢、DM（Data Master）模塊負責集羣元數據管理，數據則存儲在 Armor 分佈式 Key-Value 引擎中。Doris3 依賴 ZooKeeper 存儲元數據，從而其餘模塊依賴 ZooKeeper 作到了無狀態，進而整個系統可以作到無端障單點。

3. Druid

Druid是一個開源、分佈式、面向列式存儲的實時分析數據存儲系統。

Druid的關鍵特性以下：

亞秒級的OLAP查詢分析：採用了 列式存儲、倒排索引、位圖索引等關鍵技術；
在亞秒級別內完成海量數據的過濾、聚合以及多維分析等操做；
實時流數據分析：Druid提供了實時流數據分析，以及高效實時寫入；
實時數據在亞秒級內的可視化；
豐富的數據分析功能：Druid提供了友好的可視化界面；
SQL查詢語言；
高可用性與高可拓展性：

Druid工做節點功能單一，不相互依賴；
Druid集羣在管理、容錯、災備、擴容都很容易；

4. TiDB

TiDB 是 PingCAP 公司自主設計、研發的開源分佈式關係型數據庫，是一款同時支持OLTP與OLAP的融合型分佈式數據庫產品。

TiDB 兼容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是爲用戶提供一站式 OLTP 、OLAP 、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各類應用場景。

5. Greenplum

Greenplum 是在開源的 PostgreSQL 的基礎上採用了MPP架構的性能很是強大的關係型分佈式數據庫。爲了兼容Hadoop生態，又推出了HAWQ，分析引擎保留了Greenplum的高性能引擎，下層存儲再也不採用本地硬盤而改用HDFS，規避本地硬盤可靠性差的問題，同時融入Hadoop生態。

3）經常使用的引擎對比

一張圖總結下經常使用的OLAP引擎對比：

-- END --

掃描二維碼

收穫更多技術

五分鐘學大數據

點個在看，支持一下

本文分享自微信公衆號 - 五分鐘學大數據（gh_d4a7af3ecd50）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。