同樣都可以處理大規(guī)模數(shù)據(jù)的MPP數(shù)據(jù)庫(kù)架構(gòu)與Hadoop體系架構(gòu)屬于不同的技術(shù)體系，二者沒(méi)有直接的相關(guān)性，卻常常被放在一起進(jìn)行比較。特別是在企業(yè)數(shù)據(jù)倉(cāng)庫(kù)建設(shè)中，MPP架構(gòu)與Hadoop架構(gòu)代表兩類典型的技術(shù)路線選型，事實(shí)上，在2015年左右甚至有人認(rèn)為基于Hadoop體系的數(shù)倉(cāng)將徹底取代基于MPP數(shù)據(jù)庫(kù)的數(shù)倉(cāng)。

1.設(shè)計(jì)思路對(duì)比

兩類系統(tǒng)運(yùn)行的硬件架構(gòu)是相同的，都是普通服務(wù)器組成的集群，但從資源管理角度來(lái)說(shuō)，它們并行化軟件實(shí)現(xiàn)的設(shè)計(jì)思路卻是相反的。

MPP架構(gòu)相當(dāng)于對(duì)單機(jī)的各類資源進(jìn)行垂直綜合管理，再將多個(gè)單機(jī)系統(tǒng)橫向連接進(jìn)行集成，可以說(shuō)是先垂直后水平。

Hadoop架構(gòu)相當(dāng)于將所有機(jī)器的存儲(chǔ)資源與計(jì)算資源抽象出來(lái)，分開(kāi)管理，再進(jìn)行組件級(jí)的垂直集成，可以說(shuō)是先水平后垂直。

MPP與Hadoop架構(gòu)對(duì)比如圖1所示。

▲圖1　MPP與Hadoop架構(gòu)對(duì)比

具體分析如下。

MPP架構(gòu)是將許多單機(jī)數(shù)據(jù)庫(kù)通過(guò)網(wǎng)絡(luò)連接起來(lái)，相當(dāng)于將一個(gè)個(gè)垂直系統(tǒng)橫向連接，形成一個(gè)統(tǒng)一對(duì)外服務(wù)的分布式數(shù)據(jù)庫(kù)系統(tǒng)，每個(gè)節(jié)點(diǎn)由一個(gè)單機(jī)數(shù)據(jù)庫(kù)系統(tǒng)獨(dú)立管理和操作該節(jié)點(diǎn)所在物理機(jī)上的所有資源（CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)），節(jié)點(diǎn)內(nèi)系統(tǒng)的各組件間的相互調(diào)用不需要通過(guò)控制節(jié)點(diǎn)，即對(duì)控制節(jié)點(diǎn)來(lái)說(shuō)，每個(gè)節(jié)點(diǎn)的內(nèi)部運(yùn)行過(guò)程相對(duì)透明。

Hadoop架構(gòu)是將不同的資源管理與功能進(jìn)行分層抽象設(shè)計(jì)，每層形成一類組件，實(shí)現(xiàn)一定程度的解耦，包括存儲(chǔ)資源管理、計(jì)算資源管理、通用并行計(jì)算框架、各類分析功能等，在每層內(nèi)進(jìn)行跨節(jié)點(diǎn)的資源統(tǒng)一管理或功能并行執(zhí)行，層與層之間通過(guò)接口調(diào)用，相互透明，節(jié)點(diǎn)內(nèi)不同層的組件間的相互調(diào)用需要由控制節(jié)點(diǎn)掌握或通過(guò)控制節(jié)點(diǎn)協(xié)調(diào)，即控制節(jié)點(diǎn)了解每個(gè)節(jié)點(diǎn)內(nèi)不同層組件間的互動(dòng)過(guò)程。

2.優(yōu)缺點(diǎn)對(duì)比

MPP架構(gòu)的優(yōu)缺點(diǎn)總結(jié)如下：

• 支持標(biāo)準(zhǔn)SQL，每個(gè)節(jié)點(diǎn)都有豐富的事務(wù)處理和管理功能；
• 資源管理精細(xì)；
• 更適合預(yù)知數(shù)據(jù)結(jié)構(gòu)模型的中等規(guī)模的固定模式數(shù)據(jù)管理；
• 集群規(guī)模調(diào)整要求較多，增減節(jié)點(diǎn)時(shí)通常需要停機(jī)，且有的系統(tǒng)只能增加不能減少；
• 延遲小，相對(duì)吞吐量一般，單節(jié)點(diǎn)緩慢會(huì)拖累整體性能；
• 表記錄進(jìn)行水平分割存儲(chǔ)，方法通常包括一致性哈希（Consistent Hashing）、循環(huán)寫入（Round Robin），但容易產(chǎn)生數(shù)據(jù)熱點(diǎn)。

Hadoop架構(gòu)的優(yōu)缺點(diǎn)總結(jié)如下：

• 每個(gè)節(jié)點(diǎn)功能簡(jiǎn)單，不具備豐富的數(shù)據(jù)管理功能，不支持事務(wù)；
• 數(shù)據(jù)更新采用追加方式實(shí)現(xiàn)，同等數(shù)據(jù)量處理需要的資源更多；
• 可以不用預(yù)先了解數(shù)據(jù)的格式與內(nèi)容；
• 擴(kuò)展性好，支持集群規(guī)模更大，能動(dòng)態(tài)擴(kuò)容，支持?jǐn)U充僅用于計(jì)算的節(jié)點(diǎn)；
• 延遲高、吞吐量大、容錯(cuò)性（Failover）好。

總體來(lái)說(shuō)，Hadoop架構(gòu)在數(shù)據(jù)量較低的情況下，運(yùn)行速度遠(yuǎn)不及MPP架構(gòu)，但數(shù)據(jù)量一旦超過(guò)某個(gè)量級(jí)，Hadoop架構(gòu)在吞吐量方面將非常有優(yōu)勢(shì)。有些大數(shù)據(jù)數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品也采用混合架構(gòu)，以融合兩者的優(yōu)點(diǎn)，例如Impala、Presto等都是基于HDFS的MPP分析引擎，僅利用HDFS實(shí)現(xiàn)分區(qū)容錯(cuò)性，放棄MapReduce計(jì)算模型，在面向OLAP場(chǎng)景時(shí)可實(shí)現(xiàn)更好的性能，降低延遲。

本文摘編于《數(shù)據(jù)應(yīng)用工程：方法論與實(shí)踐》，經(jīng)出版方授權(quán)發(fā)布。（書號(hào)：9787111704096）轉(zhuǎn)載請(qǐng)保留文章出處。