3.2.1 數(shù)據(jù)抽取與集成
大數(shù)據(jù)的一個(gè)重要特點(diǎn)就是多樣性,這就意味著數(shù)據(jù)來源極其廣泛,數(shù)據(jù)類型極為繁雜。這種復(fù)雜的數(shù)據(jù)環(huán)境給大數(shù)據(jù)的處理帶來極大的挑戰(zhàn)。要想處理大數(shù)據(jù),首先必須對(duì)所需數(shù)據(jù)源的數(shù)據(jù)進(jìn)行抽取和集成,從中提取出關(guān)系和實(shí)體,經(jīng)過關(guān)聯(lián)和聚合之后采用統(tǒng)一定義的結(jié)構(gòu)來存儲(chǔ)這些數(shù)據(jù)。在數(shù)據(jù)集成和提取時(shí)需要對(duì)數(shù)據(jù)進(jìn)行清洗,保證數(shù)據(jù)質(zhì)量及可信性。同時(shí)還要特別注意前面提及的大數(shù)據(jù)時(shí)代模式和數(shù)據(jù)的關(guān)系,大數(shù)據(jù)時(shí)代的數(shù)據(jù)往往是先有數(shù)據(jù)再有模式,且模式是在不斷的動(dòng)態(tài)演化之中的。
數(shù)據(jù)抽取和集成技術(shù)不是一項(xiàng)全新的技術(shù),傳統(tǒng)數(shù)據(jù)庫(kù)領(lǐng)域已對(duì)此問題有了比較成熟的研究。隨著新的數(shù)據(jù)源的涌現(xiàn),數(shù)據(jù)集成方法也在不斷的發(fā)展之中。從數(shù)據(jù)集成模型來看,現(xiàn)有的數(shù)據(jù)抽取與集成方式可以大致分為以下四種類型:基于物化或是ETL 方法的引擎(Materialization or ETL engine)、基于聯(lián)邦數(shù)據(jù)庫(kù)或中間件方法的引擎(Federation engine orMediator)、基于數(shù)據(jù)流方法的引擎(Stream engine)及 基于搜索引擎的方法(Search engine)。
3.2.2 數(shù)據(jù)分析
數(shù)據(jù)分析是整個(gè)大數(shù)據(jù)處理流程的核心,因?yàn)榇髷?shù)據(jù)的價(jià)值產(chǎn)生于分析過程。從異構(gòu)數(shù)據(jù)源抽取和集成的數(shù)據(jù)構(gòu)成了數(shù)據(jù)分析的原始數(shù)據(jù)。根據(jù)不同應(yīng)用的需求可以從這些數(shù)據(jù)中選擇全部或部分進(jìn)行分析。傳統(tǒng)的分析技術(shù)如數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、統(tǒng)計(jì)分析等在大數(shù)據(jù)時(shí)代需要做出調(diào)整,因?yàn)檫@些技術(shù)在大數(shù)據(jù)時(shí)代面臨著一些新的挑戰(zhàn),主要有:
1、數(shù)據(jù)量大并不一定意味著數(shù)據(jù)價(jià)值的增加,相反這往往意味著數(shù)據(jù)噪音的增多。因此在數(shù)據(jù)分析之前必須進(jìn)行數(shù)據(jù)清洗等預(yù)處理工作,但是預(yù)處理如此大量的數(shù)據(jù)對(duì)于機(jī)器硬件以及算法都是嚴(yán)峻的考驗(yàn)。
2、大數(shù)據(jù)時(shí)代的算法需要進(jìn)行調(diào)整。首先大數(shù)據(jù)的應(yīng)用常常具有實(shí)時(shí)性的特點(diǎn),算法的準(zhǔn)確率不再是大數(shù)據(jù)應(yīng)用的最主要指標(biāo)。很多場(chǎng)景中算法需要在處理的實(shí)時(shí)性和準(zhǔn)確率之間取得一個(gè)平衡,比如在線的機(jī)器學(xué)習(xí)算法(online machine learning)。其次云計(jì)算是進(jìn)行大數(shù)據(jù)處理的有力工具,這就要求很多算法必須做出調(diào)整以適應(yīng)云計(jì)算的框架,算法需要變得具有可擴(kuò)展性。最后在選擇算法處理大數(shù)據(jù)時(shí)必須謹(jǐn)慎,當(dāng)數(shù)據(jù)量增長(zhǎng)到一定規(guī)模以后,可以從小量數(shù)據(jù)中挖掘出有效信息的算法并一定適用于大數(shù)據(jù)。統(tǒng)計(jì)學(xué)中的邦弗朗尼原理(Bonferroni’s Principle)就是一個(gè)典型的例子。
3、數(shù)據(jù)結(jié)果好壞的衡量。得到分析結(jié)果并不難,但是結(jié)果好壞的衡量卻是大數(shù)據(jù)時(shí)代數(shù)據(jù)分析的新挑戰(zhàn)。大數(shù)據(jù)時(shí)代的數(shù)據(jù)量大、類型龐雜,進(jìn)行分析的時(shí)候往往對(duì)整個(gè)數(shù)據(jù)的分布特點(diǎn)掌握的不太清楚,這會(huì)導(dǎo)致最后在設(shè)計(jì)衡量的方法以及指標(biāo)的時(shí)候遇到諸多困難。大數(shù)據(jù)分析已被廣泛應(yīng)用于諸多領(lǐng)域,典型的有推薦系統(tǒng)、商業(yè)智能、決策支持等。
3.2.3 數(shù)據(jù)解釋
數(shù)據(jù)分析是大數(shù)據(jù)處理的核心,但是用戶往往更關(guān)心結(jié)果的展示。如果分析的結(jié)果正確但是沒有采用適當(dāng)?shù)慕忉尫椒,則所得到的結(jié)果很可能讓用戶難以理解,極端情況下甚至?xí)`導(dǎo)用戶。數(shù)據(jù)解釋的方法很多,比較傳統(tǒng)的就是以文本形式輸出結(jié)果或者直接在電腦終端上顯示結(jié)果。這種方法在面對(duì)小數(shù)據(jù)量時(shí)是一種很好的選擇。但是大數(shù)據(jù)時(shí)代的數(shù)據(jù)分析結(jié)果往往也是海量的,同時(shí)結(jié)果之間的關(guān)聯(lián)關(guān)系極其復(fù)雜,采用傳統(tǒng)的解釋方法基本不可行。
可以考慮從下面兩個(gè)方面提升數(shù)據(jù)解釋能力。
1、引入可視化技術(shù)。可視化作為解釋大量數(shù)據(jù)最有效的手段之一率先被科學(xué)與工程計(jì)算領(lǐng)域采用。通過對(duì)分析結(jié)果的可視化用形象的方式向用戶展示結(jié)果,而且圖形化的方式比文字更易理解和接受。常見的可視化技術(shù)有標(biāo)簽云(Tag Cloud)、歷史流(history flow)、空間信息流(Spatial information flow)等?梢愿鶕(jù)具體的應(yīng)用需要選擇合適的可視化技術(shù)。
2、讓用戶能夠在一定程度上了解和參與具體的分析過程。這個(gè)既可以采用人機(jī)交互技術(shù),利用交互式的數(shù)據(jù)分析過程來引導(dǎo)用戶逐步的進(jìn)行分析,使得用戶在得到結(jié)果的同時(shí)更好的理解分析結(jié)果的由來。也可以采用數(shù)據(jù)起源技術(shù),通過該技術(shù)可以幫助追溯整個(gè)數(shù)據(jù)分析的過程,有助于用戶理解結(jié)果。
4、關(guān)鍵技術(shù)分析
大數(shù)據(jù)價(jià)值的完整體現(xiàn)需要多種技術(shù)的協(xié)同。文件系統(tǒng)提供最底層存儲(chǔ)能力的支持。為了便于數(shù)據(jù)管理,需要在文件系統(tǒng)之上建立數(shù)據(jù)庫(kù)系統(tǒng)。通過索引等的構(gòu)建,對(duì)外提供高效的數(shù)據(jù)查詢等常用功能。最終通過數(shù)據(jù)分析技術(shù)從數(shù)據(jù)庫(kù)中的大數(shù)據(jù)提取出有益的知識(shí)。
4.1 云計(jì)算:大數(shù)據(jù)的基礎(chǔ)平臺(tái)與支撐技術(shù)
如果將各種大數(shù)據(jù)的應(yīng)用比作一輛輛“汽車”的話,支撐起這些“汽車”運(yùn)行的“高速公路”就是云計(jì)算。正是云計(jì)算技術(shù)在數(shù)據(jù)存儲(chǔ)、管理與分析等方面的支撐,才使得大數(shù)據(jù)有用武之地。
在所有的“高速公路”中,Google 無疑是技術(shù)最為先進(jìn)的一個(gè)。需求推動(dòng)創(chuàng)新,面對(duì)海量的Web 數(shù)據(jù), Google 于2006 年首先提出了云計(jì)算的概念。支撐Google 內(nèi)部各種大數(shù)據(jù)應(yīng)用的正是其自行研發(fā)的一系列云計(jì)算技術(shù)和工具。難能可貴的是Google 并未將這些技術(shù)完全封閉,而是以論文的形式逐步公開其實(shí)現(xiàn)。正是這些公開的論文,使得以GFS、MapReduce、Bigtable 為代表的一系列大數(shù)據(jù)處理技術(shù)被廣泛了解并得到應(yīng)用,同時(shí)還催生出以Hadoop為代表的一系列云計(jì)算開源工具。云計(jì)算技術(shù)很多,但是通過Google 云計(jì)算技術(shù)的介紹能夠快速、完整的把握云計(jì)算技術(shù)的核心和精髓。本節(jié)以Google 的相關(guān)技術(shù)介紹為主線,詳細(xì)介紹Google 以及其他眾多學(xué)者和研究機(jī)構(gòu)在大數(shù)據(jù)技術(shù)方面已有的一些工作。根據(jù)Google 已公開的論文及相關(guān)資料,結(jié)合大數(shù)據(jù)處理的需求,我們對(duì)Google 的技術(shù)演化進(jìn)行了整理,如圖4所示:
圖 4 Google 技術(shù)演化圖
4.1.1 文件系統(tǒng)
文件系統(tǒng)是支撐上層應(yīng)用的基礎(chǔ)。在Google 之前,尚未有哪個(gè)公司面對(duì)過如此多的海量數(shù)據(jù)。因此對(duì)于Google 而言并沒有完全成熟的存儲(chǔ)方案可以直接使用。Google 認(rèn)為系統(tǒng)組件失敗是一種常態(tài)而不是異常,基于此思想Google 自行設(shè)計(jì)開發(fā)了Google 文件系統(tǒng)GFS(Google File System)。GFS 是構(gòu)建在大量廉價(jià)服務(wù)器之上的一個(gè)可擴(kuò)展的分布式文件系統(tǒng),GFS 主要針對(duì)文件較大,且讀遠(yuǎn)大于寫的應(yīng)用場(chǎng)景,采用主從(Master-Slave)結(jié)構(gòu)。通過數(shù)據(jù)分塊、追加更新(Append-Only)等方式實(shí)現(xiàn)了海量數(shù)據(jù)的高效存儲(chǔ)。隨著時(shí)間推移,GFS 的架構(gòu)逐漸開始無法適應(yīng)需求。Google 對(duì)GFS 進(jìn)行了重新的設(shè)計(jì),該系統(tǒng)正式的名稱為Colosuss,具體實(shí)現(xiàn)尚未公開,但是從ACM 對(duì)GFS 團(tuán)隊(duì)核心工程師的訪談可以了解其一些新的特性。其中GFS 的單點(diǎn)故障(指僅有一個(gè)主節(jié)點(diǎn)容易成為系統(tǒng)的瓶頸)、海量小文件的存儲(chǔ)等問題在Colosuss 中均得到了解決。
除了Google,眾多企業(yè)和學(xué)者也從不同方面對(duì)滿足大數(shù)據(jù)存儲(chǔ)需求的文件系統(tǒng)進(jìn)行了詳盡的研究。微軟自行開發(fā)的Cosmos支撐著其搜索、廣告等業(yè)務(wù)。HDFS和CloudStore都是模仿GFS 的開源實(shí)現(xiàn)。GFS 類的文件系統(tǒng)主要是針對(duì)較大文件設(shè)計(jì)的,而在圖片存儲(chǔ)等應(yīng)用場(chǎng)景,文件系統(tǒng)主要存儲(chǔ)海量小文件,此時(shí)GFS 等文件系統(tǒng)因?yàn)轭l繁讀取元數(shù)據(jù)等原因,效率很低。針對(duì)這種情況,F(xiàn)acebook 推出了專門針對(duì)海量小文件的文件系統(tǒng)Haystack,通過多個(gè)邏輯文件共享同一個(gè)物理文件、增加緩存層、部分元數(shù)據(jù)加載到內(nèi)存等方式有效的解決了Facebook 海量圖片存儲(chǔ)問題。淘寶推出了類似的文件系統(tǒng)TFS(Tao File System),通過將小文件合并成大文件、文件名隱含部分元數(shù)據(jù)等方式實(shí)現(xiàn)了海量小文件的高效存儲(chǔ)。FastDFS針對(duì)小文件的優(yōu)化類似于TFS。
4.1.2 數(shù)據(jù)庫(kù)系統(tǒng)
原始的數(shù)據(jù)存儲(chǔ)在文件系統(tǒng)之中,但是用戶習(xí)慣通過數(shù)據(jù)庫(kù)系統(tǒng)來存取文件。因?yàn)檫@樣會(huì)屏蔽掉底層的細(xì)節(jié),且方便數(shù)據(jù)管理。直接采用關(guān)系模型的分布式數(shù)據(jù)庫(kù)并不能適應(yīng)大數(shù)據(jù)時(shí)代的數(shù)據(jù)存儲(chǔ),主要因?yàn)椋?/p>
1)規(guī)模效應(yīng)所帶來的壓力。大數(shù)據(jù)時(shí)代的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)超過單機(jī)所能容納的數(shù)據(jù)量,因此必須采用分布式存儲(chǔ)的方式。這就需要系統(tǒng)具有很好的擴(kuò)展性,但這恰恰是傳統(tǒng)數(shù)據(jù)庫(kù)的弱勢(shì)之一。因?yàn)閭鹘y(tǒng)的數(shù)據(jù)庫(kù)產(chǎn)品對(duì)于性能的擴(kuò)展更傾向于Scale-Up(縱向擴(kuò)展)的方式,而這種方式對(duì)于性能的增加速度遠(yuǎn)低于需要處理數(shù)據(jù)的增長(zhǎng)速度,且性能提升存在上限。適應(yīng)大數(shù)據(jù)的數(shù)據(jù)庫(kù)系統(tǒng)應(yīng)當(dāng)具有良好的Scale-Out(橫向擴(kuò)展)能力,而這種性能擴(kuò)展方式恰恰是傳統(tǒng)數(shù)據(jù)庫(kù)所不具備的。即便是性能最好的并行數(shù)據(jù)庫(kù)產(chǎn)品其Scale-Out 能力也相對(duì)有限。
2)數(shù)據(jù)類型的多樣化。傳統(tǒng)的數(shù)據(jù)庫(kù)比較適合結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ),但是數(shù)據(jù)的多樣性是大數(shù)據(jù)時(shí)代的顯著特征之一。這也就是意味著除了結(jié)構(gòu)化數(shù)據(jù),半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)也將是大數(shù)據(jù)時(shí)代的重要數(shù)據(jù)類型組成部分。如何高效的處理多種數(shù)據(jù)類型是大數(shù)據(jù)時(shí)代數(shù)據(jù)庫(kù)技術(shù)面臨的重要挑戰(zhàn)之一。
3)設(shè)計(jì)理念的沖突。關(guān)系數(shù)據(jù)庫(kù)追求的是“One size fits all”的目標(biāo),希望將用戶從繁雜的數(shù)據(jù)管理中解脫出來,在面對(duì)不同的問題時(shí)不需要重新考慮數(shù)據(jù)管理問題,從而可以將重心轉(zhuǎn)向其他的部分。但在大數(shù)據(jù)時(shí)代不同的應(yīng)用領(lǐng)域在數(shù)據(jù)類型、數(shù)據(jù)處理方式以及數(shù)據(jù)處理時(shí)間的要求上有極大的差異。在實(shí)際的處理中幾乎不可能有一種統(tǒng)一的數(shù)據(jù)存儲(chǔ)方式能夠應(yīng)對(duì)所有場(chǎng)景。比如對(duì)于海量Web 數(shù)據(jù)的處理就不可能和天文圖像數(shù)據(jù)采取同樣的處理方式。在這種情況下,很多公司開始嘗試從“One size fits one”和“One size fits domain”的設(shè)計(jì)理念出發(fā)來研究新的數(shù)據(jù)管理方式,并產(chǎn)生了一系列非常有代表性的工作。
4)數(shù)據(jù)庫(kù)事務(wù)特性。眾所周知關(guān)系數(shù)據(jù)庫(kù)中事務(wù)的正確執(zhí)行必須滿足ACID 特性,即原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。對(duì)于數(shù)據(jù)強(qiáng)一致性的嚴(yán)格要求使其在很多大數(shù)據(jù)場(chǎng)景中無法應(yīng)用。這種情況下出現(xiàn)了新的BASE 特性,即只要求滿足Basically Available(基本可用), Soft state(柔性狀態(tài))和 Eventually consistent(最終一致)。從分布式領(lǐng)域著名的CAP 理論的角度來看,ACID 追求一致性C,而BASE更加關(guān)注可用性A。正是在事務(wù)處理過程中對(duì)于ACID 特性的嚴(yán)格要求,使得關(guān)系型數(shù)據(jù)庫(kù)的可擴(kuò)展性極其有限。
面對(duì)這些挑戰(zhàn),以Google 為代表的一批技術(shù)公司紛紛推出了自己的解決方案。Bigtable是Google 早期開發(fā)的數(shù)據(jù)庫(kù)系統(tǒng),它是一個(gè)多維稀疏排序表,由行和列組成,每個(gè)存儲(chǔ)單元都有一個(gè)時(shí)間戳,形成三維結(jié)構(gòu)。不同的時(shí)間對(duì)同一個(gè)數(shù)據(jù)單元的多個(gè)操作形成的數(shù)據(jù)的多個(gè)版本之間由時(shí)間戳來區(qū)分。除了Bigtable,Amazon 的Dynamo和Yahoo 的PNUTS也都是非常具有代表性的系統(tǒng)。Dynamo 綜合使用了鍵/值存儲(chǔ)、改進(jìn)的分布式哈希表(DHT)、向量時(shí)鐘(Vector Clock)等技術(shù)實(shí)現(xiàn)了一個(gè)完全的分布式、去中心化的高可用系統(tǒng)。PNUTS是一個(gè)分布式的數(shù)據(jù)庫(kù),在設(shè)計(jì)上使用弱一致性來達(dá)到高可用性的目標(biāo),主要的服務(wù)對(duì)象是相對(duì)較小的記錄,比如在線的大量單個(gè)記錄或者小范圍記錄集合的讀和寫訪問。不適合存儲(chǔ)大文件、流媒體等。Bigtable、Dynamo、PNUTS 等的成功促使人們開始對(duì)關(guān)系數(shù)據(jù)庫(kù)進(jìn)行反思,由此產(chǎn)生了一批未采用關(guān)系模型的數(shù)據(jù)庫(kù),這些方案現(xiàn)在被統(tǒng)一的稱為NoSQL(NotOnly SQL)。NoSQL 并沒有一個(gè)準(zhǔn)確的定義,但一般認(rèn)為NoSQL 數(shù)據(jù)庫(kù)應(yīng)當(dāng)具有以下的特征:模式自由(schema-free)、支持簡(jiǎn)易備份(easy replication support)、簡(jiǎn)單的應(yīng)用程序接口(simple API)、最終一致性(或者說支持BASE 特性,不支持ACID)、支持海量數(shù)據(jù)(Huge amountof data)。NoSQL 和關(guān)系型數(shù)據(jù)庫(kù)的簡(jiǎn)單比較如表3 所示:
表3 NoSQL 數(shù)據(jù)庫(kù)和關(guān)系數(shù)據(jù)庫(kù)的對(duì)比
典型的NoSQL 數(shù)據(jù)庫(kù)分類如表4所示:
表4 典型NoSQL 數(shù)據(jù)庫(kù)
Bigtable 的模型簡(jiǎn)單,但是相較傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)其支持的功能非常有限,不支持ACID特性。因此Google 開發(fā)了Megastore]系統(tǒng),雖然其底層數(shù)據(jù)存儲(chǔ)依賴Bigtable,但是它實(shí)現(xiàn)了類似RDBMS 的數(shù)據(jù)模型,同時(shí)提供數(shù)據(jù)的強(qiáng)一致性解決方案。Megastore 將數(shù)據(jù)進(jìn)行細(xì)粒度的分區(qū),數(shù)據(jù)更新會(huì)在機(jī)房間進(jìn)行同步復(fù)制。Spanner是已知的Google 的最新的數(shù)據(jù)庫(kù)系統(tǒng),Google 在OSDI2012 上公開了Spanner 的實(shí)現(xiàn)。Spanner 是第一個(gè)可以實(shí)現(xiàn)全球規(guī)模擴(kuò)展(Global Scale)并且支持外部一致的事務(wù)(support externally-consistent distributedtransactions)的數(shù)據(jù)庫(kù)。通過GPS 和原子時(shí)鐘(atomic clocks)技術(shù),Spanner 實(shí)現(xiàn)了一個(gè)時(shí)間API。借助該API,數(shù)據(jù)中心之間的時(shí)間同步能夠精確到10ms 以內(nèi)。Spanner 類似于Bigtable,但是它具有層次性的目錄結(jié)構(gòu)以及細(xì)粒度的數(shù)據(jù)復(fù)制。對(duì)于數(shù)據(jù)中心之間不同操作會(huì)分別支持強(qiáng)一致性或弱一致性,且支持更多的自動(dòng)操作。Spanner 的目標(biāo)是控制一百萬到一千萬臺(tái)服務(wù)器,最多包含大約10萬億目錄和一千萬億字節(jié)的存儲(chǔ)空間。另外在SIGMOD2012上,Google 公開了用于其廣告系統(tǒng)的新數(shù)據(jù)庫(kù)產(chǎn)品F1,作為一種混合型數(shù)據(jù)庫(kù)F1 融合兼有Bigtable的高擴(kuò)展性以及SQL數(shù)據(jù)庫(kù)的可用性和功能性。該產(chǎn)品的底層存儲(chǔ)正是采用Spanner,具有很多新的特性,包括全局分布式、同步跨數(shù)據(jù)中心復(fù)制、可視分片和數(shù)據(jù)移動(dòng)、常規(guī)事務(wù)等。
有些比較激進(jìn)的觀點(diǎn)認(rèn)為“關(guān)系數(shù)據(jù)庫(kù)已死”,我們認(rèn)為關(guān)系數(shù)據(jù)庫(kù)和NoSQL 并不是矛盾的對(duì)立體,而是可以相互補(bǔ)充的、適用于不同應(yīng)用場(chǎng)景的技術(shù)。例如實(shí)際的互聯(lián)網(wǎng)系統(tǒng)往往都是ACID 和BASE 兩種系統(tǒng)的結(jié)合。近些年來,以Spanner 為代表的若干新型數(shù)據(jù)庫(kù)的出現(xiàn),給數(shù)據(jù)存儲(chǔ)帶來了SQL、NoSQL 之外的新思路。這種融合了一致性和可用性的NewSQL 或許會(huì)是未來大數(shù)據(jù)存儲(chǔ)新的發(fā)展方向。
4.1.3 索引與查詢技術(shù)
數(shù)據(jù)查詢是數(shù)據(jù)庫(kù)最重要的應(yīng)用之一。而索引則是解決數(shù)據(jù)查詢問題的有效方案。就Google 自身而言,索引的構(gòu)建是提供搜索服務(wù)的關(guān)鍵部分。Google 最早的索引系統(tǒng)是利用MapReduce 來更新的。根據(jù)更新頻率進(jìn)行層次劃分,不同的層次對(duì)應(yīng)不同的更新頻率。每次需要批量更新索引,即使有些數(shù)據(jù)并未改變也需要處理掉。這種索引更新方式效率較低。隨后Google 提出了Percolator,這是一種增量式的索引更新器,每次更新不需要替換所有的索引數(shù)據(jù),效率大大提高。雖然不是所有的大數(shù)據(jù)應(yīng)用都需要索引,但是這種增量計(jì)算的思想非常值得我們借鑒。Google 當(dāng)前正在使用的索引系統(tǒng)為Caffeine,其具體實(shí)現(xiàn)尚未公布。但是可以確定Caffeine 是構(gòu)建在Spanner 之上,采用Percolator 更新索引。效率相較上一代索引系統(tǒng)而言有大幅度提高。
關(guān)系數(shù)據(jù)庫(kù)也是利用對(duì)數(shù)據(jù)構(gòu)建索引的方式較好的解決了數(shù)據(jù)查詢的問題。不同的索引方案使得關(guān)系數(shù)據(jù)庫(kù)可以滿足不同場(chǎng)景的要求。索引的建立以及更新都會(huì)耗費(fèi)較多的時(shí)間,在面對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)的小數(shù)據(jù)量時(shí)這些時(shí)間和其所帶來的查詢便利性相比是可以接受的,但是這些復(fù)雜的索引方案基本無法直接應(yīng)用到大數(shù)據(jù)之上。表5是對(duì)一些索引方案直接應(yīng)用在Facebook 上的性能估計(jì):
表5 查詢索引的案例
從上表可以看出不太可能將已有的成熟索引方案直接應(yīng)用于大數(shù)據(jù)。NoSQL 數(shù)據(jù)庫(kù)針對(duì)主鍵的查詢效率一般較高,因此有關(guān)的研究集中在NoSQL 數(shù)據(jù)庫(kù)的多值查詢優(yōu)化上。針對(duì)NoSQL 數(shù)據(jù)庫(kù)上的查詢優(yōu)化研究主要有兩種思路:
1、采用MapReduce 并行技術(shù)優(yōu)化多值查詢:當(dāng)利用MapReduce 并行查詢NoSQL 數(shù)據(jù)庫(kù)時(shí),每個(gè)MapTask 處理一部分的查詢操作,通過實(shí)現(xiàn)多個(gè)部分之間的并行查詢來提高多值查詢的效率。此時(shí)每個(gè)部分的內(nèi)部仍舊需要進(jìn)行數(shù)據(jù)的全掃描。
2、采用索引技術(shù)優(yōu)化多值查詢:很多的研究工作嘗試從添加多維索引的角度來加速NoSQL 數(shù)據(jù)庫(kù)的查詢速度。表6 列舉了已有的一些解決方案的對(duì)比。
表6 采用索引加速多值查詢的方案對(duì)比
ITHbase、IHbase、CCIndex和Asynchronous views是典型的采用多個(gè)一維二級(jí)索引來加速多值查詢優(yōu)化的實(shí)現(xiàn)方案。其中ITHbase 和IHbase 是兩個(gè)開源的實(shí)現(xiàn)方案,ITHbase 主要關(guān)注于數(shù)據(jù)一致性,事務(wù)性是其重要特性。IHbase與ITHbase類似,從HBase 源碼級(jí)別進(jìn)行了擴(kuò)展,重新定義和實(shí)現(xiàn)了Server、Client 端處理邏輯。CCIndex (ComplementalClustering Index)是中科院提出的另外一種索引結(jié)構(gòu),它在索引中既存儲(chǔ)索引項(xiàng),也存儲(chǔ)記錄的其他列的數(shù)據(jù),以便在查詢的時(shí)候直接在索引表中通過順序掃描找到相應(yīng)的數(shù)據(jù),大幅度減少查詢時(shí)間。該方法本質(zhì)是以空間代價(jià)來?yè)Q取查詢效率。CCIndex 的索引更新代價(jià)比較高,會(huì)影響系統(tǒng)的吞吐量。索引創(chuàng)建以后,不能夠動(dòng)態(tài)增加或修改。Asynchronous views 以異步視圖的方式來實(shí)現(xiàn)非主鍵的查詢,提出了兩種視圖方案:遠(yuǎn)端視圖表(Remote ViewTables: RVTs)和局部視圖表(Local View Tables: LVTs)。
RT-CAN采用多維索引加速多值查詢。其局部索引采用R-tree,全局索引中采用了能夠支持多維查詢的CAN覆蓋網(wǎng)絡(luò)。QT-Chord是另一種雙層索引結(jié)構(gòu),它的局部索引采用的是改進(jìn)的四叉樹IMX-CIF quad-tree,全局索引采用的Chord 覆蓋網(wǎng)絡(luò)。EMINC[56]針對(duì)每個(gè)局部節(jié)點(diǎn)建立一個(gè)KD-tree,然后選擇KD-tree 的部分節(jié)點(diǎn)作為全局索引。每一個(gè)局部索引節(jié)點(diǎn)被看成是一個(gè)多個(gè)維度組成的立方體,然后在全局索引中用R-tree 對(duì)這些立方體進(jìn)行索引。A-Tree提出了另外一種方案;舅悸肥牵横槍(duì)每一個(gè)存儲(chǔ)節(jié)點(diǎn)構(gòu)建R-tree,同時(shí)創(chuàng)建一個(gè)Bloom filter(布隆過濾器)。這樣在進(jìn)行點(diǎn)查詢的時(shí)候,首先通過Bloom filter進(jìn)行驗(yàn)證,如果查詢點(diǎn)不在其中,則不再進(jìn)行R-tree 查詢,否則繼續(xù)進(jìn)行R-tree查詢。
MD-HBase提出一種基于空間目標(biāo)排序的索引方案;诳臻g目標(biāo)排序的索引方法的基本思想是:按照一定規(guī)則將覆蓋整個(gè)研究區(qū)的范圍劃分為大小相等的格子,并給每一格網(wǎng)分配一個(gè)編號(hào),用這些編號(hào)為空間目標(biāo)生成一組具有代表意義的數(shù)字。其實(shí)質(zhì)是將k 維空間的實(shí)體映射到一維空間,因此可以利用現(xiàn)有數(shù)據(jù)庫(kù)管理系統(tǒng)中比較成熟的一維索引技術(shù)。UQE-Index主要針對(duì)海量物聯(lián)網(wǎng)應(yīng)用場(chǎng)景的時(shí)空特性,在時(shí)間維度上把數(shù)據(jù)分成當(dāng)前數(shù)據(jù)和歷史數(shù)據(jù),對(duì)當(dāng)前數(shù)據(jù)和歷史數(shù)據(jù)進(jìn)行不同粒度的索引,對(duì)當(dāng)前數(shù)據(jù),在時(shí)間段和子空間上進(jìn)行索引,從而減少索引更新的次數(shù),降低索引維護(hù)的代價(jià),提高系統(tǒng)的吞吐量;對(duì)歷史數(shù)據(jù),批量地建立記錄級(jí)別的索引;在建立子空間索引時(shí),為了確保數(shù)據(jù)分布均勻,采用KD Tree進(jìn)行動(dòng)態(tài)劃分。但是如果所有的數(shù)據(jù)都需要經(jīng)過KD Tree來索引的話,也會(huì)帶來較高的代價(jià),會(huì)影響數(shù)據(jù)的插入速度,因此,可以對(duì)數(shù)據(jù)進(jìn)行采樣,對(duì)采樣得到的數(shù)據(jù)利用KD Tree進(jìn)行索引,從而得到空間上的劃分方案。
就已有方案來看,針對(duì)NoSQL 數(shù)據(jù)庫(kù)上的查詢優(yōu)化技術(shù)都并不成熟,仍有很多關(guān)鍵性問題亟待解決。
核心關(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.ezxoed.cn/
本文標(biāo)題:大數(shù)據(jù)管理:概念、技術(shù)與挑戰(zhàn)(中)
本文網(wǎng)址:http://www.ezxoed.cn/html/support/1112189698.html