共用方式為

針對 Azure HDInsight 上的 Apache HBase 效能問題進行疑難排解

  • 發行項

本文描述在 Azure HDInsight 上取得最佳效能的各種 Apache HBase 效能微調指導方針與祕訣。 其中許多祕訣取決於特定的工作負載與讀取/寫入/掃描模式。 在生產環境中套用設定變更之前，請先徹底測試這些變更。

HBase 效能見解

大部分 HBase 工作負載的最常見瓶頸是預寫記錄檔 (WAL)。 其會嚴重影響寫入效能。 HDInsight HBase 具有個別的儲存體計算模型。 即使虛擬機器裝載區域伺服器，資料仍會從遠端儲存在 Azure 儲存體上。 直到最近，WAL 也能寫入 Azure 儲存體了。 在 HDInsight 中，此行為會放大此瓶頸。 加速寫入功能的設計目的是要解決此問題。 其會將 WAL 寫入 Azure 進階 SSD 受控磁碟。 這可大幅提升寫入效能，可協助某些大量寫入工作負載所面臨的許多問題。

若要大幅改善讀取作業，請使用進階區塊 Blob 儲存體帳戶作為遠端儲存體。 只有在已啟用 WAL 功能時，才能使用此選項。

壓縮

壓縮是社群中默認的另一個潛在瓶頸。 根據預設，HDInsight HBase 叢集上會停用主要壓縮。 壓縮已停用，因為即使其為需要大量資源的程式，客戶還是有完整彈性可以根據其工作負載進行排程。 例如，他們可以在離峰期間加以排程。 此外，因為我們的儲存體是遠端 (受 Azure 儲存體支援)，而不是本機 Hadoop 分散式檔案系統 (HDFS)，所以不考慮資料位置。

客戶應該在方便時排程主要壓縮。 若未執行此維護，壓縮將會對長時間執行的讀取效能造成負面影響。

針對掃描作業，平均延遲超過 100 毫秒應該是考量的原因。 檢查是否已精確地排程主要壓縮。

Apache Phoenix 工作負載

回答下列問題可協助您更了解 Apache Phoenix 工作負載：

  • 您的所有「讀取」都會翻譯為掃描嗎？
    • 若是，這些掃描的特性是什麼？
    • 您是否已針對這些掃描，將 Phoenix 資料表結構描述最佳化，包括適當的索引編制？
  • 您是否使用 EXPLAIN 陳述式來了解「讀取」產生的查詢計劃？
  • 您的寫入是 "upsert-selects" 嗎？
    • 若是，其也會進行掃描。 相較於 HBase 中的 10 毫秒，掃描的預期延遲大約為 100 毫秒。

測試方法與計量監視

若您使用 Yahoo! 等基準測試 使用雲端服務基準測試、JMeter 或 Pherf 測試及調整效能時，請確定：

  • 用戶端電腦不會成為瓶頸。 若要這樣做，請檢查用戶端電腦上的 CPU 使用量。

  • 用戶端設定 (例如執行緒數目) 會適當地調整為飽和用戶端頻寬。

  • 測試結果會精確且有系統地記錄。

若您的查詢突然開始比之前差很多，請檢查應用程式程式碼中是否有潛在的 Bug。 是否突然產生大量的無效資料？ 若是，其可能會增加讀取延遲。

移轉問題

若您要移轉至 Azure HDInsight，請確定您的移轉是以系統化且精確的方式完成，最好是透過自動化。 避免手動移轉。 請確定：

  • 資料表屬性會精確移轉。 屬性可以包含為壓縮、綻開篩選等。

  • Phoenix 資料表中的 Salt 處理設定會適當地對應至新的叢集大小。 例如，Salt 處理貯體數目應該是叢集中背景工作節點數目的倍數。 您應該使用倍數，這是作用點數量的因素。

伺服器端設定調整

