3.3 大數據技術體系

在云計算技術和計算能力提高的推動下，人們從大數據中提取有價值信息的能力也在不斷地提升。同時，通過網絡將人、設備及傳感器連接起來，使得數據的生成、傳遞、分析及分享能力發生了根本性的變化。隨著社會的不斷發展，產生的數據就類型、深度及廣度等方面而言是有極大增長的，這也對數據管理和數據分析技術提出了新的要求。只有在對大數據的容量、多樣性、處理分析速度及價值挖掘這四個方面均有應對之策時，才可以從海量的數據里面挖掘出更多有價值的信息。大規模數據的存儲、異構數據源融合、分布式文件系統、分布式數據庫HBase、并行計算框架、大數據實時流處理及大規模圖數據處理技術等均屬于大數據技術的范疇。

3.3.1 大數據存儲和管理技術

3.3.1.1 分布式文件系統

隨著大數據時代的到來，海量數據在持續產生。為了有效解決存儲大量數據的問題，Google公司開發了一種分布式文件系統GFS（Google File System），該系統使用網絡來實現文件分布式存儲在不同位置的多臺計算機上，使得對大規模數據的存儲需求有了較好的保證。同時針對GFS開發了相應的開源系統——Hadoop分布式文件系統（Hadoop Distributed File System，HDFS），旨在達到可以依托在低成本服務器集群中保證大規模分布式文件存儲的目的。

HDFS在具備良好抗干擾的基礎上，還具有兼容成本較低的硬件設備的特性，因而，在保障機器實現大流量及大數據量讀寫和分析的同時可以兼顧成本的控制。

物理結構上，計算機集群中的多個節點構成了分布式文件系統。大規模文件系統的整體結構如圖3-2所示。這些節點可以分為主節點和從節點。其中，主節點也稱為名稱節點（Name Node），從節點也稱為數據節點（Data Node）。文件和目錄的創建、重命名和刪除等由名稱節點負責，還要檢查數據節點和文件塊之間的連接，因此要找到請求的文件塊的位置，用戶端必須到達名稱節點并讀取相應的文件塊。數據節點負責存儲和讀取信息。在存儲過程中，名稱節點首先分配存儲空間，然后將用戶數據直接發送到需要存儲的相關數據節點。傳輸首先通過名稱節點接收用戶端、相應的數據節點和文件塊之間的連接，然后可以檢索所需的文件塊。根據名稱節點命令和具體的情況查看是否需要進行創建、復制和刪除相應數據節點的后續操作。

需要注意的是，分布式文件系統主要是針對大批量數據的存儲所設計的，著重用于處理大規模文件（TB級文件），當處理規模較小的文件時，不但無法發揮全部優勢，而且會影響系統的拓展性能。

3.3.1.2 分布式數據庫HBase

針對Google公司的Big Table開發了分布式數據庫HBase，可以看成前者的開源實現，HBase以其處理速度快、準確度高、適配列數據處理及延展性好的特性，應用十分廣泛，主要用于非結構化或者半結構化數據的存儲。同時，HBase支持超大規模的數據進行分布式存儲，主要通過水平拓展的方式，借助低成本的計算機集群對超過數量級為億行的數據元素所組成的數據進行處理和存儲。

HBase是面向列的數據庫，主要適用于批量數據的處理及實時查詢，可以大大降低IO開銷，支持大量用戶的并發查詢，同時具有較高的數據壓縮比。HBase在數據挖掘、決策支持及地理信息等領域有著廣泛的應用。

HBase與Hadoop生態系統中其他部分的關系如圖3-3所示。HBase的運行原理就是利用Hadoop MapReduce來處理HBase數據庫中所存儲的大規模數據，可以在短時間內完成大批量數據的計算工作；利用Zookeeper框架實現協同服務，可以對向外提供的服務進行維護，保證服務的質量，還可以兼顧對執行失敗的任務的重錄工作；使用HDFS作為可靠度高的底層存儲，借助低成本的計算機集群進行大規模數據的存儲，提高數據的準確性和系統的完整性，從而發揮出HBase對大批量數據的處理能力；通過Sqoop實現高效、便捷的RDBMS數據存儲，更為方便地在HBase上進行數據處理和分析；HBase的高層語言則由Pig和Hive進行保證。

3.3.2 大數據分布式批處理技術

隨著大規模集成電路的制作工藝已經達到一個極限，從2005年開始CPU性能遵循的“摩爾定律”——大約每隔18個月性能翻一番，已經不再適用。因此，把程序運行效率提高的目標放在性能更高的CPU上已經不可行。這也就催生出了分布式并行編程，在大規模的計算機集群中，包括大量的低成本服務器，運行分布式程序，可以并行完成大批量數據的處理分析任務，以此來獲得海量的計算能力。

分布式存儲和分布式計算是大規模數據集中處理的兩大核心環節。其中Google公司的分布式數據存儲的主要方式是分布式文件系統GFS，整個系統的各個功能部分分別是由不同的模塊來實現的，由MapReduce負責分布式計算的任務。不同于前者數據存儲適用的系統，在Hadoop中是使用分布式文件系統HDFS達到分布式存儲目的的，采用Hadoop MapReduce來實現分布式計算。對于MapReduce而言，都是在分布式文件系統的基礎上進行存儲的，集群中的多個節點上存放著這個分布式的文件。

