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

這個問題不少小伙伴在面試時都遇到過，因為對MPP這個概念了解較少，不少人都卡殼了，但是我們常用的大數(shù)據(jù)計算引擎有很多都是MPP架構的，像我們熟悉的Impala、ClickHouse、Druid、Doris等都是MPP架構。

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

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

一、MPP架構

MPP是系統(tǒng)架構角度的一種服務器分類方法。

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

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

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

先了解下這三種結構：

1． SMP

即對稱多處理器結構，就是指服務器的多個CPU對稱工作，無主次或從屬關系。SMP服務器的主要特征是共享，系統(tǒng)中的所有資源（如CPU、內存、I／O等）都是共享的。也正是由于這種特征，導致了SMP服務器的主要問題，即擴展能力非常有限。

2． NUMA

即非一致存儲訪問結構。這種結構就是為了解決SMP擴展能力不足的問題，利用NUMA技術，可以把幾十個CPU組合在一臺服務器內。NUMA的基本特征是擁有多個CPU模塊，節(jié)點之間可以通過互聯(lián)模塊進行連接和信息交互，所以，每個CPU可以訪問整個系統(tǒng)的內存（這是與MPP系統(tǒng)的重要區(qū)別）。但是訪問的速度是不一樣的，因為CPU訪問本地內存的速度遠遠高于系統(tǒng)內其他節(jié)點的內存速度，這也是非一致存儲訪問NUMA的由來。

這種結構也有一定的缺陷，由于訪問異地內存的時延遠遠超過訪問本地內存，因此，當CPU數(shù)量增加時，系統(tǒng)性能無法線性增加。

3． MPP

即大規(guī)模并行處理結構。MPP的系統(tǒng)擴展和NUMA不同，MPP是由多臺SMP服務器通過一定的節(jié)點互聯(lián)網(wǎng)絡進行連接，協(xié)同工作，完成相同的任務，從用戶的角度來看是一個服務器系統(tǒng)。每個節(jié)點只訪問自己的資源，所以是一種完全無共享（Share Nothing）結構。

MPP結構擴展能力最強，理論可以無限擴展。由于MPP是多臺SPM服務器連接的，每個節(jié)點的CPU不能訪問另一個節(jié)點內存，所以也不存在異地訪問的問題。

MPP架構圖：

MPP架構

每個節(jié)點內的CPU不能訪問另一個節(jié)點的內存，節(jié)點之間的信息交互是通過節(jié)點互聯(lián)網(wǎng)絡實現(xiàn)的，這個過程稱為數(shù)據(jù)重分配。

但是MPP服務器需要一種復雜的機制來調度和平衡各個節(jié)點的負載和并行處理過程。目前，一些基于MPP技術的服務器往往通過系統(tǒng)級軟件（如數(shù)據(jù)庫）來屏蔽這種復雜性。舉個例子，Teradata就是基于MPP技術的一個關系數(shù)據(jù)庫軟件（這是最早采用MPP架構的數(shù)據(jù)庫），基于此數(shù)據(jù)庫來開發(fā)應用時，不管后臺服務器由多少節(jié)點組成，開發(fā)人員面對的都是同一個數(shù)據(jù)庫系統(tǒng)，而無需考慮如何調度其中某幾個節(jié)點的負載。

MPP架構特征：

任務并行執(zhí)行；數(shù)據(jù)分布式存儲（本地化）；分布式計算；高并發(fā)，單個節(jié)點并發(fā)能力大于300用戶；橫向擴展，支持集群節(jié)點的擴容；Shared Nothing（完全無共享）架構。

NUMA和MPP區(qū)別：

二者有許多相似之處，首先NUMA和MPP都是由多個節(jié)點組成的；其次每個節(jié)點都有自己的CPU，內存，I／O等；都可以都過節(jié)點互聯(lián)機制進行信息交互。

那它們的區(qū)別是什么呢，首先是節(jié)點互聯(lián)機制不同，NUMA的節(jié)點互聯(lián)是在同一臺物理服務器內部實現(xiàn)的，MPP的節(jié)點互聯(lián)是在不同的SMP服務器外部通過I／O實現(xiàn)的。

其次是內存訪問機制不同，在NUMA服務器內部，任何一個CPU都可以訪問整個系統(tǒng)的內存，但異地內存訪問的性能遠遠低于本地內存訪問，因此，在開發(fā)應用程序時應該盡量避免異地內存訪問。而在MPP服務器中，每個節(jié)點只訪問本地內存，不存在異地內存訪問問題。

