１ 引言
最近幾年，數(shù)據(jù)倉(cāng)庫(kù)又成為數(shù)據(jù)管理研究的熱點(diǎn)領(lǐng)域，主要原因是當(dāng)前數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)面臨的需求在數(shù)據(jù)源、需提供的數(shù)據(jù)服務(wù)和所處的硬件環(huán)境等方面發(fā)生了根本性的變化（詳見(jiàn)１．１節(jié)），這些變化是我們必須面對(duì)的。
本文在大數(shù)據(jù)的時(shí)代背景下，對(duì)現(xiàn)有數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)實(shí)現(xiàn)方案（主要是并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ）進(jìn)行重新審視，期望能為設(shè)計(jì)滿足時(shí)代需求的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)提供理論參考，限于篇幅，本文主要關(guān)注不同數(shù)據(jù)倉(cāng)庫(kù)實(shí)現(xiàn)方案的主體架構(gòu)及其缺陷在最近幾年的改進(jìn)情況，依據(jù)研究立足點(diǎn)的不同，本文將該領(lǐng)域的研究歸為三大類(lèi)：并行數(shù)據(jù)庫(kù)、ＭａｐＲｅｄｕｃｅ、并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ技術(shù)的混合架構(gòu)，其中第三類(lèi)研究又細(xì)分為：并行數(shù)據(jù)庫(kù)主導(dǎo)型、ＭａｐＲｅｄｕｃｅ主導(dǎo)型、并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ集成型三種，文第１節(jié)分析大數(shù)據(jù)時(shí)代，數(shù)據(jù)倉(cāng)庫(kù)所面臨的問(wèn)題及挑戰(zhàn)；第２節(jié)列出大數(shù)據(jù)時(shí)代的數(shù)據(jù)倉(cāng)庫(kù)平臺(tái)需具備的幾個(gè)重要特性；第３節(jié)到第５節(jié)就這幾個(gè)特性對(duì)各類(lèi)平臺(tái)進(jìn)行歸納分析；第６節(jié)對(duì)最新研究做一跟蹤歸納；第７節(jié)介紹中國(guó)人民大學(xué)在大數(shù)據(jù)分析方面的研究工作；第８節(jié)對(duì)未來(lái)研究做出展望；第９節(jié)總結(jié)全文。
１．１ 三個(gè)變化
（１）數(shù)據(jù)量。由ＴＢ級(jí)升至ＰＢ級(jí)，并仍在持續(xù)爆炸式增長(zhǎng)，根據(jù)ＷｉｎｔｅｒＣｏｒｐ的調(diào)查顯示，最大的數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)量，每?jī)赡暝黾樱潮叮郏保荩昃鲩L(zhǎng)率為１７３％），其增長(zhǎng)速度遠(yuǎn)超摩爾定律增長(zhǎng)速度，照此增長(zhǎng)速度計(jì)算，２０１５年最大數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)量將逼近１００ＰＢ。
（２）分析需求。由常規(guī)分析轉(zhuǎn)向深度分析（ＤｅｅｐＡｎａｌｙｔｉｃｓ），數(shù)據(jù)分析日益成為企業(yè)利潤(rùn)必不可少的支撐點(diǎn)，根據(jù)ＴＤＷＩ對(duì)大數(shù)據(jù)分析的報(bào)告（如圖１），企業(yè)已經(jīng)不滿足于對(duì)現(xiàn)有數(shù)據(jù)的分析和監(jiān)測(cè)，而是更期望能對(duì)未來(lái)趨勢(shì)有更多的分析和預(yù)測(cè)，以增強(qiáng)企業(yè)競(jìng)爭(zhēng)力，這些分析操作包括諸如移動(dòng)平均線分析、數(shù)據(jù)關(guān)聯(lián)關(guān)系分析、回歸分析、市場(chǎng)籃分析等復(fù)雜統(tǒng)計(jì)分析，我們稱(chēng)之為深度分析，值得補(bǔ)充的是，本文中的大數(shù)據(jù)分析不僅僅指基于大數(shù)據(jù)上的深度分析，也包括常規(guī)分析。
圖１ 分析的趨勢(shì)
（３）硬件平臺(tái)。由高端服務(wù)器轉(zhuǎn)向由中低端硬件構(gòu)成的大規(guī)模機(jī)群平臺(tái)，由于數(shù)據(jù)量的迅速增加，并行數(shù)據(jù)庫(kù)的規(guī)模不得不隨之增大，從而導(dǎo)致其成本的急劇上升，出于成本的考慮，越來(lái)越多的企業(yè)將應(yīng)用由高端服務(wù)器轉(zhuǎn)向了由中低端硬件構(gòu)成的大規(guī)模機(jī)群平臺(tái)。
１.２ 兩個(gè)問(wèn)題
圖２是一個(gè)典型的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)，從圖中我們可以看出，傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)將整個(gè)實(shí)現(xiàn)劃分為４個(gè)層次，數(shù)據(jù)源中的數(shù)據(jù)首先通過(guò)ＥＴＬ工具被抽取到數(shù)據(jù)倉(cāng)庫(kù)中進(jìn)行集中存儲(chǔ)和管理，再按照星型模型或雪花模型組織數(shù)據(jù)，然后ＯＬＡＰ工具從數(shù)據(jù)倉(cāng)庫(kù)中讀取數(shù)據(jù)，生成數(shù)據(jù)立方體（ＭＯＬＡＰ）或者直接訪問(wèn)數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行數(shù)據(jù)分析（ＲＯＬＡＰ），在大數(shù)據(jù)時(shí)代，此種計(jì)算模式存在兩個(gè)問(wèn)題：
問(wèn)題１，數(shù)據(jù)移動(dòng)代價(jià)過(guò)高，在數(shù)據(jù)源層和分析層之間引入一個(gè)存儲(chǔ)管理層，可以提升數(shù)據(jù)質(zhì)量并針對(duì)查詢進(jìn)行優(yōu)化，但也付出了較大的數(shù)據(jù)遷移代價(jià)和執(zhí)行時(shí)的連接代價(jià)：數(shù)據(jù)首先通過(guò)復(fù)雜且耗時(shí)的ＥＴＬ過(guò)程存儲(chǔ)到數(shù)據(jù)倉(cāng)庫(kù)中，在ＯＬＡＰ服務(wù)器中轉(zhuǎn)化為星型模型或者雪花模型；執(zhí)行分析時(shí)，又通過(guò)連接方式將數(shù)據(jù)從數(shù)據(jù)庫(kù)中取出，這些代價(jià)在ＴＢ級(jí)時(shí)也許可以接受，但面對(duì)大數(shù)據(jù)，其執(zhí)行時(shí)間至少會(huì)增長(zhǎng)幾個(gè)數(shù)量級(jí)，更為重要的是，對(duì)于大量的即席分析，這種數(shù)據(jù)移動(dòng)的計(jì)算模式是不可取的。
圖２ 一個(gè)典型的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)
問(wèn)題２，不能快速適應(yīng)變化，傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)假設(shè)主題是較少變化的，其應(yīng)對(duì)變化的方式是對(duì)數(shù)據(jù)源到前端展現(xiàn)的整個(gè)流程中的每個(gè)部分進(jìn)行修改，然后再重新加載數(shù)據(jù)，甚至重新計(jì)算數(shù)據(jù)，導(dǎo)致其適應(yīng)變化的周期較長(zhǎng)，這種模式比較適合對(duì)數(shù)據(jù)質(zhì)量和查詢性能要求較高、而不太計(jì)較預(yù)處理代價(jià)的場(chǎng)合，但在大數(shù)據(jù)時(shí)代，分析處在變化的業(yè)務(wù)環(huán)境中，這種模式將難以適應(yīng)新的需求。
１．３ 一個(gè)鴻溝
在大數(shù)據(jù)時(shí)代，巨量數(shù)據(jù)與系統(tǒng)的數(shù)據(jù)處理能力之間將會(huì)產(chǎn)生一個(gè)鴻溝：一邊是至少ＰＢ級(jí)的數(shù)據(jù)量，另一邊是面向傳統(tǒng)數(shù)據(jù)分析能力設(shè)計(jì)的數(shù)據(jù)倉(cāng)庫(kù)和各種ＢＩ工具，如果這些系統(tǒng)或工具發(fā)展緩慢，該鴻溝將會(huì)隨著數(shù)據(jù)量的持續(xù)爆炸式增長(zhǎng)而逐步拉大。
雖然，傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)可以采用舍棄不重要數(shù)據(jù)或者建立數(shù)據(jù)集市的方式來(lái)緩解此問(wèn)題，但畢竟只是權(quán)益之策，并非系統(tǒng)級(jí)解決方案，而且，舍棄的數(shù)據(jù)在未來(lái)可能會(huì)重新使用，以發(fā)掘更大的價(jià)值。
２ 期望特性
本節(jié)我們列出對(duì)大數(shù)據(jù)進(jìn)行分析時(shí)，數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)需具備的幾個(gè)重要特性（表１所示）。
表１ 大數(shù)據(jù)分析平臺(tái)需具備的特性
高度可擴(kuò)展性，一個(gè)明顯的事實(shí)是，數(shù)據(jù)庫(kù)不能依靠一臺(tái)或少數(shù)幾臺(tái)機(jī)器的升級(jí)（ｓｃａｌｅｕｐ縱向擴(kuò)展）滿足數(shù)據(jù)量的爆炸式增長(zhǎng)，而是希望能方便地做到橫向可擴(kuò)展（ｓｃａｌｅｏｕｔ）來(lái)實(shí)現(xiàn)此目標(biāo)，普遍認(rèn)為ｓｈａｒｅｄｎｏｔｈｉｎｇ無(wú)共享結(jié)構(gòu)（每個(gè)節(jié)點(diǎn)擁有私有內(nèi)存和磁盤(pán)，并且通過(guò)高速網(wǎng)絡(luò)同其它節(jié)點(diǎn)互連）具備較好的擴(kuò)展性，分析型操作往往涉及大規(guī)模的并行掃描、多維聚集及星型連接操作，這些操作也比較適合在無(wú)共享結(jié)構(gòu)的網(wǎng)絡(luò)環(huán)境運(yùn)行，Ｔｅｒａｄａｔａ即采用此結(jié)構(gòu)，Ｏｒａｃｌｅ在其新產(chǎn)品Ｅｘａｄａｔａ中也采用了此結(jié)構(gòu)。
高性能，數(shù)據(jù)量的增長(zhǎng)并沒(méi)有降低對(duì)數(shù)據(jù)庫(kù)性能的要求，反而有所提高，軟件系統(tǒng)性能的提升可以降低企業(yè)對(duì)硬件的投入成本、節(jié)省計(jì)算資源，提高系統(tǒng)吞吐量，巨量數(shù)據(jù)的效率優(yōu)化，并行是必由之路，１ＰＢ數(shù)據(jù)在５０ＭＢ／ｓ速度下串行掃描一次，需要２３０天；而在６０００塊磁盤(pán)上，并行掃描１ＰＢ數(shù)據(jù)只需要１個(gè)小時(shí)。
高度容錯(cuò)，大數(shù)據(jù)的容錯(cuò)性要求在查詢執(zhí)行過(guò)程中，一個(gè)參與節(jié)點(diǎn)失效時(shí)，不需要重做整個(gè)查詢，而機(jī)群節(jié)點(diǎn)數(shù)的增加會(huì)帶來(lái)節(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)不能依賴于硬件來(lái)保證容錯(cuò)性，要更多地考慮軟件級(jí)容錯(cuò)。
支持異構(gòu)環(huán)境，建設(shè)同構(gòu)系統(tǒng)的大規(guī)模機(jī)群難度較大，原因在于計(jì)算機(jī)硬件更新較快，一次性購(gòu)置大量同構(gòu)的計(jì)算機(jī)是不可取的，而且也會(huì)在未來(lái)添置異構(gòu)計(jì)算資源，此外，不少企業(yè)已經(jīng)積累了一些閑置的計(jì)算機(jī)資源，此種情況下，對(duì)異構(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)能動(dòng)態(tài)地適應(yīng)業(yè)務(wù)分析需求，在分析需求發(fā)生變化時(shí)，減少數(shù)據(jù)準(zhǔn)備時(shí)間，系統(tǒng)能盡可能快地做出反應(yīng)，快速地進(jìn)行數(shù)據(jù)分析。
易用且開(kāi)放的接口，ＳＱＬ的優(yōu)點(diǎn)是簡(jiǎn)單易用，但其主要用于數(shù)據(jù)的檢索查詢，對(duì)于大數(shù)據(jù)上的深度分析來(lái)講，是不夠的，原因在于：（１）其提供的服務(wù)方式依賴于數(shù)據(jù)移動(dòng)來(lái)實(shí)現(xiàn)：將數(shù)據(jù)從數(shù)據(jù)庫(kù)中取出，然后傳遞給應(yīng)用程序，該實(shí)現(xiàn)方式在大數(shù)據(jù)時(shí)代代價(jià)過(guò)高；（２）復(fù)雜的分析功能，如Ｒ或Ｍａｔｌａｂ中的分析功能，ＳＱＬ是難以勝任的，因此，除對(duì)ＳＱＬ的支持外，系統(tǒng)還應(yīng)能提供開(kāi)放的接口，讓用戶自己開(kāi)發(fā)需要的功能，設(shè)計(jì)該接口時(shí)，除了關(guān)注其易用性和開(kāi)放性，還需要特別注意兩點(diǎn)隱藏的要求：（１）基于接口開(kāi)發(fā)的用戶自定義函數(shù)，能自動(dòng)在機(jī)群上并行執(zhí)行；（２）分析在數(shù)據(jù)庫(kù)內(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ù)中心的主要成本不是硬件的購(gòu)置成本，而是日常運(yùn)維成本，因此，在設(shè)計(jì)系統(tǒng)時(shí)需要更多地關(guān)注此項(xiàng)內(nèi)容。
向下兼容性，數(shù)據(jù)倉(cāng)庫(kù)發(fā)展的３０年，產(chǎn)生了大量面向客戶業(yè)務(wù)的數(shù)據(jù)處理工具（如Ｉｎｆｏｒｍａｃｔｉｃａ、ＤａｔａＳｔａｇｅ等）、分析軟件（如ＳＰＳＳ、Ｒ、Ｍａｔｌａｂ等）和前端展現(xiàn)工具（如水晶報(bào)表）等，這些軟件是一筆寶貴的財(cái)富，已被分析人員所熟悉，是大數(shù)據(jù)時(shí)代中小規(guī)模數(shù)據(jù)分析的必要補(bǔ)充，因此，新的數(shù)據(jù)倉(cāng)庫(kù)需考慮同傳統(tǒng)商務(wù)智能工具的兼容性，由于這些系統(tǒng)往往提供標(biāo)準(zhǔn)驅(qū)動(dòng)程序，如ＯＤＢＣ、ＪＤＢＣ等，這項(xiàng)需求的實(shí)際要求是對(duì)ＳＱＬ的支持。
總之，以較低的成本投入、高效地進(jìn)行數(shù)據(jù)分析，是大數(shù)據(jù)分析的基本目標(biāo)。
３ 并行數(shù)據(jù)庫(kù)
并行數(shù)據(jù)庫(kù)起源于２０世紀(jì)８０年代，當(dāng)前主流的并行數(shù)據(jù)庫(kù)都同早期的Ｇａｍｍａ和Ｇｒａｃｅ等并行數(shù)據(jù)庫(kù)類(lèi)似，這些數(shù)據(jù)庫(kù)都支持標(biāo)準(zhǔn)ＳＱＬ，并且實(shí)現(xiàn)了數(shù)據(jù)庫(kù)界過(guò)去３０年提出的許多先進(jìn)技術(shù)，其主要采用ｓｈａｒｅｄｎｏｔｈｉｎｇ結(jié)構(gòu)，將關(guān)系表在節(jié)點(diǎn)間橫向劃分，并且利用優(yōu)化器來(lái)對(duì)執(zhí)行過(guò)程進(jìn)行調(diào)度和管理，其目標(biāo)是高性能和高可用性。
并行數(shù)據(jù)庫(kù)的最大優(yōu)勢(shì)在于性能，這主要得益于數(shù)據(jù)庫(kù)界近幾十年的研究成果———許多先進(jìn)的技術(shù)手段及算法，如索引、數(shù)據(jù)壓縮、物化視圖、結(jié)果緩沖、Ｉ／Ｏ共享、優(yōu)化的數(shù)據(jù)連接等，但是在大數(shù)據(jù)時(shí)代，如前言所述，數(shù)據(jù)移動(dòng)的實(shí)現(xiàn)方式將影響其性能。
并行數(shù)據(jù)庫(kù)通過(guò)ＳＱＬ向外提供數(shù)據(jù)訪問(wèn)服務(wù)，ＳＱＬ因其簡(jiǎn)單易用的特點(diǎn)而被廣泛使用，因此，大多ＢＩ工具都支持基于標(biāo)準(zhǔn)ＳＱＬ的數(shù)據(jù)交互方式，使得關(guān)系數(shù)據(jù)庫(kù)能較好地兼容當(dāng)前多數(shù)ＢＩ工具，某些數(shù)據(jù)庫(kù)，如ＩＢＭＤＢ２還針對(duì)一些ＢＩ工具進(jìn)行了優(yōu)化，但在大數(shù)據(jù)分析面前，ＳＱＬ接口面臨巨大挑戰(zhàn)，ＳＱＬ的優(yōu)勢(shì)源于其對(duì)底層數(shù)據(jù)訪問(wèn)的封裝，但封裝在一定程度上影響了其開(kāi)放性，而且并行數(shù)據(jù)庫(kù)提供的用戶自定義函數(shù)大都是基于單數(shù)據(jù)庫(kù)實(shí)例設(shè)計(jì)的，從而不能在機(jī)群上并行執(zhí)行，也即意味著傳統(tǒng)的實(shí)現(xiàn)方式不適合大數(shù)據(jù)的處理及分析，而且，在并行數(shù)據(jù)庫(kù)中實(shí)現(xiàn)用戶自定義函數(shù)往往需要經(jīng)過(guò)復(fù)雜的系統(tǒng)交互，甚至要熟悉數(shù)據(jù)庫(kù)的內(nèi)部結(jié)構(gòu)及系統(tǒng)調(diào)用等，從而難以使用。
并行數(shù)據(jù)庫(kù)在擴(kuò)展性、容錯(cuò)性、成本、對(duì)異構(gòu)環(huán)境的支持等幾項(xiàng)上有所欠缺，這幾項(xiàng)實(shí)際是相互影響的，我們以其最大問(wèn)題———擴(kuò)展性為主線展開(kāi)討論，并行數(shù)據(jù)庫(kù)大多支持有限擴(kuò)展，一般可擴(kuò)至數(shù)百節(jié)點(diǎn)的規(guī)模，尚未有數(shù)千節(jié)點(diǎn)規(guī)模的應(yīng)用案例，并行數(shù)據(jù)庫(kù)擴(kuò)展性有限主要因?yàn)槿缦聨c(diǎn)：（１）并行數(shù)據(jù)庫(kù)軟件級(jí)容錯(cuò)能力較差，并行數(shù)據(jù)庫(kù)基于高端硬件設(shè)計(jì)，并且假設(shè)查詢失敗屬于稀有事件，因此當(dāng)查詢失敗時(shí)，一般采取重做查詢的方式，而在大規(guī)模機(jī)群環(huán)境下，查詢失敗將會(huì)變?yōu)橐粋�(gè)普通事件，極端情況下，并行數(shù)據(jù)有可能出現(xiàn)不停重做查詢的局面；（２）并行數(shù)據(jù)庫(kù)對(duì)異構(gòu)硬件的支持非常有限，且對(duì)于處理較慢的節(jié)點(diǎn)反應(yīng)敏感，容易出現(xiàn)“木桶效應(yīng)”，如第２節(jié)中所論述的，完全基于同構(gòu)硬件搭建大規(guī)模機(jī)群在現(xiàn)實(shí)中是較難實(shí)現(xiàn)的，因而，對(duì)異構(gòu)硬件的支持能力影響了其擴(kuò)展性；（３）并行數(shù)據(jù)庫(kù)若做到大規(guī)�？蓴U(kuò)展，其代價(jià)將會(huì)較高（需基于高端硬件來(lái)保證可靠性，需購(gòu)買(mǎi)昂貴的軟件系統(tǒng)），從而限制了其擴(kuò)展性；（４）根據(jù)ＣＡＰ理論①，在分布式系統(tǒng)中，數(shù)據(jù)一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、子網(wǎng)可分解性（ＮｅｔｗｏｒｋＰａｒｔｉｔｉｏｎｉｎｇ）不可同時(shí)兼得，選擇其中任兩項(xiàng)，便會(huì)損害另一項(xiàng)，并行數(shù)據(jù)庫(kù)追求的是數(shù)據(jù)一致性和系統(tǒng)的可用性，從而影響了它的擴(kuò)展能力。
此外，如１.２節(jié)所討論的，基于并行數(shù)據(jù)庫(kù)實(shí)現(xiàn)的傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)借助于外圍工具（ＥＴＬ工具、ＯＬＡＰ產(chǎn)品、ＢＩ報(bào)表工具、統(tǒng)計(jì)分析軟件等）來(lái)完成數(shù)據(jù)的預(yù)處理和分析展現(xiàn)任務(wù)，導(dǎo)致其數(shù)據(jù)處理及分析過(guò)程涉及大量的數(shù)據(jù)遷移和計(jì)算，分析延遲往往較高。
４MapReduce
ＭａｐＲｅｄｕｃｅ是２００４年由Ｇｏｏｇｌｅ提出的面向大數(shù)據(jù)集處理的編程模型，起初主要用作互聯(lián)網(wǎng)數(shù)據(jù)的處理，例如文檔抓取、倒排索引的建立等，但由于其簡(jiǎn)單而強(qiáng)大的數(shù)據(jù)處理接口和對(duì)大規(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ù)抽象為一系列的Ｍａｐ（映射）Ｒｅｄｕｃｅ（化簡(jiǎn)）操作對(duì)，Ｍａｐ主要完成數(shù)據(jù)的過(guò)濾操作，Ｒｅｄｕｃｅ主要完成數(shù)據(jù)的聚集操作，輸入輸出數(shù)據(jù)均以〈ｋｅｙ，ｖａｌｕｅ〉格式存儲(chǔ)，用戶在使用該編程模型時(shí)，只需按照自己熟悉的語(yǔ)言實(shí)現(xiàn)Ｍａｐ函數(shù)和Ｒｅｄｕｃｅ函即可，ＭａｐＲｅｄｕｃｅ框架會(huì)自動(dòng)對(duì)任務(wù)進(jìn)行劃分以做到并行執(zhí)行。
下面本文將以基于ＭａｐＲｅｄｕｃｅ的開(kāi)源實(shí)現(xiàn)Ｈａｄｏｏｐ為主，對(duì)其主要特性進(jìn)行介紹。
ＭａｐＲｅｄｕｃｅ是面向由數(shù)千臺(tái)中低端計(jì)算機(jī)組成的大規(guī)模機(jī)群而設(shè)計(jì)的，其擴(kuò)展能力得益于其ｓｈａｒｅｄｎｏｔｈｉｎｇ結(jié)構(gòu)、各個(gè)節(jié)點(diǎn)間的松耦合性和較強(qiáng)的軟件級(jí)容錯(cuò)能力：節(jié)點(diǎn)可以被任意地從機(jī)群中移除，而幾乎不影響現(xiàn)有任務(wù)的執(zhí)行，該技術(shù)被稱(chēng)為ＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ／ＲｅｌｉａｂｌｅＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔ（ａｎｄＩｎｅｘｐｅｎｓｉｖｅ）Ｎｏｄｅｓ），ＭａｐＲｅｄｕｃｅ卓越的擴(kuò)展能力已在工業(yè)界（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｂａｉｄｕ、Ｔａｏｂ等）得到了充分驗(yàn)證，ＭａｐＲｅｄｕｃｅ對(duì)硬件的要求較低，可以基于異構(gòu)的廉價(jià)硬件來(lái)搭建機(jī)群，且免費(fèi)開(kāi)源，因此其構(gòu)建成本低于并行數(shù)據(jù)庫(kù)，但基于ＭａｐＲｅｄｕｃｅ的應(yīng)用軟件相對(duì)較少，許多數(shù)據(jù)分析功能需要用戶自行開(kāi)發(fā)，從而會(huì)導(dǎo)致使用成本的增加。
作為開(kāi)源系統(tǒng)，ＭａｐＲｅｄｕｃｅ具有完全的開(kāi)放性：其〈ｋｅｙ，ｖａｌｕｅ〉存儲(chǔ)模型具有較強(qiáng)的表現(xiàn)力，可以存儲(chǔ)任意格式的數(shù)據(jù)；Ｍａｐ和Ｒｅｄｕｃｅ兩個(gè)基本的函數(shù)接口也給用戶提供了足夠的發(fā)揮空間，可以實(shí)現(xiàn)各種復(fù)雜的數(shù)據(jù)處理功能，但這種開(kāi)放性也帶來(lái)一個(gè)問(wèn)題，就是將本來(lái)應(yīng)由數(shù)據(jù)庫(kù)管理系統(tǒng)完成的工作，諸如文件存儲(chǔ)格式的設(shè)計(jì)、模式信息的記錄、數(shù)據(jù)處理算法的實(shí)現(xiàn)等，轉(zhuǎn)移給了程序員，從而導(dǎo)致程序員負(fù)擔(dān)過(guò)重，程序員水平對(duì)系統(tǒng)處理性能起決定性作用，在某些情況下，寫(xiě)ＭａｐＲｅｄｕｃｅ程序的時(shí)間遠(yuǎn)大于寫(xiě)ＳＱＬ語(yǔ)句的時(shí)間，部分復(fù)雜的ＢＩ報(bào)表分析，可能僅程序的編寫(xiě)和調(diào)試就要耗費(fèi)幾天的時(shí)間。
基于ＭａｐＲｅｄｕｃｅ平臺(tái)的分析，無(wú)需復(fù)雜的數(shù)據(jù)預(yù)處理和寫(xiě)入數(shù)據(jù)庫(kù)的過(guò)程，而是可以直接基于平面文件進(jìn)行分析，并且其采用的計(jì)算模式是移動(dòng)計(jì)算而非移動(dòng)數(shù)據(jù)，因此可以將分析延遲最小化。
在同等硬件條件下，ＭａｐＲｅｄｕｃｅ性能遠(yuǎn)低于并行數(shù)據(jù)庫(kù)，這是由其最初的設(shè)計(jì)定位決定的，ＭａｐＲｅｄｕｃｅ的設(shè)計(jì)初衷是面向非結(jié)構(gòu)化數(shù)據(jù)的處理，這些數(shù)據(jù)具有數(shù)據(jù)量大，處理復(fù)雜等特點(diǎn)，而且往往是一次性處理，為了獲得較好的擴(kuò)展能力和容錯(cuò)能力，ＭａｐＲｅｄｕｃｅ采取了基于掃描的處理模式和對(duì)中間結(jié)果步步物化的執(zhí)行策略，從而導(dǎo)致較高的Ｉ／Ｏ代價(jià)，為了減少數(shù)據(jù)預(yù)處理時(shí)間，ＭａｐＲｅｄｕｃｅ沒(méi)有使用模式、索引、物化視圖等技術(shù)手段，其數(shù)據(jù)預(yù)處理僅是一次數(shù)據(jù)加載操作，但由此導(dǎo)致了一個(gè)問(wèn)題———較高的元組解析代價(jià)。ＭａｐＲｅｄｕｃｅ環(huán)境下，每個(gè)查詢都是直接從文件系統(tǒng)中讀入原始數(shù)據(jù)文件，而非傳統(tǒng)的從數(shù)據(jù)庫(kù)中讀入經(jīng)處理過(guò)的文件，因此其元組解析代價(jià)遠(yuǎn)高于關(guān)系數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)分析領(lǐng)域來(lái)說(shuō)，連接是關(guān)鍵操作（如傳統(tǒng)的星型查詢和雪花查詢均是依賴于連接來(lái)處理查詢），但ＭａｐＲｅｄｕｃｅ處理連接的性能尤其不盡如人意，原因在于ＭａｐＲｅｄｕｃｅ最初是針對(duì)單數(shù)據(jù)集設(shè)計(jì)的處理模型，而連接操作往往涉及多個(gè)數(shù)據(jù)集，在利用ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)連接時(shí)，最直接的方式是每個(gè)任務(wù)執(zhí)行一個(gè)屬性上的連接操作，然后將多個(gè)ＭａｐＲｅｄｕｃｅ任務(wù)通過(guò)物化的中間結(jié)果串接起來(lái)，這種實(shí)現(xiàn)方式往往涉及中間結(jié)果的讀寫(xiě)，從而導(dǎo)致大量的Ｉ／Ｏ操作和網(wǎng)絡(luò)傳輸。
ＭａｐＲｅｄｕｃｅ目前基本不兼容現(xiàn)有的ＢＩ工具，原因在于其初衷并不是要成為數(shù)據(jù)庫(kù)系統(tǒng)，因此它并未提供ＳＱＬ接口，但已有研究致力于ＳＱＬ語(yǔ)句與ＭａｐＲｅｄｕｃｅ任務(wù)的轉(zhuǎn)換工作（例如Ｈｉｖｅ），進(jìn)而有可能實(shí)現(xiàn)ＭａｐＲｅｄｕｃｅ與現(xiàn)存ＢＩ工具的兼容。
５ 并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ的混合架構(gòu)
基于以上分析，我們可以清楚地看出，基于并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)都不是大數(shù)據(jù)分析的理想方案，針對(duì)兩者哪個(gè)更適合時(shí)代需求的問(wèn)題，業(yè)界近年展開(kāi)了激烈爭(zhēng)論，當(dāng)前基本達(dá)成如下共識(shí)：并行數(shù)據(jù)庫(kù)和ＭａｐＲｅｄｕｃｅ是互補(bǔ)關(guān)系，應(yīng)該相互學(xué)習(xí)，基于該觀點(diǎn)，大量研究著手將兩者結(jié)合起來(lái)，期望設(shè)計(jì)出兼具兩者優(yōu)點(diǎn)的數(shù)據(jù)分析平臺(tái)，這種架構(gòu)又可以分為三類(lèi)：并行數(shù)據(jù)庫(kù)主導(dǎo)型、ＭａｐＲｅｄｕｃｅ主導(dǎo)型、ＭａｐＲｅｄｕｃｅ和并行數(shù)據(jù)庫(kù)集成型（表２對(duì)３種架構(gòu)進(jìn)行了對(duì)比分析）。
表２ 混合架構(gòu)型解決方案對(duì)比分析
５．１ 并行數(shù)據(jù)庫(kù)主導(dǎo)型
該種方式關(guān)注于如何利用ＭａｐＲｅｄｕｃｅ來(lái)增強(qiáng)并行數(shù)據(jù)庫(kù)的數(shù)據(jù)處理能力，代表性系統(tǒng)是Ｇｒｅｅｎｐｌｕｍ（已被ＥＭＣ收購(gòu)）和ＡｓｔｅｒＤａｔａ（已被Ｔｅｒａｄａｔａ收購(gòu)），ＡｓｔｅｒＤａｔａ將ＳＱＬ和ＭａｐＲｅｄｕｃｅ進(jìn)行結(jié)合，針對(duì)大數(shù)據(jù)分析提出了ＳＱＬ／ＭａｐＲｅｄｕｃｅ框架。
該框架允許用戶使用Ｃ＋＋、ｊａｖａ、Ｐｙｔｈｏｎ等語(yǔ)言編寫(xiě)ＭａｐＲｅｄｕｃｅ函數(shù)，編寫(xiě)的函數(shù)可以作為一個(gè)子查詢?cè)冢樱眩讨惺褂茫瑥亩瑫r(shí)獲得ＳＱＬ的易用性和ＭａｐＲｅｄｕｃｅ的開(kāi)放性，不僅如此，ＡｓｔｅｒＤａｔａ基于ＭａｐＲｅｄｕｃｅ實(shí)現(xiàn)了３０多個(gè)統(tǒng)計(jì)軟件包，從而將數(shù)據(jù)分析推向數(shù)據(jù)庫(kù)內(nèi)進(jìn)行（數(shù)據(jù)庫(kù)內(nèi)分析），大大提升了數(shù)據(jù)分析的性能。
Ｇｒｅｅｎｐｌｕｍ也在其數(shù)據(jù)庫(kù)中引入了ＭａｐＲｅｄｕｃｅ處理功能，其執(zhí)行引擎可以同時(shí)處理ＳＱＬ查詢和ＭａｐＲｅｄｕｃｅ任務(wù)，這種方式在代碼級(jí)整合了ＳＱＬ和ＭａｐＲｅｄｕｃｅ：ＳＱＬ可以直接使用ＭａｐＲｅｄｕｃｅ任務(wù)的輸出，同時(shí)ＭａｐＲｅｄｕｃｅ任務(wù)也可以使用ＳＱＬ的查詢結(jié)果作為輸入。
總的來(lái)說(shuō)，這些系統(tǒng)都集中于利用ＭａｐＲｅｄｕｃｅ來(lái)改進(jìn)并行數(shù)據(jù)庫(kù)的數(shù)據(jù)處理功能，其根本性問(wèn)題———可擴(kuò)展能力和容錯(cuò)能力并未改變。
５．２ＭａｐＲｅｄｕｃｅ主導(dǎo)型
該方向的研究主要集中于利用關(guān)系數(shù)據(jù)庫(kù)的ＳＱＬ接口和對(duì)模式的支持等技術(shù)來(lái)改善ＭａｐＲｅｄｕｃｅ的易用性，代表系統(tǒng)是Ｈｉｖｅ、ＰｉｇＬａｔｉｎ等。
Ｈｉｖｅ是Ｆａｃｅｂｏｏｋ提出的基于Ｈａｄｏｏｐ的大型數(shù)據(jù)倉(cāng)庫(kù)，其目標(biāo)是簡(jiǎn)化Ｈａｄｏｏｐ上的數(shù)據(jù)聚集、ａｄｈｏｃ查詢及大數(shù)據(jù)集的分析等操作，以減輕程序員的負(fù)擔(dān)，它借鑒關(guān)系數(shù)據(jù)庫(kù)的模式管理、ＳＱＬ接口等技術(shù)，把結(jié)構(gòu)化的數(shù)據(jù)文件映射為數(shù)據(jù)庫(kù)表，提供類(lèi)似于ＳＱＬ的描述性語(yǔ)言ＨｉｖｅＱＬ供程序員使用，可自動(dòng)將ＨｉｖｅＱＬ語(yǔ)句解析成一優(yōu)化的ＭａｐＲｅｄｕｃｅ任務(wù)執(zhí)行序列，此外，它也支持用戶自定義的ＭａｐＲｅｄｕｃｅ函數(shù)。
ＰｉｇＬａｔｉｎ是Ｙａｈｏｏ！提出的類(lèi)似于Ｈｉｖｅ的大數(shù)據(jù)集分析平臺(tái)，兩者的區(qū)別主要在于語(yǔ)言接口。
Ｈｉｖｅ提供了類(lèi)似ＳＱＬ的接口，ＰｉｇＬａｔｉｎ提供的是一種基于操作符的數(shù)據(jù)流式的接口，圖３是ＰｉｇＬａｔｉｎ在處理查詢時(shí)的一個(gè)操作實(shí)例，該查詢的目的是找出“年齡在１８～２５周歲之間的用戶（Ｕｓｅｒｓ）最頻繁訪問(wèn)的５個(gè)頁(yè)面（Ｐａｇｅｓ）”，從圖３可以看出，Ｐｉｇ提供的操作接口類(lèi)似于關(guān)系數(shù)據(jù)庫(kù)的操作符（對(duì)應(yīng)圖中右側(cè)部分中的每一行命令），用戶查詢的腳本類(lèi)似于邏輯查詢計(jì)劃（對(duì)應(yīng)圖中左側(cè)部分），因此，也可以說(shuō)Ｐｉｇ利用操作符來(lái)對(duì)Ｈａｄｏｏｐ進(jìn)行封裝，Ｈｉｖｅ利用ＳＱＬ進(jìn)行封裝。
５．３ＭａｐＲｅｄｕｃｅ和并行數(shù)據(jù)庫(kù)集成型
該方向的代表性研究是耶魯大學(xué)提出的ＨａｄｏｏｐＤＢ（已于２０１１年商業(yè)化為Ｈａｄａｐｔ）Ｓｔｏｎｅｂｒａｋｅｒ等人設(shè)計(jì)的Ｖｅｒｔｉｃａ數(shù)據(jù)庫(kù)和ＮＣＲ公司的Ｔｅｒａｄａｔａ數(shù)據(jù)庫(kù)。
圖３ ＰｉｇＬａｔｉｎ的一個(gè)查詢示例（右邊為實(shí)際腳本）
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(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)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望(上)
本文網(wǎng)址：http://www.oesoe.com/html/support/1112158844.html
相關(guān)文章
