巫東來 湯仕磊

摘 要：開發(fā)海量數(shù)據(jù)處理系統(tǒng)時存在技術(shù)框架選擇不確定問題。從理論及應(yīng)用角度對兩種主流的海量數(shù)據(jù)處理架構(gòu)MPP和Hadoop進行對比，分析各自技術(shù)特點，闡述其與傳統(tǒng)數(shù)據(jù)處理的優(yōu)勢。分析結(jié)果表明，Hadoop在存儲數(shù)據(jù)規(guī)模上可輕松支持PB級別，而MPP架構(gòu)大多只支持TB級別;Hadoop對海量半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)存儲和處理有一定優(yōu)勢，但在處理速度和易用性上不及MPP;在結(jié)構(gòu)化數(shù)據(jù)處理、響應(yīng)性能和衍生工具等方面MPP 則占優(yōu)，適用于查詢業(yè)務(wù)場景較多項目。通過分析兩大框架底層核心技術(shù)以及歸納優(yōu)缺點，為企業(yè)相關(guān)應(yīng)用的技術(shù)選型提供參考。

關(guān)鍵詞：大數(shù)據(jù); 海量數(shù)據(jù)存儲; Hadoop; MPP;分布式計算

DOI：10. 11907/rjdk. 201655

中圖分類號：TP391文獻標(biāo)識碼：A 文章編號：1672-7800（2020）010-0218-05

Abstract：In order to improve the uncertainties in the choice of technical framework when developing massive data processing systems，we make an in-depth comparison between the two mainstream massive data processing frameworks MPP and Hadoop from a theoretical and application perspective. We analyze their respective technical characteristics， and discusses their advantages over traditional data processing. The analysis results show that Hadoop can easily support the PB-level data scale in terms of the size of the stored data， while most MPP architectures only support the TB-level. Hadoop has certain advantages in the storage and processing of massive semi-structured and unstructured data， but it is inferior to MPP in processing speed and ease of use. MPP is dominant in structured data processing， response performance， and derivatives， and is suitable for projects with many query business scenarios. By analyzing the underlying core technologies of the two frameworks and summarizing their advantages and disadvantages， a comprehensive reference for enterprises in the selection of relevant application technologies is provided.

Key Words： big data; massive data storage; Hadoop; MPP; distributed computing

0 引言

隨著云計算、大數(shù)據(jù)產(chǎn)業(yè)的不斷發(fā)展，傳統(tǒng)使用單機數(shù)據(jù)庫進行數(shù)據(jù)存儲的模式已經(jīng)不能滿足業(yè)界日益增長需求，海量數(shù)據(jù)處理成為一個關(guān)鍵問題。目前主流的海量數(shù)據(jù)處理架構(gòu)分為兩種：①基于傳統(tǒng)數(shù)據(jù)庫及數(shù)據(jù)倉庫所衍生出的MPP（Massively Parallel Processing）架構(gòu)[1];②基于Hadoop并行計算框架的分布式架構(gòu)[2]。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫隨著數(shù)據(jù)量增長性能急劇下降，業(yè)界提出一種橫向擴展（scale out）方式，通過增加節(jié)點使用更多廉價的機器構(gòu)建更強的集群系統(tǒng)。在這種背景下，分布式數(shù)據(jù)庫和數(shù)據(jù)倉庫越來越受到重視，其中基于MPP架構(gòu)的數(shù)據(jù)庫是主流解決方案，越來越多的廠商選擇使用它改造和升級原有軟件系統(tǒng)[3]。Hadoop是一種分布式數(shù)據(jù)處理框架，使用普通X86計算機組成分布式系統(tǒng)處理海量數(shù)據(jù)及進行大數(shù)據(jù)分析[4]。Hadoop架構(gòu)近年伴隨著云計算而興，其生態(tài)系統(tǒng)和大數(shù)據(jù)緊密聯(lián)系在一起，不僅僅因為它是開源系統(tǒng)，更主要的是它形成了一個完整的技術(shù)生態(tài)圈[5-6]。混合架構(gòu)則綜合了MPP架構(gòu)和Hadoop架構(gòu)各自特點，通過混合部署將各自的優(yōu)點充分發(fā)揮出來。如Ma等[7]將Hadoop生態(tài)系統(tǒng)與ETL、Spark處理引擎一起使用，結(jié)合基于MPP的海量并行處理數(shù)據(jù)庫（MPP）實現(xiàn)銀行綜合風(fēng)險管理系統(tǒng)，具有更好的性能;鄧涵元等[8]基于MPP-Hadoop 混合框架構(gòu)建一套融合多種不同結(jié)構(gòu)數(shù)據(jù)的數(shù)據(jù)集成系統(tǒng) ，提升了數(shù)據(jù)查詢和加載效率。同時，混合架構(gòu)案例近年得到長足發(fā)展[9-12]。