二、批處理架構和MPP架構

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

相同點：

批處理架構與MPP架構都是分布式并行處理，將任務并行的分散到多個服務器和節(jié)點上，在每個節(jié)點上計算完成后，將各自部分的結果匯總在一起得到最終的結果。

不同點：

批處理架構和MPP架構的不同點可以舉例來說：我們執(zhí)行一個任務，首先這個任務會被分成多個task執(zhí)行，對于MapReduce來說，這些tasks被隨機的分配在空閑的Executor上；而對于MPP架構的引擎來說，每個處理數(shù)據(jù)的task被綁定到持有該數(shù)據(jù)切片的指定Executor上。

正是由于以上的不同，使得兩種架構有各自優(yōu)勢也有各自缺陷：

批處理的優(yōu)勢：

對于批處理架構來說，如果某個Executor執(zhí)行過慢，那么這個Executor會慢慢分配到更少的task執(zhí)行，批處理架構有個推測執(zhí)行策略，推測出某個Executor執(zhí)行過慢或者有故障，則在接下來分配task時就會較少的分配給它或者直接不分配，這樣就不會因為某個節(jié)點出現(xiàn)問題而導致集群的性能受限。

批處理的缺陷：

任何事情都是有代價的，對于批處理而言，它的優(yōu)勢也造成了它的缺點，會將中間結果寫入到磁盤中，這嚴重限制了處理數(shù)據(jù)的性能。

MPP的優(yōu)勢：

MPP架構不需要將中間數(shù)據(jù)寫入磁盤，因為一個單一的Executor只處理一個單一的task，因此可以簡單直接將數(shù)據(jù)stream到下一個執(zhí)行階段。這個過程稱為pipelining，它提供了很大的性能提升。

MPP的缺陷：

對于MPP架構來說，因為task和Executor是綁定的，如果某個Executor執(zhí)行過慢或故障，將會導致整個集群的性能就會受限于這個故障節(jié)點的執(zhí)行速度（所謂木桶的短板效應），所以MPP架構的最大缺陷就是——短板效應。另一點，集群中的節(jié)點越多，則某個節(jié)點出現(xiàn)問題的概率越大，而一旦有節(jié)點出現(xiàn)問題，對于MPP架構來說，將導致整個集群性能受限，所以一般實際生產中MPP架構的集群節(jié)點不易過多。

舉個例子來說下兩種架構的數(shù)據(jù)落盤：要實現(xiàn)兩個大表的join操作，對于批處理而言，如Spark將會寫磁盤三次（第一次寫入：表1根據(jù)join key進行shuffle；第二次寫入：表2根據(jù)join key進行shuffle；第三次寫入：Hash表寫入磁盤）， 而MPP只需要一次寫入（Hash表寫入）。這是因為MPP將mapper和reducer同時運行，而MapReduce將它們分成有依賴關系的tasks（DAG），這些task是異步執(zhí)行的，因此必須通過寫入中間數(shù)據(jù)共享內存來解決數(shù)據(jù)的依賴。

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

兩個架構的優(yōu)勢和缺陷都很明顯，并且它們有互補關系，如果我們能將二者結合起來使用，是不是就能發(fā)揮各自最大的優(yōu)勢。目前批處理和MPP也確實正在逐漸走向融合，也已經(jīng)有了一些設計方案，技術成熟后，可能會風靡大數(shù)據(jù)領域，我們拭目以待！

三、 MPP架構的OLAP引擎

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

采用MPP架構的OLAP引擎分為兩類，一類是自身不存儲數(shù)據(jù)，只負責計算的引擎；一類是自身既存儲數(shù)據(jù)，也負責計算的引擎。

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

1． Impala

Apache Impala是采用MPP架構的查詢引擎，本身不存儲任何數(shù)據(jù)，直接使用內存進行計算，兼顧數(shù)據(jù)倉庫，具有實時，批處理，多并發(fā)等優(yōu)點。

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

Impala支持共享Hive Metastore，但沒有再使用緩慢的 Hive＋MapReduce 批處理，而是通過使用與商用并行關系數(shù)據(jù)庫中類似的分布式查詢引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分組成），可以直接從 HDFS 或 HBase 中用 SELECT、JOIN 和統(tǒng)計函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲。

Impala經(jīng)常搭配存儲引擎Kudu一起提供服務，這么做最大的優(yōu)勢是查詢比較快，并且支持數(shù)據(jù)的Update和Delete。

2． Presto

