探秘MPP 數(shù)據(jù)庫

孫淳曄，梁 楊/Sun Chunye,Liang Yang

（中國移動通信集團設(shè)計院有限公司河北分公司 石家莊050021）

1 引言

早期，運營商的數(shù)據(jù)庫大多如Oracle、DB2 等OldSQL 型，近幾年來，隨著大數(shù)據(jù)技術(shù)的發(fā)展，數(shù)據(jù)處理技術(shù)進入了一個新的創(chuàng)新和發(fā)展高潮期。在硬件技術(shù)發(fā)展及市場需求雙重因素的推動下，涌現(xiàn)出NewSQL、NoSQL 等新型數(shù)據(jù)庫并逐步得以商用，形成目前數(shù)據(jù)庫市場NewSQL、NoSQL、OldSQL 等多元異構(gòu)的混搭格局[1]，如圖1所示。其中，基于開源技術(shù)的Hadoop 作為NoSQL的典型代表，通過擴展和封裝Hadoop平臺，能出色地完成對半結(jié)構(gòu)化和非結(jié)構(gòu)化的信令類、互聯(lián)網(wǎng)類等數(shù)據(jù)的處理及分析支撐。MPP（Massively Parallel Processing，大量信息并行處理機）作為NewSQL的典型代表，本質(zhì)屬于關(guān)系型分析類數(shù)據(jù)庫，主要面向行業(yè)大數(shù)據(jù)，在企業(yè)傳統(tǒng)數(shù)據(jù)倉庫去IOE化[2]、構(gòu)建新型數(shù)據(jù)倉庫及結(jié)構(gòu)化分析的過程中起著無法替代的作用。本文主要針對MPP 數(shù)據(jù)庫進行探究介紹。

圖1 多元混搭的數(shù)據(jù)處理架構(gòu)

現(xiàn)階段比較成熟的MPP 產(chǎn)品很多，主要分為兩個陣營：有Master 節(jié)點的集群，如Greenplum、Aster Data、HBase 等；無Master 節(jié)點的集群，如Vertica、GBase 等。在電信運營商領(lǐng)域，MPP 多用于BASS、ODS、EDW 等系統(tǒng)數(shù)據(jù)倉庫搭建、面向歷史庫搭建、深度分析庫搭建或?qū)ｍ棓?shù)據(jù)集市的應(yīng)用等，呈現(xiàn)從平臺、數(shù)據(jù)到應(yīng)用的集中處理。隨著傳統(tǒng)架構(gòu)瓶頸的日益凸顯，MPP 數(shù)據(jù)庫在海量數(shù)據(jù)的查詢、統(tǒng)計、分析、挖掘等方面的價值日益體現(xiàn)，行業(yè)應(yīng)用也在不斷深化。

2 MPP 數(shù)據(jù)庫

MPP 是一種大規(guī)模并行處理的集群系統(tǒng)[3]，由大量松耦合的處理單元Segment 組成，多為廉價的x86設(shè)備，區(qū)別于常見的Share-Disk，其采用Share-Nothing 架構(gòu)，兩種架構(gòu)對比如圖2所示。主機、操作系統(tǒng)、內(nèi)存、存儲都是自我控制的，不存在共享，各Segment 之間通過IP網(wǎng)絡(luò)互聯(lián)組網(wǎng)。在進行事務(wù)處理時，將任務(wù)通過某種分布方式并行地分散到多個Segment 上，在各Segment 上計算完成后，將各部分的結(jié)果匯總在一起得到最終結(jié)果。相較于傳統(tǒng)的共享盤陣模式，MPP 省略了磁盤陣列的高額采購及擴容成本，且采用設(shè)備價格低廉，因此，在擴展性和成本費用上具有更大的優(yōu)勢。

由于近年來x86 設(shè)備性能的大幅提升，結(jié)合當前系統(tǒng)橫向擴容難、資源綜合利用效率低、維護成本高等矛盾日益突出的問題[4]，某省運營商自NG 4.0時代開始，就在經(jīng)分系統(tǒng)引入MPP 數(shù)據(jù)庫建設(shè)，采用大量x86 設(shè)備進行分布式組網(wǎng)，由傳統(tǒng)數(shù)據(jù)倉庫向深度分析MPP 數(shù)據(jù)庫逐步過渡，總結(jié)幾期建設(shè)經(jīng)驗及日常維護經(jīng)驗，逐步摸索探究MPP 數(shù)據(jù)庫。

3 MPP的運行機制及特點

MPP 采用無共享資源結(jié)構(gòu)，其最重要的優(yōu)勢體現(xiàn)在大規(guī)模存儲及并行計算上。這種特點不僅需要MPP 軟件的支持，還需要硬件的保障。

（1）大規(guī)模存儲

