大數據處理概論 - epaper.gotop.com.twepaper.gotop.com.tw/pdfsample/acd014000.pdf · 第1 章...
TRANSCRIPT
大數據處理概論
第 1 章 大數據處理概論
1-2
It was the best of times, it was the worst of times.
（這是最好的時代，也是最壞的時代。）
──《A Tale of Two Cities》, Charles Dickens (1812～1870)
數據（Big Data），也稱為海量資料（Massive Data），是隨著電腦技術及
網路技術的高速發展而產生的獨特資料現象。現代社會正以不可想像的速
度產生大數據，手機通訊、網站造訪、微博留言、影片上傳、商品產生、物流運
送、科學實驗……無處不在的社會和商業活動源源不斷地產生各種資料，人們已
經進入資料爆炸性增長的全新時代—大數據時代。
「這是最好的時代，也是最壞的時代」，著名作家狄更斯 150年前在《雙城記》中
留下的名句，預言般準確地描述了人們今天面臨的大數據時代的兩面性。一方面，
網路和資料庫中所記載的各種資料，真實地記錄和反映了現實世界中的各類活動
資訊，這些資訊就如巨大的寶藏等待人們去挖掘。如能善加利用，這些資料將如
航道中的燈塔，指引現代社會的科學研究和商業活動，進入下一個黃金時代。而
另一方面，不可控制的持續爆炸的大數據，如海嘯般湧向傳統的 IT世界，這股迅
猛的浪潮，挑戰著包括資料中心基礎設施和資料分析基礎架構在內的資料處理的
各個環節，稍有不慎，資料的擁有者和使用者將迷失在這大數據中。
幸運的是，電腦技術與網際網路的發展，在產生大數據的同時，也為人們帶來了
全新的雲端運算技術。雲端運算技術帶來的大數據處理能力，使得分析和掌握大
數據中蘊藏的無盡資訊、知識和智慧成為可能。在本書中，將結合大數據帶來的
技術挑戰和雲端運算技術帶來的全新能力，從資料處理發展進程、雲端運算演算
法和架構、雲端儲存與資料倉庫等多個方面，全面地介紹以 Hadoop 為代表的雲
端運算技術為大數據處理帶來的變革。
本章接下來的內容組織如下：1.1節提供了大數據的多維度定義；1.2節闡述了大
數據帶來的技術挑戰；1.3節介紹了已有的大數據儲存技術；1.4節介紹了針對大
數據環境的計算技術；1.5節對大數據處理平台的容錯問題進行了討論；1.6節介
紹了雲端運算技術引入後對大數據處理領域的影響。
大
1.3 大數據處理的儲存
1-21
複雜度緊密相關。SURE 架構的目標是優化資料搜尋操作，因此通常被作為
一個完整資料庫機的搜尋處理功能單元部分使用。
在對不同資料庫機架構進行性能評估時[15] 發現，PPH架構在執行一些滿足特定條
件的資料搜尋時，表現出了良好的性能。評估結果顯示，PPH架構的性能大部分
依賴於資料索引的品質，在較差索引條件下，PPH有可能出現嚴重的性能下降。
同時，研究還指出，在執行一些複雜的資料搜尋，例如包含多重關聯的搜尋操作
時，PPH具有嚴重的性能問題。為了解決以上這些問題，PPH的支持者不得不在
原始架構中引入一些後續處理單元，以支援複雜的搜尋操作。
3. 多處理器快取架構
在解決由 PPT架構引出的大數據情況下的磁軌容量問題時，一部分研究者提出了
與 PPH架構不同的作法，即將原來直接相連的處理器與儲存元件分離，採用一個
大容量的共用快取將兩者相連。這麼做的目的是充分利用多處理器並行讀取的高
速處理能力，和通用大型儲存區設備的低成本優勢。MPC 架構的結構圖如圖 1.9
所示。
圖 1.9 多處理器快取架構（MPC）結構圖
在 MPC架構中，新引入的共用快取機制發揮了關鍵性的作用。一方面，儲存元件
中的資料複製到共用快取後即可被所有的處理器並行使用；另一方面，處理器運
算後獲得的搜尋結果也可以存入共用快取中，方便快捷地被後續處理使用。
第 1 章 大數據處理概論
1-24
出，在經歷了 1971 年至 1993 年約 20 年的主頻艱難爬升期後，開始了一個持續
10年的快速增長期，增長到 2005年的 3.8GHz。然而從 2005年開始，處理器的
主頻提升進入了一個瓶頸期，主頻遲遲不能突破 4GHz大關。直到 2011年，才由
Intel 公司發佈的 Xeon 處理器突破了這一障礙。其原因在於對處理器主頻進行提
升並不是沒有極限的，在提高主頻的同時，處理器的功耗在以 3次方的指數速度
極速上升並導致發熱量的急劇增加，這極大地限制了主頻可提升的範圍。在這樣
的背景下，研究者們逐漸開始將研究重點，轉向以改進架構的來提升處理器的每
個時脈週期可執行的指令數量（IPC）上。
圖 1.10 處理器主頻增長圖
在 1965 年，GordonMoore 發現了一個有趣的規律，即當價格不變時，積體電路
上可容納的電晶體數目，約每隔 18個月便會增加一倍，性能也將提升一倍。隨著
半導體工業技術的飛速發展，摩爾定律得到了不斷驗證，這使得在處理器的單一
晶片上可整合的電晶體數量已經超過了 10億個。在這一條件下，研究者們得以採
用多核（Multi-core）技術突破單核處理器提升主頻才能實現性能提升的瓶頸。多
核技術採用架構優化的作法，以「橫向擴展」替代「縱向擴展」的創新方式來提
升處理器性能。IPC 是處理器在每個時脈週期內所能處理指示數的總量，因此增
加一個核心，理論上處理器每個時脈週期內可執行的指令數將增加一倍。其道理
很簡單，即多核處理器可以採用並行的方式執行多個指令，擁有幾個核心單位時
間可以執行的指令數量理論上限就可以增加幾倍。而在晶片內部多嵌入幾個核心
第 1 章 大數據處理概論
1-30
2. 平行算法
適合並行機處理的計算任務普遍具有可分解為多個並行子任務的特性，將一個大
的計算任務分解為多個可執行的並行子任務的過程即為平行算法的設計。一個好
的平行算法設計，可以極大地提升計算任務的並行度，即可降低公式（1.1）中的
參數 F，從而實現在平行計算環境下的更高性能處理。
在平行算法的設計中，兩個最基本的概念是任務（Task）和通道（Channel）[40]，
它們之間的關連如圖 1.14所示。圖中的每個圓圈代表一個任務，在右側的任務放
大圖中顯示了每個任務所包含的基本元素：程式碼、本地記憶體和與執行環境互
動的介面。圖中的每條箭頭線代表了一條通道，通道通常是一個訊息佇列，訊息
發送者可以推送訊息至佇列中，訊息接收者可以從佇列中取出訊息。
圖 1.14 平行算法中的任務與通道
平行算法的設計過程，可以分為以下 4個階段，如圖 1.15所示。
圖 1.15 平行算法設計 4 階段圖
第 3 章 MapReduce 計算模式
3-16
第 5 章 HBase 大數據資料庫
5-8
表 5.1 HBase 邏輯視圖表
行關鍵字 版本 列族：contents 列族：anchor
com.bbc.www t2 anchor:www.bbc.com = “BBC”
com.bbc.www t1 <html>a1</html>
com.cnn.www t7 anchor:cnnsi.com = “CNN”
com.cnn.www t6 anchor:my.look.ca = “CNN.com”
com.cnn.www t5 <html>d4</html>
com.cnn.www t4 <html>c3</html>
com.cnn.www t3 <html>b2</html>
雖然 HBase 的邏輯視圖可以採用與傳統關聯式資料庫類似的資料行表的形式表
達，但實際上這些資料在進行實體儲存時是以列族為單位進行儲存的。這種邏輯
視圖到實體視圖的對應可以透過圖 5.3來理解。
圖 5.3 HBase 邏輯視圖到實體視圖的對應
從圖 5.3 中可以看到，如果將邏輯視圖中的一行資料看作一個面，則這個面是由
若干個 Store 構成的，每個 Store 儲存了同屬於一個列族的資料。經過這樣的對
應，表 5.1中的 com.cnn.www行對應的資料就需要轉換為下面兩張實體儲存表，
見表 5.2和表 5.3。
表 5.2 HBase 實體視圖表 1—列族 contents
行關鍵字 版本 列族：contents
com.cnn.www t5 <html>d4</html>
com.cnn.www t4 <html>c3</html>
com.cnn.www t3 <html>b2</html>
第 5 章 HBase 大數據資料庫
5-10
2. HRegion 到 Store
HRegion 是 HBase 中分散式儲存的最小單元，但並不是實體儲存的最小單元。
HRegion是劃分為若干 Store進行儲存的，每個 Store儲存了一個列族中的資料。
這個過程如圖 5.5所示。
圖 5.5 HRegion 到 Store 儲存圖
3. Store 到 HFile
Store 由兩部分組成：MemStore 和 StoreFile，如圖 5.6 所示。MemStore 是
HRegionServer 上的一段記憶體空間。資料庫操作寫入的資料會先存入
MemStore，當 MemStore 滿了後會轉存到 StoreFile 中。HRegionServer 借用了
HDFS DataNode的功能，StoreFile實際上是 HDFS中的一個 HFile。
圖 5.6 Store 到 HFile 儲存圖
第 5 章 HBase 大數據資料庫
5-12
其中行關鍵字為表名、此 Region起始關鍵字和 Region的 id，info:regioninfo記
錄了此 Region的一些必要資訊，info:server為此 Region所在的 RegionServer的
地址和埠，info.serverstartcode代表此 RegionServer持有對應 RegionServer資訊
的進程的啟動時間。為了提高存取速度，.META.表會全部載入到記憶體中。
結合上面的內容，可以用圖 5.7 展示由 ZooKeeper 開始擴展到所有表的
RegionServer的過程。
圖 5.7 RegionServer 的定點陣圖
5.2.4 實體部署與讀寫流程
本節結合一個經典的 HBase 部署場景來了解對 HBase 進行資料管理的流程。圖
5.8中展示了一個常用的 HBase叢集。其中的 Master Server作為控制節點，部署
了 HBase 中的 HMaster 元件及 HDFS 中的 NameNode 元件，並在需要運行
MapReduce作業時，也會在 Master Server上啟動 JobTracker。Region Server R、
M1、M2是儲存-ROOT-表和.META.表的伺服器，用戶資料表儲存在 Region Server
U1至 Un中，這些 Region Server都部署了 HDFS的 DataNode元件以提高資料造
5.3 管理 HBase 中的資料
5-27
HBase 非 Java API 的代理伺服器可以與 RegionServer 部署在一台伺服器上，也
可以單獨部署在獨立的伺服器上。在圖 5.9 的中部， 3 類代理伺服器就與
RegionServer 部署在一起，上方的用戶端透過對應的介面造訪相應的代理伺服
器，代理伺服器將收到的請求進行轉換後以內嵌的 Java API功能與 RegionServer
互動，完成資料操作。而在圖 5.9的下方，一個 Thrift代理伺服器與 Thrift終端運
行在一台單獨的伺服器上，Thrift代理伺服器使用 Java API與遠端 RegionServer
進行互動。這種方式可以提高協力廠商終端與代理伺服器間的通訊效率，因為在
終端與代理伺服器間的通訊為一台伺服器上的本地通訊。
下面以使用 REST API造訪 REST代理伺服器為例，說明代理伺服器的使用方法。
首先在一台 RegionServer（IP位址為 192.168.1.100）上使用如下命令啟動 REST
代理伺服器：hbase-daemon.sh start rest。然後使用如程式碼 5.10 所示的程式碼
造訪 REST代理伺服器。
程式碼 5.10 使用 REST API 造訪資料程式碼
1: Cluster cluster = new Cluster();
2: cluster.add("192.168.1.100", 8080);
3: Client client = new Client(cluster);
4: RemoteHTable table = new RemoteHTable(client, "DemoTable");
5: Get get = new Get(Bytes.toBytes("row1"));
6: get.addColumn(Bytes.toBytes("colfam1"), Bytes.toBytes("qual1"));
7: Result result = table.get(get);
8: System.out.println("Get result: " + result);
在 HBase 的 org.apache.hadoop.hbase.rest.client 包中提供了與 HTable 和
HBaseAdmin類似的 RemoteHTable和 RemoteAdmin類別，用於與 REST代理伺
服器進行互動管理資料。上述程式碼第 1行和第 2行建立了一個 REST伺服器叢
集類，並指向啟動了 REST代理伺服器的 Region Server。第 3行用這個叢集類建
立了一個連接用戶端。第 4至第 7行使用與 HTable類似的方法，透過 RemoteHTable
取得了 DemoTable中行關鍵字 row1、列為 colfam1:qual1的數據，並在第 8行輸
出。
與 REST介面類別相似，在啟動 HBase提供的 Thrift和 Avro代理伺服器後，也
可依照這些介面的標準，透過代理伺服器造訪和管理資料。
第 5 章 HBase 大數據資料庫
5-28
5.4 從 RDBMS到 HBase
作為新興的列資料庫代表，HBase經常會被拿來與傳統的 RDBMS進行比較。雖然
HBase的設計目標、實現機制和運行效果與 RDBMS都不盡相同，但由於 HBase
和 RDBMS在很多場合下可以互相替代以滿足某一特定的資料庫儲存需求，因此
這樣的比較是不可避免的。
HBase是一個分散式列儲存資料庫系統，底層實體儲存利用了 HDFS分散式檔案
系統，其設計目標是為了滿足有海量行數（10億數量級）、大量列數（百萬級）
及資料結構不固定這類特殊資料的儲存需求，並可以運行於大量低成本架構的硬
體平台上，針對的應用環境是對事務一致性沒有特別嚴格要求的領域。而 RDBMS
是一個採用列導向（row-oriented）資料儲存，使用固定資料結構的資料庫系統，
並且要採用一系列機制保證滿足事務一致性要求的 ACID 特性。兩者之間的設計
目標差異導致了它們在實現機制和使用場合上也存在較大的差異，可以從以下幾
個角度對兩者進行比較：
(1) 硬體需求。RDBMS中的資料以行的方式組織資料，因此在進行搜尋查詢時，
即使只需要少量列的資料，也需要在讀取整行資料後進行過濾方可獲得。因
此 RDBMS是一個典型的 IO瓶頸系統，在資料量很大時，需要使用大量昂貴
的高性能磁碟陣列才能滿足速度需求。因此採用 RDBMS技術架構一個大數
據處理平台，其成本十分高昂。而 HBase作為典型的列資料庫，以列屬性為
單元連續儲存資料，這就使得對同一個屬性的資料造訪更加集中，可以有效
地減少資料 IO，提高存取速度。這在其針對的存在大量列屬性的應用環境
下，擁有比 RDBMS高得多的運行效率。同時，在設計之初 HBase就考慮了
整個系統的實現成本。透過充分利用底層分散式檔案系統的基礎能力，HBase
可以運行於由大量低成本計算機構成的叢集之上，並且維持大規模高吞吐的
性能。
(2) 可擴展性。一個優秀的資料庫系統應當能隨著資料的增長保持持續的可擴展
性。RDBMS的可擴展性通常依賴以下方式實現：
① 透過分散式快取技術（例如 memcached[6]）實現高性能的分散式記憶體物
件快取，透過快取資料和物件減少資料庫的讀取速度，以提高性能。
第 6 章 大數據的分析處理
6-4
中，Facebook 曾調查研究了多種不同的底層架構以支援 Hive 的運行，但最終
Hadoop體系中的 HDFS和 MapReduce簡潔高效的特性，促使了 Facebook將 Hive
的實現架構在這兩個技術基礎之上。
6.2.1 系統架構及元件
Hive的設計目的是讓熟練掌握 SQL語言，但不具備 Java程式設計能力的資料分
析人員，能對儲存好的結構化資料進行資料查詢和處理操作。因此 Hive的核心是
提供一套類 SQL的資料操作語言，並將其轉換為 MapReduce程式執行，對儲存
於 HDFS中的資料進行處理。Hive的架構如圖 6.1所示。
圖 6.1 Hive 架構圖
Hive架構中主要包括以下幾類組件：
(1) 使用者操作介面。使用者操作介面主要有 3類。第一類是指令介面（CLI），
指令介面支援資料分析員以指令的形式輸入類 SQL語言（HiveQL將在 6.2.5