本文對MPP和Hadoop兩種架構(gòu)進行深入分析，并對比各自優(yōu)缺點以及適用范圍，給出不同類型應(yīng)用的技術(shù)架構(gòu)選型推薦方案。

1 基于MPP的數(shù)據(jù)處理架構(gòu)

MPP指處于不同部分的多個處理器對程序進行協(xié)同處理的過程，每個處理器使用自己的操作系統(tǒng)、內(nèi)存、總線和磁盤等，如圖1所示。通常MPP處理器使用某些消息傳遞接口進行通信。在某些實現(xiàn)中，同一應(yīng)用程序最多可以使用200個或更多處理器，這種結(jié)構(gòu)最大的特點在于共享資源。

MPP數(shù)據(jù)庫（MPP DB）基于MPP架構(gòu)，通過并行化各種操作提高性能，如加載數(shù)據(jù)、構(gòu)建索引以及使用并行的多個CPU和磁盤等。

MPP數(shù)據(jù)庫通常具有無共享架構(gòu)，因為每個系統(tǒng)都有自己的CPU、內(nèi)存和磁盤。通過數(shù)據(jù)庫軟件和高速互連，系統(tǒng)可以整體運行，并且可通過添加新服務(wù)器對集群進行擴展。MPP數(shù)據(jù)庫通常比托管在大型多處理器服務(wù)器上的傳統(tǒng)RDBMS更靈活，可伸縮且更具成本優(yōu)勢，可提供快速的交互式查詢響應(yīng)，如圖2所示。這種架構(gòu)特征是任務(wù)并行執(zhí)行、數(shù)據(jù)分布式存儲（本地化）、分布式計算、資源私有、可橫向擴展等。

1.1 MPP數(shù)據(jù)庫集群架構(gòu)

MPP數(shù)據(jù)庫集群架構(gòu)如圖3所示，分為以下兩種架構(gòu)：

（1）有專職Master。Master節(jié)點的主要功能是作為系統(tǒng)訪問入口，對存儲在系統(tǒng)中的元數(shù)據(jù)進行管理，以及實現(xiàn)SQL Parser，生成執(zhí)行計劃和任務(wù)調(diào)度等。Master有兩個節(jié)點，會進行數(shù)據(jù)同步，在出現(xiàn)故障時可切換。典型產(chǎn)品有Greenplum、AsterData、ParAccel、Hawg等。

（2）無專職Master。Master節(jié)點和數(shù)據(jù)節(jié)點共享一臺物理機，先連接上的節(jié)點會作為系統(tǒng)的Master。典型產(chǎn)品有Gbase8a、Vertica、Teradata、DB2、Impala 、IBM BigSQL、HP DragonRed、VerticaVIVE等。

1.2 MPP架構(gòu)選擇

兩種架構(gòu)各有優(yōu)缺點，在超大規(guī)模分布式集群中，第（2）種架構(gòu)更有優(yōu)勢，可演變?yōu)椤岸鄊aster”架構(gòu)（如Gbase8a和Vertica集群）。此種架構(gòu)下，通過Zookeeper等分布式一致性軟件協(xié)調(diào)多個master，提供高可用性、透明性以及擴展性，同時數(shù)據(jù)節(jié)點具有對等性。

