架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望(上)

１ 引言

    最近幾年，數(shù)據(jù)倉庫又成為數(shù)據(jù)管理研究的熱點(diǎn)領(lǐng)域，主要原因是當(dāng)前數(shù)據(jù)倉庫系統(tǒng)面臨的需求在數(shù)據(jù)源、需提供的數(shù)據(jù)服務(wù)和所處的硬件環(huán)境等方面發(fā)生了根本性的變化（詳見１．１節(jié)），這些變化是我們必須面對的。

    本文在大數(shù)據(jù)的時(shí)代背景下，對現(xiàn)有數(shù)據(jù)倉庫系統(tǒng)實(shí)現(xiàn)方案（主要是并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ）進(jìn)行重新審視，期望能為設(shè)計(jì)滿足時(shí)代需求的數(shù)據(jù)倉庫系統(tǒng)提供理論參考，限于篇幅，本文主要關(guān)注不同數(shù)據(jù)倉庫實(shí)現(xiàn)方案的主體架構(gòu)及其缺陷在最近幾年的改進(jìn)情況，依據(jù)研究立足點(diǎn)的不同，本文將該領(lǐng)域的研究歸為三大類：并行數(shù)據(jù)庫、ＭａｐＲｅｄｕｃｅ、并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ技術(shù)的混合架構(gòu)，其中第三類研究又細(xì)分為：并行數(shù)據(jù)庫主導(dǎo)型、ＭａｐＲｅｄｕｃｅ主導(dǎo)型、并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ集成型三種，文第１節(jié)分析大數(shù)據(jù)時(shí)代，數(shù)據(jù)倉庫所面臨的問題及挑戰(zhàn)；第２節(jié)列出大數(shù)據(jù)時(shí)代的數(shù)據(jù)倉庫平臺需具備的幾個(gè)重要特性；第３節(jié)到第５節(jié)就這幾個(gè)特性對各類平臺進(jìn)行歸納分析；第６節(jié)對最新研究做一跟蹤歸納；第７節(jié)介紹中國人民大學(xué)在大數(shù)據(jù)分析方面的研究工作；第８節(jié)對未來研究做出展望；第９節(jié)總結(jié)全文。

    １．１ 三個(gè)變化

    （１）數(shù)據(jù)量。由ＴＢ級升至ＰＢ級，并仍在持續(xù)爆炸式增長，根據(jù)ＷｉｎｔｅｒＣｏｒｐ的調(diào)查顯示，最大的數(shù)據(jù)倉庫中的數(shù)據(jù)量，每兩年增加３倍［１］（年均增長率為１７３％），其增長速度遠(yuǎn)超摩爾定律增長速度，照此增長速度計(jì)算，２０１５年最大數(shù)據(jù)倉庫中的數(shù)據(jù)量將逼近１００ＰＢ。

    （２）分析需求。由常規(guī)分析轉(zhuǎn)向深度分析（ＤｅｅｐＡｎａｌｙｔｉｃｓ），數(shù)據(jù)分析日益成為企業(yè)利潤必不可少的支撐點(diǎn)，根據(jù)ＴＤＷＩ對大數(shù)據(jù)分析的報(bào)告（如圖１），企業(yè)已經(jīng)不滿足于對現(xiàn)有數(shù)據(jù)的分析和監(jiān)測，而是更期望能對未來趨勢有更多的分析和預(yù)測，以增強(qiáng)企業(yè)競爭力，這些分析操作包括諸如移動平均線分析、數(shù)據(jù)關(guān)聯(lián)關(guān)系分析、回歸分析、市場籃分析等復(fù)雜統(tǒng)計(jì)分析，我們稱之為深度分析，值得補(bǔ)充的是，本文中的大數(shù)據(jù)分析不僅僅指基于大數(shù)據(jù)上的深度分析，也包括常規(guī)分析。

