計算機(jī)領(lǐng)域的很多概念都存在一些傳播上的“謬誤”。

MPP這個概念就是其中之一。它的“謬誤”之處在于，明明叫做“Massively Parallel Processing（大規(guī)模并行處理）”，卻讓非常多的人拿它與大規(guī)模并行處理領(lǐng)域最著名的開源框架Hadoop相關(guān)框架做對比，這實(shí)在是讓人困惑——難道Hadoop不是“大規(guī)模并行處理”架構(gòu)了？

很多人在對比兩者時，其實(shí)并不知道MPP的含義究竟是什么、兩者的可比性到底在哪里。實(shí)際上，當(dāng)人們在對比兩者時，與其說是對比架構(gòu)，不如說是對比產(chǎn)品。雖然MPP的原意是“大規(guī)模并行處理”，但由于一些歷史原因，現(xiàn)在當(dāng)人們說到MPP架構(gòu)時，它們實(shí)際上指代的是“分布式數(shù)據(jù)庫”，而Hadoop架構(gòu)指的則是以Hadoop項(xiàng)目為基礎(chǔ)的一系列分布式計算和存儲框架。不過由于MPP的字面意思，現(xiàn)實(shí)中還是經(jīng)常有人糾結(jié)兩者到底有什么聯(lián)系和區(qū)別，兩者到底是不是同一個層面的概念。

(資料圖)

這種概念上的含混不清之所以還在流傳，主要是因?yàn)椴欢夹g(shù)的人而喜歡這些概念的大有人在，所以也并不在意要去澄清概念?！凹热环植际綌?shù)據(jù)庫是MPP架構(gòu)，那么MPP架構(gòu)就等于分布式數(shù)據(jù)庫應(yīng)該也沒什么問題吧。”于是大家就都不在意了。

不過，作為一個技術(shù)人員，還是應(yīng)該搞清楚兩種技術(shù)的本質(zhì)。本文旨在做一些概念上的澄清，并從技術(shù)角度論述兩者同宗同源且會在未來殊途同歸。

MPP架構(gòu)與Hadoop架構(gòu)在理論基礎(chǔ)上幾乎是在講同一件事，即，把大規(guī)模數(shù)據(jù)的計算和存儲分布到不同的獨(dú)立的節(jié)點(diǎn)中去做。

有人可能會問：“既然如此，為什么人們不說Hadoop是MPP（大規(guī)模并行處理）架構(gòu)呢？”

關(guān)于這個問題嘛，請先問是不是，再問為什么。

在GreenPlum的官方文檔中就寫道：“Hadoop就是一種常見的MPP存儲與分析工具。Spark也是一種MPP架構(gòu)。”來看下面的圖，更能體會到兩者的相似性。

問：這是什么架構(gòu)？

答：MPP架構(gòu)。

相信了解過MPP架構(gòu)的讀者對這幅圖不會陌生。也許在不同的分布式數(shù)據(jù)庫產(chǎn)品中，節(jié)點(diǎn)角色的名稱會有差異，但總體而言都是一個主節(jié)點(diǎn)加上多個從節(jié)點(diǎn)的架構(gòu)。

但是，還可以有其他答案，比如MapReduce on Yarn：

這幅圖或許大家有些陌生，但只不過是省略了資源調(diào)度的簡化版MapReduce運(yùn)行時架構(gòu)罷了。

當(dāng)然，還可以有更多答案，如Spark：

自然還可以是Flink：

有人可能會說，雖然直觀上這些架構(gòu)長得很像，但是MPP架構(gòu)中的Master所負(fù)責(zé)的事情是不是與其他框架不一樣？

那么，MPP架構(gòu)的Master做的什么事呢？它會接收SQL語句，解析它并生成執(zhí)行計劃，將計劃分發(fā)到各個節(jié)點(diǎn)。那么，這與Spark SQL有區(qū)別嗎？不僅與Spark SQL沒有區(qū)別，與其他任何Hadoop生態(tài)圈類似架構(gòu)如Hive SQL、Flink SQL都沒有區(qū)別。對于非SQL的輸入，邏輯也是一致的，只是沒有了解析SQL的步驟，但還是會生成執(zhí)行圖分發(fā)到各個節(jié)點(diǎn)去執(zhí)行，執(zhí)行結(jié)果也可以在主節(jié)點(diǎn)進(jìn)行匯總。

