MPP大規(guī)模并行處理架構(gòu)詳解
本文轉(zhuǎn)載自微信公眾號(hào)「五分鐘學(xué)大數(shù)據(jù)」,作者園陌。轉(zhuǎn)載本文請(qǐng)聯(lián)系五分鐘學(xué)大數(shù)據(jù)公眾號(hào)。
面試官:說(shuō)下你知道的MPP架構(gòu)的計(jì)算引擎?
這個(gè)問(wèn)題不少小伙伴在面試時(shí)都遇到過(guò),因?yàn)閷?duì)MPP這個(gè)概念了解較少,不少人都卡殼了,但是我們常用的大數(shù)據(jù)計(jì)算引擎有很多都是MPP架構(gòu)的,像我們熟悉的Impala、ClickHouse、Druid、Doris等都是MPP架構(gòu)。
采用MPP架構(gòu)的很多OLAP引擎號(hào)稱(chēng):億級(jí)秒開(kāi)。
本文分為三部分講解,第一部分詳解MPP架構(gòu),第二部分剖析MPP架構(gòu)與批處理架構(gòu)的異同點(diǎn),第三部分是采用MPP架構(gòu)的OLAP引擎介紹。
一、MPP架構(gòu)
MPP是系統(tǒng)架構(gòu)角度的一種服務(wù)器分類(lèi)方法。
目前商用的服務(wù)器分類(lèi)大體有三種:
SMP(對(duì)稱(chēng)多處理器結(jié)構(gòu))
NUMA(非一致存儲(chǔ)訪(fǎng)問(wèn)結(jié)構(gòu))
MPP(大規(guī)模并行處理結(jié)構(gòu))
我們今天的主角是 MPP,因?yàn)殡S著分布式、并行化技術(shù)成熟應(yīng)用,MPP引擎逐漸表現(xiàn)出強(qiáng)大的高吞吐、低時(shí)延計(jì)算能力,有很多采用MPP架構(gòu)的引擎都能達(dá)到“億級(jí)秒開(kāi)”。
先了解下這三種結(jié)構(gòu):
1. SMP
即對(duì)稱(chēng)多處理器結(jié)構(gòu),就是指服務(wù)器的多個(gè)CPU對(duì)稱(chēng)工作,無(wú)主次或從屬關(guān)系。SMP服務(wù)器的主要特征是共享,系統(tǒng)中的所有資源(如CPU、內(nèi)存、I/O等)都是共享的。也正是由于這種特征,導(dǎo)致了SMP服務(wù)器的主要問(wèn)題,即擴(kuò)展能力非常有限。
2. NUMA
即非一致存儲(chǔ)訪(fǎng)問(wèn)結(jié)構(gòu)。這種結(jié)構(gòu)就是為了解決SMP擴(kuò)展能力不足的問(wèn)題,利用NUMA技術(shù),可以把幾十個(gè)CPU組合在一臺(tái)服務(wù)器內(nèi)。NUMA的基本特征是擁有多個(gè)CPU模塊,節(jié)點(diǎn)之間可以通過(guò)互聯(lián)模塊進(jìn)行連接和信息交互,所以,每個(gè)CPU可以訪(fǎng)問(wèn)整個(gè)系統(tǒng)的內(nèi)存(這是與MPP系統(tǒng)的重要區(qū)別)。但是訪(fǎng)問(wèn)的速度是不一樣的,因?yàn)镃PU訪(fǎng)問(wèn)本地內(nèi)存的速度遠(yuǎn)遠(yuǎn)高于系統(tǒng)內(nèi)其他節(jié)點(diǎn)的內(nèi)存速度,這也是非一致存儲(chǔ)訪(fǎng)問(wèn)NUMA的由來(lái)。
這種結(jié)構(gòu)也有一定的缺陷,由于訪(fǎng)問(wèn)異地內(nèi)存的時(shí)延遠(yuǎn)遠(yuǎn)超過(guò)訪(fǎng)問(wèn)本地內(nèi)存,因此,當(dāng)CPU數(shù)量增加時(shí),系統(tǒng)性能無(wú)法線(xiàn)性增加。
3. MPP
即大規(guī)模并行處理結(jié)構(gòu)。MPP的系統(tǒng)擴(kuò)展和NUMA不同,MPP是由多臺(tái)SMP服務(wù)器通過(guò)一定的節(jié)點(diǎn)互聯(lián)網(wǎng)絡(luò)進(jìn)行連接,協(xié)同工作,完成相同的任務(wù),從用戶(hù)的角度來(lái)看是一個(gè)服務(wù)器系統(tǒng)。每個(gè)節(jié)點(diǎn)只訪(fǎng)問(wèn)自己的資源,所以是一種完全無(wú)共享(Share Nothing)結(jié)構(gòu)。
MPP結(jié)構(gòu)擴(kuò)展能力最強(qiáng),理論可以無(wú)限擴(kuò)展。由于MPP是多臺(tái)SPM服務(wù)器連接的,每個(gè)節(jié)點(diǎn)的CPU不能訪(fǎng)問(wèn)另一個(gè)節(jié)點(diǎn)內(nèi)存,所以也不存在異地訪(fǎng)問(wèn)的問(wèn)題。
MPP架構(gòu)圖:
MPP架構(gòu)
每個(gè)節(jié)點(diǎn)內(nèi)的CPU不能訪(fǎng)問(wèn)另一個(gè)節(jié)點(diǎn)的內(nèi)存,節(jié)點(diǎn)之間的信息交互是通過(guò)節(jié)點(diǎn)互聯(lián)網(wǎng)絡(luò)實(shí)現(xiàn)的,這個(gè)過(guò)程稱(chēng)為數(shù)據(jù)重分配。
但是MPP服務(wù)器需要一種復(fù)雜的機(jī)制來(lái)調(diào)度和平衡各個(gè)節(jié)點(diǎn)的負(fù)載和并行處理過(guò)程。目前,一些基于MPP技術(shù)的服務(wù)器往往通過(guò)系統(tǒng)級(jí)軟件(如數(shù)據(jù)庫(kù))來(lái)屏蔽這種復(fù)雜性。舉個(gè)例子,Teradata就是基于MPP技術(shù)的一個(gè)關(guān)系數(shù)據(jù)庫(kù)軟件(這是最早采用MPP架構(gòu)的數(shù)據(jù)庫(kù)),基于此數(shù)據(jù)庫(kù)來(lái)開(kāi)發(fā)應(yīng)用時(shí),不管后臺(tái)服務(wù)器由多少節(jié)點(diǎn)組成,開(kāi)發(fā)人員面對(duì)的都是同一個(gè)數(shù)據(jù)庫(kù)系統(tǒng),而無(wú)需考慮如何調(diào)度其中某幾個(gè)節(jié)點(diǎn)的負(fù)載。
MPP架構(gòu)特征:
- 任務(wù)并行執(zhí)行;
- 數(shù)據(jù)分布式存儲(chǔ)(本地化);
- 分布式計(jì)算;
- 高并發(fā),單個(gè)節(jié)點(diǎn)并發(fā)能力大于300用戶(hù);
- 橫向擴(kuò)展,支持集群節(jié)點(diǎn)的擴(kuò)容;
- Shared Nothing(完全無(wú)共享)架構(gòu)。
NUMA和MPP區(qū)別:
二者有許多相似之處,首先NUMA和MPP都是由多個(gè)節(jié)點(diǎn)組成的;其次每個(gè)節(jié)點(diǎn)都有自己的CPU,內(nèi)存,I/O等;都可以都過(guò)節(jié)點(diǎn)互聯(lián)機(jī)制進(jìn)行信息交互。
那它們的區(qū)別是什么呢,首先是節(jié)點(diǎn)互聯(lián)機(jī)制不同,NUMA的節(jié)點(diǎn)互聯(lián)是在同一臺(tái)物理服務(wù)器內(nèi)部實(shí)現(xiàn)的,MPP的節(jié)點(diǎn)互聯(lián)是在不同的SMP服務(wù)器外部通過(guò)I/O實(shí)現(xiàn)的。
其次是內(nèi)存訪(fǎng)問(wèn)機(jī)制不同,在NUMA服務(wù)器內(nèi)部,任何一個(gè)CPU都可以訪(fǎng)問(wèn)整個(gè)系統(tǒng)的內(nèi)存,但異地內(nèi)存訪(fǎng)問(wèn)的性能遠(yuǎn)遠(yuǎn)低于本地內(nèi)存訪(fǎng)問(wèn),因此,在開(kāi)發(fā)應(yīng)用程序時(shí)應(yīng)該盡量避免異地內(nèi)存訪(fǎng)問(wèn)。而在MPP服務(wù)器中,每個(gè)節(jié)點(diǎn)只訪(fǎng)問(wèn)本地內(nèi)存,不存在異地內(nèi)存訪(fǎng)問(wèn)問(wèn)題。
二、批處理架構(gòu)和MPP架構(gòu)
批處理架構(gòu)(如 MapReduce)與MPP架構(gòu)的異同點(diǎn),以及它們各自的優(yōu)缺點(diǎn)是什么呢?
相同點(diǎn):
批處理架構(gòu)與MPP架構(gòu)都是分布式并行處理,將任務(wù)并行的分散到多個(gè)服務(wù)器和節(jié)點(diǎn)上,在每個(gè)節(jié)點(diǎn)上計(jì)算完成后,將各自部分的結(jié)果匯總在一起得到最終的結(jié)果。
不同點(diǎn):
批處理架構(gòu)和MPP架構(gòu)的不同點(diǎn)可以舉例來(lái)說(shuō):我們執(zhí)行一個(gè)任務(wù),首先這個(gè)任務(wù)會(huì)被分成多個(gè)task執(zhí)行,對(duì)于MapReduce來(lái)說(shuō),這些tasks被隨機(jī)的分配在空閑的Executor上;而對(duì)于MPP架構(gòu)的引擎來(lái)說(shuō),每個(gè)處理數(shù)據(jù)的task被綁定到持有該數(shù)據(jù)切片的指定Executor上。
正是由于以上的不同,使得兩種架構(gòu)有各自?xún)?yōu)勢(shì)也有各自缺陷:
- 批處理的優(yōu)勢(shì):
對(duì)于批處理架構(gòu)來(lái)說(shuō),如果某個(gè)Executor執(zhí)行過(guò)慢,那么這個(gè)Executor會(huì)慢慢分配到更少的task執(zhí)行,批處理架構(gòu)有個(gè)推測(cè)執(zhí)行策略,推測(cè)出某個(gè)Executor執(zhí)行過(guò)慢或者有故障,則在接下來(lái)分配task時(shí)就會(huì)較少的分配給它或者直接不分配,這樣就不會(huì)因?yàn)槟硞€(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題而導(dǎo)致集群的性能受限。
- 批處理的缺陷:
任何事情都是有代價(jià)的,對(duì)于批處理而言,它的優(yōu)勢(shì)也造成了它的缺點(diǎn),會(huì)將中間結(jié)果寫(xiě)入到磁盤(pán)中,這嚴(yán)重限制了處理數(shù)據(jù)的性能。
- MPP的優(yōu)勢(shì):
MPP架構(gòu)不需要將中間數(shù)據(jù)寫(xiě)入磁盤(pán),因?yàn)橐粋€(gè)單一的Executor只處理一個(gè)單一的task,因此可以簡(jiǎn)單直接將數(shù)據(jù)stream到下一個(gè)執(zhí)行階段。這個(gè)過(guò)程稱(chēng)為pipelining,它提供了很大的性能提升。
- MPP的缺陷:
對(duì)于MPP架構(gòu)來(lái)說(shuō),因?yàn)閠ask和Executor是綁定的,如果某個(gè)Executor執(zhí)行過(guò)慢或故障,將會(huì)導(dǎo)致整個(gè)集群的性能就會(huì)受限于這個(gè)故障節(jié)點(diǎn)的執(zhí)行速度(所謂木桶的短板效應(yīng)),所以MPP架構(gòu)的最大缺陷就是——短板效應(yīng)。另一點(diǎn),集群中的節(jié)點(diǎn)越多,則某個(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題的概率越大,而一旦有節(jié)點(diǎn)出現(xiàn)問(wèn)題,對(duì)于MPP架構(gòu)來(lái)說(shuō),將導(dǎo)致整個(gè)集群性能受限,所以一般實(shí)際生產(chǎn)中MPP架構(gòu)的集群節(jié)點(diǎn)不易過(guò)多。
舉個(gè)例子來(lái)說(shuō)下兩種架構(gòu)的數(shù)據(jù)落盤(pán):要實(shí)現(xiàn)兩個(gè)大表的join操作,對(duì)于批處理而言,如Spark將會(huì)寫(xiě)磁盤(pán)三次(第一次寫(xiě)入:表1根據(jù)join key進(jìn)行shuffle;第二次寫(xiě)入:表2根據(jù)join key進(jìn)行shuffle;第三次寫(xiě)入:Hash表寫(xiě)入磁盤(pán)), 而MPP只需要一次寫(xiě)入(Hash表寫(xiě)入)。這是因?yàn)镸PP將mapper和reducer同時(shí)運(yùn)行,而MapReduce將它們分成有依賴(lài)關(guān)系的tasks(DAG),這些task是異步執(zhí)行的,因此必須通過(guò)寫(xiě)入中間數(shù)據(jù)共享內(nèi)存來(lái)解決數(shù)據(jù)的依賴(lài)。
批處理架構(gòu)和MPP架構(gòu)融合:
兩個(gè)架構(gòu)的優(yōu)勢(shì)和缺陷都很明顯,并且它們有互補(bǔ)關(guān)系,如果我們能將二者結(jié)合起來(lái)使用,是不是就能發(fā)揮各自最大的優(yōu)勢(shì)。目前批處理和MPP也確實(shí)正在逐漸走向融合,也已經(jīng)有了一些設(shè)計(jì)方案,技術(shù)成熟后,可能會(huì)風(fēng)靡大數(shù)據(jù)領(lǐng)域,我們拭目以待!
三、 MPP架構(gòu)的OLAP引擎
采用MPP架構(gòu)的OLAP引擎有很多,下面只選擇常見(jiàn)的幾個(gè)引擎對(duì)比下,可為公司的技術(shù)選型提供參考。
采用MPP架構(gòu)的OLAP引擎分為兩類(lèi),一類(lèi)是自身不存儲(chǔ)數(shù)據(jù),只負(fù)責(zé)計(jì)算的引擎;一類(lèi)是自身既存儲(chǔ)數(shù)據(jù),也負(fù)責(zé)計(jì)算的引擎。
1)只負(fù)責(zé)計(jì)算,不負(fù)責(zé)存儲(chǔ)的引擎
1. Impala
Apache Impala是采用MPP架構(gòu)的查詢(xún)引擎,本身不存儲(chǔ)任何數(shù)據(jù),直接使用內(nèi)存進(jìn)行計(jì)算,兼顧數(shù)據(jù)倉(cāng)庫(kù),具有實(shí)時(shí),批處理,多并發(fā)等優(yōu)點(diǎn)。
提供了類(lèi)SQL(類(lèi)Hsql)語(yǔ)法,在多用戶(hù)場(chǎng)景下也能擁有較高的響應(yīng)速度和吞吐量。它是由Java和C++實(shí)現(xiàn)的,Java提供的查詢(xún)交互的接口和實(shí)現(xiàn),C++實(shí)現(xiàn)了查詢(xún)引擎部分。
Impala支持共享Hive Metastore,但沒(méi)有再使用緩慢的 Hive+MapReduce 批處理,而是通過(guò)使用與商用并行關(guān)系數(shù)據(jù)庫(kù)中類(lèi)似的分布式查詢(xún)引擎(由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分組成),可以直接從 HDFS 或 HBase 中用 SELECT、JOIN 和統(tǒng)計(jì)函數(shù)查詢(xún)數(shù)據(jù),從而大大降低了延遲。
Impala經(jīng)常搭配存儲(chǔ)引擎Kudu一起提供服務(wù),這么做最大的優(yōu)勢(shì)是查詢(xún)比較快,并且支持?jǐn)?shù)據(jù)的Update和Delete。
2. Presto
Presto是一個(gè)分布式的采用MPP架構(gòu)的查詢(xún)引擎,本身并不存儲(chǔ)數(shù)據(jù),但是可以接入多種數(shù)據(jù)源,并且支持跨數(shù)據(jù)源的級(jí)聯(lián)查詢(xún)。Presto是一個(gè)OLAP的工具,擅長(zhǎng)對(duì)海量數(shù)據(jù)進(jìn)行復(fù)雜的分析;但是對(duì)于OLTP場(chǎng)景,并不是Presto所擅長(zhǎng),所以不要把Presto當(dāng)做數(shù)據(jù)庫(kù)來(lái)使用。
Presto是一個(gè)低延遲高并發(fā)的內(nèi)存計(jì)算引擎。需要從其他數(shù)據(jù)源獲取數(shù)據(jù)來(lái)進(jìn)行運(yùn)算分析,它可以連接多種數(shù)據(jù)源,包括Hive、RDBMS(Mysql、Oracle、Tidb等)、Kafka、MongoDB、Redis等。
2)既負(fù)責(zé)計(jì)算,又負(fù)責(zé)存儲(chǔ)的引擎
1. ClickHouse
ClickHouse是近年來(lái)備受關(guān)注的開(kāi)源列式數(shù)據(jù)庫(kù),主要用于數(shù)據(jù)分析(OLAP)領(lǐng)域。
它自包含了存儲(chǔ)和計(jì)算能力,完全自主實(shí)現(xiàn)了高可用,而且支持完整的SQL語(yǔ)法包括JOIN等,技術(shù)上有著明顯優(yōu)勢(shì)。相比于hadoop體系,以數(shù)據(jù)庫(kù)的方式來(lái)做大數(shù)據(jù)處理更加簡(jiǎn)單易用,學(xué)習(xí)成本低且靈活度高。當(dāng)前社區(qū)仍舊在迅猛發(fā)展中,并且在國(guó)內(nèi)社區(qū)也非?;馃?,各個(gè)大廠(chǎng)紛紛跟進(jìn)大規(guī)模使用。
ClickHouse在計(jì)算層做了非常細(xì)致的工作,竭盡所能榨干硬件能力,提升查詢(xún)速度。它實(shí)現(xiàn)了單機(jī)多核并行、分布式計(jì)算、向量化執(zhí)行與SIMD指令、代碼生成等多種重要技術(shù)。
ClickHouse從OLAP場(chǎng)景需求出發(fā),定制開(kāi)發(fā)了一套全新的高效列式存儲(chǔ)引擎,并且實(shí)現(xiàn)了數(shù)據(jù)有序存儲(chǔ)、主鍵索引、稀疏索引、數(shù)據(jù)Sharding、數(shù)據(jù)Partitioning、TTL、主備復(fù)制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎(chǔ)。
2. Doris
Doris是百度主導(dǎo)的,根據(jù)Google Mesa論文和Impala項(xiàng)目改寫(xiě)的一個(gè)大數(shù)據(jù)分析引擎,是一個(gè)海量分布式 KV 存儲(chǔ)系統(tǒng),其設(shè)計(jì)目標(biāo)是支持中等規(guī)模高可用可伸縮的 KV 存儲(chǔ)集群。
Doris可以實(shí)現(xiàn)海量存儲(chǔ),線(xiàn)性伸縮、平滑擴(kuò)容,自動(dòng)容錯(cuò)、故障轉(zhuǎn)移,高并發(fā),且運(yùn)維成本低。部署規(guī)模,建議部署4-100+臺(tái)服務(wù)器。
Doris3 的主要架構(gòu):DT(Data Transfer)負(fù)責(zé)數(shù)據(jù)導(dǎo)入、DS(Data Seacher)模塊負(fù)責(zé)數(shù)據(jù)查詢(xún)、DM(Data Master)模塊負(fù)責(zé)集群元數(shù)據(jù)管理,數(shù)據(jù)則存儲(chǔ)在 Armor 分布式 Key-Value 引擎中。Doris3 依賴(lài) ZooKeeper 存儲(chǔ)元數(shù)據(jù),從而其他模塊依賴(lài) ZooKeeper 做到了無(wú)狀態(tài),進(jìn)而整個(gè)系統(tǒng)能夠做到無(wú)故障單點(diǎn)。
3. Druid
Druid是一個(gè)開(kāi)源、分布式、面向列式存儲(chǔ)的實(shí)時(shí)分析數(shù)據(jù)存儲(chǔ)系統(tǒng)。
Druid的關(guān)鍵特性如下:
- 亞秒級(jí)的OLAP查詢(xún)分析:采用了列式存儲(chǔ)、倒排索引、位圖索引等關(guān)鍵技術(shù);
- 在亞秒級(jí)別內(nèi)完成海量數(shù)據(jù)的過(guò)濾、聚合以及多維分析等操作;
- 實(shí)時(shí)流數(shù)據(jù)分析:Druid提供了實(shí)時(shí)流數(shù)據(jù)分析,以及高效實(shí)時(shí)寫(xiě)入;
- 實(shí)時(shí)數(shù)據(jù)在亞秒級(jí)內(nèi)的可視化;
- 豐富的數(shù)據(jù)分析功能:Druid提供了友好的可視化界面;
- SQL查詢(xún)語(yǔ)言;
- 高可用性與高可拓展性:
- Druid工作節(jié)點(diǎn)功能單一,不相互依賴(lài);
- Druid集群在管理、容錯(cuò)、災(zāi)備、擴(kuò)容都很容易;
4. TiDB
TiDB 是 PingCAP 公司自主設(shè)計(jì)、研發(fā)的開(kāi)源分布式關(guān)系型數(shù)據(jù)庫(kù),是一款同時(shí)支持OLTP與OLAP的融合型分布式數(shù)據(jù)庫(kù)產(chǎn)品。
TiDB 兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。目標(biāo)是為用戶(hù)提供一站式 OLTP 、OLAP 、HTAP 解決方案。TiDB 適合高可用、強(qiáng)一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場(chǎng)景。
5. Greenplum
Greenplum 是在開(kāi)源的 PostgreSQL 的基礎(chǔ)上采用了MPP架構(gòu)的性能非常強(qiáng)大的關(guān)系型分布式數(shù)據(jù)庫(kù)。為了兼容Hadoop生態(tài),又推出了HAWQ,分析引擎保留了Greenplum的高性能引擎,下層存儲(chǔ)不再采用本地硬盤(pán)而改用HDFS,規(guī)避本地硬盤(pán)可靠性差的問(wèn)題,同時(shí)融入Hadoop生態(tài)。
3)常用的引擎對(duì)比
一張圖總結(jié)下常用的OLAP引擎對(duì)比:
常見(jiàn)OLAP引擎對(duì)比