HBase基礎知識分享(二)

ikestu小猪發表於2024-11-14

HBase的Split機制

Region的分裂策略

HBase中的Region儲存的是一張表的資料。當Region中的資料條數過多時，會直接影響查詢效率，過大的Region會被拆分為兩個Region，HMaster會將這些分裂的Region分配到不同的RegionServer上，最終達到負載均衡的目的，這是HBase的一個優點。

常見的Region分裂策略：

  1. ConstantSizeRegionSplitPolicy

    • 0.94版本前是HBase預設的Region切分策略。
    • 當Region中最大的Store大小超過某個閾值（hbase.hregion.max.filesize=10G）時，觸發Region的切分。
    • 然而，這種策略對大表和小表沒有明顯區分：
      • 大表：閾值設定較大時對大表友好，但小表可能不會觸發分裂。
      • 小表：閾值設定較小時對小表友好，但會在叢集中產生大量的Region，增加資源管理和failover的負擔。

  2. IncreasingToUpperBoundRegionSplitPolicy

    • 0.94版本到2.0版本是HBase的預設切分策略。
    • 切分閾值基於Region的數量動態調整，隨著Region數量的增加，切分閾值逐漸增大，避免大量小Region的產生。
    • 該策略更加自適應大表、小表，但對小表不太友好，可能導致大量小Region分佈在不同RegionServer上。

  3. SteppingSplitPolicy

    • 2.0版本後預設的切分策略。
    • 簡單高效。根據Region數量調整切分閾值：
      • 當Region數目為1時，使用較小的閾值（128M*2）。
      • 否則，使用最大Region檔案大小（MaxRegionFileSize）。
    • 對大叢集的適應性好，不會導致大量的小Region，並且較適用於小表。

  4. KeyPrefixRegionSplitPolicy

    • 根據RowKey的字首進行資料分割槽，例如RowKey是16位，指定前5位作為字首進行切分。

  5. DelimitedKeyPrefixRegionSplitPolicy

    • 與KeyPrefixRegionSplitPolicy類似，但切分時使用指定的分隔符，例如RowKey格式為userid_eventtype_eventid，指定_為分隔符進行切分。

  6. BusyRegionSplitPolicy

    • 依據Region是否“繁忙”來判斷是否需要拆分。如果系統常常會出現熱點Region，並且對效能有較高要求，可以考慮使用此策略。

  7. 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時。

相關文章