圖１ 分析的趨勢

    （３）硬件平臺。由高端服務(wù)器轉(zhuǎn)向由中低端硬件構(gòu)成的大規(guī)模機(jī)群平臺，由于數(shù)據(jù)量的迅速增加，并行數(shù)據(jù)庫的規(guī)模不得不隨之增大，從而導(dǎo)致其成本的急劇上升，出于成本的考慮，越來越多的企業(yè)將應(yīng)用由高端服務(wù)器轉(zhuǎn)向了由中低端硬件構(gòu)成的大規(guī)模機(jī)群平臺。

    １.２ 兩個(gè)問題

    圖２是一個(gè)典型的數(shù)據(jù)倉庫架構(gòu)，從圖中我們可以看出，傳統(tǒng)的數(shù)據(jù)倉庫將整個(gè)實(shí)現(xiàn)劃分為４個(gè)層次，數(shù)據(jù)源中的數(shù)據(jù)首先通過ＥＴＬ工具被抽取到數(shù)據(jù)倉庫中進(jìn)行集中存儲和管理，再按照星型模型或雪花模型組織數(shù)據(jù)，然后ＯＬＡＰ工具從數(shù)據(jù)倉庫中讀取數(shù)據(jù)，生成數(shù)據(jù)立方體（ＭＯＬＡＰ）或者直接訪問數(shù)據(jù)倉庫進(jìn)行數(shù)據(jù)分析（ＲＯＬＡＰ），在大數(shù)據(jù)時(shí)代，此種計(jì)算模式存在兩個(gè)問題：

    問題１，數(shù)據(jù)移動代價(jià)過高，在數(shù)據(jù)源層和分析層之間引入一個(gè)存儲管理層，可以提升數(shù)據(jù)質(zhì)量并針對查詢進(jìn)行優(yōu)化，但也付出了較大的數(shù)據(jù)遷移代價(jià)和執(zhí)行時(shí)的連接代價(jià)：數(shù)據(jù)首先通過復(fù)雜且耗時(shí)的ＥＴＬ過程存儲到數(shù)據(jù)倉庫中，在ＯＬＡＰ服務(wù)器中轉(zhuǎn)化為星型模型或者雪花模型；執(zhí)行分析時(shí)，又通過連接方式將數(shù)據(jù)從數(shù)據(jù)庫中取出，這些代價(jià)在ＴＢ級時(shí)也許可以接受，但面對大數(shù)據(jù)，其執(zhí)行時(shí)間至少會增長幾個(gè)數(shù)量級，更為重要的是，對于大量的即席分析，這種數(shù)據(jù)移動的計(jì)算模式是不可取的。

圖２ 一個(gè)典型的數(shù)據(jù)倉庫架構(gòu)

    問題２，不能快速適應(yīng)變化，傳統(tǒng)的數(shù)據(jù)倉庫假設(shè)主題是較少變化的，其應(yīng)對變化的方式是對數(shù)據(jù)源到前端展現(xiàn)的整個(gè)流程中的每個(gè)部分進(jìn)行修改，然后再重新加載數(shù)據(jù)，甚至重新計(jì)算數(shù)據(jù)，導(dǎo)致其適應(yīng)變化的周期較長，這種模式比較適合對數(shù)據(jù)質(zhì)量和查詢性能要求較高、而不太計(jì)較預(yù)處理代價(jià)的場合，但在大數(shù)據(jù)時(shí)代，分析處在變化的業(yè)務(wù)環(huán)境中，這種模式將難以適應(yīng)新的需求。

    １．３ 一個(gè)鴻溝

    在大數(shù)據(jù)時(shí)代，巨量數(shù)據(jù)與系統(tǒng)的數(shù)據(jù)處理能力之間將會產(chǎn)生一個(gè)鴻溝：一邊是至少ＰＢ級的數(shù)據(jù)量，另一邊是面向傳統(tǒng)數(shù)據(jù)分析能力設(shè)計(jì)的數(shù)據(jù)倉庫和各種ＢＩ工具，如果這些系統(tǒng)或工具發(fā)展緩慢，該鴻溝將會隨著數(shù)據(jù)量的持續(xù)爆炸式增長而逐步拉大。

    雖然，傳統(tǒng)數(shù)據(jù)倉庫可以采用舍棄不重要數(shù)據(jù)或者建立數(shù)據(jù)集市的方式來緩解此問題，但畢竟只是權(quán)益之策，并非系統(tǒng)級解決方案，而且，舍棄的數(shù)據(jù)在未來可能會重新使用，以發(fā)掘更大的價(jià)值。

２ 期望特性

    本節(jié)我們列出對大數(shù)據(jù)進(jìn)行分析時(shí)，數(shù)據(jù)倉庫系統(tǒng)需具備的幾個(gè)重要特性（表１所示）。

