Hbase是基於HDFS的面向列的分佈式數據庫，用於海量結構化數據存儲。內部的文件全部存儲在HDFS上
HBase中表的特點：
1 大，一個表可以有幾十億行，上百萬列
2 面向列，面向列族的存儲和權限控制，列簇的獨立檢索
3 稀疏，對於為空的列，並不佔據空間，因此表的設計可以非常稀疏
4 無模式，每行又有一個可排序的主鍵和任意多的列，列可以根據需要動態的添加，同一張表不同的行可以使用不同的列
Hbase的存儲實例：
1 每個column family存儲在HDFS上的一個單獨的文件中
2 key和version number在每個column family中均有一份
3 空值不會被保存
4 hbase為每個值維護了多級索引，即row key、column family、column name、timestamp等
物理存儲：
1 table中的所有行都按照row key的字典序排列
2 table在行的方向上分割為多個region
3 region按大小分割的，每個表開始只有一個region，隨著數據的增大，region會不斷的增大，當增大到一個閾值的時候，region就會等分為兩個新的region，之後會有越來越多的region
4 region是hbase中分佈式存儲和負載均衡的最小單元。不同的region分佈到不同的regionserver上。
5 region雖然是分佈式存儲的最小單元，但不是存儲最小單元。Region由一個或者多個store組成。每個store保存一個column family，每個store又由一個memstore和0至多個storeFile組成，memStore存儲在內存中，storeFile存儲在HDFS上
Hbase架構圖：
Zookeeper：
1 保證在任何時候，集群中只有一個master(負責Hmaster的選舉)
2 存儲所有region的尋址入口
3 實時監控regionServer的狀態，將regionserver的上線和下線信息實時通知給master(服務器之間的狀態同步)
4 存儲Hbase的schema(元數據信息)，其中保存table和table中的colume family
Hmaster:主要負責table和region的管理工作
1 region分裂後，為regionServer分配新的region
2 負責regionServer的負載均衡，調整region的分配
3 發現失效的region Server並重新分配其上的region(region自動切分是Hbase能夠擁有良好拓展性的重要因素之一)
4 管理用戶對table的增刪改查操作
5 監聽zookeeper，基於zookeeper感應rs的上下線和保證HA(高可用)
6 處理schema更新請求(對錶的增刪改查)
7 不參與對錶的訪問讀寫
8 在一個regionServer宕機後，負責失效節點的region的遷移
HregionServer(負責響應用戶對其上region的I/O請求，向HDFS讀寫數據):
1 HregionServer維護master分配給它的region
2 維護region的cache
3 處理region的flush、compact、split
4 內部管理一系列的Hregion對象
5 一個HRegionServer會有多個Hregion和一個HLog
Region/Hrgion:
1 每一個region由很多的store組成，每一個store存儲的是一個列簇(columnFamily)下所有的數據。在每個store中又包含memstore，memstore駐留在內存中，數據到來時首先要更新到memstore中，當到達閾值後再flush(默認64M)到對應的storeFile/Hfile中。storeFile負責的是實際數據存儲，為HBase中最小的存儲單元
2 當region到達閾值時(默認為256M)，開始分裂。一個HRegionServer管理多個表，一個表下有多個region，一個Hregion有多少個列族就要多個列族就有多少個store，store下有多個storeFile文件，是Hbase中最小的存儲單元。
3 每個column Family單獨存儲：storeFile。storeFile的數量達到閾值，合併。
4 當某個columnFamily累計的大小超過閾值時，自動分裂為兩個region。
StoreFile：
Memstore內存中的數據寫入到文件之後就是storeFile，storeFile底層是以Hfile格式保存
Hbase的容錯性：
1 master容錯：
Zookeeper重新選擇一個新的master
沒有master的過程中，數據讀取依舊運行，但region的切分、負載均衡無法進行
2 regionServer容錯
定時向zookeeper彙報心跳，如果一旦一段時間未出現心跳，master將該regionServer上的region重新分配到其他regionServer上。
失效服務器上日誌(HLOG)由主服務器進行分割並派送給新的regionServer
3 zookeeper容錯
Zookeeper後會介紹
什麼時候適合使用HBase？
1 半結構化和非結構化數據：對於數據結構字段不確定或雜亂無章，很難以一個概念進行抽取的數據適合HBase，因為HBase支持動態添加列
2 記錄很稀疏：傳統的行列是固定的，null的存儲浪費空間。而HBase的null不會被存儲，這樣既節省了空間又提高了讀性能
3 多版本號數據：依據rowkey和column key 定位的value能夠有隨意數量的版本號，因此對於需要存儲變動歷史記錄的數據，HBase很方便
4 僅要求最終一致性：對於數據存儲事務的要求不像金融行業和財務系統那麼高，只要保證最終一致性就可以。
5 高可用和海量數據以及很大的瞬間寫入量
6 索引插入比查詢更頻繁的情況。例如，對歷史記錄表和日誌文件
7 業務場景簡單：不需要太多的關係型數據庫特定
Rowkey 的設計：
Rowkey的概念和mysql中的主鍵概念是一致的，HBase使用rowkey來唯一的標識一行數據
HBase中僅支持三種查詢方式：
1 基於rowkey的範圍掃描
2 基於rowkey的單行查詢
3 全表掃描
Rowkey的行鍵在實際應用中，長度一般為(10-100bytes)，最好16bytes。在HBase的內部，rowkey保存為字節數組。Hbase會對錶中的數據按照rowkey排序(字典序)
設計原則：
1 唯一原則。必須保持其唯一性。如果同一張表插入相同的rowkey，則原先的數據會被覆蓋掉
2 排序原則。根據實際情況。如對視頻下方的評論，按時間作為rowkey排序最佳
3 散列原則：rowkey應該均勻的分佈在HBase的各個節點上。如常見的時間戳，如果rowkey是按照系統時間戳的方式遞增，rowkey的第一部分如果是時間戳信息的話，將會造成所有的新數據都在一個regionServer上堆積的熱點現象。
解決熱點問題：
Reverse反轉：針對固定長度的rowkey反轉後存儲
Salt加鹽：將每一個rowkey加一個前綴，前綴前使用一些隨機字符，使數據分散在多個不同的region，達到region負載均衡的目標
Hash散列或者mod：將原始的rowkey進過hash處理
4 長度原則：Rowkey的行鍵在實際應用中，長度一般為(10-100bytes)，最好16bytes。
HBase 宕機如何處理
宕機分為 HMaster 宕機和 HRegisoner 宕機，如果是 HRegisoner 宕機， HMaster 會將其所管理的 region 重新分佈到其他活動的 RegionServer 上，由於數據和日誌都持久在 HDFS中，該操作不會導致數據丟失。所以數據的一致性和安全性是有保障的。如果是 HMaster 宕機， HMaster 沒有單點問題， HBase 中可以啟動多個 HMaster，通過Zookeeper 的 Master Election 機制保證總有一個 Master 運行。即 ZooKeeper 會保證總會有一個 HMaster 在對外提供服務。
閱讀更多 不知火周 的文章
