ClickHouse、Doris、 Impala等MPP架構詳解

我們常用的大資料計算引擎有很多都是MPP架構的，像我們熟悉的Impala、ClickHouse、Druid、Doris等都是MPP架構。

採用MPP架構的很多OLAP引擎號稱：億級秒開。

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

一、MPP架構

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

目前商用的伺服器分類大體有三種：

1. SMP(對稱多處理器結構)

2. NUMA(非一致儲存訪問結構)

3. MPP(大規模並行處理結構)

我們今天的主角是 MPP，因為隨著分散式、並行化技術成熟應用，MPP引擎逐漸表現出強大的高吞吐、低時延計算能力，有很多采用MPP架構的引擎都能達到“億級秒開”。

先了解下這三種結構：

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架構圖：

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伺服器中，每個節點只訪問本地記憶體，不存在異地記憶體訪問問題。

二、批處理架構和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也確實正在逐漸走向融合，也已經有了一些設計方案，技術成熟後，可能會風靡大資料領域，我們拭目以待!

三、 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引擎對比：

常見OLAP引擎對比