Azure HDInsight 中的 Apache HBase 建議程式

發行項
06/07/2024

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

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

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

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

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

將 hbase.rs.cacheblocksonwrite 設定為 true。 HDInsight HBase 中的這個預設設定是 true，因此請檢查其是否不會重設為 false。
增加 hbase.hstore.compactionThreshold 值，如此就可以避免壓縮啟動。根據預設，此值為 3。您可以將其增加為較高的值，例如 10。
如果您遵循步驟 2 並設定 compactionThreshold，則將 hbase.hstore.compaction.max 變更為較高的值，例如 100，同時將設定 hbase.hstore.blockingStoreFiles 的值增加為較高的值，例如 300。
如果您確定必須唯讀最近的資料，請將 hbase.rs.cachecompactedblocksonwrite 設定設為 [開啟]。此設定會告知系統即使壓縮發生，資料仍會保留在快取中。您也可以在系列等級進行這些設定。

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

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

最佳化排清佇列

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

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

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

區域計數調整

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

範例情節：

假設區域伺服器的堆積大小為 10 GB。預設的 hbase.hregion.memstore.flush.size 是 128M。 hbase.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.bound 和 hbase.hstore.compaction.throughput.higher.bound。如果這些設定已設定為 50M 和 100M，請保持原樣。不過，如果您將這些設定設為較低的值 (較舊的叢集就是如此)，請將限制分別變更為 50M 和 100M。

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

完整資料表掃描

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

設定每個掃描資料列的適當開始和停止。
使用 MultiRowRangeFilter API，讓您可以在一個掃描呼叫中查詢不同的範圍。如需詳細資訊，請參閱 MultiRowRangeFilter API 文件。
如果您需要完整資料表或區域掃描，請檢查是否有可能避免這些查詢的快取使用量，讓其他使用快取的查詢可能不會收回經常性存取的區塊。若要確保掃描不會使用快取，請在程式碼中使用掃描 API 搭配 setCaching (false) 選項：
```
scan#setCaching(false)
```

下一步

使用 Ambari 最佳化 Apache HBase

共用方式為