HBase的Split機制
Region的分裂策略
HBase中的Region儲存的是一張表的資料。當Region中的資料條數過多時，會直接影響查詢效率，過大的Region會被拆分為兩個Region，HMaster會將這些分裂的Region分配到不同的RegionServer上，最終達到負載均衡的目的，這是HBase的一個優點。
常見的Region分裂策略：
-
ConstantSizeRegionSplitPolicy
- 0.94版本前是HBase預設的Region切分策略。
- 當Region中最大的Store大小超過某個閾值（
hbase.hregion.max.filesize=10G）時，觸發Region的切分。 - 然而，這種策略對大表和小表沒有明顯區分：
- 大表：閾值設定較大時對大表友好，但小表可能不會觸發分裂。
- 小表：閾值設定較小時對小表友好，但會在叢集中產生大量的Region，增加資源管理和failover的負擔。
-
IncreasingToUpperBoundRegionSplitPolicy
- 0.94版本到2.0版本是HBase的預設切分策略。
- 切分閾值基於Region的數量動態調整，隨著Region數量的增加，切分閾值逐漸增大，避免大量小Region的產生。
- 該策略更加自適應大表、小表，但對小表不太友好，可能導致大量小Region分佈在不同RegionServer上。
-
SteppingSplitPolicy
- 2.0版本後預設的切分策略。
- 簡單高效。根據Region數量調整切分閾值：
- 當Region數目為1時，使用較小的閾值（
128M*2）。 - 否則，使用最大Region檔案大小（
MaxRegionFileSize）。
- 當Region數目為1時，使用較小的閾值（
- 對大叢集的適應性好，不會導致大量的小Region，並且較適用於小表。
-
KeyPrefixRegionSplitPolicy
- 根據RowKey的字首進行資料分割槽，例如RowKey是16位，指定前5位作為字首進行切分。
-
DelimitedKeyPrefixRegionSplitPolicy
- 與
KeyPrefixRegionSplitPolicy類似，但切分時使用指定的分隔符，例如RowKey格式為userid_eventtype_eventid，指定_為分隔符進行切分。
- 與
-
BusyRegionSplitPolicy
- 依據Region是否“繁忙”來判斷是否需要拆分。如果系統常常會出現熱點Region，並且對效能有較高要求，可以考慮使用此策略。
-
DisabledRegionSplitPolicy
- 不啟用自動拆分，需要手動拆分Region。
RowKey設計的原則
1. RowKey唯一原則
- RowKey必須保證唯一性，HBase是按照字典順序儲存資料的，因此設計RowKey時應充分利用這種特性，將常訪問的資料儲存在同一區域。
2. RowKey長度原則
- RowKey的長度一般建議不超過100位元組。過長的RowKey會佔用更多的記憶體和儲存空間，影響HFile的儲存效率，同時減少MemStore和BlockCache的快取效率，降低檢索效率。
3. RowKey雜湊原則
- 如果RowKey按照時間戳等遞增模式設計，可能導致熱點問題。為了避免這種問題，可以將RowKey的高位設計為雜湊欄位，低位放置時間戳等欄位，這樣可以將資料均衡分佈到不同RegionServer上，避免熱點。
HBase熱點問題
1. 什麼是熱點問題？
- 在HBase中，資料按照RowKey排序並儲存。如果某些RowKey頻繁被訪問，資料會集中儲存在同一個Region，可能導致：
- 某個Region的負載過高。
- 某個RegionServer被過度請求，成為瓶頸。
- 叢集負載不均，造成資源浪費和效能瓶頸。
2. 導致熱點問題的原因
- 順序寫入：如使用遞增的ID或時間戳，導致寫入操作集中在同一個Region。
- 過度集中在某些RowKey範圍：某些特定的RowKey頻繁被訪問，導致特定Region頻繁被請求。
- RowKey缺乏隨機性：如果RowKey設計缺乏隨機性，訪問會集中在某個Region，導致負載不均。
3. 如何避免和解決熱點問題
- 隨機化RowKey：例如在RowKey前加上隨機數，或者使用逆序時間戳來避免順序寫入帶來的熱點問題。
- 使用時間區間分割槽（預分裂）：在表建立時進行預分裂，將RowKey按時間或其他特徵進行分割槽，避免資料集中在某個Region。
- 更復雜的RowKey設計：例如使用複合型RowKey，結合多種欄位（如使用者ID、時間戳等）進行設計，從而實現資料的均勻分佈。
- 動態擴充套件與負載均衡：透過Region Split或Region Merge操作，及時調整Region的分佈，解決熱點問題。
- 監控與調優：實時監控RegionServer的負載情況，透過調整策略解決熱點問題。
HBase的Flush機制
觸發條件
- Region中的MemStore佔用記憶體超過閾值：如果MemStore的佔用記憶體超過
hbase.hregion.memstore.flush.size（預設為128MB），會觸發Flush操作。 - RegionServer的MemStore佔用記憶體超過閾值：當RegionServer中所有Region的MemStore佔用記憶體超過閾值時，Flush操作會被觸發。
- WAL數量超過閾值：如果RegionServer的WAL數量或大小超過某個閾值，MemStore會被觸發Flush。
- 定期自動刷寫：透過定期檢查MemStore，觸發定時的Flush操作。
觸發操作
常見的操作，如put、delete、append、incr等，會觸發Flush操作。此外，Region的分裂、Merge操作、bulkLoad HFiles、快照等操作也會觸發Flush。
Flush策略
- FlushAllStoresPolicy：每次刷寫都會觸及Region中的所有MemStore。
- FlushAllLargeStoresPolicy：首先判斷MemStore是否超過某個閾值，如果超過則觸發刷寫。
- FlushNonSloppyStoresFirstPolicy：優先刷寫記憶體佔用大的、非Sloppy型別的MemStore。
HBase的Compaction機制
Minor Compaction
Minor Compaction指的是將相鄰的小StoreFile合併為更大的StoreFile，不會處理已刪除或過期的資料。結果是StoreFile變少，檔案更大。
Major Compaction
Major Compaction會將所有StoreFile合併為一個StoreFile，並清理無效資料（如已刪除的資料、過期資料）。這一過程消耗大量資源，通常會在低峰時手動觸發。
二級索引
- 基於一級索引之上構建的索引。
- 為什麼構建二級索引：HBase預設的RowKey是唯一且只能做字首匹配查詢，查詢條件如果不是RowKey的字首，查詢效率較低。透過二級索引可以提高查詢效能，尤其是當查詢條件不包含RowKey時。