MPP 能夠被廣泛應(yīng)用的原因主要是其不依賴于共享磁陣，而是采用眾多x86 設(shè)備來搭建，并配置有大量的本地磁盤。一方面，大量的硬盤在執(zhí)行并行計算時能夠充分體現(xiàn)快速的優(yōu)勢； 另一方面，MPP 單位存儲的造價要遠小于磁盤陣列的單位造價。此外，數(shù)據(jù)的安全要兼?zhèn)淇紤]數(shù)據(jù)及硬件機器的備份冗余，進一步加大了存儲需求。MPP 采用列存儲、粗粒度索引等技術(shù)，配合分布式架構(gòu)來實現(xiàn)其高性能和高擴展性的特點。

（2）并行計算

隨著近年來x86 單體設(shè)備性能的大幅提升，MPP 集群的性能優(yōu)勢也得以體現(xiàn)。MPP的優(yōu)勢更多地體現(xiàn)在大規(guī)模計算上，當執(zhí)行大規(guī)模任務(wù)時，由于所有主機并發(fā)執(zhí)行運算，MPP 則具備較快速的處理能力。但是MPP 數(shù)據(jù)庫既要負責計算匯總，又要負責節(jié)點間通信，若通信時間占用過長，這一優(yōu)勢將不復存在。因此，MPP 多用于數(shù)據(jù)量大、響應(yīng)速度要求高、并發(fā)用戶多的交互式數(shù)據(jù)分析，支撐PB 級別的結(jié)構(gòu)化數(shù)據(jù)分析。

MPP的優(yōu)勢主要體現(xiàn)在以下幾個方面。

①分布式數(shù)據(jù)處理最核心的操作是表Join，而MPP 能較好地處理大數(shù)據(jù)量的SQL，在大表關(guān)聯(lián)、更新、排序、匯總等方面性能優(yōu)異。

圖2 架構(gòu)對比

②并發(fā)處理性能突出，數(shù)據(jù)分布時，采用某種分布方式將表分布到所有Segment 節(jié)點；讀取時，各Segment 并發(fā)加載以提高IO 性能。

③壓縮比和壓縮性能高，壓縮比高達10∶1，甚至更高，能提高數(shù)據(jù)存儲能力。很多產(chǎn)品同時支持行存儲及列存儲，可以根據(jù)不同應(yīng)用需求確定存儲類型，以提高查詢效率。

④MPP 號稱支持線性擴展及具備高穩(wěn)定性，支持在線擴容?；ヂ?lián)網(wǎng)應(yīng)用普及而帶來的用戶訪問量增加，導致大規(guī)模數(shù)據(jù)的存儲和訪問成為系統(tǒng)設(shè)計的瓶頸，這就要求系統(tǒng)同時具備較強的穩(wěn)定性及靈活的擴展性，Share-Nothing的架構(gòu)使得MPP 不再受限于傳統(tǒng)共享存儲的大小，具有很強的擴展性。

4 設(shè)計MPP 數(shù)據(jù)庫的影響因素

MPP 數(shù)據(jù)庫在替代傳統(tǒng)IOE 數(shù)據(jù)倉庫的進程中發(fā)揮著巨大作用，已經(jīng)從炒作走向商用，然而，隨著在工程過程中的接觸以及運維人員的反饋，也逐步發(fā)現(xiàn)了一些問題。MPP的工作原理是通過數(shù)據(jù)分布策略使得每個數(shù)據(jù)節(jié)點承擔相當?shù)臄?shù)據(jù)任務(wù)。其中，能力差的節(jié)點將成為短板，從而會拖慢集群的整體性能，因此MPP 數(shù)據(jù)庫的設(shè)備必須具有一致的配置及性能，在進行系統(tǒng)設(shè)計時主要受以下因素制約。

（1）設(shè)備選型不可控

除首次建設(shè)MPP 數(shù)據(jù)庫外，之后每次節(jié)點擴容時都要面臨設(shè)備的選型配比和壓力一致性測試，但采集結(jié)果不可控，無論同構(gòu)、異構(gòu)，設(shè)備均會存在問題。同構(gòu)產(chǎn)品性能可能會由于產(chǎn)品升級、性能提高而造成新機器性能浪費；異構(gòu)廠家的服務(wù)器參數(shù)即使在配置上相同，在能力上也會存在差距，只能達到準線性擴容。

（2）自動化負載均衡分配不到位

設(shè)備性能的差距始終是影響擴容的一個因素，部分產(chǎn)品無法根據(jù)設(shè)備能力自動分配相應(yīng)的任務(wù)量。傳統(tǒng)數(shù)據(jù)庫的小型機時代，由于設(shè)備數(shù)量較少，可以根據(jù)設(shè)備的性能，人工調(diào)整運行的實例數(shù)量，做到負載均衡。而在MPP 架構(gòu)機制中，動輒幾十臺的設(shè)備上線，人工調(diào)節(jié)工作無疑是海量的，而人工調(diào)節(jié)此類的案例更多地存在于電商領(lǐng)域中，依靠工程師的經(jīng)驗來調(diào)節(jié)，對操作人員的專業(yè)水平要求極高，對于企業(yè)級的生產(chǎn)系統(tǒng)來說并不可取，缺乏安全保障機制。