不僅是在計算上沒有區(qū)別，存儲架構(gòu)上也沒有區(qū)別。下面是HDFS的架構(gòu)圖：

所以回到最初說的那句話——MPP架構(gòu)與Hadoop架構(gòu)在理論基礎(chǔ)上幾乎是在講同一件事，即，把大規(guī)模數(shù)據(jù)的計算和存儲分布到不同的獨(dú)立的節(jié)點(diǎn)中去做。上面的幾幅架構(gòu)圖印證了這一點(diǎn)。

既然MPP架構(gòu)與Hadoop架構(gòu)本質(zhì)上是一回事，那么為什么很多人還要將兩者分開討論呢？我們可能經(jīng)常聽到這樣的話：“這個項(xiàng)目的架構(gòu)是MPP架構(gòu)?！边@似乎有意在說：“這可不是Hadoop那一套哦?！?/p>

這就與MPP架構(gòu)的歷史有關(guān)系。雖然從理論基礎(chǔ)上兩者是一回事，但是MPP架構(gòu)與Hadoop架構(gòu)的發(fā)展卻是走的兩條路線。MPP架構(gòu)雖然也是指的“大規(guī)模并行處理”，但是由于提出者是數(shù)據(jù)庫廠商，所以MPP架構(gòu)在很多人眼中就成了“分布式數(shù)據(jù)庫”的代名詞，它處理的也都是“結(jié)構(gòu)化”的數(shù)據(jù)，常常作為企業(yè)數(shù)據(jù)倉庫的解決方案

而Hadoop生態(tài)圈是根正苗紅伴隨著“大數(shù)據(jù)”興起而發(fā)展起來的概念，它所要解決的是大規(guī)模數(shù)據(jù)量的存儲和計算，它的提出者也并非數(shù)據(jù)庫廠商，而是有著C端數(shù)據(jù)的互聯(lián)網(wǎng)企業(yè)。因此Hadoop架構(gòu)雖然也解決“大規(guī)模并行處理”，但沒有了數(shù)據(jù)庫那一套東西的限制，處理的也大多是“非結(jié)構(gòu)化”的數(shù)據(jù)（自然在最初階段也少了相關(guān)的優(yōu)化）。當(dāng)然，Hadoop生態(tài)圈也要考慮“結(jié)構(gòu)化”的數(shù)據(jù)，這時Hive就成了Hadoop生態(tài)圈的數(shù)據(jù)倉庫解決方案。但是，Hadoop、Spark等框架的理論基礎(chǔ)與分布式數(shù)據(jù)庫仍然是一樣的。

廣義上講，MPP架構(gòu)是一種更高層次的概念，它的含義就是字面含義，但是它本身并沒有規(guī)定如何去實(shí)現(xiàn)。Hadoop相關(guān)框架和各個分布式數(shù)據(jù)庫產(chǎn)品則是具體的實(shí)現(xiàn)。狹義上講，MPP架構(gòu)成了分布式數(shù)據(jù)庫這種體系架構(gòu)的代名詞，而Hadoop架構(gòu)指的是以Hadoop框架為基礎(chǔ)的一套生態(tài)圈。

本文并不想僅僅從較高層次的架構(gòu)設(shè)計來說明兩者是一回事，這樣還是缺乏說服力。下面，我們從分布式計算框架中最重要的過程——Shuffle——來展示兩者更多的相似性。

Shuffle是分布式計算框架中最重要的概念與過程之一。在MPP架構(gòu)（分布式數(shù)據(jù)庫）中，這個數(shù)據(jù)重分區(qū)的過程與Hadoop相關(guān)框架在計算中的數(shù)據(jù)重分區(qū)過程也是一致的。

無論是Hadoop MapReduce，還是Spark或Flink，由于業(yè)務(wù)的需求，往往需要在計算過程中對數(shù)據(jù)進(jìn)行Hash分區(qū)，再進(jìn)行Join操作。這個過程中不同的框架會有不同的優(yōu)化，但是歸根到底，可以總結(jié)為兩種方式。