2 基于Hadoop架構(gòu)的數(shù)據(jù)處理框架

2.1 Hadoop數(shù)據(jù)分塊

Hadoop 架構(gòu)與MPP架構(gòu)相似，圖4顯示Hadoop處理數(shù)據(jù)過程。名稱服務(wù)器充當(dāng)目錄查找服務(wù)。Hadoop將數(shù)據(jù)分為任意塊，大小一般設(shè)為128Mb，將其復(fù)制到至少兩個其它節(jié)點以實現(xiàn)分布式存儲。小文件（小于128Mb的文件）完全保存在單個節(jié)點上，甚至1G大小的文件也只需要分布在8個節(jié)點（加上副本）上。因此，Hadoop可處理非常大的數(shù)據(jù)集。

由于小表格分布在較少服務(wù)器上，因此對于50～100Gb以下的數(shù)據(jù)文件不是理想選擇。在Hadoop上處理小數(shù)據(jù)集是一個挑戰(zhàn)，因為在某些情況下，單個節(jié)點上處理數(shù)據(jù)完全按順序運行而不是并行運行。許多Hadoop集群傾向于使用大量相對較慢且價格便宜的服務(wù)器，因此小數(shù)據(jù)性能可能較差。此外，隨著小文件數(shù)量增加，名稱服務(wù)器管理問題會越來越多。經(jīng)驗表明，在大多數(shù)中型數(shù)據(jù)倉庫平臺（大約10Tb的數(shù)據(jù)）上只有大約10%的表擁有超過100Gb的數(shù)據(jù)，而70%的表不足1Gb數(shù)據(jù)。即使兩個最大的表超過1Tb，對于在Hadoop上部署也不是很有利。

2.2 Hadoop集群架構(gòu)

Hadoop處理框架包括3個模塊：HDFS、MapReduce和YARN。

（1）HDFS是一個分布式文件系統(tǒng)，用于將單個集群擴展到數(shù)百個甚至數(shù)千個節(jié)點，具有高度的容錯能力，部署在低成本硬件上。 HDFS提供應(yīng)用程序高吞吐量數(shù)據(jù)訪問，適用于具有大數(shù)據(jù)集的應(yīng)用程序。

（2）MapReduce是一個軟件框架，以高可靠性、高容錯方式并行處理大型集群（數(shù)千個節(jié)點）上的海量數(shù)據(jù)（多TB數(shù)據(jù)集）。MapReduce作業(yè)通常將輸入數(shù)據(jù)集拆分為獨立的塊，這些任務(wù)以完全并行的方式進行處理。

（3）YARN：Hadoop集群資源管理主要依靠資源管理器（YARN）提供細(xì)粒度的資源管理。MapReduce作業(yè)不需要并行運行所有計算任務(wù)，因此可以處理大量的計算任務(wù)，具有可擴展性及支持長壽命容器等功能，但它比MPP資源管理器要慢，有時對于并發(fā)性管理支持不是很好。

2.3 Hadoop數(shù)據(jù)查詢

Hadoop的SQL接口有多種工具供選擇，包括MR / Tez/Spark上運行的Hive、SparkSQL、Impala、HAWQ或IBM BigSQL。

（1）Hive將SQL查詢轉(zhuǎn)換為MR / Tez / Spark作業(yè)并在集群上執(zhí)行。所有作業(yè)均基于相同的MapReduce概念構(gòu)建，提供良好的集群利用率，以及與其它Hadoop堆棧技術(shù)的良好集成。缺點是執(zhí)行查詢延遲大，尤其表連接性能較低，沒有查詢優(yōu)化器（至少目前是這樣），因此即使是最不合理的查詢引擎也會執(zhí)行操作。