可以用“化整為零”來描述MapReduce的核心理念。MapReduce的工作流程如圖3-4所示。按照一定的規則，將一個完整的待處理數據集合化整為零，即分解成多個分片，每一個小的分片都有一個Map任務與之對應，這些小任務在多臺機器上并行處理，而在數據存儲的節點上存儲相應的Map任務，這樣數據的計算和存儲就可以在同一處運行，不需要消耗額外的數據傳輸資源。

需要注意的是，不同的Map任務之間是不會進行直接通信的，不同的Reduce任務之間也不會有直接的信息交換發生，這就說明用戶是無法顯式地將消息從一臺機器發送給另一臺機器的，意味著需要MapReduce框架自身去實現所有的數據交換任務。

3.3.3 大數據實時流處理技術

大數據計算技術包含批量計算技術和實時計算技術，其中批量計算技術只是針對大數據類別中的靜態數據類，而實時計算技術則是針對動態數據或者稱為流數據的數據類處理計算的。隨著大數據處理分析實時性需求的日益增加，如何實時計算海量流數據成為大數據領域新的挑戰。由于傳統的MapReduce框架基于離線處理計算的方式，面對靜態數據的處理分析有著獨特的優勢，但是其離線性也意味著無法滿足流數據實時性的要求，因此產生了流計算這種大數據數據處理計算技術，流計算可以很好地符合流數據實時計算的要求。

流數據（或數據流）是指滿足時間分布和數量無限的動態數據集合體，數據記錄是組成數據流的最小單位。隨著web應用、傳感檢測、生產制造等領域的發展，數據流開始興起，其具備海量、時變、快速的特點。在日常的電子商務活動中，購物網站通過對用戶點擊流、瀏覽歷史等行為的了解實時分析用戶的購買意圖，并實時推薦分析后的相關商品，達到提高商品銷量的目的，同時也可以提升用戶的購物體驗，讓用戶感受到個性化的服務，可以一舉兩得。

流計算平臺實時獲取來自不同數據源的海量數據，為了獲取有價值的信息需要做到及時的分析處理。在流計算中數據的價值會隨時間的推移逐漸降低，因此，收取到數據時需要及時處理，如果緩存起來或是延遲使用批量處理的話就難以獲得最有價值的信息。傳統的數據處理流程如圖3-5所示，需要將事先采集到的數據存儲在數據管理系統中，之后用戶才可以從數據管理系統中進行查詢操作，從而獲取到需要的查詢結果。這也意味著傳統的數據處理流程中所存儲的數據已經不具備查詢的時效性了。流計算的數據處理流程如圖3-6所示，包含數據實時采集、數據實時計算及實時查詢服務，所查詢到的結果是具有時效性的，可以實時反映當時的事件狀況。

3.3.4 大規模圖數據處理技術

大數據時代的來臨也伴隨著更多的大數據是通過大規模圖的形式呈現出來的，如社交網絡、氣象數據及交通事故等，此外，為了更加方便地進行分析處理，大量非圖結構的數據也時常會被轉換成圖模型。隨著需要分析處理的圖規模的日益增大，部分甚至達到億數量級的邊和頂點數，這時需要高效的處理分析圖模型就會有很大的難度，也就意味著一臺機器已經無法滿足所有圖數據的計算，急需一個分布式的計算環境。

現存的圖計算框架和圖算法庫已經無法適配大規模圖計算的需求，此時新的圖計算框架應運而生，Pregel就是代表性的產品之一，這是一種基于BSP模型實現的并行圖處理系統。在Pregel中搭建的一套可擴展的、有抗干擾機制的平臺，可以很好地解決大型圖計算的分布式計算問題，同時該平臺提供了許多應用廣泛的應用接口，用以滿足不同類別的圖計算需求。Pregel作為分布式圖計算的計算框架，主要用于圖遍歷、最短路徑、PageRank計算等。

Pregel計算模型以有向圖作為輸入口，在圖數據進入計算模型以后，有向圖的每個頂點都會被標簽成一個字符串類型的頂點身份ID，并將用戶的自定義值和這些頂點進行關聯綁定，而源頂點則鏈接到每一條有向邊，同時記錄其目標頂點的身份ID，并將一個可修改的用戶自定義值與之關聯起來。

對于頂點之間的信息交互方面，Pregel舍棄了遠程數據讀取或者共享內存的方式，轉而采用純消息傳遞模型，如圖3-7所示。采用這種做法主要基于以下兩個原因。

（1）頂點之間的消息傳遞是可以包含足夠信息內容的，無須使用遠距離調用或內存共享的方式。

（2）對系統整體性能的提升具有很大的幫助。具體表現在大規模圖計算一般是在一個計算集群環境中進行的，在集群環境中執行遠程數據讀取會有較大的延時，而Pregel采用異步和批量的消息傳遞方式，可以相對緩解遠距離調用和處理產生的延時問題。