3.2.1 數(shù)據(jù)抽取與集成

    大數(shù)據(jù)的一個重要特點就是多樣性，這就意味著數(shù)據(jù)來源極其廣泛，數(shù)據(jù)類型極為繁雜。這種復雜的數(shù)據(jù)環(huán)境給大數(shù)據(jù)的處理帶來極大的挑戰(zhàn)。要想處理大數(shù)據(jù)，首先必須對所需數(shù)據(jù)源的數(shù)據(jù)進行抽取和集成，從中提取出關(guān)系和實體，經(jīng)過關(guān)聯(lián)和聚合之后采用統(tǒng)一定義的結(jié)構(gòu)來存儲這些數(shù)據(jù)。在數(shù)據(jù)集成和提取時需要對數(shù)據(jù)進行清洗，保證數(shù)據(jù)質(zhì)量及可信性。同時還要特別注意前面提及的大數(shù)據(jù)時代模式和數(shù)據(jù)的關(guān)系，大數(shù)據(jù)時代的數(shù)據(jù)往往是先有數(shù)據(jù)再有模式，且模式是在不斷的動態(tài)演化之中的。

    數(shù)據(jù)抽取和集成技術(shù)不是一項全新的技術(shù)，傳統(tǒng)數(shù)據(jù)庫領域已對此問題有了比較成熟的研究。隨著新的數(shù)據(jù)源的涌現(xiàn)，數(shù)據(jù)集成方法也在不斷的發(fā)展之中。從數(shù)據(jù)集成模型來看，現(xiàn)有的數(shù)據(jù)抽取與集成方式可以大致分為以下四種類型：基于物化或是ETL 方法的引擎(Materialization or ETL engine)、基于聯(lián)邦數(shù)據(jù)庫或中間件方法的引擎(Federation engine orMediator)、基于數(shù)據(jù)流方法的引擎(Stream engine)及 基于搜索引擎的方法(Search engine)。

    3.2.2 數(shù)據(jù)分析

    數(shù)據(jù)分析是整個大數(shù)據(jù)處理流程的核心，因為大數(shù)據(jù)的價值產(chǎn)生于分析過程。從異構(gòu)數(shù)據(jù)源抽取和集成的數(shù)據(jù)構(gòu)成了數(shù)據(jù)分析的原始數(shù)據(jù)。根據(jù)不同應用的需求可以從這些數(shù)據(jù)中選擇全部或部分進行分析。傳統(tǒng)的分析技術(shù)如數(shù)據(jù)挖掘、機器學習、統(tǒng)計分析等在大數(shù)據(jù)時代需要做出調(diào)整，因為這些技術(shù)在大數(shù)據(jù)時代面臨著一些新的挑戰(zhàn)，主要有：

    1、數(shù)據(jù)量大并不一定意味著數(shù)據(jù)價值的增加，相反這往往意味著數(shù)據(jù)噪音的增多。因此在數(shù)據(jù)分析之前必須進行數(shù)據(jù)清洗等預處理工作，但是預處理如此大量的數(shù)據(jù)對于機器硬件以及算法都是嚴峻的考驗。

    2、大數(shù)據(jù)時代的算法需要進行調(diào)整。首先大數(shù)據(jù)的應用常常具有實時性的特點，算法的準確率不再是大數(shù)據(jù)應用的最主要指標。很多場景中算法需要在處理的實時性和準確率之間取得一個平衡，比如在線的機器學習算法(online machine learning)。其次云計算是進行大數(shù)據(jù)處理的有力工具，這就要求很多算法必須做出調(diào)整以適應云計算的框架，算法需要變得具有可擴展性。最后在選擇算法處理大數(shù)據(jù)時必須謹慎，當數(shù)據(jù)量增長到一定規(guī)模以后，可以從小量數(shù)據(jù)中挖掘出有效信息的算法并一定適用于大數(shù)據(jù)。統(tǒng)計學中的邦弗朗尼原理(Bonferroni’s Principle)就是一個典型的例子。

    3、數(shù)據(jù)結(jié)果好壞的衡量。得到分析結(jié)果并不難，但是結(jié)果好壞的衡量卻是大數(shù)據(jù)時代數(shù)據(jù)分析的新挑戰(zhàn)。大數(shù)據(jù)時代的數(shù)據(jù)量大、類型龐雜，進行分析的時候往往對整個數(shù)據(jù)的分布特點掌握的不太清楚，這會導致最后在設計衡量的方法以及指標的時候遇到諸多困難。大數(shù)據(jù)分析已被廣泛應用于諸多領域，典型的有推薦系統(tǒng)、商業(yè)智能、決策支持等。

    3.2.3 數(shù)據(jù)解釋

    數(shù)據(jù)分析是大數(shù)據(jù)處理的核心，但是用戶往往更關(guān)心結(jié)果的展示。如果分析的結(jié)果正確但是沒有采用適當?shù)慕忉尫椒�，則所得到的結(jié)果很可能讓用戶難以理解，極端情況下甚至會誤導用戶。數(shù)據(jù)解釋的方法很多，比較傳統(tǒng)的就是以文本形式輸出結(jié)果或者直接在電腦終端上顯示結(jié)果。這種方法在面對小數(shù)據(jù)量時是一種很好的選擇。但是大數(shù)據(jù)時代的數(shù)據(jù)分析結(jié)果往往也是海量的，同時結(jié)果之間的關(guān)聯(lián)關(guān)系極其復雜，采用傳統(tǒng)的解釋方法基本不可行。

    可以考慮從下面兩個方面提升數(shù)據(jù)解釋能力。

    1、引入可視化技術(shù)。可視化作為解釋大量數(shù)據(jù)最有效的手段之一率先被科學與工程計算領域采用。通過對分析結(jié)果的可視化用形象的方式向用戶展示結(jié)果，而且圖形化的方式比文字更易理解和接受。常見的可視化技術(shù)有標簽云(Tag Cloud)、歷史流(history flow)、空間信息流(Spatial information flow)等�？梢愿鶕�(jù)具體的應用需要選擇合適的可視化技術(shù)。

    2、讓用戶能夠在一定程度上了解和參與具體的分析過程。這個既可以采用人機交互技術(shù)，利用交互式的數(shù)據(jù)分析過程來引導用戶逐步的進行分析，使得用戶在得到結(jié)果的同時更好的理解分析結(jié)果的由來。也可以采用數(shù)據(jù)起源技術(shù)，通過該技術(shù)可以幫助追溯整個數(shù)據(jù)分析的過程，有助于用戶理解結(jié)果。