（2）SparkSQL是介于MapReduce和MPP-over-Hadoop方法之間的一種工具，兼顧兩者優(yōu)點。與MapReduce相似，將工作分解為一組單獨計劃任務(wù)以提供更好的穩(wěn)定性。在執(zhí)行階段之間進行流式傳輸數(shù)據(jù)以加快處理速度，使用類似MPP中的固定執(zhí)行程序概念減少查詢延遲。

（3）混合方案如Impala和HAWQ類的解決方案，是Hadoop之上的MPP執(zhí)行引擎，可處理HDFS中存儲的數(shù)據(jù)。與其它MPP引擎一樣，可提供更低的延遲和更少的查詢處理時間，但代價是可伸縮性和穩(wěn)定性較低。

3 Hadoop與MPP架構(gòu)選擇

3.1 節(jié)點架構(gòu)

（1）底層數(shù)據(jù)庫。MPP底層運行的是SQL引擎，而Hadoop底層處理是MapReduce程序。

（2）擴展程度。MPP雖然支持橫向擴展，但一般只支持?jǐn)U展到百個節(jié)點級別， Hadoop則可以擴展到千個節(jié)點級別。

基于Hadoop框架的數(shù)據(jù)平臺可看作是新一代的分布式數(shù)據(jù)倉庫產(chǎn)品，而MPP數(shù)據(jù)庫會應(yīng)用與大數(shù)據(jù)類似的解決方案。針對不同使用場景，其發(fā)揮的作用和給用戶帶來的體驗也不同。

MPP和Hadoop平臺互為補充，分別用于不同場景。MPP用于高端數(shù)據(jù)庫產(chǎn)品，Hadoop可部署到普通X86集群。MPP和Hadoop底層支持的硬件不同， Hadoop控制機制大多通過Java代碼實現(xiàn)，而MPP產(chǎn)品則通過SQL進行查詢。Hadoop的子項目“Hive”本質(zhì)上也是通過MapReduce提供SQL抽象。在許多情況下，與編寫MapReduce作業(yè)相比，SQL更容易且生產(chǎn)率更高，具有SQL技能的數(shù)據(jù)庫專業(yè)人員比Hadoop專家更多且成本更低。

3.2 CAP理論

CAP定理（CAP theorem）又稱布魯爾定理（Brewer's theorem），在理論計算機科學(xué)中指一個分布式系統(tǒng)最多只能滿足以下3個特征中的兩個：①一致性（Consistency）：同一時間系統(tǒng)中所有的節(jié)點都具有相同的數(shù)據(jù)值;②可用性（Availability）：系統(tǒng)中即使一個或多個節(jié)點發(fā)生故障，客戶端的任何請求仍將獲得響應(yīng);③分區(qū)容忍性（Partition tolerance）：即使系統(tǒng)節(jié)點之間發(fā)生許多通信故障，集群也必須繼續(xù)工作。

CAP理論是MPP架構(gòu)擴展性弱的原因，因為MPP數(shù)據(jù)庫設(shè)計仍然以數(shù)據(jù)查詢?yōu)橹饕康模紫瓤紤]一致性，其次考慮可用性，最后在可能的情況下考慮分區(qū)容忍性。而Hadoop是為并行處理與存儲設(shè)計的，所以數(shù)據(jù)均以文件存儲，有限考慮分區(qū)容忍性，然后考慮可用性，一致性則最后考慮，所以可靠性上Hadoop要優(yōu)于MPP。

3.3 數(shù)據(jù)擴展制約性

（1）高可用。MPP數(shù)據(jù)庫通過將哈希算法應(yīng)用于分配鍵列值，在數(shù)據(jù)切片之間確定數(shù)據(jù)存儲的物理機器，而Hadoop則是通過數(shù)據(jù)分塊實現(xiàn)分布式存儲，因而Hadoop可用性更強。

