分佈式系統概述（Hadoop與HBase）

引子：

古代，人們用牛來拉重物。當一頭牛拉不動一根圓木時，他們未曾想過培育更大更壯的牛。

一樣：咱們也不須要嘗試開發超級計算機，而應試着結合使用更多計算機系統。

—— Grace Hopper（計算機軟件第一夫人，計算機歷史上第一個BUG的發現者，也是史上最大BUG千年蟲的製造者）

這就是分佈式。

 

 

再來看一組使人瞠目結舌的數據：

2012年11月11日

支付寶總交易額191億元，訂單1億零580萬筆，生成15TB日誌，訪問1931億次內存數據塊，13億個物理讀……

從上面的資料中咱們看到了：高性能！高併發！高一致性！高可用性！海量數據！

這就是海量數據處理。遠遠超出單臺計算機的能力範疇。

這就是分佈式集羣能力的體現，更說明了採用分佈式系統的必要性。

 

正文：

單臺設備的性能、資源、可擴展性等限制 —— 分佈式系統（Hadoop）

傳統關係型數據庫在面對海量數據時的乏力 —— 分佈式數據庫（HBase）

關係型數據庫，顧名思義，善於處理數據模型間複雜的關係、邏輯、事務。

但在處理海量數據時速度、併發量、可擴展性卻慘不忍睹。

固然，咱們能夠經過巧妙的設計與二次開發來解決上述問題。

速度：分表（減小單表數據量）、緩存查詢、靜態預生成、提升硬件性能。

併發量：打破單機（或雙機）模式，組建數據庫集羣。

可擴展性：複雜的數據遷移方案。

這個過程想必至關痛苦，並且因爲技術約束，形成的用戶體驗也不夠好。

好比咱們查銀行帳單、手機話費的歷史記錄，總要先選擇指定的月份或時間範圍，而後點提交。

這就是分錶帶來的用戶體驗降低。

 

什麼是Hadoop

而在原生的分佈式系統中，整個集羣的節點間共享計算、存儲、IO資源，完美的解決了性能、併發、數據存儲問題。

看一組關於Google的資料（約在2010年）：

Google共有36個數據中心。其中美國有19個、歐洲12個、俄羅斯1個、南美1個和亞洲3個（北京-Google.cn<這個……>、香港-Google.com.hk和東京各1個）。
數據中心以集裝箱爲單位，每一個數據中心有衆多集裝箱，每一個集裝箱裏面有1160臺服務器。

如何使這麼多臺服務器協同工做？

Google的三大核心元素：
　　一、Google文件系統（GFS）
　　二、Google大表；Bigtable：是Google一種對於半結構化數據進行分佈存儲與訪問的接口或服務）；因爲Google的文件系統異常龐大，以致於甲骨文和IBM公司的商業數據庫在方面無用武之地。另外，商業數據庫都是按 CPU數量來收費，若是Google使用商業數據庫，可想而知，這是一筆天文數字。因此，Google量體裁衣地設計了符合自身的大表。
　　三、Mapreduce 算法；它是Google開發的C++編程工具，用於大於1TB數據的大規模數據集並行運算。MapReduce可以找出一個詞語在Google搜索目錄中 出現的次數；一系列網頁中特定詞語出現的頻率；連接到某個特定網站的全部網站數量等。

好用的東西，總能找到對應的開源實現，這就是Hadoop。

 

Hadoop的構成

其中：

Pig，可使用Pig Latin流式編程語言來操做HBase中的數據

Hive，可使用相似SQL語言來訪問HBase，最終本質是編譯成MapReduce Job來處理HBase表數據，適合作數據統計。

 

誰在用Hadoop

Amazon、Adobe、Ebay、Facebook、Twitter、Yahoo、IBM……

國內：淘寶和支付寶的數據倉庫、華爲、百度的搜索日誌分析，騰訊……

這裏有更多的資料可查 http://wiki.apache.org/hadoop/PoweredBy

Facebook實時消息存儲系統於2010年下半年遷移到了HBase。

 

HBase的前生今世

2006 年底 —— Google 「BigTable: A Distributed Storage System for Structured Data」；

2007 02月 —— HBase的源代碼初稿；

2007 10月 —— 第一個版本，隨Hadoop 0.15.0 捆綁發佈；