4、關(guān)鍵技術(shù)分析

    大數(shù)據(jù)價值的完整體現(xiàn)需要多種技術(shù)的協(xié)同。文件系統(tǒng)提供最底層存儲能力的支持。為了便于數(shù)據(jù)管理，需要在文件系統(tǒng)之上建立數(shù)據(jù)庫系統(tǒng)。通過索引等的構(gòu)建，對外提供高效的數(shù)據(jù)查詢等常用功能。最終通過數(shù)據(jù)分析技術(shù)從數(shù)據(jù)庫中的大數(shù)據(jù)提取出有益的知識。

    4.1 云計算：大數(shù)據(jù)的基礎平臺與支撐技術(shù)

    如果將各種大數(shù)據(jù)的應用比作一輛輛“汽車”的話，支撐起這些“汽車”運行的“高速公路”就是云計算。正是云計算技術(shù)在數(shù)據(jù)存儲、管理與分析等方面的支撐，才使得大數(shù)據(jù)有用武之地。

    在所有的“高速公路”中，Google 無疑是技術(shù)最為先進的一個。需求推動創(chuàng)新，面對海量的Web 數(shù)據(jù)， Google 于2006 年首先提出了云計算的概念。支撐Google 內(nèi)部各種大數(shù)據(jù)應用的正是其自行研發(fā)的一系列云計算技術(shù)和工具。難能可貴的是Google 并未將這些技術(shù)完全封閉，而是以論文的形式逐步公開其實現(xiàn)。正是這些公開的論文，使得以GFS、MapReduce、Bigtable 為代表的一系列大數(shù)據(jù)處理技術(shù)被廣泛了解并得到應用，同時還催生出以Hadoop為代表的一系列云計算開源工具。云計算技術(shù)很多，但是通過Google 云計算技術(shù)的介紹能夠快速、完整的把握云計算技術(shù)的核心和精髓。本節(jié)以Google 的相關(guān)技術(shù)介紹為主線，詳細介紹Google 以及其他眾多學者和研究機構(gòu)在大數(shù)據(jù)技術(shù)方面已有的一些工作。根據(jù)Google 已公開的論文及相關(guān)資料，結(jié)合大數(shù)據(jù)處理的需求，我們對Google 的技術(shù)演化進行了整理，如圖4所示：

