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