表１ 大數(shù)據(jù)分析平臺需具備的特性

    高度可擴(kuò)展性，一個(gè)明顯的事實(shí)是，數(shù)據(jù)庫不能依靠一臺或少數(shù)幾臺機(jī)器的升級（ｓｃａｌｅ�玻酰鹂v向擴(kuò)展）滿足數(shù)據(jù)量的爆炸式增長，而是希望能方便地做到橫向可擴(kuò)展（ｓｃａｌｅ�玻铮酰簦﹣韺�(shí)現(xiàn)此目標(biāo)，普遍認(rèn)為ｓｈａｒｅｄ�玻睿铮簦瑁椋睿鐭o共享結(jié)構(gòu)（每個(gè)節(jié)點(diǎn)擁有私有內(nèi)存和磁盤，并且通過高速網(wǎng)絡(luò)同其它節(jié)點(diǎn)互連）具備較好的擴(kuò)展性，分析型操作往往涉及大規(guī)模的并行掃描、多維聚集及星型連接操作，這些操作也比較適合在無共享結(jié)構(gòu)的網(wǎng)絡(luò)環(huán)境運(yùn)行，Ｔｅｒａｄａｔａ即采用此結(jié)構(gòu)，Ｏｒａｃｌｅ在其新產(chǎn)品Ｅｘａｄａｔａ中也采用了此結(jié)構(gòu)。

    高性能，數(shù)據(jù)量的增長并沒有降低對數(shù)據(jù)庫性能的要求，反而有所提高，軟件系統(tǒng)性能的提升可以降低企業(yè)對硬件的投入成本、節(jié)省計(jì)算資源，提高系統(tǒng)吞吐量，巨量數(shù)據(jù)的效率優(yōu)化，并行是必由之路，１ＰＢ數(shù)據(jù)在５０ＭＢ／ｓ速度下串行掃描一次，需要２３０天；而在６０００塊磁盤上，并行掃描１ＰＢ數(shù)據(jù)只需要１個(gè)小時(shí)。

    高度容錯(cuò)，大數(shù)據(jù)的容錯(cuò)性要求在查詢執(zhí)行過程中，一個(gè)參與節(jié)點(diǎn)失效時(shí)，不需要重做整個(gè)查詢，而機(jī)群節(jié)點(diǎn)數(shù)的增加會帶來節(jié)點(diǎn)失效概率的增加，在大規(guī)模機(jī)群環(huán)境下，節(jié)點(diǎn)的失效將不再是稀有事件（Ｇｏｏｇｌｅ報(bào)告，平均每個(gè)ＭａｐＲｅｄｕｃｅ數(shù)據(jù)處理任務(wù)就有１.２個(gè)工作節(jié)點(diǎn)失效），因此在大規(guī)模機(jī)群環(huán)境下，系統(tǒng)不能依賴于硬件來保證容錯(cuò)性，要更多地考慮軟件級容錯(cuò)。

    支持異構(gòu)環(huán)境，建設(shè)同構(gòu)系統(tǒng)的大規(guī)模機(jī)群難度較大，原因在于計(jì)算機(jī)硬件更新較快，一次性購置大量同構(gòu)的計(jì)算機(jī)是不可取的，而且也會在未來添置異構(gòu)計(jì)算資源，此外，不少企業(yè)已經(jīng)積累了一些閑置的計(jì)算機(jī)資源，此種情況下，對異構(gòu)環(huán)境的支持可以有效地利用這些閑置計(jì)算資源，降低硬件成本的投入，還需特別關(guān)注的是，在異構(gòu)環(huán)境下，不同節(jié)點(diǎn)的性能是不一樣的，可能出現(xiàn)“木桶效應(yīng)”，即最慢節(jié)點(diǎn)的性能決定整體處理性能，因此，異構(gòu)的機(jī)群需要特別關(guān)注負(fù)載均衡、任務(wù)調(diào)度等方面的設(shè)計(jì)。

    較低的分析延遲，分析延遲指的是分析前的數(shù)據(jù)準(zhǔn)備時(shí)間，在大數(shù)據(jù)時(shí)代，分析所處的業(yè)務(wù)環(huán)境是變化的，因此也要求系統(tǒng)能動態(tài)地適應(yīng)業(yè)務(wù)分析需求，在分析需求發(fā)生變化時(shí)，減少數(shù)據(jù)準(zhǔn)備時(shí)間，系統(tǒng)能盡可能快地做出反應(yīng)，快速地進(jìn)行數(shù)據(jù)分析。

    易用且開放的接口，ＳＱＬ的優(yōu)點(diǎn)是簡單易用，但其主要用于數(shù)據(jù)的檢索查詢，對于大數(shù)據(jù)上的深度分析來講，是不夠的，原因在于：（１）其提供的服務(wù)方式依賴于數(shù)據(jù)移動來實(shí)現(xiàn)：將數(shù)據(jù)從數(shù)據(jù)庫中取出，然后傳遞給應(yīng)用程序，該實(shí)現(xiàn)方式在大數(shù)據(jù)時(shí)代代價(jià)過高；（２）復(fù)雜的分析功能，如Ｒ或Ｍａｔｌａｂ中的分析功能，ＳＱＬ是難以勝任的，因此，除對ＳＱＬ的支持外，系統(tǒng)還應(yīng)能提供開放的接口，讓用戶自己開發(fā)需要的功能，設(shè)計(jì)該接口時(shí)，除了關(guān)注其易用性和開放性，還需要特別注意兩點(diǎn)隱藏的要求：（１）基于接口開發(fā)的用戶自定義函數(shù)，能自動在機(jī)群上并行執(zhí)行；（２）分析在數(shù)據(jù)庫內(nèi)進(jìn)行，即分析盡可能靠近數(shù)據(jù)。

    較低的成本，在滿足需求的前提下，某技術(shù)成本越低，其生命力就越強(qiáng)，需要指出的是成本是一個(gè)綜合指標(biāo)，不僅僅是硬件或軟件的代價(jià)，還應(yīng)包括日常運(yùn)維成本（網(wǎng)絡(luò)費(fèi)用、電費(fèi)、建筑等）和管理人員成本等，據(jù)報(bào)告，數(shù)據(jù)中心的主要成本不是硬件的購置成本，而是日常運(yùn)維成本，因此，在設(shè)計(jì)系統(tǒng)時(shí)需要更多地關(guān)注此項(xiàng)內(nèi)容。

    向下兼容性，數(shù)據(jù)倉庫發(fā)展的３０年，產(chǎn)生了大量面向客戶業(yè)務(wù)的數(shù)據(jù)處理工具（如Ｉｎｆｏｒｍａｃｔｉｃａ、ＤａｔａＳｔａｇｅ等）、分析軟件（如ＳＰＳＳ、Ｒ、Ｍａｔｌａｂ等）和前端展現(xiàn)工具（如水晶報(bào)表）等，這些軟件是一筆寶貴的財(cái)富，已被分析人員所熟悉，是大數(shù)據(jù)時(shí)代中小規(guī)模數(shù)據(jù)分析的必要補(bǔ)充，因此，新的數(shù)據(jù)倉庫需考慮同傳統(tǒng)商務(wù)智能工具的兼容性，由于這些系統(tǒng)往往提供標(biāo)準(zhǔn)驅(qū)動程序，如ＯＤＢＣ、ＪＤＢＣ等，這項(xiàng)需求的實(shí)際要求是對ＳＱＬ的支持。

    總之，以較低的成本投入、高效地進(jìn)行數(shù)據(jù)分析，是大數(shù)據(jù)分析的基本目標(biāo)。

