1 引言
最近幾年,數(shù)據(jù)倉庫又成為數(shù)據(jù)管理研究的熱點領(lǐng)域,主要原因是當前數(shù)據(jù)倉庫系統(tǒng)面臨的需求在數(shù)據(jù)源、需提供的數(shù)據(jù)服務(wù)和所處的硬件環(huán)境等方面發(fā)生了根本性的變化(詳見1.1節(jié)),這些變化是我們必須面對的。
本文在大數(shù)據(jù)的時代背景下,對現(xiàn)有數(shù)據(jù)倉庫系統(tǒng)實現(xiàn)方案(主要是并行數(shù)據(jù)庫和MapReduce)進行重新審視,期望能為設(shè)計滿足時代需求的數(shù)據(jù)倉庫系統(tǒng)提供理論參考,限于篇幅,本文主要關(guān)注不同數(shù)據(jù)倉庫實現(xiàn)方案的主體架構(gòu)及其缺陷在最近幾年的改進情況,依據(jù)研究立足點的不同,本文將該領(lǐng)域的研究歸為三大類:并行數(shù)據(jù)庫、MapReduce、并行數(shù)據(jù)庫和MapReduce技術(shù)的混合架構(gòu),其中第三類研究又細分為:并行數(shù)據(jù)庫主導型、MapReduce主導型、并行數(shù)據(jù)庫和MapReduce集成型三種,文第1節(jié)分析大數(shù)據(jù)時代,數(shù)據(jù)倉庫所面臨的問題及挑戰(zhàn);第2節(jié)列出大數(shù)據(jù)時代的數(shù)據(jù)倉庫平臺需具備的幾個重要特性;第3節(jié)到第5節(jié)就這幾個特性對各類平臺進行歸納分析;第6節(jié)對最新研究做一跟蹤歸納;第7節(jié)介紹中國人民大學在大數(shù)據(jù)分析方面的研究工作;第8節(jié)對未來研究做出展望;第9節(jié)總結(jié)全文。
1.1 三個變化
(1)數(shù)據(jù)量。由TB級升至PB級,并仍在持續(xù)爆炸式增長,根據(jù)WinterCorp的調(diào)查顯示,最大的數(shù)據(jù)倉庫中的數(shù)據(jù)量,每兩年增加3倍[1](年均增長率為173%),其增長速度遠超摩爾定律增長速度,照此增長速度計算,2015年最大數(shù)據(jù)倉庫中的數(shù)據(jù)量將逼近100PB。
(2)分析需求。由常規(guī)分析轉(zhuǎn)向深度分析(DeepAnalytics),數(shù)據(jù)分析日益成為企業(yè)利潤必不可少的支撐點,根據(jù)TDWI對大數(shù)據(jù)分析的報告(如圖1),企業(yè)已經(jīng)不滿足于對現(xiàn)有數(shù)據(jù)的分析和監(jiān)測,而是更期望能對未來趨勢有更多的分析和預(yù)測,以增強企業(yè)競爭力,這些分析操作包括諸如移動平均線分析、數(shù)據(jù)關(guān)聯(lián)關(guān)系分析、回歸分析、市場籃分析等復雜統(tǒng)計分析,我們稱之為深度分析,值得補充的是,本文中的大數(shù)據(jù)分析不僅僅指基于大數(shù)據(jù)上的深度分析,也包括常規(guī)分析。
圖1 分析的趨勢
(3)硬件平臺。由高端服務(wù)器轉(zhuǎn)向由中低端硬件構(gòu)成的大規(guī)模機群平臺,由于數(shù)據(jù)量的迅速增加,并行數(shù)據(jù)庫的規(guī)模不得不隨之增大,從而導致其成本的急劇上升,出于成本的考慮,越來越多的企業(yè)將應(yīng)用由高端服務(wù)器轉(zhuǎn)向了由中低端硬件構(gòu)成的大規(guī)模機群平臺。
1.2 兩個問題
圖2是一個典型的數(shù)據(jù)倉庫架構(gòu),從圖中我們可以看出,傳統(tǒng)的數(shù)據(jù)倉庫將整個實現(xiàn)劃分為4個層次,數(shù)據(jù)源中的數(shù)據(jù)首先通過ETL工具被抽取到數(shù)據(jù)倉庫中進行集中存儲和管理,再按照星型模型或雪花模型組織數(shù)據(jù),然后OLAP工具從數(shù)據(jù)倉庫中讀取數(shù)據(jù),生成數(shù)據(jù)立方體(MOLAP)或者直接訪問數(shù)據(jù)倉庫進行數(shù)據(jù)分析(ROLAP),在大數(shù)據(jù)時代,此種計算模式存在兩個問題:
問題1,數(shù)據(jù)移動代價過高,在數(shù)據(jù)源層和分析層之間引入一個存儲管理層,可以提升數(shù)據(jù)質(zhì)量并針對查詢進行優(yōu)化,但也付出了較大的數(shù)據(jù)遷移代價和執(zhí)行時的連接代價:數(shù)據(jù)首先通過復雜且耗時的ETL過程存儲到數(shù)據(jù)倉庫中,在OLAP服務(wù)器中轉(zhuǎn)化為星型模型或者雪花模型;執(zhí)行分析時,又通過連接方式將數(shù)據(jù)從數(shù)據(jù)庫中取出,這些代價在TB級時也許可以接受,但面對大數(shù)據(jù),其執(zhí)行時間至少會增長幾個數(shù)量級,更為重要的是,對于大量的即席分析,這種數(shù)據(jù)移動的計算模式是不可取的。
圖2 一個典型的數(shù)據(jù)倉庫架構(gòu)
問題2,不能快速適應(yīng)變化,傳統(tǒng)的數(shù)據(jù)倉庫假設(shè)主題是較少變化的,其應(yīng)對變化的方式是對數(shù)據(jù)源到前端展現(xiàn)的整個流程中的每個部分進行修改,然后再重新加載數(shù)據(jù),甚至重新計算數(shù)據(jù),導致其適應(yīng)變化的周期較長,這種模式比較適合對數(shù)據(jù)質(zhì)量和查詢性能要求較高、而不太計較預(yù)處理代價的場合,但在大數(shù)據(jù)時代,分析處在變化的業(yè)務(wù)環(huán)境中,這種模式將難以適應(yīng)新的需求。
1.3 一個鴻溝
在大數(shù)據(jù)時代,巨量數(shù)據(jù)與系統(tǒng)的數(shù)據(jù)處理能力之間將會產(chǎn)生一個鴻溝:一邊是至少PB級的數(shù)據(jù)量,另一邊是面向傳統(tǒng)數(shù)據(jù)分析能力設(shè)計的數(shù)據(jù)倉庫和各種BI工具,如果這些系統(tǒng)或工具發(fā)展緩慢,該鴻溝將會隨著數(shù)據(jù)量的持續(xù)爆炸式增長而逐步拉大。
雖然,傳統(tǒng)數(shù)據(jù)倉庫可以采用舍棄不重要數(shù)據(jù)或者建立數(shù)據(jù)集市的方式來緩解此問題,但畢竟只是權(quán)益之策,并非系統(tǒng)級解決方案,而且,舍棄的數(shù)據(jù)在未來可能會重新使用,以發(fā)掘更大的價值。
2 期望特性
本節(jié)我們列出對大數(shù)據(jù)進行分析時,數(shù)據(jù)倉庫系統(tǒng)需具備的幾個重要特性(表1所示)。
表1 大數(shù)據(jù)分析平臺需具備的特性
高度可擴展性,一個明顯的事實是,數(shù)據(jù)庫不能依靠一臺或少數(shù)幾臺機器的升級(scaleup縱向擴展)滿足數(shù)據(jù)量的爆炸式增長,而是希望能方便地做到橫向可擴展(scaleout)來實現(xiàn)此目標,普遍認為sharednothing無共享結(jié)構(gòu)(每個節(jié)點擁有私有內(nèi)存和磁盤,并且通過高速網(wǎng)絡(luò)同其它節(jié)點互連)具備較好的擴展性,分析型操作往往涉及大規(guī)模的并行掃描、多維聚集及星型連接操作,這些操作也比較適合在無共享結(jié)構(gòu)的網(wǎng)絡(luò)環(huán)境運行,Teradata即采用此結(jié)構(gòu),Oracle在其新產(chǎn)品Exadata中也采用了此結(jié)構(gòu)。
高性能,數(shù)據(jù)量的增長并沒有降低對數(shù)據(jù)庫性能的要求,反而有所提高,軟件系統(tǒng)性能的提升可以降低企業(yè)對硬件的投入成本、節(jié)省計算資源,提高系統(tǒng)吞吐量,巨量數(shù)據(jù)的效率優(yōu)化,并行是必由之路,1PB數(shù)據(jù)在50MB/s速度下串行掃描一次,需要230天;而在6000塊磁盤上,并行掃描1PB數(shù)據(jù)只需要1個小時。
高度容錯,大數(shù)據(jù)的容錯性要求在查詢執(zhí)行過程中,一個參與節(jié)點失效時,不需要重做整個查詢,而機群節(jié)點數(shù)的增加會帶來節(jié)點失效概率的增加,在大規(guī)模機群環(huán)境下,節(jié)點的失效將不再是稀有事件(Google報告,平均每個MapReduce數(shù)據(jù)處理任務(wù)就有1.2個工作節(jié)點失效),因此在大規(guī)模機群環(huán)境下,系統(tǒng)不能依賴于硬件來保證容錯性,要更多地考慮軟件級容錯。
支持異構(gòu)環(huán)境,建設(shè)同構(gòu)系統(tǒng)的大規(guī)模機群難度較大,原因在于計算機硬件更新較快,一次性購置大量同構(gòu)的計算機是不可取的,而且也會在未來添置異構(gòu)計算資源,此外,不少企業(yè)已經(jīng)積累了一些閑置的計算機資源,此種情況下,對異構(gòu)環(huán)境的支持可以有效地利用這些閑置計算資源,降低硬件成本的投入,還需特別關(guān)注的是,在異構(gòu)環(huán)境下,不同節(jié)點的性能是不一樣的,可能出現(xiàn)“木桶效應(yīng)”,即最慢節(jié)點的性能決定整體處理性能,因此,異構(gòu)的機群需要特別關(guān)注負載均衡、任務(wù)調(diào)度等方面的設(shè)計。
較低的分析延遲,分析延遲指的是分析前的數(shù)據(jù)準備時間,在大數(shù)據(jù)時代,分析所處的業(yè)務(wù)環(huán)境是變化的,因此也要求系統(tǒng)能動態(tài)地適應(yīng)業(yè)務(wù)分析需求,在分析需求發(fā)生變化時,減少數(shù)據(jù)準備時間,系統(tǒng)能盡可能快地做出反應(yīng),快速地進行數(shù)據(jù)分析。
易用且開放的接口,SQL的優(yōu)點是簡單易用,但其主要用于數(shù)據(jù)的檢索查詢,對于大數(shù)據(jù)上的深度分析來講,是不夠的,原因在于:(1)其提供的服務(wù)方式依賴于數(shù)據(jù)移動來實現(xiàn):將數(shù)據(jù)從數(shù)據(jù)庫中取出,然后傳遞給應(yīng)用程序,該實現(xiàn)方式在大數(shù)據(jù)時代代價過高;(2)復雜的分析功能,如R或Matlab中的分析功能,SQL是難以勝任的,因此,除對SQL的支持外,系統(tǒng)還應(yīng)能提供開放的接口,讓用戶自己開發(fā)需要的功能,設(shè)計該接口時,除了關(guān)注其易用性和開放性,還需要特別注意兩點隱藏的要求:(1)基于接口開發(fā)的用戶自定義函數(shù),能自動在機群上并行執(zhí)行;(2)分析在數(shù)據(jù)庫內(nèi)進行,即分析盡可能靠近數(shù)據(jù)。
較低的成本,在滿足需求的前提下,某技術(shù)成本越低,其生命力就越強,需要指出的是成本是一個綜合指標,不僅僅是硬件或軟件的代價,還應(yīng)包括日常運維成本(網(wǎng)絡(luò)費用、電費、建筑等)和管理人員成本等,據(jù)報告,數(shù)據(jù)中心的主要成本不是硬件的購置成本,而是日常運維成本,因此,在設(shè)計系統(tǒng)時需要更多地關(guān)注此項內(nèi)容。
向下兼容性,數(shù)據(jù)倉庫發(fā)展的30年,產(chǎn)生了大量面向客戶業(yè)務(wù)的數(shù)據(jù)處理工具(如Informactica、DataStage等)、分析軟件(如SPSS、R、Matlab等)和前端展現(xiàn)工具(如水晶報表)等,這些軟件是一筆寶貴的財富,已被分析人員所熟悉,是大數(shù)據(jù)時代中小規(guī)模數(shù)據(jù)分析的必要補充,因此,新的數(shù)據(jù)倉庫需考慮同傳統(tǒng)商務(wù)智能工具的兼容性,由于這些系統(tǒng)往往提供標準驅(qū)動程序,如ODBC、JDBC等,這項需求的實際要求是對SQL的支持。
總之,以較低的成本投入、高效地進行數(shù)據(jù)分析,是大數(shù)據(jù)分析的基本目標。
3 并行數(shù)據(jù)庫
并行數(shù)據(jù)庫起源于20世紀80年代,當前主流的并行數(shù)據(jù)庫都同早期的Gamma和Grace等并行數(shù)據(jù)庫類似,這些數(shù)據(jù)庫都支持標準SQL,并且實現(xiàn)了數(shù)據(jù)庫界過去30年提出的許多先進技術(shù),其主要采用sharednothing結(jié)構(gòu),將關(guān)系表在節(jié)點間橫向劃分,并且利用優(yōu)化器來對執(zhí)行過程進行調(diào)度和管理,其目標是高性能和高可用性。
并行數(shù)據(jù)庫的最大優(yōu)勢在于性能,這主要得益于數(shù)據(jù)庫界近幾十年的研究成果———許多先進的技術(shù)手段及算法,如索引、數(shù)據(jù)壓縮、物化視圖、結(jié)果緩沖、I/O共享、優(yōu)化的數(shù)據(jù)連接等,但是在大數(shù)據(jù)時代,如前言所述,數(shù)據(jù)移動的實現(xiàn)方式將影響其性能。
并行數(shù)據(jù)庫通過SQL向外提供數(shù)據(jù)訪問服務(wù),SQL因其簡單易用的特點而被廣泛使用,因此,大多BI工具都支持基于標準SQL的數(shù)據(jù)交互方式,使得關(guān)系數(shù)據(jù)庫能較好地兼容當前多數(shù)BI工具,某些數(shù)據(jù)庫,如IBMDB2還針對一些BI工具進行了優(yōu)化,但在大數(shù)據(jù)分析面前,SQL接口面臨巨大挑戰(zhàn),SQL的優(yōu)勢源于其對底層數(shù)據(jù)訪問的封裝,但封裝在一定程度上影響了其開放性,而且并行數(shù)據(jù)庫提供的用戶自定義函數(shù)大都是基于單數(shù)據(jù)庫實例設(shè)計的,從而不能在機群上并行執(zhí)行,也即意味著傳統(tǒng)的實現(xiàn)方式不適合大數(shù)據(jù)的處理及分析,而且,在并行數(shù)據(jù)庫中實現(xiàn)用戶自定義函數(shù)往往需要經(jīng)過復雜的系統(tǒng)交互,甚至要熟悉數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)及系統(tǒng)調(diào)用等,從而難以使用。
并行數(shù)據(jù)庫在擴展性、容錯性、成本、對異構(gòu)環(huán)境的支持等幾項上有所欠缺,這幾項實際是相互影響的,我們以其最大問題———擴展性為主線展開討論,并行數(shù)據(jù)庫大多支持有限擴展,一般可擴至數(shù)百節(jié)點的規(guī)模,尚未有數(shù)千節(jié)點規(guī)模的應(yīng)用案例,并行數(shù)據(jù)庫擴展性有限主要因為如下幾點:(1)并行數(shù)據(jù)庫軟件級容錯能力較差,并行數(shù)據(jù)庫基于高端硬件設(shè)計,并且假設(shè)查詢失敗屬于稀有事件,因此當查詢失敗時,一般采取重做查詢的方式,而在大規(guī)模機群環(huán)境下,查詢失敗將會變?yōu)橐粋普通事件,極端情況下,并行數(shù)據(jù)有可能出現(xiàn)不停重做查詢的局面;(2)并行數(shù)據(jù)庫對異構(gòu)硬件的支持非常有限,且對于處理較慢的節(jié)點反應(yīng)敏感,容易出現(xiàn)“木桶效應(yīng)”,如第2節(jié)中所論述的,完全基于同構(gòu)硬件搭建大規(guī)模機群在現(xiàn)實中是較難實現(xiàn)的,因而,對異構(gòu)硬件的支持能力影響了其擴展性;(3)并行數(shù)據(jù)庫若做到大規(guī)?蓴U展,其代價將會較高(需基于高端硬件來保證可靠性,需購買昂貴的軟件系統(tǒng)),從而限制了其擴展性;(4)根據(jù)CAP理論①,在分布式系統(tǒng)中,數(shù)據(jù)一致性(Consistency)、可用性(Availability)、子網(wǎng)可分解性(NetworkPartitioning)不可同時兼得,選擇其中任兩項,便會損害另一項,并行數(shù)據(jù)庫追求的是數(shù)據(jù)一致性和系統(tǒng)的可用性,從而影響了它的擴展能力。
此外,如1.2節(jié)所討論的,基于并行數(shù)據(jù)庫實現(xiàn)的傳統(tǒng)數(shù)據(jù)倉庫借助于外圍工具(ETL工具、OLAP產(chǎn)品、BI報表工具、統(tǒng)計分析軟件等)來完成數(shù)據(jù)的預(yù)處理和分析展現(xiàn)任務(wù),導致其數(shù)據(jù)處理及分析過程涉及大量的數(shù)據(jù)遷移和計算,分析延遲往往較高。
4MapReduce
MapReduce是2004年由Google提出的面向大數(shù)據(jù)集處理的編程模型,起初主要用作互聯(lián)網(wǎng)數(shù)據(jù)的處理,例如文檔抓取、倒排索引的建立等,但由于其簡單而強大的數(shù)據(jù)處理接口和對大規(guī)模并行執(zhí)行、容錯及負載均衡等實現(xiàn)細節(jié)的隱藏,該技術(shù)一經(jīng)推出便迅速在機器學習、數(shù)據(jù)挖掘、數(shù)據(jù)分析等領(lǐng)域得到廣泛應(yīng)用。
MapReduce將數(shù)據(jù)處理任務(wù)抽象為一系列的Map(映射)Reduce(化簡)操作對,Map主要完成數(shù)據(jù)的過濾操作,Reduce主要完成數(shù)據(jù)的聚集操作,輸入輸出數(shù)據(jù)均以〈key,value〉格式存儲,用戶在使用該編程模型時,只需按照自己熟悉的語言實現(xiàn)Map函數(shù)和Reduce函即可,MapReduce框架會自動對任務(wù)進行劃分以做到并行執(zhí)行。
下面本文將以基于MapReduce的開源實現(xiàn)Hadoop為主,對其主要特性進行介紹。
MapReduce是面向由數(shù)千臺中低端計算機組成的大規(guī)模機群而設(shè)計的,其擴展能力得益于其sharednothing結(jié)構(gòu)、各個節(jié)點間的松耦合性和較強的軟件級容錯能力:節(jié)點可以被任意地從機群中移除,而幾乎不影響現(xiàn)有任務(wù)的執(zhí)行,該技術(shù)被稱為RAIN(Redundant/ReliableArrayofIndependent(andInexpensive)Nodes),MapReduce卓越的擴展能力已在工業(yè)界(Google、Facebook、Baidu、Taob等)得到了充分驗證,MapReduce對硬件的要求較低,可以基于異構(gòu)的廉價硬件來搭建機群,且免費開源,因此其構(gòu)建成本低于并行數(shù)據(jù)庫,但基于MapReduce的應(yīng)用軟件相對較少,許多數(shù)據(jù)分析功能需要用戶自行開發(fā),從而會導致使用成本的增加。
作為開源系統(tǒng),MapReduce具有完全的開放性:其〈key,value〉存儲模型具有較強的表現(xiàn)力,可以存儲任意格式的數(shù)據(jù);Map和Reduce兩個基本的函數(shù)接口也給用戶提供了足夠的發(fā)揮空間,可以實現(xiàn)各種復雜的數(shù)據(jù)處理功能,但這種開放性也帶來一個問題,就是將本來應(yīng)由數(shù)據(jù)庫管理系統(tǒng)完成的工作,諸如文件存儲格式的設(shè)計、模式信息的記錄、數(shù)據(jù)處理算法的實現(xiàn)等,轉(zhuǎn)移給了程序員,從而導致程序員負擔過重,程序員水平對系統(tǒng)處理性能起決定性作用,在某些情況下,寫MapReduce程序的時間遠大于寫SQL語句的時間,部分復雜的BI報表分析,可能僅程序的編寫和調(diào)試就要耗費幾天的時間。
基于MapReduce平臺的分析,無需復雜的數(shù)據(jù)預(yù)處理和寫入數(shù)據(jù)庫的過程,而是可以直接基于平面文件進行分析,并且其采用的計算模式是移動計算而非移動數(shù)據(jù),因此可以將分析延遲最小化。
在同等硬件條件下,MapReduce性能遠低于并行數(shù)據(jù)庫,這是由其最初的設(shè)計定位決定的,MapReduce的設(shè)計初衷是面向非結(jié)構(gòu)化數(shù)據(jù)的處理,這些數(shù)據(jù)具有數(shù)據(jù)量大,處理復雜等特點,而且往往是一次性處理,為了獲得較好的擴展能力和容錯能力,MapReduce采取了基于掃描的處理模式和對中間結(jié)果步步物化的執(zhí)行策略,從而導致較高的I/O代價,為了減少數(shù)據(jù)預(yù)處理時間,MapReduce沒有使用模式、索引、物化視圖等技術(shù)手段,其數(shù)據(jù)預(yù)處理僅是一次數(shù)據(jù)加載操作,但由此導致了一個問題———較高的元組解析代價。MapReduce環(huán)境下,每個查詢都是直接從文件系統(tǒng)中讀入原始數(shù)據(jù)文件,而非傳統(tǒng)的從數(shù)據(jù)庫中讀入經(jīng)處理過的文件,因此其元組解析代價遠高于關(guān)系數(shù)據(jù)庫,對數(shù)據(jù)分析領(lǐng)域來說,連接是關(guān)鍵操作(如傳統(tǒng)的星型查詢和雪花查詢均是依賴于連接來處理查詢),但MapReduce處理連接的性能尤其不盡如人意,原因在于MapReduce最初是針對單數(shù)據(jù)集設(shè)計的處理模型,而連接操作往往涉及多個數(shù)據(jù)集,在利用MapReduce實現(xiàn)連接時,最直接的方式是每個任務(wù)執(zhí)行一個屬性上的連接操作,然后將多個MapReduce任務(wù)通過物化的中間結(jié)果串接起來,這種實現(xiàn)方式往往涉及中間結(jié)果的讀寫,從而導致大量的I/O操作和網(wǎng)絡(luò)傳輸。
MapReduce目前基本不兼容現(xiàn)有的BI工具,原因在于其初衷并不是要成為數(shù)據(jù)庫系統(tǒng),因此它并未提供SQL接口,但已有研究致力于SQL語句與MapReduce任務(wù)的轉(zhuǎn)換工作(例如Hive),進而有可能實現(xiàn)MapReduce與現(xiàn)存BI工具的兼容。
5 并行數(shù)據(jù)庫和MapReduce的混合架構(gòu)
基于以上分析,我們可以清楚地看出,基于并行數(shù)據(jù)庫和MapReduce實現(xiàn)的數(shù)據(jù)倉庫系統(tǒng)都不是大數(shù)據(jù)分析的理想方案,針對兩者哪個更適合時代需求的問題,業(yè)界近年展開了激烈爭論,當前基本達成如下共識:并行數(shù)據(jù)庫和MapReduce是互補關(guān)系,應(yīng)該相互學習,基于該觀點,大量研究著手將兩者結(jié)合起來,期望設(shè)計出兼具兩者優(yōu)點的數(shù)據(jù)分析平臺,這種架構(gòu)又可以分為三類:并行數(shù)據(jù)庫主導型、MapReduce主導型、MapReduce和并行數(shù)據(jù)庫集成型(表2對3種架構(gòu)進行了對比分析)。
表2 混合架構(gòu)型解決方案對比分析
5.1 并行數(shù)據(jù)庫主導型
該種方式關(guān)注于如何利用MapReduce來增強并行數(shù)據(jù)庫的數(shù)據(jù)處理能力,代表性系統(tǒng)是Greenplum(已被EMC收購)和AsterData(已被Teradata收購),AsterData將SQL和MapReduce進行結(jié)合,針對大數(shù)據(jù)分析提出了SQL/MapReduce框架。
該框架允許用戶使用C++、java、Python等語言編寫MapReduce函數(shù),編寫的函數(shù)可以作為一個子查詢在SQL中使用,從而同時獲得SQL的易用性和MapReduce的開放性,不僅如此,AsterData基于MapReduce實現(xiàn)了30多個統(tǒng)計軟件包,從而將數(shù)據(jù)分析推向數(shù)據(jù)庫內(nèi)進行(數(shù)據(jù)庫內(nèi)分析),大大提升了數(shù)據(jù)分析的性能。
Greenplum也在其數(shù)據(jù)庫中引入了MapReduce處理功能,其執(zhí)行引擎可以同時處理SQL查詢和MapReduce任務(wù),這種方式在代碼級整合了SQL和MapReduce:SQL可以直接使用MapReduce任務(wù)的輸出,同時MapReduce任務(wù)也可以使用SQL的查詢結(jié)果作為輸入。
總的來說,這些系統(tǒng)都集中于利用MapReduce來改進并行數(shù)據(jù)庫的數(shù)據(jù)處理功能,其根本性問題———可擴展能力和容錯能力并未改變。
5.2MapReduce主導型
該方向的研究主要集中于利用關(guān)系數(shù)據(jù)庫的SQL接口和對模式的支持等技術(shù)來改善MapReduce的易用性,代表系統(tǒng)是Hive、PigLatin等。
Hive是Facebook提出的基于Hadoop的大型數(shù)據(jù)倉庫,其目標是簡化Hadoop上的數(shù)據(jù)聚集、adhoc查詢及大數(shù)據(jù)集的分析等操作,以減輕程序員的負擔,它借鑒關(guān)系數(shù)據(jù)庫的模式管理、SQL接口等技術(shù),把結(jié)構(gòu)化的數(shù)據(jù)文件映射為數(shù)據(jù)庫表,提供類似于SQL的描述性語言HiveQL供程序員使用,可自動將HiveQL語句解析成一優(yōu)化的MapReduce任務(wù)執(zhí)行序列,此外,它也支持用戶自定義的MapReduce函數(shù)。
PigLatin是Yahoo!提出的類似于Hive的大數(shù)據(jù)集分析平臺,兩者的區(qū)別主要在于語言接口。
Hive提供了類似SQL的接口,PigLatin提供的是一種基于操作符的數(shù)據(jù)流式的接口,圖3是PigLatin在處理查詢時的一個操作實例,該查詢的目的是找出“年齡在18~25周歲之間的用戶(Users)最頻繁訪問的5個頁面(Pages)”,從圖3可以看出,Pig提供的操作接口類似于關(guān)系數(shù)據(jù)庫的操作符(對應(yīng)圖中右側(cè)部分中的每一行命令),用戶查詢的腳本類似于邏輯查詢計劃(對應(yīng)圖中左側(cè)部分),因此,也可以說Pig利用操作符來對Hadoop進行封裝,Hive利用SQL進行封裝。
5.3MapReduce和并行數(shù)據(jù)庫集成型
該方向的代表性研究是耶魯大學提出的HadoopDB(已于2011年商業(yè)化為Hadapt)Stonebraker等人設(shè)計的Vertica數(shù)據(jù)庫和NCR公司的Teradata數(shù)據(jù)庫。
圖3 PigLatin的一個查詢示例(右邊為實際腳本)
核心關(guān)注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用,蘊涵了豐富的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.ezxoed.cn/
本文標題:架構(gòu)大數(shù)據(jù):挑戰(zhàn)、現(xiàn)狀與展望(上)
本文網(wǎng)址:http://www.ezxoed.cn/html/support/1112158844.html