圖 4 Google 技術(shù)演化圖

    4.1.1 文件系統(tǒng)

    文件系統(tǒng)是支撐上層應用的基礎。在Google 之前，尚未有哪個公司面對過如此多的海量數(shù)據(jù)。因此對于Google 而言并沒有完全成熟的存儲方案可以直接使用。Google 認為系統(tǒng)組件失敗是一種常態(tài)而不是異常，基于此思想Google 自行設計開發(fā)了Google 文件系統(tǒng)GFS(Google File System)。GFS 是構(gòu)建在大量廉價服務器之上的一個可擴展的分布式文件系統(tǒng)，GFS 主要針對文件較大，且讀遠大于寫的應用場景，采用主從(Master-Slave)結(jié)構(gòu)。通過數(shù)據(jù)分塊、追加更新(Append-Only)等方式實現(xiàn)了海量數(shù)據(jù)的高效存儲。隨著時間推移，GFS 的架構(gòu)逐漸開始無法適應需求。Google 對GFS 進行了重新的設計，該系統(tǒng)正式的名稱為Colosuss，具體實現(xiàn)尚未公開，但是從ACM 對GFS 團隊核心工程師的訪談可以了解其一些新的特性。其中GFS 的單點故障(指僅有一個主節(jié)點容易成為系統(tǒng)的瓶頸)、海量小文件的存儲等問題在Colosuss 中均得到了解決。

    除了Google，眾多企業(yè)和學者也從不同方面對滿足大數(shù)據(jù)存儲需求的文件系統(tǒng)進行了詳盡的研究。微軟自行開發(fā)的Cosmos支撐著其搜索、廣告等業(yè)務。HDFS和CloudStore都是模仿GFS 的開源實現(xiàn)。GFS 類的文件系統(tǒng)主要是針對較大文件設計的，而在圖片存儲等應用場景，文件系統(tǒng)主要存儲海量小文件，此時GFS 等文件系統(tǒng)因為頻繁讀取元數(shù)據(jù)等原因，效率很低。針對這種情況，F(xiàn)acebook 推出了專門針對海量小文件的文件系統(tǒng)Haystack，通過多個邏輯文件共享同一個物理文件、增加緩存層、部分元數(shù)據(jù)加載到內(nèi)存等方式有效的解決了Facebook 海量圖片存儲問題。淘寶推出了類似的文件系統(tǒng)TFS(Tao File System)，通過將小文件合并成大文件、文件名隱含部分元數(shù)據(jù)等方式實現(xiàn)了海量小文件的高效存儲。FastDFS針對小文件的優(yōu)化類似于TFS。

    4.1.2 數(shù)據(jù)庫系統(tǒng)

    原始的數(shù)據(jù)存儲在文件系統(tǒng)之中，但是用戶習慣通過數(shù)據(jù)庫系統(tǒng)來存取文件。因為這樣會屏蔽掉底層的細節(jié)，且方便數(shù)據(jù)管理。直接采用關(guān)系模型的分布式數(shù)據(jù)庫并不能適應大數(shù)據(jù)時代的數(shù)據(jù)存儲，主要因為：

    1)規(guī)模效應所帶來的壓力。大數(shù)據(jù)時代的數(shù)據(jù)量遠遠超過單機所能容納的數(shù)據(jù)量，因此必須采用分布式存儲的方式。這就需要系統(tǒng)具有很好的擴展性，但這恰恰是傳統(tǒng)數(shù)據(jù)庫的弱勢之一。因為傳統(tǒng)的數(shù)據(jù)庫產(chǎn)品對于性能的擴展更傾向于Scale-Up(縱向擴展)的方式，而這種方式對于性能的增加速度遠低于需要處理數(shù)據(jù)的增長速度，且性能提升存在上限。適應大數(shù)據(jù)的數(shù)據(jù)庫系統(tǒng)應當具有良好的Scale-Out(橫向擴展)能力，而這種性能擴展方式恰恰是傳統(tǒng)數(shù)據(jù)庫所不具備的。即便是性能最好的并行數(shù)據(jù)庫產(chǎn)品其Scale-Out 能力也相對有限。

    2)數(shù)據(jù)類型的多樣化。傳統(tǒng)的數(shù)據(jù)庫比較適合結(jié)構(gòu)化數(shù)據(jù)的存儲，但是數(shù)據(jù)的多樣性是大數(shù)據(jù)時代的顯著特征之一。這也就是意味著除了結(jié)構(gòu)化數(shù)據(jù)，半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)也將是大數(shù)據(jù)時代的重要數(shù)據(jù)類型組成部分。如何高效的處理多種數(shù)據(jù)類型是大數(shù)據(jù)時代數(shù)據(jù)庫技術(shù)面臨的重要挑戰(zhàn)之一。

    3)設計理念的沖突。關(guān)系數(shù)據(jù)庫追求的是“One size fits all”的目標，希望將用戶從繁雜的數(shù)據(jù)管理中解脫出來，在面對不同的問題時不需要重新考慮數(shù)據(jù)管理問題，從而可以將重心轉(zhuǎn)向其他的部分。但在大數(shù)據(jù)時代不同的應用領域在數(shù)據(jù)類型、數(shù)據(jù)處理方式以及數(shù)據(jù)處理時間的要求上有極大的差異。在實際的處理中幾乎不可能有一種統(tǒng)一的數(shù)據(jù)存儲方式能夠應對所有場景。比如對于海量Web 數(shù)據(jù)的處理就不可能和天文圖像數(shù)據(jù)采取同樣的處理方式。在這種情況下，很多公司開始嘗試從“One size fits one”和“One size fits domain”的設計理念出發(fā)來研究新的數(shù)據(jù)管理方式，并產(chǎn)生了一系列非常有代表性的工作。

    4)數(shù)據(jù)庫事務特性。眾所周知關(guān)系數(shù)據(jù)庫中事務的正確執(zhí)行必須滿足ACID 特性，即原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。對于數(shù)據(jù)強一致性的嚴格要求使其在很多大數(shù)據(jù)場景中無法應用。這種情況下出現(xiàn)了新的BASE 特性，即只要求滿足Basically Available(基本可用), Soft state(柔性狀態(tài))和 Eventually consistent(最終一致)。從分布式領域著名的CAP 理論的角度來看，ACID 追求一致性C，而BASE更加關(guān)注可用性A。正是在事務處理過程中對于ACID 特性的嚴格要求，使得關(guān)系型數(shù)據(jù)庫的可擴展性極其有限。

    面對這些挑戰(zhàn)，以Google 為代表的一批技術(shù)公司紛紛推出了自己的解決方案。Bigtable是Google 早期開發(fā)的數(shù)據(jù)庫系統(tǒng)，它是一個多維稀疏排序表，由行和列組成，每個存儲單元都有一個時間戳，形成三維結(jié)構(gòu)。不同的時間對同一個數(shù)據(jù)單元的多個操作形成的數(shù)據(jù)的多個版本之間由時間戳來區(qū)分。除了Bigtable，Amazon 的Dynamo和Yahoo 的PNUTS也都是非常具有代表性的系統(tǒng)。Dynamo 綜合使用了鍵/值存儲、改進的分布式哈希表(DHT)、向量時鐘(Vector Clock)等技術(shù)實現(xiàn)了一個完全的分布式、去中心化的高可用系統(tǒng)。PNUTS是一個分布式的數(shù)據(jù)庫，在設計上使用弱一致性來達到高可用性的目標，主要的服務對象是相對較小的記錄，比如在線的大量單個記錄或者小范圍記錄集合的讀和寫訪問。不適合存儲大文件、流媒體等。Bigtable、Dynamo、PNUTS 等的成功促使人們開始對關(guān)系數(shù)據(jù)庫進行反思，由此產(chǎn)生了一批未采用關(guān)系模型的數(shù)據(jù)庫，這些方案現(xiàn)在被統(tǒng)一的稱為NoSQL(NotOnly SQL)。NoSQL 并沒有一個準確的定義，但一般認為NoSQL 數(shù)據(jù)庫應當具有以下的特征：模式自由(schema-free)、支持簡易備份(easy replication support)、簡單的應用程序接口(simple API)、最終一致性(或者說支持BASE 特性，不支持ACID)、支持海量數(shù)據(jù)(Huge amountof data)。NoSQL 和關(guān)系型數(shù)據(jù)庫的簡單比較如表3 所示：