（2）并行任務(wù)。雖然MPP是根據(jù)Hash切分?jǐn)?shù)據(jù)的，但是它的任務(wù)沒有切分，因此任務(wù)都會在每個節(jié)點上運行一次。

（3）文件系統(tǒng)。在MPP數(shù)據(jù)庫中，雖然數(shù)據(jù)被切分了，但文件數(shù)量并未減少，每個表在節(jié)點上有一個或多個文件。存儲的表越多節(jié)點數(shù)就越多，導(dǎo)致系統(tǒng)存儲過多文件。

（4）網(wǎng)絡(luò)瓶頸。MPP數(shù)據(jù)庫大多使用對等節(jié)點架構(gòu)，對等的點對點連接消耗大量網(wǎng)絡(luò)寬帶，限制系統(tǒng)線性擴展。Hadoop使用主從節(jié)點架構(gòu)，在線性擴展上強于MPP。

（5）其它關(guān)系數(shù)據(jù)庫限制。關(guān)系型數(shù)據(jù)庫中的鎖機制、日志系統(tǒng)、權(quán)限管理、節(jié)點管理等瓶頸均限制MPP規(guī)模擴大，而Hadoop沒有使用關(guān)系型數(shù)據(jù)庫，并且有專用的分布式一致性管理軟件，因此這些性能要優(yōu)于MPP。

3.4 技術(shù)選擇

Hadoop架構(gòu)數(shù)據(jù)存儲、傳統(tǒng)數(shù)據(jù)倉庫、MPP數(shù)據(jù)庫技術(shù)性能及適用場景對比如表2所示。

因此，Hadoop和MPP兩種技術(shù)應(yīng)根據(jù)具體業(yè)務(wù)以及場景進行選擇。

（1）對于半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，Hadoop在處理上比MPP有一定優(yōu)勢，適合于海量數(shù)據(jù)批處理類應(yīng)用，如海量數(shù)據(jù)ETL、非結(jié)構(gòu)化數(shù)據(jù)分析與挖掘（關(guān)鍵詞提取、情感分析等）。若系統(tǒng)對非結(jié)構(gòu)化數(shù)據(jù)存儲需求較大且數(shù)據(jù)量巨大，需要動態(tài)擴展數(shù)據(jù)節(jié)點等，則使用Hadoop架構(gòu)更為合適。

（2）MPP架構(gòu)更適合對現(xiàn)有關(guān)系型數(shù)據(jù)庫和數(shù)據(jù)倉庫系統(tǒng)進行升級或替換，其在數(shù)據(jù)查詢類業(yè)務(wù)上比Hadoop更具優(yōu)勢，適合處理SQL類事務(wù)請求、多維度數(shù)據(jù)分析、展示數(shù)據(jù)報表等。若大部分存儲數(shù)據(jù)是結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)量不是很大，未來不會爆炸式增長，或業(yè)務(wù)人員習(xí)慣使用SQL場景，則可優(yōu)先考慮使用MPP數(shù)據(jù)庫。

（3）MPPDB+Hadoop混合架構(gòu)是未來海量數(shù)據(jù)處理發(fā)展趨勢。用MPP處理PB級結(jié)構(gòu)化數(shù)據(jù)存儲與查詢，提供完整的SQL與事務(wù)支持功能。用Hadoop處理半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，提供靈活的自定義模型與算法開發(fā)能力，同時滿足多種數(shù)據(jù)類型處理需求，并在實時查詢與離線分析上都能提供較高性能，但MPPDB+Hadoop混合架構(gòu)開發(fā)與維護成本可能較高。一個典型的混合架構(gòu)如圖5所示。

4 結(jié)語