３ 并行數(shù)據(jù)庫

    并行數(shù)據(jù)庫起源于２０世紀(jì)８０年代，當(dāng)前主流的并行數(shù)據(jù)庫都同早期的Ｇａｍｍａ和Ｇｒａｃｅ等并行數(shù)據(jù)庫類似，這些數(shù)據(jù)庫都支持標(biāo)準(zhǔn)ＳＱＬ，并且實(shí)現(xiàn)了數(shù)據(jù)庫界過去３０年提出的許多先進(jìn)技術(shù)，其主要采用ｓｈａｒｅｄ�玻睿铮簦瑁椋睿缃Y(jié)構(gòu)，將關(guān)系表在節(jié)點(diǎn)間橫向劃分，并且利用優(yōu)化器來對執(zhí)行過程進(jìn)行調(diào)度和管理，其目標(biāo)是高性能和高可用性。

    并行數(shù)據(jù)庫的最大優(yōu)勢在于性能，這主要得益于數(shù)據(jù)庫界近幾十年的研究成果———許多先進(jìn)的技術(shù)手段及算法，如索引、數(shù)據(jù)壓縮、物化視圖、結(jié)果緩沖、Ｉ／Ｏ共享、優(yōu)化的數(shù)據(jù)連接等，但是在大數(shù)據(jù)時(shí)代，如前言所述，數(shù)據(jù)移動的實(shí)現(xiàn)方式將影響其性能。

    并行數(shù)據(jù)庫通過ＳＱＬ向外提供數(shù)據(jù)訪問服務(wù)，ＳＱＬ因其簡單易用的特點(diǎn)而被廣泛使用，因此，大多ＢＩ工具都支持基于標(biāo)準(zhǔn)ＳＱＬ的數(shù)據(jù)交互方式，使得關(guān)系數(shù)據(jù)庫能較好地兼容當(dāng)前多數(shù)ＢＩ工具，某些數(shù)據(jù)庫，如ＩＢＭＤＢ２還針對一些ＢＩ工具進(jìn)行了優(yōu)化，但在大數(shù)據(jù)分析面前，ＳＱＬ接口面臨巨大挑戰(zhàn)，ＳＱＬ的優(yōu)勢源于其對底層數(shù)據(jù)訪問的封裝，但封裝在一定程度上影響了其開放性，而且并行數(shù)據(jù)庫提供的用戶自定義函數(shù)大都是基于單數(shù)據(jù)庫實(shí)例設(shè)計(jì)的，從而不能在機(jī)群上并行執(zhí)行，也即意味著傳統(tǒng)的實(shí)現(xiàn)方式不適合大數(shù)據(jù)的處理及分析，而且，在并行數(shù)據(jù)庫中實(shí)現(xiàn)用戶自定義函數(shù)往往需要經(jīng)過復(fù)雜的系統(tǒng)交互，甚至要熟悉數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)及系統(tǒng)調(diào)用等，從而難以使用。

    并行數(shù)據(jù)庫在擴(kuò)展性、容錯(cuò)性、成本、對異構(gòu)環(huán)境的支持等幾項(xiàng)上有所欠缺，這幾項(xiàng)實(shí)際是相互影響的，我們以其最大問題———擴(kuò)展性為主線展開討論，并行數(shù)據(jù)庫大多支持有限擴(kuò)展，一般可擴(kuò)至數(shù)百節(jié)點(diǎn)的規(guī)模，尚未有數(shù)千節(jié)點(diǎn)規(guī)模的應(yīng)用案例，并行數(shù)據(jù)庫擴(kuò)展性有限主要因?yàn)槿缦聨�點(diǎn)：（１）并行數(shù)據(jù)庫軟件級容錯(cuò)能力較差，并行數(shù)據(jù)庫基于高端硬件設(shè)計(jì)，并且假設(shè)查詢失敗屬于稀有事件，因此當(dāng)查詢失敗時(shí)，一般采取重做查詢的方式，而在大規(guī)模機(jī)群環(huán)境下，查詢失敗將會變?yōu)橐粋�(gè)普通事件，極端情況下，并行數(shù)據(jù)有可能出現(xiàn)不停重做查詢的局面；（２）并行數(shù)據(jù)庫對異構(gòu)硬件的支持非常有限，且對于處理較慢的節(jié)點(diǎn)反應(yīng)敏感，容易出現(xiàn)“木桶效應(yīng)”，如第２節(jié)中所論述的，完全基于同構(gòu)硬件搭建大規(guī)模機(jī)群在現(xiàn)實(shí)中是較難實(shí)現(xiàn)的，因而，對異構(gòu)硬件的支持能力影響了其擴(kuò)展性；（３）并行數(shù)據(jù)庫若做到大規(guī)模可擴(kuò)展，其代價(jià)將會較高（需基于高端硬件來保證可靠性，需購買昂貴的軟件系統(tǒng)），從而限制了其擴(kuò)展性；（４）根據(jù)ＣＡＰ理論①，在分布式系統(tǒng)中，數(shù)據(jù)一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、子網(wǎng)可分解性（ＮｅｔｗｏｒｋＰａｒｔｉｔｉｏｎｉｎｇ）不可同時(shí)兼得，選擇其中任兩項(xiàng)，便會損害另一項(xiàng)，并行數(shù)據(jù)庫追求的是數(shù)據(jù)一致性和系統(tǒng)的可用性，從而影響了它的擴(kuò)展能力。

    此外，如１.２節(jié)所討論的，基于并行數(shù)據(jù)庫實(shí)現(xiàn)的傳統(tǒng)數(shù)據(jù)倉庫借助于外圍工具（ＥＴＬ工具、ＯＬＡＰ產(chǎn)品、ＢＩ報(bào)表工具、統(tǒng)計(jì)分析軟件等）來完成數(shù)據(jù)的預(yù)處理和分析展現(xiàn)任務(wù)，導(dǎo)致其數(shù)據(jù)處理及分析過程涉及大量的數(shù)據(jù)遷移和計(jì)算，分析延遲往往較高。