（3）數(shù)據(jù)重分布困難，耗時長

當數(shù)據(jù)庫節(jié)點擴容重新組成集群時，需要重新分布已有數(shù)據(jù)，但數(shù)據(jù)重分布需要耗費大量時間，影響核心生產(chǎn)系統(tǒng)。反之，在人工節(jié)點收縮或由于部分設(shè)備宕機造成節(jié)點收縮時，同樣存在相同的問題，部分產(chǎn)品甚至不支持節(jié)點收縮，造成設(shè)備一旦加入節(jié)點群后便不能退出，設(shè)備的故障恢復策略并不完善。

針對上述存在的若干問題，結(jié)合工程經(jīng)驗，提出以下建議。

（1）選配建議

由于MPP 數(shù)據(jù)庫的備份保障機制對存儲需求較大，設(shè)備選配盡量選用可配置較多塊本地SAS 硬盤（一般為12~24 塊，萬轉(zhuǎn)/s 以上）的機架式x86 服務(wù)器，并具備RAID 保障機制，方便擴展級聯(lián)并保證較高的IO，而刀片式服務(wù)器做存儲節(jié)點并無優(yōu)勢，存儲刀片PC的所有數(shù)據(jù)吞吐都要通過刀框的背板，無論是測試還是日常運行環(huán)境，都極易造成IO瓶頸。退一步講，即使機架式服務(wù)器與刀片式服務(wù)器能夠達到相同配置，業(yè)內(nèi)機架式、刀片式x86 服務(wù)器混搭MPP 數(shù)據(jù)庫的先例在生產(chǎn)系統(tǒng)也極為少見。

（2）組網(wǎng)建議

由于MPP的運行機制，每一項任務(wù)都要分配到所有的節(jié)點，節(jié)點之間也會涉及信息的傳遞，機器交換網(wǎng)卡的速度、存儲介質(zhì)的讀寫速度，都會影響數(shù)據(jù)庫的整體性能，而所有的信息傳遞都要通過外部互聯(lián)交換機作為中轉(zhuǎn)，因此，務(wù)必要保證此交換機具備較大的吞吐量，達到萬兆組網(wǎng)，消除通信時延。

（3）冗余建議

為避免非主流設(shè)備的易淘汰性，務(wù)必選用比較通用的中高檔次的x86 設(shè)備類型，保證后期擴容能方便匹配，實現(xiàn)準線性擴容。此外，在投資充分的前提下，盡量多配置冗余硬件，一方面保證數(shù)據(jù)庫出現(xiàn)故障后能夠及時恢復，另一方面考慮盡量減少MPP的擴容次數(shù)以減小擴容代價。

（4）軟件建議

從數(shù)據(jù)庫軟件自身來說，應(yīng)具備較強的設(shè)備適用性，并具有任務(wù)的自動調(diào)節(jié)分配、可網(wǎng)管性、易操作性等功能，成為規(guī)范化、標準化的通用產(chǎn)品。

5 結(jié)束語

近年來，業(yè)界去IOE的勢頭越來越強烈，運營商邁入徹底的云計算服務(wù)模式已成為時代的必然，各省都或多或少進行了MPP 數(shù)據(jù)庫的建設(shè)，謀求從系統(tǒng)架構(gòu)上進行改變，然而，理想與現(xiàn)實之間的矛盾注定了過程的復雜性。在此，MPP 數(shù)據(jù)庫建設(shè)經(jīng)驗只是拋磚引玉的一點，僅供參考借鑒，以后還會面臨各種其他新挑戰(zhàn)及新問題，不是為用而用，要打造出精品的IT 支撐還需要運營商、軟/硬件提供商等多方面協(xié)同配合，共同努力。

[1]張雨，蔡鑫，李愛民等.分布式文件系統(tǒng)與MPP 數(shù)據(jù)庫的混搭架構(gòu)在電信大數(shù)據(jù)平臺中的應(yīng)用[J].電信科學,2013，（11）.

[2]孫淳曄.基于大數(shù)據(jù)平臺的企業(yè)級經(jīng)營分析系統(tǒng)建設(shè)探討[J].電信工程技術(shù)與標準化,2015，（1）.

[3]辛晃，易興輝，陳震宇.基于Hadoop+MPP 架構(gòu)的電信運營商網(wǎng)絡(luò)數(shù)據(jù)共享平臺研究[J].電信科學,2014，（4）.

[4]饒高鋼，郝金隆.電信運營商IT 系統(tǒng)去IOE 思路及實施方法[J].電信工程技術(shù)與標準化,2014，（9）.