為什麼要讨論HBase編碼壓縮
- 編碼+壓縮能夠成倍的減少資料的磁盤占用空間，節省可觀的存儲費用
- 編碼+壓縮通常情況下可以提高系統吞吐率，讓系統可以做更多的功
- 預設建表不啟用編碼或者壓縮，對初學者不友好
了解HBase編碼
舉個栗子，我們有一張物流表叫"express"，記錄物流訂單的流轉詳情。如下面表格：rowkey包含兩個部分，用#号分割，左邊是物流訂單号，右邊是物流資訊的更新時間點。表包含兩個列，一個物流狀态，一個是物流描述資訊
| rowkey | 狀态列 | 描述資訊列 |
|---|---|---|
| 10324224#2019-04-21 10:51 | 已發貨 | 包裹正在等待攬收 |
| 10324224#2019-04-21 19:46 | 已攬件 | [嘉興市]平湖南橋的xxx已攬收 |
| 運輸中 | [嘉興市]快件已從平湖南橋出發，準備發往嘉興中轉部 | |
| 10324224#2019-04-21 20:41 | [嘉興市]快件已到達嘉興中轉部 | |
| 10324224#2019-04-21 20:42 | [嘉興市]快件已從達嘉興中轉部出發，準備發往杭州中轉部 | |
| 10324224#2019-04-21 22:50 | [嘉興市]快件已到達杭州中轉部 | |
| ... |
我們對Rowkey進行編碼得到如下
| rowkey 字首長度 | 詳情列 | ||
|---|---|---|---|
| 19:46 | 20 | ||
| 20:41 | |||
| 20:42 | |||
| 22:50 | |||
可以看到，除了第一行存儲了完整的rowkey以外，其它行與首行進行了Diff，隻儲存了不相同的部分。除了rowkey編碼以為，HBase還可以對版本号，更新類型等進行編碼。HBase目前提供的可靠的編碼包括“Prefix,Diff,Fast Diff, Index Encoding(阿裡巴巴HBase團隊研發的優化随機讀場景的編碼）”，更多關于編碼的參考
Compression and Data Block Encoding In HBase以及
HBase資料壓縮編碼探索了解HBase壓縮
HBase壓縮的對象是一行中的值，不包括rowkey、版本等。由于HBase的中繼資料中沒有資料類型，是以HBase的壓縮算法都是面向通用壓縮場景，一般會有4-10倍的壓縮率，下面表格介紹了各種壓縮算法在不同場景下的收益
HBase還有其它的壓縮算法如“Snappy，GZIP”。更多關于壓縮的參考
如何選擇HBase編碼壓縮
不同的場景下優化的側重不同，選擇的難度也不同。
- 讀少寫多，大存儲量場景
該場景通常是存儲一些比較冷的資料，對請求的響應要求不高，對存儲成本敏感。在存儲媒體上通常選擇便宜的HDD、高效雲盤。這些媒體相比于SSD在IO吞吐和IOPS方面都要弱很多。這裡我們選擇高壓縮比的壓縮算法“ZSTD、GZIP”，編碼選擇Diff。比如“Diff+ZSTD”組合，不僅節省存儲成本，同時會減少寫入和Compaction對IO的壓力（因為寫入磁盤的資料量減少了），提升寫吞吐量
注：壓縮不是萬金油，有時候資料寫入前就壓縮了，或者壓縮率不理想，這時候設定壓縮反而浪費了CPU，弄巧成拙。是以我們需要運作時資料來判斷壓縮比，進入HBase的Web UI，找到表‘t1’的詳情頁：
我們把Table Schema部分展開，看一下目前表的編碼（DATA_BLOCK_ENCODING）和壓縮（COMPRESSION）配置
然後我們繼續向下看Table Regions，看到表‘t1’有兩個分區分布在兩台Region Server節點上。我們選擇一個Region Server點進入
選擇第一個Region Server進入
在Region Server的詳情中，我們找到Regions部分，然後選擇Storefile Metrics标簽，下面是該Region Server上各個分區的檔案詳情。我們找到‘t1’表的分區，如上圖紅色框的哪一行，可以看到檔案未編碼壓縮前是305MB，編碼壓縮後是49MB，壓縮比是 1 ：6.2
- 讀請求較多場景
該場景一般偏向線上，請求多且對延遲有一定要求。讀的優化相比寫要更複雜，這個和場景關聯性很強，是以我們可以有一些政策和預判，但是還是需要實際的資料來指導優化，具體問題具體分析。總的來講，讀存在一個緩存“BlockCache”，緩存的命中率嚴重影響讀的性能。預設的情況下BlockCache中的資料是可以保持“編碼”，但是資料從磁盤讀出後被解壓存儲在BlockCache，在2.0版本中新增了Compressed Block Cache（全表次元），使得Block Cache中的資料也可以處于壓縮狀态。
優勢：
1 緩存一般的命中在20%~80%較常見，是以一定有相當量的請求要走磁盤IO，那麼編碼壓縮有助于減少這部分IO的開銷
2 編碼和壓縮都可以使得Block Cache緩存更多的資料，進而提高命中率。但具體的提升效果也和場景相關，随機讀場景的提升就不如順序讀多的場景
3 由于緩存命中提高，緩存淘汰相應減少，有利于GC
劣勢：
1 編碼壓縮增加了CPU的開銷，在CPU資源吃緊的情況下會影響讀寫響應時間
總結，通常情況下建議編碼壓縮都打開，使用DIFF+ZSTD組合作為預設配置可以滿足絕大部分場景。通過HBase WebUI以及監控觀察壓縮比，CPU負載，IO負載，緩存命中率，讀寫請求響應等名額來判斷是否需要進一步調整編碼壓縮配置。
如何修改編碼壓縮
編碼壓縮是column family級别的，我們可以通過shell來線上修改
alter 't1', {NAME => 'info', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'ZSTD'}
注：修改表的編碼壓縮後并不是立即生效的，需要執行一次Major Compaction刷一遍資料檔案，新生成檔案才是新的編碼壓縮格式。