４MapReduce

    ＭａｐＲｅｄｕｃｅ是２００４年由Ｇｏｏｇｌｅ提出的面向大數(shù)據(jù)集處理的編程模型，起初主要用作互聯(lián)網(wǎng)數(shù)據(jù)的處理，例如文檔抓取、倒排索引的建立等，但由于其簡單而強(qiáng)大的數(shù)據(jù)處理接口和對大規(guī)模并行執(zhí)行、容錯(cuò)及負(fù)載均衡等實(shí)現(xiàn)細(xì)節(jié)的隱藏，該技術(shù)一經(jīng)推出便迅速在機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘、數(shù)據(jù)分析等領(lǐng)域得到廣泛應(yīng)用。

    ＭａｐＲｅｄｕｃｅ將數(shù)據(jù)處理任務(wù)抽象為一系列的Ｍａｐ（映射）�玻遥澹洌酰悖澹ɑ�簡）操作對，Ｍａｐ主要完成數(shù)據(jù)的過濾操作，Ｒｅｄｕｃｅ主要完成數(shù)據(jù)的聚集操作，輸入輸出數(shù)據(jù)均以〈ｋｅｙ，ｖａｌｕｅ〉格式存儲，用戶在使用該編程模型時(shí)，只需按照自己熟悉的語言實(shí)現(xiàn)Ｍａｐ函數(shù)和Ｒｅｄｕｃｅ函即可，ＭａｐＲｅｄｕｃｅ框架會自動對任務(wù)進(jìn)行劃分以做到并行執(zhí)行。

    下面本文將以基于ＭａｐＲｅｄｕｃｅ的開源實(shí)現(xiàn)Ｈａｄｏｏｐ為主，對其主要特性進(jìn)行介紹。

    ＭａｐＲｅｄｕｃｅ是面向由數(shù)千臺中低端計(jì)算機(jī)組成的大規(guī)模機(jī)群而設(shè)計(jì)的，其擴(kuò)展能力得益于其ｓｈａｒｅｄ�玻睿铮簦瑁椋睿缃Y(jié)構(gòu)、各個(gè)節(jié)點(diǎn)間的松耦合性和較強(qiáng)的軟件級容錯(cuò)能力：節(jié)點(diǎn)可以被任意地從機(jī)群中移除，而幾乎不影響現(xiàn)有任務(wù)的執(zhí)行，該技術(shù)被稱為ＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ／ＲｅｌｉａｂｌｅＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔ（ａｎｄＩｎｅｘｐｅｎｓｉｖｅ）Ｎｏｄｅｓ），ＭａｐＲｅｄｕｃｅ卓越的擴(kuò)展能力已在工業(yè)界（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｂａｉｄｕ、Ｔａｏｂ等）得到了充分驗(yàn)證，ＭａｐＲｅｄｕｃｅ對硬件的要求較低，可以基于異構(gòu)的廉價(jià)硬件來搭建機(jī)群，且免費(fèi)開源，因此其構(gòu)建成本低于并行數(shù)據(jù)庫，但基于ＭａｐＲｅｄｕｃｅ的應(yīng)用軟件相對較少，許多數(shù)據(jù)分析功能需要用戶自行開發(fā)，從而會導(dǎo)致使用成本的增加。

    作為開源系統(tǒng)，ＭａｐＲｅｄｕｃｅ具有完全的開放性：其〈ｋｅｙ，ｖａｌｕｅ〉存儲模型具有較強(qiáng)的表現(xiàn)力，可以存儲任意格式的數(shù)據(jù)；Ｍａｐ和Ｒｅｄｕｃｅ兩個(gè)基本的函數(shù)接口也給用戶提供了足夠的發(fā)揮空間，可以實(shí)現(xiàn)各種復(fù)雜的數(shù)據(jù)處理功能，但這種開放性也帶來一個(gè)問題，就是將本來應(yīng)由數(shù)據(jù)庫管理系統(tǒng)完成的工作，諸如文件存儲格式的設(shè)計(jì)、模式信息的記錄、數(shù)據(jù)處理算法的實(shí)現(xiàn)等，轉(zhuǎn)移給了程序員，從而導(dǎo)致程序員負(fù)擔(dān)過重，程序員水平對系統(tǒng)處理性能起決定性作用，在某些情況下，寫ＭａｐＲｅｄｕｃｅ程序的時(shí)間遠(yuǎn)大于寫ＳＱＬ語句的時(shí)間，部分復(fù)雜的ＢＩ報(bào)表分析，可能僅程序的編寫和調(diào)試就要耗費(fèi)幾天的時(shí)間。

    基于ＭａｐＲｅｄｕｃｅ平臺的分析，無需復(fù)雜的數(shù)據(jù)預(yù)處理和寫入數(shù)據(jù)庫的過程，而是可以直接基于平面文件進(jìn)行分析，并且其采用的計(jì)算模式是移動計(jì)算而非移動數(shù)據(jù)，因此可以將分析延遲最小化。

    在同等硬件條件下，ＭａｐＲｅｄｕｃｅ性能遠(yuǎn)低于并行數(shù)據(jù)庫，這是由其最初的設(shè)計(jì)定位決定的，ＭａｐＲｅｄｕｃｅ的設(shè)計(jì)初衷是面向非結(jié)構(gòu)化數(shù)據(jù)的處理，這些數(shù)據(jù)具有數(shù)據(jù)量大，處理復(fù)雜等特點(diǎn)，而且往往是一次性處理，為了獲得較好的擴(kuò)展能力和容錯(cuò)能力，ＭａｐＲｅｄｕｃｅ采取了基于掃描的處理模式和對中間結(jié)果步步物化的執(zhí)行策略，從而導(dǎo)致較高的Ｉ／Ｏ代價(jià)，為了減少數(shù)據(jù)預(yù)處理時(shí)間，ＭａｐＲｅｄｕｃｅ沒有使用模式、索引、物化視圖等技術(shù)手段，其數(shù)據(jù)預(yù)處理僅是一次數(shù)據(jù)加載操作，但由此導(dǎo)致了一個(gè)問題———較高的元組解析代價(jià)。ＭａｐＲｅｄｕｃｅ環(huán)境下，每個(gè)查詢都是直接從文件系統(tǒng)中讀入原始數(shù)據(jù)文件，而非傳統(tǒng)的從數(shù)據(jù)庫中讀入經(jīng)處理過的文件，因此其元組解析代價(jià)遠(yuǎn)高于關(guān)系數(shù)據(jù)庫，對數(shù)據(jù)分析領(lǐng)域來說，連接是關(guān)鍵操作（如傳統(tǒng)的星型查詢和雪花查詢均是依賴于連接來處理查詢），但ＭａｐＲｅｄｕｃｅ處理連接的性能尤其不盡如人意，原因在于ＭａｐＲｅｄｕｃｅ最初是針對單數(shù)據(jù)集設(shè)計(jì)的處理模型，而連接操作往往涉及多個(gè)數(shù)據(jù)集，在利用ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)連接時(shí)，最直接的方式是每個(gè)任務(wù)執(zhí)行一個(gè)屬性上的連接操作，然后將多個(gè)ＭａｐＲｅｄｕｃｅ任務(wù)通過物化的中間結(jié)果串接起來，這種實(shí)現(xiàn)方式往往涉及中間結(jié)果的讀寫，從而導(dǎo)致大量的Ｉ／Ｏ操作和網(wǎng)絡(luò)傳輸。

    ＭａｐＲｅｄｕｃｅ目前基本不兼容現(xiàn)有的ＢＩ工具，原因在于其初衷并不是要成為數(shù)據(jù)庫系統(tǒng)，因此它并未提供ＳＱＬ接口，但已有研究致力于ＳＱＬ語句與ＭａｐＲｅｄｕｃｅ任務(wù)的轉(zhuǎn)換工作（例如Ｈｉｖｅ），進(jìn)而有可能實(shí)現(xiàn)ＭａｐＲｅｄｕｃｅ與現(xiàn)存ＢＩ工具的兼容。