其中一種方式就是直接將兩個數(shù)據(jù)源的數(shù)據(jù)進(jìn)行分區(qū)后，分別傳輸?shù)较掠稳蝿?wù)中做Join。這就是一般的“Hash Join”。

另一種方式是，當(dāng)其中一個數(shù)據(jù)源數(shù)據(jù)較少時，可以將該數(shù)據(jù)源的數(shù)據(jù)分發(fā)到所有節(jié)點(diǎn)上，與這些節(jié)點(diǎn)上的另一個數(shù)據(jù)源的數(shù)據(jù)進(jìn)行Join。這種方式叫做“Broadcast Join”。它的好處是，數(shù)據(jù)源數(shù)據(jù)較多的一方不需要進(jìn)行網(wǎng)絡(luò)傳輸。

以上是Hadoop相關(guān)框架的實(shí)現(xiàn)。下面用一個具體的例子來看MPP架構(gòu)對這一過程的思考。

在MPP架構(gòu)中，數(shù)據(jù)往往會先指定分區(qū)Key，數(shù)據(jù)就按照分區(qū)Key分布在各個節(jié)點(diǎn)中。

現(xiàn)在假設(shè)有三張表，其中兩張為大表，一張為小表：

很自然地，訂單表會選擇訂單ID為做分區(qū)Key，產(chǎn)品表會選擇產(chǎn)品ID作為分區(qū)Key，客戶表會選擇客戶ID作為分區(qū)Key。給這些表中添加一些數(shù)據(jù)，并且執(zhí)行一個查詢語句：

首先，訂單表要與客戶表做Join，Join Key是客戶ID。這種操作在Hadoop生態(tài)圈的分布式計算框架中，相當(dāng)于對兩個表做了Hash分區(qū)的操作。不過由于客戶表已經(jīng)按照客戶ID提前做好了分區(qū)，所以這時只需要對訂單表做重分區(qū)。在MPP架構(gòu)中，會產(chǎn)生如下的結(jié)果：

此時，訂單表整個表的數(shù)據(jù)會發(fā)生重分區(qū)，由此產(chǎn)生網(wǎng)絡(luò)IO。這種情況相當(dāng)于Hadoop架構(gòu)中的“Hash Join”。

接著，需要讓結(jié)果與產(chǎn)品表按照產(chǎn)品ID做Join。這時，因?yàn)橹爱a(chǎn)生的結(jié)果的分區(qū)Key不是產(chǎn)品ID，看起來又需要將整個數(shù)據(jù)進(jìn)行重分區(qū)。不過，注意到產(chǎn)品表是個小表，所以此時只需要將該表廣播到各個節(jié)點(diǎn)即可。結(jié)果如下：

在這個過程中，就只有小表的數(shù)據(jù)發(fā)生了網(wǎng)絡(luò)IO。這就相當(dāng)于Hadoop架構(gòu)中的“Broadcast Join”。兩者還有區(qū)別嗎？

前文在MPP架構(gòu)的概念、歷史以及技術(shù)細(xì)節(jié)上與Hadoop架構(gòu)做了對比，了解到了兩者一些極為相似的地方，而且在廣義上講，Hadoop就是MPP架構(gòu)的一種實(shí)現(xiàn)。

然而前文也講到，由于傳播上的謬誤，現(xiàn)在人們說到MPP架構(gòu)，主要指的是分布式數(shù)據(jù)庫，它處理的是結(jié)構(gòu)化的數(shù)據(jù)，而Hadoop生態(tài)圈是由“大數(shù)據(jù)”這套概念發(fā)展而來，最初處理的都是非結(jié)構(gòu)化的數(shù)據(jù)。以此為出發(fā)點(diǎn)，兩者到底在發(fā)展過程中產(chǎn)生了多大的區(qū)別呢？