在數(shù)據(jù)爆炸時代，傳統(tǒng)的數(shù)據(jù)庫架構(gòu)處理系統(tǒng)已經(jīng)不能滿足行業(yè)需要。本文從理論及應(yīng)用角度將兩種主流的海量數(shù)據(jù)處理架構(gòu)MPP和Hadoop進行對比，分析各自的技術(shù)特點，論述它們與傳統(tǒng)數(shù)據(jù)處理的優(yōu)勢。通過分析兩大框架底層核心技術(shù)，對其優(yōu)缺點進行了歸納。Hadoop對海量半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)存儲與處理有一定優(yōu)勢，但在處理速度和易用性上不及MPP。Hadoop靈活性較強，企業(yè)可根據(jù)自身業(yè)務(wù)特點進行定制開發(fā)。MPP優(yōu)勢在海量結(jié)構(gòu)化數(shù)據(jù)處理、響應(yīng)性能和衍生工具等方面，適用于查詢業(yè)務(wù)場景較多的項目。隨著Hadoop 生態(tài)圈的不斷發(fā)展，如Hadoop 的SQL 性能提升、BI工具的不斷豐富， MPP 技術(shù)發(fā)展會向Hadoop 靠攏?；贛PP 與Hadoop框架并結(jié)合Spark內(nèi)存計算、流計算等技術(shù)的混合架構(gòu)平臺，會成為大型數(shù)據(jù)處理項目的理想選擇。

參考文獻：

[1] 羅遠(yuǎn)浩. MPP數(shù)據(jù)倉庫的架構(gòu)及加載技術(shù)優(yōu)化研究[D]. 北京：中國科學(xué)院大學(xué)，2017.

[2] 郝樹魁. Hadoop HDFS和MapReduce架構(gòu)淺析[J]. 郵電設(shè)計技術(shù)，2012，11（7）：37-42.

[3] 田雯，劉倩，孫紅恩. MPP數(shù)據(jù)庫在中國移動大數(shù)據(jù)應(yīng)用中的前景分析[J]. 電信工程技術(shù)與標(biāo)準(zhǔn)化，2017，30（3）：87-91.

[4] 許吳環(huán)，顧瀟華. 大數(shù)據(jù)處理平臺比較研究[J]. 軟件導(dǎo)刊，2017，16（4）：212-214.

[5] 陳吉榮，樂嘉錦. 基于Hadoop生態(tài)系統(tǒng)的大數(shù)據(jù)解決方案綜述[J]. 計算機工程與科學(xué)，2013，35（10）：25-35.

[6] 曹恒瑞，曹展碩. 一種基于Hadoop平臺的分布式數(shù)據(jù)檢索系統(tǒng)[J]. 軟件導(dǎo)刊，2017，16（4）：118-120.

[7] MA S，WANG H，XU B，et al. Banking comprehensive risk management system based on big data architecture of hybrid processing engines and databases[C]. IEEE Smartworld， Ubiquitous Intelligence & Computing， Advanced & Trusted Computing， Scalable Computing & Communications， Cloud & Big Data Computing， Internet of People & Smart City Innovation，2018：1844-1851.

[8] 鄧涵元，盧山，程光. 基于MPP-Hadoop混合架構(gòu)高校數(shù)據(jù)集成系統(tǒng)研究[J]. 計算機技術(shù)與發(fā)展，2018，28（8）：160-163，169.

[9] 劉冰. 公安云混搭架構(gòu)下的數(shù)據(jù)安全增強技術(shù)研究[J]. 警察技術(shù)，2019，18（2）：33-36.

[10] 劉磊. 基于大數(shù)據(jù)的政府審計全覆蓋路徑設(shè)計與方法——以MPP及Hadoop技術(shù)路線為例[J]. 許昌學(xué)院學(xué)報，2020，39（1）：98-102.

[11] LU X，SU F，LIU H，et al. A unified OLAP/OLTP big data processing framework in telecom industry[C]. Qingdao：International Symposium on Communications & Information Technologies，2016.

[12] VIJAYAKUMAR S，BHARGAVI A，PRASEEDA U，et al. Optimizing sequence alignment in cloud using Hadoop and MPP database[C]. IEEE International Conference on Cloud Computing，2012：819-827.

（責(zé)任編輯：杜能鋼）