Presto是一個分布式的采用MPP架構的查詢引擎，本身并不存儲數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源，并且支持跨數(shù)據(jù)源的級聯(lián)查詢。Presto是一個OLAP的工具，擅長對海量數(shù)據(jù)進行復雜的分析；但是對于OLTP場景，并不是Presto所擅長，所以不要把Presto當做數(shù)據(jù)庫來使用。

Presto是一個低延遲高并發(fā)的內存計算引擎。需要從其他數(shù)據(jù)源獲取數(shù)據(jù)來進行運算分析，它可以連接多種數(shù)據(jù)源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。

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

1． ClickHouse

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

它自包含了存儲和計算能力，完全自主實現(xiàn)了高可用，而且支持完整的SQL語法包括JOIN等，技術上有著明顯優(yōu)勢。相比于hadoop體系，以數(shù)據(jù)庫的方式來做大數(shù)據(jù)處理更加簡單易用，學習成本低且靈活度高。當前社區(qū)仍舊在迅猛發(fā)展中，并且在國內社區(qū)也非常火熱，各個大廠紛紛跟進大規(guī)模使用。

ClickHouse在計算層做了非常細致的工作，竭盡所能榨干硬件能力，提升查詢速度。它實現(xiàn)了單機多核并行、分布式計算、向量化執(zhí)行與SIMD指令、代碼生成等多種重要技術。

ClickHouse從OLAP場景需求出發(fā)，定制開發(fā)了一套全新的高效列式存儲引擎，并且實現(xiàn)了數(shù)據(jù)有序存儲、主鍵索引、稀疏索引、數(shù)據(jù)Sharding、數(shù)據(jù)Partitioning、TTL、主備復制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎。

2． Doris

Doris是百度主導的，根據(jù)Google Mesa論文和Impala項目改寫的一個大數(shù)據(jù)分析引擎，是一個海量分布式 KV 存儲系統(tǒng)，其設計目標是支持中等規(guī)模高可用可伸縮的 KV 存儲集群。

Doris可以實現(xiàn)海量存儲，線性伸縮、平滑擴容，自動容錯、故障轉移，高并發(fā)，且運維成本低。部署規(guī)模，建議部署4－100＋臺服務器。

Doris3 的主要架構：DT（Data Transfer）負責數(shù)據(jù)導入、DS（Data Seacher）模塊負責數(shù)據(jù)查詢、DM（Data Master）模塊負責集群元數(shù)據(jù)管理，數(shù)據(jù)則存儲在 Armor 分布式 Key－Value 引擎中。Doris3 依賴 ZooKeeper 存儲元數(shù)據(jù)，從而其他模塊依賴 ZooKeeper 做到了無狀態(tài)，進而整個系統(tǒng)能夠做到無故障單點。

3． Druid

Druid是一個開源、分布式、面向列式存儲的實時分析數(shù)據(jù)存儲系統(tǒng)。

Druid的關鍵特性如下：

亞秒級的OLAP查詢分析：采用了列式存儲、倒排索引、位圖索引等關鍵技術；在亞秒級別內完成海量數(shù)據(jù)的過濾、聚合以及多維分析等操作；實時流數(shù)據(jù)分析：Druid提供了實時流數(shù)據(jù)分析，以及高效實時寫入；實時數(shù)據(jù)在亞秒級內的可視化；豐富的數(shù)據(jù)分析功能：Druid提供了友好的可視化界面；SQL查詢語言；高可用性與高可拓展性：Druid工作節(jié)點功能單一，不相互依賴；Druid集群在管理、容錯、災備、擴容都很容易；

4． TiDB

TiDB 是 PingCAP 公司自主設計、研發(fā)的開源分布式關系型數(shù)據(jù)庫，是一款同時支持OLTP與OLAP的融合型分布式數(shù)據(jù)庫產品。

TiDB 兼容 MySQL 5．7 協(xié)議和 MySQL 生態(tài)等重要特性。目標是為用戶提供一站式 OLTP 、OLAP 、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數(shù)據(jù)規(guī)模較大等各種應用場景。

5． Greenplum

Greenplum 是在開源的 PostgreSQL 的基礎上采用了MPP架構的性能非常強大的關系型分布式數(shù)據(jù)庫。為了兼容Hadoop生態(tài)，又推出了HAWQ，分析引擎保留了Greenplum的高性能引擎，下層存儲不再采用本地硬盤而改用HDFS，規(guī)避本地硬盤可靠性差的問題，同時融入Hadoop生態(tài)。

3）常用的引擎對比

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

常見OLAP引擎對比

編輯：lyn