引子：
古代，人們用牛來拉重物。當一頭牛拉不動一根圓木時，他們不曾想過培育更大更壯的牛。
同樣：我們也不需要嘗試開發超級計算機，而應試着結合使用更多計算機系統。
—— 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的三大核心元素：
1、Google文件系統（GFS）
2、Google大表；Bigtable：是Google一種對於半結構化數據進行分佈存儲與訪問的接口或服務）；由於Google的文件系統異常龐大，以至於甲骨文和IBM公司的商業數據庫在方面無用武之地。另外，商業數據庫都是按 CPU數量來收費，如果Google使用商業數據庫，可想而知，這是一筆天文數字。所以，Google量體裁衣地設計了符合自身的大表。
3、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的管理工作
1、建表、刪表、查看錶格屬性；
2、管理RegionServer負載均衡，調整Region分佈；
3、Region Split後，負責新Region的分配；
4、在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: [email protected]
轉載請註明出處，謝謝。