在 HDInsight HBase 中，HFiles 會儲存在遠端儲存體上。 當快取遺漏時，讀取的成本會高於內部部署系統，因為內部部署系統上的資料是由本機 HDFS 所支援。 在大部分情況下，HBase 快取 (區塊快取與貯體快取) 智慧型使用方式的設計訴求為規避此問題。 若問題未規避，則使用進階區塊 Blob 帳戶可能有助於此問題。 Windows Azure 儲存體 Blob 驅動程式依賴某些屬性，例如：fs.azure.read.request.size 會根據其判斷為讀取模式 (循序與隨機) 的內容來擷取區塊中的資料，因此可能會持續有較高的讀取延遲執行個體。 透過經驗實驗，我們發現將讀取要求區塊大小 (fs.azure.read.request.size) 設定為 512 KB，並將 HBase 資料表的區塊大小比對為相同大小會產生最佳做法。

針對大部分的大型節點叢集，HDInsight HBase 會在連結至虛擬機器的本機進階 SSD 上提供 bucketcache 作為檔案，以執行 regionservers。 改用卸載快取可能會提供一些改善。 此因應措施有使用可用記憶體的限制，而且可能小於檔案式快取，因此可能不一定是最佳選擇。

下列是我們調整後的一些其他特定參數，而且似乎提供不同程度的協助：

  • 將 memstore 大小從預設 128 MB 增加到 256 MB。 一般而言，針對大量寫入案例，建議使用此設定。

  • 將專用於壓縮的執行緒數目，從預設值 1 增加到 4。 若我們觀察到頻繁的次要壓縮，則與此設定相關。

  • 避免因為存放區限制而封鎖 memstore 排清。 若要提供此緩衝區，請將 Hbase.hstore.blockingStoreFiles 設定增加為 100。

  • 若要控制排清，請使用下列設定：

    • Hbase.regionserver.maxlogs：140 (因為 WAL 限制而避免排清)

    • Hbase.regionserver.global.memstore.lowerLimit：0.55

    • Hbase.regionserver.global.memstore.upperLimit：0.60

  • 執行緒集區微調的 Phoenix 特定設定：

    • Phoenix.query.queuesize：10000

    • Phoenix.query.threadpoolsize：512

  • 其他 Phoenix 特定設定：

    • Phoenix.rpc.index.handler.count：50 (若有大型或許多索引查閱)

    • Phoenix.stats.updateFrequency：1 小時

    • Phoenix.coprocessor.maxmetadatacachetimetolivems：1 小時

    • Phoenix.coprocessor.maxmetadatacachesize：50 MB

  • RPC 逾時：3 分鐘

    • RPC 逾時包括 HBase RPC 逾時、HBase 用戶端掃描器逾時，以及 Phoenix 查詢逾時。
    • 請確定 hbase.client.scanner.caching 參數在伺服器端與用戶端中都設定為相同值。 若其不相同，則此設定會導致與 OutOfOrderScannerException 相關的用戶端錯誤。 此設定應該設定為大型掃描的最低值。 我們將此值設定為 100。

其他考量

下列是考慮微調的其他參數：

  • Hbase.rs.cacheblocksonwrite – 根據預設，在 HDI 上，此設定會設定為 true。

  • 設定允許延遲次要壓縮以供稍後使用。

  • 實驗性設定，例如調整保留給讀取與寫入要求的佇列百分比。

下一步

若問題尚未解決，請前往下列通道以取得更多支援：

  • 透過 Azure 社群支援獲得由 Azure 專家所提供的解答。

  • 與 @AzureSupport 連絡。 這是用於改善客戶體驗的官方 Microsoft Azure 帳戶。 其會與 Azure 社群連絡，具有正確的資源：解答、支援與專家。

  • 如果需要更多協助，您可在 Azure 入口網站提交支援要求。 從功能表列中選取 [支援] 或開啟 [說明 + 支援] 中樞。 如需詳細資訊，請參閱如何建立 Azure 支援要求。 您的 Microsoft Azure 訂閱包括訂閱管理與帳單支援的存取權，並透過其中一項 Azure 支援方案提供技術支援。