共用方式為


Azure HDInsight 中的 Apache HBase 建議程式

本文說明數個建議程式,可協助您最佳化 Azure HDInsight 中的 Apache HBase 效能。

最佳化 HBase 以讀取最近寫入的資料

如果您的使用案例牽涉到從 HBase 讀取最近寫入的資料,此建議程式可為您提供協助。 為了達到高效能,最好從 memstore (而不是從遠端儲存體) 提供 HBase 讀取。

查詢建議程式指出,針對資料表中指定資料行系列,> 75% 讀取是從 memstore 提供的。 此指標意味著即使在 memstore 上發生排清,也必須存取最近的檔案,而且檔案必須位於快取中。 資料會先寫入系統存取最近之資料的 memstore。 內部 HBase 排清器執行緒可能偵測到指定的區域已達到 128M (預設) 大小,而且可以觸發排清。 此情節甚至發生在 memstore 大小約 128M 時所寫入的最新資料。 因此,稍後讀取這些最近記錄可能會需要讀取檔案,而不是從 memstore 讀取。 因此,最好的辦法是最佳化,即使最近排清的資料也能夠位於快取中。

若要最佳化快取中最近的資料,請考慮下列設定:

  1. hbase.rs.cacheblocksonwrite 設定為 true。 HDInsight HBase 中的這個預設設定是 true,因此請檢查其是否不會重設為 false

  2. 增加 hbase.hstore.compactionThreshold 值,如此就可以避免壓縮啟動。 根據預設,此值為 3。 您可以將其增加為較高的值,例如 10

  3. 如果您遵循步驟 2 並設定 compactionThreshold,則將 hbase.hstore.compaction.max 變更為較高的值,例如 100,同時將設定 hbase.hstore.blockingStoreFiles 的值增加為較高的值,例如 300

  4. 如果您確定必須唯讀最近的資料,請將 hbase.rs.cachecompactedblocksonwrite 設定設為 [開啟]。 此設定會告知系統即使壓縮發生,資料仍會保留在快取中。 您也可以在系列等級進行這些設定。

    在 HBase 殼層中,執行下列命令來進行 hbase.rs.cachecompactedblocksonwrite 設定:

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
    
  5. 您可以針對資料表中的指定系列關閉區塊快取。 請確定已針對具有最近資料讀取的系列 [開啟] 區塊快取。 根據預設,會針對資料表中的所有系列開啟區塊快取。 如果您已停用系列的區塊快取,且需要將其開啟,請使用來自 hbase 殼層的 alter 命令。

    這些設定有助於確保資料可在快取中使用,而且最近的資料不會進行壓縮。 如果您的情節中可能有 TTL,請考慮使用日期階層式壓縮。 如需詳細資訊,請參閱 Apache HBase 參考指南:日期階層式壓縮

最佳化排清佇列

此建議程式表示 HBase 排清可能需要微調。 目前的排清處理常式設定可能不夠高,無法處理寫入流量,這可能會導致排清變慢。

在區域伺服器 UI 中,請注意排清佇列是否成長超過 100。 此臨界值表示排清速度很慢,您可能必須微調 hbase.hstore.flusher.count 設定。 根據預設,此值是 2。 請確定最大排清器執行緒不會增加超過 6。

此外,請查看您是否有區域計數調整的建議。 如果是,建議您嘗試區域微調,以查看是否有助於加速排清。 否則,調整排清器執行緒可能會有所幫助。

區域計數調整

區域計數微調建議程式指出 HBase 已封鎖更新,且區域計數可能超過最佳支援的堆積大小。 您可以微調堆積大小、memstore 大小和區域計數。

範例情節:

  • 假設區域伺服器的堆積大小為 10 GB。 預設的 hbase.hregion.memstore.flush.size128Mhbase.regionserver.global.memstore.size 的預設值為 0.4。 這表示在 10 GB 中,4 GB 會配置給 memstore (全域)。

  • 假設所有區域的寫入負載平均分佈,而且假設每個區域僅成長到 128 MB,則此設定中的區域數目上限為 32 個區域。 如果指定的區域伺服器設定為有 32 個區域,則系統就能更好地避免封鎖更新。

  • 有了這些設定,區域數目會是 100。 4 GB 的全域 memstore 現在分成 100 個區域。 因此,每個區域實際上只會針對 memstore 取得 40 MB。 當寫入是統一時,系統會經常排清,且順序 < 40 MB 的較小大小。 有許多排清器執行緒可能會增加排清速度 hbase.hstore.flusher.count

建議程式表示最好重新考慮每部伺服器的區域數目、堆積大小和全域 memstore 大小設定,以及排清執行緒的微調,以避免更新遭到封鎖。

壓縮佇列微調

如果 HBase 壓縮佇列成長到超過 2000 個,而且會定期發生,您可以將壓縮執行緒增加為較大的值。

當壓縮的檔案數量過多時,可能會導致與檔案和 Azure 檔案系統互動相關的更多堆積使用量。 因此,最好儘快完成壓縮。 在較舊的叢集中,與節流相關的壓縮設定可能會導致壓縮速率變慢。

檢查設定 hbase.hstore.compaction.throughput.lower.boundhbase.hstore.compaction.throughput.higher.bound。 如果這些設定已設定為 50M 和 100M,請保持原樣。 不過,如果您將這些設定設為較低的值 (較舊的叢集就是如此),請將限制分別變更為 50M 和 100M。

這些設定是 hbase.regionserver.thread.compaction.smallhbase.regionserver.thread.compaction.large (預設值為每個 1 個)。 將這個設定的最大值上限設為小於 3。

完整資料表掃描

完整資料表掃描建議程式指出發出的超過 75% 的掃描是完整資料表/區域掃描。 您可以重新瀏覽程式碼呼叫掃描的方式,以改善查詢效能。 請考慮下列做法:

  • 設定每個掃描資料列的適當開始和停止。

  • 使用 MultiRowRangeFilter API,讓您可以在一個掃描呼叫中查詢不同的範圍。 如需詳細資訊,請參閱 MultiRowRangeFilter API 文件

  • 如果您需要完整資料表或區域掃描,請檢查是否有可能避免這些查詢的快取使用量,讓其他使用快取的查詢可能不會收回經常性存取的區塊。 若要確保掃描不會使用快取,請在程式碼中使用掃描 API 搭配 [setCaching (false)] 選項:

    scan#setCaching(false)
    

下一步

使用 Ambari 最佳化 Apache HBase