表3 NoSQL 數(shù)據(jù)庫和關(guān)系數(shù)據(jù)庫的對比

    典型的NoSQL 數(shù)據(jù)庫分類如表4所示：

表4 典型NoSQL 數(shù)據(jù)庫

    Bigtable 的模型簡單，但是相較傳統(tǒng)的關(guān)系數(shù)據(jù)庫其支持的功能非常有限，不支持ACID特性。因此Google 開發(fā)了Megastore]系統(tǒng)，雖然其底層數(shù)據(jù)存儲依賴Bigtable，但是它實現(xiàn)了類似RDBMS 的數(shù)據(jù)模型，同時提供數(shù)據(jù)的強一致性解決方案。Megastore 將數(shù)據(jù)進行細粒度的分區(qū)，數(shù)據(jù)更新會在機房間進行同步復制。Spanner是已知的Google 的最新的數(shù)據(jù)庫系統(tǒng)，Google 在OSDI2012 上公開了Spanner 的實現(xiàn)。Spanner 是第一個可以實現(xiàn)全球規(guī)模擴展(Global Scale)并且支持外部一致的事務(support externally-consistent distributedtransactions)的數(shù)據(jù)庫。通過GPS 和原子時鐘(atomic clocks)技術(shù)，Spanner 實現(xiàn)了一個時間API。借助該API，數(shù)據(jù)中心之間的時間同步能夠精確到10ms 以內(nèi)。Spanner 類似于Bigtable，但是它具有層次性的目錄結(jié)構(gòu)以及細粒度的數(shù)據(jù)復制。對于數(shù)據(jù)中心之間不同操作會分別支持強一致性或弱一致性，且支持更多的自動操作。Spanner 的目標是控制一百萬到一千萬臺服務器，最多包含大約10萬億目錄和一千萬億字節(jié)的存儲空間。另外在SIGMOD2012上，Google 公開了用于其廣告系統(tǒng)的新數(shù)據(jù)庫產(chǎn)品F1，作為一種混合型數(shù)據(jù)庫F1 融合兼有Bigtable的高擴展性以及SQL數(shù)據(jù)庫的可用性和功能性。該產(chǎn)品的底層存儲正是采用Spanner，具有很多新的特性，包括全局分布式、同步跨數(shù)據(jù)中心復制、可視分片和數(shù)據(jù)移動、常規(guī)事務等。

    有些比較激進的觀點認為“關(guān)系數(shù)據(jù)庫已死”，我們認為關(guān)系數(shù)據(jù)庫和NoSQL 并不是矛盾的對立體，而是可以相互補充的、適用于不同應用場景的技術(shù)。例如實際的互聯(lián)網(wǎng)系統(tǒng)往往都是ACID 和BASE 兩種系統(tǒng)的結(jié)合。近些年來，以Spanner 為代表的若干新型數(shù)據(jù)庫的出現(xiàn)，給數(shù)據(jù)存儲帶來了SQL、NoSQL 之外的新思路。這種融合了一致性和可用性的NewSQL 或許會是未來大數(shù)據(jù)存儲新的發(fā)展方向。

    4.1.3 索引與查詢技術(shù)

    數(shù)據(jù)查詢是數(shù)據(jù)庫最重要的應用之一。而索引則是解決數(shù)據(jù)查詢問題的有效方案。就Google 自身而言，索引的構(gòu)建是提供搜索服務的關(guān)鍵部分。Google 最早的索引系統(tǒng)是利用MapReduce 來更新的。根據(jù)更新頻率進行層次劃分，不同的層次對應不同的更新頻率。每次需要批量更新索引，即使有些數(shù)據(jù)并未改變也需要處理掉。這種索引更新方式效率較低。隨后Google 提出了Percolator，這是一種增量式的索引更新器，每次更新不需要替換所有的索引數(shù)據(jù)，效率大大提高。雖然不是所有的大數(shù)據(jù)應用都需要索引，但是這種增量計算的思想非常值得我們借鑒。Google 當前正在使用的索引系統(tǒng)為Caffeine，其具體實現(xiàn)尚未公布。但是可以確定Caffeine 是構(gòu)建在Spanner 之上，采用Percolator 更新索引。效率相較上一代索引系統(tǒng)而言有大幅度提高。

    關(guān)系數(shù)據(jù)庫也是利用對數(shù)據(jù)構(gòu)建索引的方式較好的解決了數(shù)據(jù)查詢的問題。不同的索引方案使得關(guān)系數(shù)據(jù)庫可以滿足不同場景的要求。索引的建立以及更新都會耗費較多的時間，在面對傳統(tǒng)數(shù)據(jù)庫的小數(shù)據(jù)量時這些時間和其所帶來的查詢便利性相比是可以接受的，但是這些復雜的索引方案基本無法直接應用到大數(shù)據(jù)之上。表5是對一些索引方案直接應用在Facebook 上的性能估計：

