HadoopDB的核心思想是利用Hadoop作為調(diào)度層和網(wǎng)絡(luò)溝通層,關(guān)系數(shù)據(jù)庫(kù)作為執(zhí)行引擎,盡可能地將查詢(xún)壓入數(shù)據(jù)庫(kù)層處理,目標(biāo)是想借助Hadoop框架來(lái)獲得較好的容錯(cuò)性和對(duì)異構(gòu)環(huán)境的支持;通過(guò)將查詢(xún)盡可能推入數(shù)據(jù)庫(kù)中執(zhí)行來(lái)獲得關(guān)系數(shù)據(jù)庫(kù)的性能優(yōu)勢(shì),HadoopDB的思想是深遠(yuǎn)的,但目前尚無(wú)應(yīng)用案例,原因在于:
(1)其數(shù)據(jù)預(yù)處理代價(jià)過(guò)高:數(shù)據(jù)需要進(jìn)行兩次分解和一次數(shù)據(jù)庫(kù)加載操作后才能使用;
(2)將查詢(xún)推向數(shù)據(jù)庫(kù)層只是少數(shù)情況,大多數(shù)情況下,查詢(xún)?nèi)杂桑龋椋觯逋瓿,因(yàn)?a href="http://www.ezxoed.cn/" title="" target="_blank" >數(shù)據(jù)倉(cāng)庫(kù)查詢(xún)往往涉及多表連接,由于連接的復(fù)雜性,難以做到在保持連接數(shù)據(jù)局部性的前提下將參某種模式劃分;
(3)維護(hù)代價(jià)過(guò)高,不僅要維護(hù)Hadoop系統(tǒng),還要維護(hù)每個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn);
(4)目前尚不支持?jǐn)?shù)據(jù)的動(dòng)態(tài)劃分,需要手工方式將數(shù)據(jù)一次性劃分好,總的來(lái)說(shuō),HadoopDB在某些情況下,可以同時(shí)實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫(kù)的高性能特性和MapReduce的擴(kuò)展性、容錯(cuò)性,但同時(shí)也喪失了關(guān)系數(shù)據(jù)庫(kù)和MapReduce的某些優(yōu)點(diǎn),比如MapReduce較低的預(yù)處理代價(jià)和維護(hù)代價(jià)、關(guān)系數(shù)據(jù)庫(kù)的動(dòng)態(tài)數(shù)據(jù)重分布等。
Vertica采用的是共存策略:根據(jù)Hadoop和Vertica各自的處理優(yōu)勢(shì),對(duì)數(shù)據(jù)處理任務(wù)進(jìn)行劃分,比如Hadoop負(fù)責(zé)非結(jié)構(gòu)化數(shù)據(jù)的處理,Vertica負(fù)責(zé)結(jié)構(gòu)化數(shù)據(jù)的處理;Hadoop負(fù)責(zé)耗時(shí)的批量復(fù)雜處理,Vertica負(fù)責(zé)高性能的交互式查詢(xún)等,從而將兩者結(jié)合起來(lái),Vertica實(shí)際采用的是兩套系統(tǒng),同時(shí)支持在MapReduce任務(wù)中直接訪問(wèn)Vertica數(shù)據(jù)庫(kù)中的數(shù)據(jù),由于結(jié)構(gòu)化數(shù)據(jù)仍在Vertica中處理,在處理結(jié)構(gòu)化大數(shù)據(jù)上的查詢(xún)分析時(shí),仍面臨擴(kuò)展性問(wèn)題;如果將查詢(xún)推向Hadoop進(jìn)行,又將面臨性能問(wèn)題,因此,Vertica的擴(kuò)展性問(wèn)題和Hadoop的性能問(wèn)題在該系統(tǒng)中共存。
與前兩者相比,Teradata的集成相對(duì)簡(jiǎn)單,Teradata采用了存儲(chǔ)層的整合:MapReduce任務(wù)可以從Teradata數(shù)據(jù)庫(kù)中讀取數(shù)據(jù),Teradata數(shù)據(jù)庫(kù)也可以從Hadoop分布式文件系統(tǒng)上讀取數(shù)據(jù),同樣,Teradata和Hadoop各自的根本性問(wèn)題都未解決。
6 研究現(xiàn)狀
對(duì)并行數(shù)據(jù)庫(kù)來(lái)講,其最大問(wèn)題在于有限的擴(kuò)展能力和待改進(jìn)的軟件級(jí)容錯(cuò)能力;MapReduce的最大問(wèn)題在于性能,尤其是連接操作的性能;混合式架構(gòu)的關(guān)鍵是,如何能盡可能多地把工作推向合適的執(zhí)行引擎(并行數(shù)據(jù)庫(kù)或MapReduce),本節(jié)對(duì)近年來(lái)在這些問(wèn)題上的研究做一分析和歸納。
6.1 并行數(shù)據(jù)庫(kù)擴(kuò)展性和容錯(cuò)性研究
華盛頓大學(xué)在文獻(xiàn)[23]中提出了可以生成具備容錯(cuò)能力的并行執(zhí)行計(jì)劃優(yōu)化器,該優(yōu)化器可以依靠輸入的并行執(zhí)行計(jì)劃、各個(gè)操作符的容錯(cuò)策略及查詢(xún)失敗的期望值等,輸出一個(gè)具備容錯(cuò)能力的并行執(zhí)行計(jì)劃,在該計(jì)劃中,每個(gè)操作符都可以采取不同的容錯(cuò)策略,在失敗時(shí)僅重新執(zhí)行其子操作符(在某節(jié)點(diǎn)上運(yùn)行的操作符)的任務(wù)來(lái)避免整個(gè)查詢(xún)的重新執(zhí)行。
MIT于2010年設(shè)計(jì)的Osprey系統(tǒng)基于維表在各個(gè)節(jié)點(diǎn)全復(fù)制、事實(shí)表橫向切分并冗余備份的數(shù)據(jù)分布策略,將一星型查詢(xún)劃分為眾多獨(dú)立子查詢(xún),每個(gè)子查詢(xún)?cè)趫?zhí)行失敗時(shí)都可以在其備份節(jié)點(diǎn)上重新執(zhí)行,而不用重做整個(gè)查詢(xún),使得數(shù)據(jù)倉(cāng)庫(kù)查詢(xún)獲得類(lèi)似MapReduce的容錯(cuò)能力,數(shù)據(jù)倉(cāng)庫(kù)擴(kuò)展性方面的研究較少,中國(guó)人民大學(xué)的LinearDB原型屬于這方面的研究,詳細(xì)參見(jiàn)7.1節(jié)。
6.2MapReduce性能優(yōu)化研究
MapReduce的性能優(yōu)化研究集中于對(duì)關(guān)系數(shù)據(jù)庫(kù)的先進(jìn)技術(shù)和特性的移植上。
Facebook和俄亥俄州立大學(xué)合作,將關(guān)系數(shù)據(jù)庫(kù)的混合式存儲(chǔ)模型應(yīng)用于Hadoop平臺(tái),提出了RCFile存儲(chǔ)格式。與之不同,文獻(xiàn)[26]將列存儲(chǔ)技術(shù)引入Hadoop平臺(tái),Hadoop++系統(tǒng)運(yùn)用了傳統(tǒng)數(shù)據(jù)庫(kù)的索引技術(shù),并通過(guò)分區(qū)數(shù)據(jù)并置(CoPartition)的方式來(lái)提升性能,文獻(xiàn)[2829]基于MapReduce實(shí)現(xiàn)了以流水線方式在各個(gè)操作符間傳遞數(shù)據(jù),從而縮短了任務(wù)執(zhí)行時(shí)間;在線聚集(onlineaggregation)的操作模式使得用戶(hù)可以在查詢(xún)執(zhí)行過(guò)程中看到部分較早返回的結(jié)果,兩者的不同之處在于前者仍基于sortmerge方式來(lái)實(shí)現(xiàn)流水線,只是將排序等操作推向了reducer,部分情況下仍會(huì)出現(xiàn)流水線停頓的情況;而后者利用hash方式來(lái)分布數(shù)據(jù),能實(shí)現(xiàn)更好的并行流水線操作,文獻(xiàn)[30]提出了MRShare架構(gòu),對(duì)批量查詢(xún)進(jìn)行轉(zhuǎn)換,將可共享掃描、共享Map輸出結(jié)果等的一組任務(wù)合并為一個(gè),以提升性能,新加坡國(guó)立大學(xué)對(duì)影響Hadoop性能的因素做了深入分析,并提出了5項(xiàng)有效的優(yōu)化技術(shù),使得Hadoop的性能提升了近3倍,逼近關(guān)系數(shù)據(jù)庫(kù)的性能。
近年的研究熱點(diǎn)是基于MapReduce的連接操作的性能優(yōu)化,文獻(xiàn)[31]對(duì)MapReduce平臺(tái)的兩表連接算法做了總結(jié),提出了Map端連接、Reduce端連接及廣播式連接等算法,文獻(xiàn)[32]對(duì)MapReduce框架進(jìn)行了擴(kuò)展,在Reduce步驟后添加了一Merge步驟來(lái)完成連接操作,提出的MapReduceMerge框架可以同時(shí)處理兩個(gè)異構(gòu)數(shù)據(jù)源的數(shù)據(jù),對(duì)于多表連接,當(dāng)前主流的研究集中于僅通過(guò)一個(gè)任務(wù)來(lái)完成連接操作,文獻(xiàn)提出了一對(duì)多復(fù)制的方法,在Map階段結(jié)束后,為保證連接操作的局部性,元組會(huì)被復(fù)制到多個(gè)節(jié)點(diǎn),但在節(jié)點(diǎn)數(shù)和數(shù)據(jù)量增大的情況下,會(huì)帶來(lái)I/O量及網(wǎng)絡(luò)傳輸量的巨大增長(zhǎng),Llama通過(guò)預(yù)排序和按連接屬性劃分?jǐn)?shù)據(jù)的方式來(lái)降低星型連接的代價(jià),但要付出可觀的預(yù)處理代價(jià)和空間代價(jià),不同于以上等值連接優(yōu)化,文獻(xiàn)[36]提出了針對(duì)任意連接條件的優(yōu)化模型,以上連接方式都是先執(zhí)行連接,然后在連接后的數(shù)據(jù)上執(zhí)行聚集操作,而中國(guó)人民大學(xué)的Dumbo系統(tǒng)卻采用了另一種更適應(yīng)于MapReduce平臺(tái)的思路:先執(zhí)行過(guò)濾聚集操作,再基于聚集的數(shù)據(jù)執(zhí)行連接,詳細(xì)參考7.2節(jié)。
6.3HadoopDB的改進(jìn)
HadoopDB于2011年針對(duì)其架構(gòu)提出了兩種連接優(yōu)化技術(shù)和兩種聚集優(yōu)化技術(shù)。
兩種連接優(yōu)化的核心思想都是盡可能地將數(shù)據(jù)的處理推入數(shù)據(jù)庫(kù)層執(zhí)行,第1種優(yōu)化方式是根據(jù)表與表之間的連接關(guān)系,通過(guò)數(shù)據(jù)預(yù)分解,使參與連接的數(shù)據(jù)盡可能分布在同一數(shù)據(jù)庫(kù)內(nèi)(參照分解法),從而實(shí)現(xiàn)將連接操作下壓進(jìn)數(shù)據(jù)庫(kù)內(nèi)執(zhí)行,該算法的缺點(diǎn)是應(yīng)用場(chǎng)景有限,只適用于鏈?zhǔn)竭B接,第2種連接方式是針對(duì)廣播式連接而設(shè)計(jì)的,在執(zhí)行連接前,先在數(shù)據(jù)庫(kù)內(nèi)為每張參與連接的維表建立一張臨時(shí)表,使得連接操作盡可能在數(shù)據(jù)庫(kù)內(nèi)執(zhí)行,該算法的缺點(diǎn)是較多的網(wǎng)絡(luò)傳輸和磁盤(pán)I/O操作。
兩種聚集優(yōu)化技術(shù)分別是連接后聚集和連接前聚集,前者是執(zhí)行完Reduce端連接后,直接對(duì)符合條件的記錄執(zhí)行聚集操作;后者是將所有數(shù)據(jù)先在數(shù)據(jù)庫(kù)層執(zhí)行聚集操作,然后基于聚集數(shù)據(jù)執(zhí)行連接操作,并將不符合條件的聚集數(shù)據(jù)做減法操作,該方式適用的條件有限,主要用于參與連接和聚集的列的基數(shù)相乘后小于表記錄數(shù)的情況。
總的來(lái)看,HadoopDB的優(yōu)化技術(shù)大都局限性較強(qiáng),對(duì)于復(fù)雜的連接操作(如環(huán)形連接等)仍不能下推至數(shù)據(jù)庫(kù)層執(zhí)行,并未從根本上解決其性能問(wèn)題。
7 MapReduce和關(guān)系數(shù)據(jù)庫(kù)技術(shù)的融合
綜上所述,當(dāng)前研究大都集中于功能或特性的移植,即從一個(gè)平臺(tái)學(xué)習(xí)新的技術(shù),到另一平臺(tái)重新實(shí)現(xiàn)和集成,未涉及執(zhí)行核心,因此也沒(méi)有從根本上解決大數(shù)據(jù)分析問(wèn)題,鑒于此,中國(guó)人民大學(xué)高性能數(shù)據(jù)庫(kù)實(shí)驗(yàn)室的研究小組采取了另一種思路:從數(shù)據(jù)的組織和查詢(xún)的執(zhí)行兩個(gè)核心層次入手,融合關(guān)系數(shù)據(jù)庫(kù)和MapReduce兩種技術(shù),設(shè)計(jì)高性能的可擴(kuò)展的抽象數(shù)據(jù)倉(cāng)庫(kù)查詢(xún)處理框架,該框架在支持高度可擴(kuò)展的同時(shí),又具有關(guān)系數(shù)據(jù)庫(kù)的性能,我們團(tuán)隊(duì)嘗試過(guò)兩個(gè)研究方向:
(1)借鑒MapReduce的思想,使OLAP查詢(xún)的處理能像MapReduce一樣高度可擴(kuò)展(LinearDB原型);
(2)利用關(guān)系數(shù)據(jù)庫(kù)的技術(shù),使MapReduce在處理OLAP查詢(xún)時(shí),逼近關(guān)系數(shù)據(jù)庫(kù)的性能(Dumbo原型)。
7.1 LinearDB
LinearDB①原型系統(tǒng)沒(méi)有直接采用基于連接的星型模型(雪花模型),而是對(duì)其進(jìn)行了改造,設(shè)計(jì)了擴(kuò)展性更好的、基于掃描的無(wú)連接雪花模型JFSS(JoinFreeSnowflakeSchema),該模型的設(shè)計(jì)借鑒了泛關(guān)系模型的思想,采用層次編碼技術(shù)[40]將維表層次信息壓縮進(jìn)事實(shí)表,使得事實(shí)表可以獨(dú)立執(zhí)行維表上的謂詞判斷、聚集等操作,從而使連接的數(shù)據(jù)在大規(guī)模機(jī)群上實(shí)現(xiàn)局部性,消除了連接操作,圖4是一個(gè)星型模型和無(wú)連接雪花模型的對(duì)應(yīng)示意圖。
在執(zhí)行層次上,LinearDB吸取了MapReduce處理模式的設(shè)計(jì)思想,將數(shù)據(jù)倉(cāng)庫(kù)查詢(xún)的處理抽象為Transform、Reduce、Merge3個(gè)操作(TRM執(zhí)行模型):
(1)Transform,主節(jié)點(diǎn)對(duì)查詢(xún)進(jìn)行預(yù)處理,將查詢(xún)中作用于維表的操作(主要是謂詞判斷,groupby聚集操作等)轉(zhuǎn)換為事實(shí)表上的操作;
(2)Reduce,每個(gè)數(shù)據(jù)節(jié)點(diǎn)并行地掃描、聚集本地?cái)?shù)據(jù),然后將處理結(jié)果返回給主節(jié)點(diǎn);
(3)Merge,主節(jié)點(diǎn)對(duì)各個(gè)數(shù)據(jù)節(jié)點(diǎn)返回的結(jié)果進(jìn)行合并,并執(zhí)行后續(xù)的過(guò)濾、排序等操作,基于TRM執(zhí)行模型,查詢(xún)可以劃分為眾多獨(dú)立的子任務(wù)在大規(guī)模機(jī)群上并行執(zhí)行,執(zhí)行過(guò)程中,任何失敗子任務(wù)都可以在其備份節(jié)點(diǎn)重新執(zhí)行,從而獲得較好的容錯(cuò)能力。LinearDB的執(zhí)行代價(jià)主要取決于對(duì)事實(shí)表的Reduce(主要是掃描)操作,因此,LinearDB可以獲得近乎線性的大規(guī)?蓴U(kuò)展能力。
實(shí)驗(yàn)表明,其性能比HadoopDB至少高出一個(gè)數(shù)量級(jí)。
LinearDB的擴(kuò)展能力、容錯(cuò)能力和高性能在于其巧妙地結(jié)合了關(guān)系數(shù)據(jù)庫(kù)技術(shù)(層次編碼技術(shù)、泛關(guān)系模式)和MapReduce處理模式的設(shè)計(jì)思想,由此,可以看出,結(jié)合方式的不同可以導(dǎo)致系統(tǒng)能力的巨大差異。
7.2Dumbo
Dumbo的核心思想是根據(jù)MapReduce的“過(guò)濾->聚集”的處理模式,對(duì)OLAP查詢(xún)的處理進(jìn)行改造,使其適應(yīng)于MapReduce框架,Dumbo采用了類(lèi)似于LinearDB的數(shù)據(jù)組織模式———利用層次編碼技術(shù)將維表信息壓縮進(jìn)事實(shí)表,區(qū)別在于Dumbo采用了更加有效的編碼方式,并針對(duì)Hadoop分布式文件系統(tǒng)的特點(diǎn)對(duì)數(shù)據(jù)的存儲(chǔ)進(jìn)行了優(yōu)化。
在執(zhí)行層次上,Dumbo對(duì)MapReduce框架進(jìn)行了擴(kuò)展,設(shè)計(jì)了新的OLAP查詢(xún)處理框架———TMRP(Transform->Map->Reduce->Postprocess)處理框架(如圖5所示),在該框架中,主節(jié)點(diǎn)首先對(duì)查詢(xún)進(jìn)行轉(zhuǎn)換,生成一個(gè)MapReduce任務(wù)來(lái)執(zhí)行查詢(xún),該任務(wù)在Map階段以流水線方式掃描、聚集本地?cái)?shù)據(jù),并只將本地的聚集數(shù)據(jù)傳至Reduce階段,來(lái)進(jìn)行數(shù)據(jù)的合并及聚集、排序等操作,在Postprocess階段,主節(jié)點(diǎn)在數(shù)據(jù)節(jié)點(diǎn)上傳的聚集數(shù)據(jù)之上執(zhí)行連接操作,實(shí)驗(yàn)表明,Dumbo性能遠(yuǎn)超Hadoop和HadoopDB。
由此我們可以看出,復(fù)雜的OLAP查詢(xún)?cè)冢停幔穑遥澹洌酰悖蹇蚣芟乱部梢垣@得接近甚至超越關(guān)系數(shù)據(jù)庫(kù)的性能,其關(guān)鍵在于如何有效地結(jié)合關(guān)系數(shù)據(jù)庫(kù)和MapReduce兩種技術(shù),僅僅停留于表層的移植和集成是難以從根本上解決大數(shù)據(jù)分析問(wèn)題的,我們?cè)谖墨I(xiàn)[41]的研究中也展示了如何基于這種新的數(shù)據(jù)組織方式來(lái)實(shí)現(xiàn)復(fù)雜分析操作———百分位數(shù)的高效計(jì)算問(wèn)題。
LinearDB和Dumbo雖然基本可以達(dá)到預(yù)期的設(shè)計(jì)目標(biāo),但兩者都需要對(duì)數(shù)據(jù)進(jìn)行預(yù)處理,其預(yù)處理代價(jià)是普通加載時(shí)間的7倍左右,因此其應(yīng)對(duì)變化的能力還較弱,這是我們未來(lái)的工作內(nèi)容之一。
圖4 對(duì)比:一個(gè)典型星型模型與其對(duì)應(yīng)的無(wú)連接雪花模型
8 研究展望
當(dāng)前3個(gè)方向的研究都不能完美地解決大數(shù)據(jù)分析問(wèn)題,也就意味著每個(gè)方向都有極具挑戰(zhàn)性的工作等待著我們。
對(duì)并行數(shù)據(jù)庫(kù)來(lái)說(shuō),其擴(kuò)展性近年雖有較大改善(如Greenplum和AsterData都是面向PB級(jí)數(shù)據(jù)規(guī)模設(shè)計(jì)開(kāi)發(fā)的),但距離大數(shù)據(jù)的分析需求仍有較大差距,因此,如何改善并行數(shù)據(jù)庫(kù)的擴(kuò)展能力是一項(xiàng)非常有挑戰(zhàn)的工作,該項(xiàng)研究將同時(shí)涉及數(shù)據(jù)一致性協(xié)議、容錯(cuò)性、性能等數(shù)據(jù)庫(kù)領(lǐng)域的諸多方面。
圖5 Dumbo架構(gòu)(深灰色部分是新增模塊,剩余部分是Hadoop自帶模塊)
混合式架構(gòu)方案可以復(fù)用已有成果,開(kāi)發(fā)量較小,但只是簡(jiǎn)單的功能集成似乎并不能有效解決大數(shù)據(jù)的分析問(wèn)題,因此該方向還需要更加深入的研究工作,比如從數(shù)據(jù)模型及查詢(xún)處理模式上進(jìn)行研究,使兩者能較自然地結(jié)合起來(lái),這將是一項(xiàng)非常有意義的工作,中國(guó)人民大學(xué)的Dumbo系統(tǒng)即是在深層結(jié)合方向上努力的一個(gè)例子。
相比于前兩者,MapReduce的性能優(yōu)化進(jìn)展迅速,其性能正逐步逼近關(guān)系數(shù)據(jù)庫(kù),該方向的研究又分為兩個(gè)方向:理論界側(cè)重于利用關(guān)系數(shù)據(jù)庫(kù)技術(shù)及理論改善MapReduce的性能;工業(yè)界側(cè)重于基于MapReduce平臺(tái)開(kāi)發(fā)高效的應(yīng)用軟件,針對(duì)數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域,我們認(rèn)為如下幾個(gè)研究方向比較重要,且目前研究還較少涉及:
(1)多維數(shù)據(jù)的預(yù)計(jì)算,MapReduce更多針對(duì)的是一次性分析操作,大數(shù)據(jù)上的分析操作雖然難以預(yù)測(cè),但傳統(tǒng)的分析,如基于報(bào)表和多維數(shù)據(jù)的分析仍占多數(shù),因此,MapReduce平臺(tái)也可以利用預(yù)計(jì)算等手段加快數(shù)據(jù)分析的速度,基于存儲(chǔ)空間的考慮(可以想象,在爆炸數(shù)據(jù)之上計(jì)算數(shù)據(jù)立方體需要付出昂貴的存儲(chǔ)空間代價(jià)),MOLAP是不可取的,混合式OLAP(HOLAP)應(yīng)該是MapReduce平臺(tái)的優(yōu)選OLAP實(shí)現(xiàn)方案,具體研究如:①基于MapReduce框架的高效Cube計(jì)算算法;②物化視圖的選擇問(wèn)題,即物化哪些數(shù)據(jù);③不同分析操作的物化手段(比如預(yù)測(cè)分析操作的物化)及如何基于物化的數(shù)據(jù)進(jìn)行復(fù)雜分析操作(如數(shù)據(jù)訪問(wèn)路徑的選擇問(wèn)題)。
(2)各種分析操作的并行化實(shí)現(xiàn),大數(shù)據(jù)分析需要高效的復(fù)雜統(tǒng)計(jì)分析功能的支持,IBM將開(kāi)源統(tǒng)計(jì)分析軟件R集成進(jìn)Hadoop平臺(tái),增強(qiáng)了Hadoop的統(tǒng)計(jì)分析功能,但更具挑戰(zhàn)性的問(wèn)題是,如何基于MapReduce框架設(shè)計(jì)可并行化的、高效的分析算法,尤其需要強(qiáng)調(diào)的是,鑒于移動(dòng)數(shù)據(jù)的巨大代價(jià),這些算法應(yīng)基于移動(dòng)計(jì)算的方式來(lái)實(shí)現(xiàn)。
(3)查詢(xún)共享,MapReduce采用步步物化的處理方式,導(dǎo)致其I/O代價(jià)及網(wǎng)絡(luò)傳輸代價(jià)較高,一種有效的降低該代價(jià)的方式是在多個(gè)查詢(xún)間共享物化的中間結(jié)果,甚至原始數(shù)據(jù),以分?jǐn)偞鷥r(jià)并避免重復(fù)計(jì)算,因此如何在多查詢(xún)間共享中間結(jié)果將是一項(xiàng)非常有實(shí)際應(yīng)用價(jià)值的研究。
(4)用戶(hù)接口,如何較好地實(shí)現(xiàn)數(shù)據(jù)分析的展示和操作,尤其是復(fù)雜分析操作的直觀展示。
(5)Hadoop可靠性研究,當(dāng)前Hadoop采用主從結(jié)構(gòu),由此決定了主節(jié)點(diǎn)一旦失效,將會(huì)出現(xiàn)整個(gè)系統(tǒng)失效的局面,因此,如何在不影響Hadoop現(xiàn)有實(shí)現(xiàn)的前提下,提高主節(jié)點(diǎn)的可靠性,將是一項(xiàng)切實(shí)的研究。
(6)數(shù)據(jù)壓縮,MapReduce的執(zhí)行模型決定了其性能取決于I/O和網(wǎng)絡(luò)傳輸代價(jià),文獻(xiàn)[11]在比較并行數(shù)據(jù)庫(kù)和MapReduce基于壓縮數(shù)據(jù)的性能時(shí),發(fā)現(xiàn)壓縮技術(shù)并沒(méi)有改善Hadoop的性能①,但實(shí)際情況是,壓縮不僅可以節(jié)省空間,節(jié)。桑霞熬W(wǎng)絡(luò)帶寬,還可以利用當(dāng)前CPU的多核并行計(jì)算能力,平衡I/O和CPU的處理能力,從而提高性能,比如并行數(shù)據(jù)庫(kù)利用數(shù)據(jù)壓縮后,性能往往可以大幅提升,此后,文獻(xiàn)[25、26]的研究成功地利用壓縮技術(shù)提升了Hadoop的性能,但這些研究都基于各自的存儲(chǔ)模型,而非Hadoop的默認(rèn)存儲(chǔ)模式(行存模型),因此,MapReduce上的壓縮是一個(gè)尚待研究的重要問(wèn)題。
(7)多維索引研究,如何基于MapReduce框架實(shí)現(xiàn)多維索引,加快多維數(shù)據(jù)的檢索速度。
當(dāng)然,仍有許多其它研究工作,比如基于Hadoop的實(shí)時(shí)數(shù)據(jù)分析、彈性研究、數(shù)據(jù)一致性研究等,都是非常有挑戰(zhàn)和意義的研究,限于篇幅我們不再贅述。
9 總結(jié)
本文對(duì)大數(shù)據(jù)分析的主流實(shí)現(xiàn)平臺(tái)(并行數(shù)據(jù)庫(kù)、MapReduce及兩者的混合架構(gòu))進(jìn)行了評(píng)價(jià)、歸納與對(duì)比分析,介紹了中國(guó)人民大學(xué)在大數(shù)據(jù)分析方面的研究,并對(duì)當(dāng)前的研究進(jìn)行了歸納,從文中可以看出,每種分析平臺(tái)都不是完美的,在大數(shù)據(jù)面前,都有很長(zhǎng)的路要走,大數(shù)據(jù)分析迫使我們反思傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu),虛心地研究MapReduce等新生平臺(tái),以站在更高的層次來(lái)思考問(wèn)題,從而找到適應(yīng)時(shí)代需求的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)。
核心關(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管理軟件信賴(lài)品牌。
轉(zhuǎn)載請(qǐng)注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題:架構(gòu)大數(shù)據(jù):挑戰(zhàn)、現(xiàn)狀與展望(下)
本文網(wǎng)址:http://www.ezxoed.cn/html/support/1112158845.html