當我們對於數據結構字段不夠確定或雜亂無章很難按壹個概念去進行抽取的數據適合用使用什麽數據庫？答案是什麽，如果我們使用的傳統數據庫，肯定留有多余的字段，10個不行，20個，但是這個嚴重影響了質量。並且如果面對大數據庫，pt級別的數據，這種浪費更是嚴重的，那麽我們該使用是什麽數據庫？hbase數個不錯的選擇，那麽我們對於hbase還存在下列問題：
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）。