表5 查詢索引的案例

    從上表可以看出不太可能將已有的成熟索引方案直接應用于大數(shù)據(jù)。NoSQL 數(shù)據(jù)庫針對主鍵的查詢效率一般較高，因此有關(guān)的研究集中在NoSQL 數(shù)據(jù)庫的多值查詢優(yōu)化上。針對NoSQL 數(shù)據(jù)庫上的查詢優(yōu)化研究主要有兩種思路：

    1、采用MapReduce 并行技術(shù)優(yōu)化多值查詢：當利用MapReduce 并行查詢NoSQL 數(shù)據(jù)庫時，每個MapTask 處理一部分的查詢操作，通過實現(xiàn)多個部分之間的并行查詢來提高多值查詢的效率。此時每個部分的內(nèi)部仍舊需要進行數(shù)據(jù)的全掃描。

    2、采用索引技術(shù)優(yōu)化多值查詢：很多的研究工作嘗試從添加多維索引的角度來加速NoSQL 數(shù)據(jù)庫的查詢速度。表6 列舉了已有的一些解決方案的對比。

表6 采用索引加速多值查詢的方案對比

    ITHbase、IHbase、CCIndex和Asynchronous views是典型的采用多個一維二級索引來加速多值查詢優(yōu)化的實現(xiàn)方案。其中ITHbase 和IHbase 是兩個開源的實現(xiàn)方案，ITHbase 主要關(guān)注于數(shù)據(jù)一致性，事務性是其重要特性。IHbase與ITHbase類似，從HBase 源碼級別進行了擴展，重新定義和實現(xiàn)了Server、Client 端處理邏輯。CCIndex (ComplementalClustering Index)是中科院提出的另外一種索引結(jié)構(gòu)，它在索引中既存儲索引項，也存儲記錄的其他列的數(shù)據(jù)，以便在查詢的時候直接在索引表中通過順序掃描找到相應的數(shù)據(jù)，大幅度減少查詢時間。該方法本質(zhì)是以空間代價來換取查詢效率。CCIndex 的索引更新代價比較高，會影響系統(tǒng)的吞吐量。索引創(chuàng)建以后，不能夠動態(tài)增加或修改。Asynchronous views 以異步視圖的方式來實現(xiàn)非主鍵的查詢，提出了兩種視圖方案：遠端視圖表(Remote ViewTables: RVTs)和局部視圖表(Local View Tables: LVTs)。

    RT-CAN采用多維索引加速多值查詢。其局部索引采用R-tree，全局索引中采用了能夠支持多維查詢的CAN覆蓋網(wǎng)絡。QT-Chord是另一種雙層索引結(jié)構(gòu)，它的局部索引采用的是改進的四叉樹IMX-CIF quad-tree，全局索引采用的Chord 覆蓋網(wǎng)絡。EMINC[56]針對每個局部節(jié)點建立一個KD-tree，然后選擇KD-tree 的部分節(jié)點作為全局索引。每一個局部索引節(jié)點被看成是一個多個維度組成的立方體，然后在全局索引中用R-tree 對這些立方體進行索引。A-Tree提出了另外一種方案�；�本思路是：針對每一個存儲節(jié)點構(gòu)建R-tree，同時創(chuàng)建一個Bloom filter(布隆過濾器)。這樣在進行點查詢的時候，首先通過Bloom filter進行驗證，如果查詢點不在其中，則不再進行R-tree 查詢，否則繼續(xù)進行R-tree查詢。

    MD-HBase提出一種基于空間目標排序的索引方案�；�于空間目標排序的索引方法的基本思想是：按照一定規(guī)則將覆蓋整個研究區(qū)的范圍劃分為大小相等的格子，并給每一格網(wǎng)分配一個編號，用這些編號為空間目標生成一組具有代表意義的數(shù)字。其實質(zhì)是將k 維空間的實體映射到一維空間，因此可以利用現(xiàn)有數(shù)據(jù)庫管理系統(tǒng)中比較成熟的一維索引技術(shù)。UQE-Index主要針對海量物聯(lián)網(wǎng)應用場景的時空特性，在時間維度上把數(shù)據(jù)分成當前數(shù)據(jù)和歷史數(shù)據(jù)，對當前數(shù)據(jù)和歷史數(shù)據(jù)進行不同粒度的索引，對當前數(shù)據(jù)，在時間段和子空間上進行索引，從而減少索引更新的次數(shù)，降低索引維護的代價，提高系統(tǒng)的吞吐量；對歷史數(shù)據(jù)，批量地建立記錄級別的索引；在建立子空間索引時，為了確保數(shù)據(jù)分布均勻，采用KD Tree進行動態(tài)劃分。但是如果所有的數(shù)據(jù)都需要經(jīng)過KD Tree來索引的話，也會帶來較高的代價，會影響數(shù)據(jù)的插入速度，因此，可以對數(shù)據(jù)進行采樣，對采樣得到的數(shù)據(jù)利用KD Tree進行索引，從而得到空間上的劃分方案。

    就已有方案來看，針對NoSQL 數(shù)據(jù)庫上的查詢優(yōu)化技術(shù)都并不成熟，仍有很多關(guān)鍵性問題亟待解決。

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

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

本文標題：大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)（中）

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