首先要回答一個問題，為何要使用HBase？
隨著業務不斷髮展、資料量不斷增大，MySQL資料庫存在這些問題：
- MySQL支援的資料量為TB級，不能一直保留歷史資料。而HBase支援的資料量為PB級，適合儲存久遠的歷史冷資料
- 新增列的代價較高，資料量越大耗費時間越長。而HBase可以隨意增加列，空列不佔據空間，業務模型可以靈活變化
要使用HBase，最重要的一點是rowkey行鍵設計，如果設計不妥，後續要改的代價非常大。
HBase行鍵設計原則
下面列幾個HBase rowkey設計的原則：
- 組合鍵：組合鍵是指拼接多個業務欄位，如需查詢，則業務欄位必須作為rowKey的一部分
- 欄位順序：一對多，則一應該放在前面，以便能夠scan得到結果，如使用者id:訂單id，如果反過來則無法得到使用者下的所有訂單
- 業務欄位對齊長度：因為rowKey是按字典序排列的，所以需要對齊長度，比如id取12位，9位id前補齊3個0，否則就會出現123456789比654321比排在前面的問題。對齊長度後，000000654321排在000123456789之前，符合預期
- 打散以避免熱點：id與時間有關，隨時間遞增，如果不做處理可能導致部分節點有讀寫熱點，加上字首可以打散，如取 業務id的後幾位 % region個數 作為rowKey的字首
HBase應用舉例
冷熱資料分離
- HBase適合作為冷資料儲存，儲存和查詢海量歷史資料
- MySQL適合作為熱儲存儲存，支援資料讀寫、事務操作
- 歸檔近期未更新的歷史資料，新增資料至HBase，再刪除MySQL記錄
流水記錄
- 流水記錄可隨時新增欄位
- 適合儲存海量流水記錄
簡要回顧HBase架構
- region：所有行按rowkey字典序排列，region是其中一部分，相當於分片，每個region只能在一個region server上
- region server：可以包含一到多個region，呼叫HDFS的客戶端介面對region所有資料進行讀寫操作
- WAL：預寫日誌，WAL是Write-Ahead Log的縮寫。預先寫入，WAL是一個保險機制，資料在寫到Memstore之前，先被寫到WAL了。這樣當故障恢復的時候可以從WAL中恢復資料
- store：一個列族對應一個store，因此為了提高效能，不建議使用超過2個列族。一個store包含一個memstore和多個HFile
- memstore：資料寫入WAL之後就會被放入memstore，主要用於在記憶體中對行做排序，排序完成後再寫入HFile
- HFile：資料的儲存實體，memstore寫滿後就會寫入HFile
- region自動分片（split）、合併（merge）：region大小達到閾值後，會自動分割槽，反之會做合併region的操作
- HFile合併（compaction）：刪除資料後會導致HFile變小，需要合併以減少HFile的數量，即減少碎片檔案數量，提高定址效率