５ 并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ的混合架構(gòu)

    基于以上分析，我們可以清楚地看出，基于并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)的數(shù)據(jù)倉庫系統(tǒng)都不是大數(shù)據(jù)分析的理想方案，針對兩者哪個(gè)更適合時(shí)代需求的問題，業(yè)界近年展開了激烈爭論，當(dāng)前基本達(dá)成如下共識：并行數(shù)據(jù)庫和ＭａｐＲｅｄｕｃｅ是互補(bǔ)關(guān)系，應(yīng)該相互學(xué)習(xí)，基于該觀點(diǎn)，大量研究著手將兩者結(jié)合起來，期望設(shè)計(jì)出兼具兩者優(yōu)點(diǎn)的數(shù)據(jù)分析平臺，這種架構(gòu)又可以分為三類：并行數(shù)據(jù)庫主導(dǎo)型、ＭａｐＲｅｄｕｃｅ主導(dǎo)型、ＭａｐＲｅｄｕｃｅ和并行數(shù)據(jù)庫集成型（表２對３種架構(gòu)進(jìn)行了對比分析）。

表２ 混合架構(gòu)型解決方案對比分析

    ５．１ 并行數(shù)據(jù)庫主導(dǎo)型

    該種方式關(guān)注于如何利用ＭａｐＲｅｄｕｃｅ來增強(qiáng)并行數(shù)據(jù)庫的數(shù)據(jù)處理能力，代表性系統(tǒng)是Ｇｒｅｅｎｐｌｕｍ（已被ＥＭＣ收購）和ＡｓｔｅｒＤａｔａ（已被Ｔｅｒａｄａｔａ收購），ＡｓｔｅｒＤａｔａ將ＳＱＬ和ＭａｐＲｅｄｕｃｅ進(jìn)行結(jié)合，針對大數(shù)據(jù)分析提出了ＳＱＬ／ＭａｐＲｅｄｕｃｅ框架。

    該框架允許用戶使用Ｃ＋＋、ｊａｖａ、Ｐｙｔｈｏｎ等語言編寫ＭａｐＲｅｄｕｃｅ函數(shù)，編寫的函數(shù)可以作為一個(gè)子查詢在ＳＱＬ中使用，從而同時(shí)獲得ＳＱＬ的易用性和ＭａｐＲｅｄｕｃｅ的開放性，不僅如此，ＡｓｔｅｒＤａｔａ基于ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)了３０多個(gè)統(tǒng)計(jì)軟件包，從而將數(shù)據(jù)分析推向數(shù)據(jù)庫內(nèi)進(jìn)行（數(shù)據(jù)庫內(nèi)分析），大大提升了數(shù)據(jù)分析的性能。

    Ｇｒｅｅｎｐｌｕｍ也在其數(shù)據(jù)庫中引入了ＭａｐＲｅｄｕｃｅ處理功能，其執(zhí)行引擎可以同時(shí)處理ＳＱＬ查詢和ＭａｐＲｅｄｕｃｅ任務(wù)，這種方式在代碼級整合了ＳＱＬ和ＭａｐＲｅｄｕｃｅ：ＳＱＬ可以直接使用ＭａｐＲｅｄｕｃｅ任務(wù)的輸出，同時(shí)ＭａｐＲｅｄｕｃｅ任務(wù)也可以使用ＳＱＬ的查詢結(jié)果作為輸入。

    總的來說，這些系統(tǒng)都集中于利用ＭａｐＲｅｄｕｃｅ來改進(jìn)并行數(shù)據(jù)庫的數(shù)據(jù)處理功能，其根本性問題———可擴(kuò)展能力和容錯(cuò)能力并未改變。

   ５．２ＭａｐＲｅｄｕｃｅ主導(dǎo)型

    該方向的研究主要集中于利用關(guān)系數(shù)據(jù)庫的ＳＱＬ接口和對模式的支持等技術(shù)來改善ＭａｐＲｅｄｕｃｅ的易用性，代表系統(tǒng)是Ｈｉｖｅ、ＰｉｇＬａｔｉｎ等。

    Ｈｉｖｅ是Ｆａｃｅｂｏｏｋ提出的基于Ｈａｄｏｏｐ的大型數(shù)據(jù)倉庫，其目標(biāo)是簡化Ｈａｄｏｏｐ上的數(shù)據(jù)聚集、ａｄ�玻瑁铮悴樵兗按髷�(shù)據(jù)集的分析等操作，以減輕程序員的負(fù)擔(dān)，它借鑒關(guān)系數(shù)據(jù)庫的模式管理、ＳＱＬ接口等技術(shù)，把結(jié)構(gòu)化的數(shù)據(jù)文件映射為數(shù)據(jù)庫表，提供類似于ＳＱＬ的描述性語言ＨｉｖｅＱＬ供程序員使用，可自動將ＨｉｖｅＱＬ語句解析成一優(yōu)化的Ｍａ�玻穑遥澹洌酰悖迦蝿�(wù)執(zhí)行序列，此外，它也支持用戶自定義的ＭａｐＲｅｄｕｃｅ函數(shù)。

    ＰｉｇＬａｔｉｎ是Ｙａｈｏｏ！提出的類似于Ｈｉｖｅ的大數(shù)據(jù)集分析平臺，兩者的區(qū)別主要在于語言接口。

    Ｈｉｖｅ提供了類似ＳＱＬ的接口，ＰｉｇＬａｔｉｎ提供的是一種基于操作符的數(shù)據(jù)流式的接口，圖３是ＰｉｇＬａｔｉｎ在處理查詢時(shí)的一個(gè)操作實(shí)例，該查詢的目的是找出“年齡在１８～２５周歲之間的用戶（Ｕｓｅｒｓ）最頻繁訪問的５個(gè)頁面（Ｐａｇｅｓ）”，從圖３可以看出，Ｐｉｇ提供的操作接口類似于關(guān)系數(shù)據(jù)庫的操作符（對應(yīng)圖中右側(cè)部分中的每一行命令），用戶查詢的腳本類似于邏輯查詢計(jì)劃（對應(yīng)圖中左側(cè)部分），因此，也可以說Ｐｉｇ利用操作符來對Ｈａｄｏｏｐ進(jìn)行封裝，Ｈｉｖｅ利用ＳＱＬ進(jìn)行封裝。

    ５．３ＭａｐＲｅｄｕｃｅ和并行數(shù)據(jù)庫集成型

    該方向的代表性研究是耶魯大學(xué)提出的ＨａｄｏｏｐＤＢ（已于２０１１年商業(yè)化為Ｈａｄａｐｔ）Ｓｔｏｎｅｂｒａｋｅｒ等人設(shè)計(jì)的Ｖｅｒｔｉｃａ數(shù)據(jù)庫和ＮＣＲ公司的Ｔｅｒａｄａｔａ數(shù)據(jù)庫。

圖３ ＰｉｇＬａｔｉｎ的一個(gè)查詢示例（右邊為實(shí)際腳本）  

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.lukmueng.com/

本文標(biāo)題：架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望(上)

本文網(wǎng)址：http://www.lukmueng.com/html/support/1112158844.html