對比的維度有很多，比如很多人會說，MPP架構(gòu)的平臺封閉、擁有成熟的人才市場，而Hadoop架構(gòu)平臺開放、人才專業(yè)培訓(xùn)較少等。但這些并不是本質(zhì)的區(qū)別。這里還是以技術(shù)指標(biāo)作為維度來進(jìn)行對比。

技術(shù)角度上來講，MPP產(chǎn)品最大的優(yōu)勢是作業(yè)運(yùn)行時間更快。這不難理解，因?yàn)镸PP產(chǎn)品處理的都是結(jié)構(gòu)化數(shù)據(jù)，本身就是從數(shù)據(jù)庫發(fā)展而來，擁有極為復(fù)雜的優(yōu)化器對作業(yè)進(jìn)行優(yōu)化。這些優(yōu)化器是各廠商最有價值的商業(yè)機(jī)密，自然是開源產(chǎn)品不能比的。不過另一個角度來看，這也是MPP產(chǎn)品相比于Hadoop相關(guān)產(chǎn)品不夠靈活的地方——它只能處理結(jié)構(gòu)化數(shù)據(jù)。

有人說MPP產(chǎn)品能夠處理的數(shù)據(jù)量沒有Hadoop架構(gòu)大。這種說法并不準(zhǔn)確。Hadoop架構(gòu)之所以能處理更大量的數(shù)據(jù)，其中一個原因是硬件成本較低，擴(kuò)展更加的方便。實(shí)際上，經(jīng)過精心設(shè)計的MPP架構(gòu)照樣可以處理PB及以上級別的數(shù)據(jù)。有人說，MPP產(chǎn)品不能處理大規(guī)模數(shù)據(jù)，是因?yàn)樵獢?shù)據(jù)的量十分巨大。其實(shí)，同樣的問題也存在于Hadoop相關(guān)框架中。另一方面，Hadoop相關(guān)框架能處理多大量的數(shù)據(jù)，與具體的實(shí)現(xiàn)有很大關(guān)系。如果擁有足夠的資金可以對MPP產(chǎn)品進(jìn)行擴(kuò)展，而Hadoop相關(guān)產(chǎn)品我們又用基于內(nèi)存的計算，那么，對比的結(jié)果一定是MPP產(chǎn)品能夠應(yīng)對更大的數(shù)據(jù)量。如果非要從數(shù)據(jù)量這一維度來做對比，可能反而是Hadoop相關(guān)產(chǎn)品對小數(shù)據(jù)量更有優(yōu)勢。比如想要存儲一個極小的表，MPP產(chǎn)品也許會根據(jù)分區(qū)Key將其拆分到100個節(jié)點(diǎn)中去，而HDFS用一個文件塊存儲就夠用了。

前面講到MPP產(chǎn)品對結(jié)構(gòu)化數(shù)據(jù)的計算和存儲都更有效率。其中一部分優(yōu)化就包括了存儲時的“列存儲”技術(shù)，查詢時的“CBO優(yōu)化”等等。這些都是Hadoop生態(tài)圈一開始比較缺乏的技術(shù)。但是隨著這些年的發(fā)展，這些技術(shù)早就融入到了Hadoop生態(tài)圈中，Hive、Spark框架的優(yōu)化技術(shù)也越做越好，由此與MPP架構(gòu)的技術(shù)差距也越來越小，甚至有覆蓋的趨勢。從最核心的技術(shù)上來看，兩者未來只會越來越像。可以預(yù)測，Hadoop架構(gòu)的市場會越來越大。

不過，分布式數(shù)據(jù)庫產(chǎn)品在安全性等方面仍然提供著更成熟的解決方案，這是開源產(chǎn)品短時間內(nèi)無法超越的。因此，“MPP架構(gòu)”這個概念仍然會在政府、傳統(tǒng)企業(yè)中長期占有一席之地。

本文轉(zhuǎn)載自微信公眾號「 滌生大數(shù)據(jù)」，作者「滌生大數(shù)據(jù)」，可以通過以下二維碼關(guān)注。

轉(zhuǎn)載本文請聯(lián)系「 滌生大數(shù)據(jù)」公眾號。

關(guān)鍵詞： 分布式數(shù)據(jù)庫 大規(guī)模并行處理 分布式計算 解決方案