2010 05月 —— HBase從Hadoop子項目升級成Apache頂層項目；

 

什麼是HBase

HBase是一個在Hadoop上開發的面向列（同類軟件還有Cassandra和HyperTable）的分佈式數據庫。

利用HDFS做爲其文件存儲系統

利用MapReduce來處理HBase中的海量數據

利用Zookeeper做爲協同服務，主要用於實時隨機讀/寫超大規模數據集

不少關係型數據庫爲了應對這種場景提供了複製（replication）和分區（partitioning）解決方案，讓數據庫能從單個節點上擴展出去。

可是難以安裝和維護，且須要犧牲一些重要的RDBMS（Relational DataBase Management System）特性，鏈接、複雜查詢、觸發器、視圖以及外鍵約束這些功能要麼運行開銷大，要麼根本沒法使用。

HBase從另外一個方向來解決可伸縮性的問題。它自底向上的進行構建，可以簡單的經過增長節點來達到線性擴展。

HBase並非關係型數據庫，它不支持SQL，但它可以作RDBMS不能作的事；

在廉價硬件構成的集羣上管理超大規模的稀疏表。

 

HBase的特色

面向列：列的動態、無限擴展 —— 內容評論的擴展，同類數據集中存儲便於壓縮

稀疏表：有數據時這個單元格才存在 —— 節省空間

 

HBase表格示意圖

Ø Row Key: 行鍵，Table的主鍵，Table中的記錄按照Row Key排序

Ø Timestamp: 時間戳，每次數據操做對應的時間戳，能夠看做是數據的version number

Ø Column Family：列簇，Table在水平方向有一個或者多個Column Family組成，一個Column Family中能夠由任意多個Column組成，即Column Family支持動態擴展，無需預先定義Column的數量以及類型，全部Column均以二進制格式存儲，用戶須要自行進行類型轉換。

 

HBase的組件構成

HMaster （HA），負責Table和Region的管理工做

一、建表、刪表、查看錶格屬性；

二、管理RegionServer負載均衡，調整Region分佈；

三、Region Split後，負責新Region的分配；

四、在RegionServer失效後，負責失效節點上的Regions遷移；

RegionServer（x N），主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據

 

HBase中表格的存儲

一張表存儲在[1-N)個HRegion中，每一個HRegion保存某張表RowKey連續的一段記錄。

建表時能夠預劃分HRegion——提升並行度，進而提高讀寫速度

不然初始表存在單一HRegion中，隨着數據增大HRegion會分裂爲多個HRegion

HBase中有兩張特殊的Table，-ROOT-和.META.

Ø  .META.：記錄了用戶表的Region信息，.META.能夠有多個regoin

Ø  -ROOT-：記錄了.META.表的Region信息，-ROOT-只有一個region

Ø  Zookeeper中記錄了-ROOT-表的location

首先 HBase Client端會鏈接Zookeeper Qurom

經過 Zookeeper組件Client 能獲知哪一個 RegionServer管理-ROOT- Region 。

那麼Client就去訪問管理 -ROOT-的HRegionServer ，在META中記錄了 HBase中全部表信息，(你可使用   scan '.META.' 命令列出你建立的全部表的詳細信息 )，從而獲取Region 分佈的信息。一旦 Client獲取了這一行的位置信息，好比這一行屬於哪一個 Region，Client 將會緩存這個信息並直接訪問 HRegionServer。

長此以往Client 緩存的信息漸漸增多，即便不訪問 .META.表 也能知道去訪問哪一個 HRegionServer。

HBase讀數據

HBase讀取數據優先讀取HMemcache中的內容，若是未取到再去讀取Hstore中的數據，提升數據讀取的性能。

HBase寫數據

HBase寫入數據會寫到HMemcache和Hlog中，HMemcache創建緩存，Hlog同步Hmemcache和Hstore的事務日誌，發起Flush Cache時，數據持久化到Hstore中，並清空HMemecache。

 

文本部份內容與圖片引用於互聯網，引用地址以下：

http://www.searchtb.com/2011/01/understanding-hbase.html

 

 

Author：Pirate Leo

myBlog: http://blog.csdn.net/pirateleo/

myEmail: codeevoship@gmail.com

轉載請註明出處，謝謝。