Hbase總結（五）-hbase常識及habse適合什麼場景
1.Column Family代表什麼？
2.HBase通過row和column確定一份資料，這份資料的值可能有多個版本，為什麼會存在多個版本？
3.查詢的時候會顯示那個版本？
4.它們的儲存型別是什麼？
5.tableName是什麼型別？
6.RowKey 和 ColumnName是什麼型別？
7.Timestamp 是什麼型別？
8.value 是什麼型別？
帶著以上幾個問題去讀下面內容：
引言
團隊中使用HBase的專案多了起來，對於業務人員而言，通常並不需要從頭搭建、維護一套HBase的叢集環境，對於其架構細節也不一定要深刻理解（交由HBase叢集維護團隊負責），迫切需要的是快速理解基本技術來解決業務問題。最近在XX專案輪崗過程中，嘗試著從業務人員視角去看HBase，將一些過程記錄下來，期望對快速瞭解HBase、掌握相關技術來開展工作的業務人員有點幫助。我覺得作為一個初次接觸HBase的業務開發測試人員，他需要迫切掌握的至少包含以下幾點：
深入理解HTable，掌握如何結合業務設計高效能的HTable
掌握與HBase的互動，反正是離不開資料的增刪改查，通過HBase Shell命令及Java Api都是需要的
掌握如何用MapReduce分析HBase裡的資料，HBase裡的資料總要分析的，用MapReduce是其中一種方式
掌握如何測試HBase MapReduce，總不能光寫不管正確性吧，debug是需要的吧，看看如何在本機單測debug吧
本系列將圍繞以上幾點展開，篇幅較長，如果是HBase初學者建議邊讀邊練，對於HBase比較熟練的，可以選讀下，比如關注下HBase的MapReduce及其測試方法。
從一個示例說起
傳統的關係型資料庫想必大家都不陌生，我們將以一個簡單的例子來說明使用RDBMS和HBase各自的解決方式及優缺點。
以博文為例，RDBMS的表設計如下：
為了方便理解，我們以一些資料示例下
上面的例子，我們用HBase可以按以下方式設計
同樣為了方便理解，我們以一些資料示例下，同時用紅色標出了一些關鍵概念，後面會解釋
HTable一些基本概念
Row key
行主鍵，
HBase不支援條件查詢和Order by等查詢，讀取記錄只能按Row key（及其range）或全表掃描，因此Row key需要根據業務來設計以利用其儲存排序特性（Table按Row key字典序排序如1,10,100,11,2）提高效能。
Column Family（列族）
在表建立時宣告，每個Column
Family為一個儲存單元。在上例中設計了一個HBase表blog，該表有兩個列族：article和author。
Column（列）
HBase的每個列都屬於一個列族，以列族名為字首，如列article:title和article:content屬於article列族，author:name和author:nickname屬於author列族。
Column不用建立表時定義即可以動態新增，同一Column
Family的Columns會群聚在一個儲存單元上，並依Column key排序，因此設計時應將具有相同I/O特性的Column設計在一個Column Family上以提高效能。同時這裡需要注意的是：這個列是可以增加和刪除的，這和我們的傳統資料庫很大的區別。所以他適合非結構化資料。
Timestamp
HBase通過row和column確定一份資料，這份資料的值可能有多個版本，不同版本的值按照時間倒序排序，即最新的資料排在最前面，查詢時預設返回最新版本。如上例中row
key=1的author:nickname值有兩個版本，分別為1317180070811對應的“一葉渡江”和1317180718830對應的“yedu”（對應到實際業務可以理解為在某時刻修改了nickname為yedu，但舊值仍然存在）。Timestamp預設為系統當前時間（精確到毫秒），也可以在寫入資料時指定該值。
Value
每個值通過4個鍵唯一索引，tableName+RowKey+ColumnKey+Timestamp=>value，例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’
1317180718830’}索引到的唯一值是“yedu”。
儲存型別
TableName
是字串
RowKey
和 ColumnName 是二進位制值（Java 型別 byte[]）
Timestamp
是一個 64 位整數（Java 型別 long）
value
是一個位元組陣列（Java型別 byte[]）。
儲存結構
可以簡單的將HTable的儲存結構理解為
即HTable按Row
key自動排序，每個Row包含任意數量個Columns，Columns之間按Column key自動排序，每個Column包含任意數量個Values。理解該儲存結構將有助於查詢結果的迭代。
話說什麼情況需要HBase
半結構化或非結構化資料
對於資料結構欄位不夠確定或雜亂無章很難按一個概念去進行抽取的資料適合用HBase。以上面的例子為例，當業務發展需要儲存author的email，phone，address資訊時RDBMS需要停機維護，而HBase支援動態增加.
記錄非常稀疏
RDBMS的行有多少列是固定的，為null的列浪費了儲存空間。而如上文提到的，HBase為null的Column不會被儲存，這樣既節省了空間又提高了讀效能。
多版本資料
如上文提到的根據Row
key和Column key定位到的Value可以有任意數量的版本值，因此對於需要儲存變動歷史記錄的資料，用HBase就非常方便了。比如上例中的author的Address是會變動的，業務上一般只需要最新的值，但有時可能需要查詢到歷史值。
超大資料量
當資料量越來越大，RDBMS資料庫撐不住了，就出現了讀寫分離策略，通過一個Master專門負責寫操作，多個Slave負責讀操作，伺服器成本倍增。隨著壓力增加，Master撐不住了，這時就要分庫了，把關聯不大的資料分開部署，一些join查詢不能用了，需要藉助中間層。隨著資料量的進一步增加，一個表的記錄越來越大，查詢就變得很慢，於是又得搞分表，比如按ID取模分成多個表以減少單個表的記錄數。經歷過這些事的人都知道過程是多麼的折騰。採用HBase就簡單了，只需要加機器即可，HBase會自動水平切分擴充套件，跟Hadoop的無縫整合保障了其資料可靠性（HDFS）和海量資料分析的高效能（MapReduce）。