共用方式為


使用 Azure 數據總管優化以達到高並行

在具有大型使用者基底的案例中,需要高度並行的應用程式,其中應用程式可同時處理許多低延遲和高輸送量的要求。

使用案例包括大規模的監視和警示儀錶板。 範例包括Microsoft產品和服務,例如 Azure 監視器Azure 時間序列深入解析Playfab。 所有這些服務都會使用 Azure 數據總管來提供高並行工作負載。 Azure 資料總管是快速且完全受控的巨量數據分析服務,可從應用程式、網站、IoT 裝置等進行大量數據串流即時分析。

注意

可在叢集上同時執行的查詢數目取決於叢集 SKU、數據磁碟區、查詢複雜度和使用模式等因素。

若要設定高並行應用程式,請設計後端架構,如下所示:

本文提供上述每個主題的建議,您可以實作這些主題,以獲得最佳且符合成本效益的方式達到高並行。 這些功能可以單獨或結合使用。

優化數據

針對高並行存取,查詢應該會耗用最少的CPU資源數量。 您可以使用下列任何或所有方法:

使用數據表架構設計最佳做法

使用下表架構設計建議,將所使用的CPU資源降到最低:

  • 不論值是否為數值,標識符數據行都應該定義為字串數據類型。 字串數據行的索引比數值數據行更複雜,可提供更佳的篩選效能。
  • 以最佳方式比對數據行數據類型與儲存在這些數據行中的實際數據。 例如,請勿將 datetime 值儲存在字串數據行中。
  • 請避免具有許多數據行的大型疏鬆數據表,並使用動態數據行來儲存疏鬆屬性。
  • 使用非動態數據類型,將常用屬性儲存在自己的數據行中。
  • 將數據反正規化,以避免需要相對大型 CPU 資源的聯結。

分割資料

數據會以範圍形式儲存(數據分區),預設會依擷取時間進行分割。 您可以使用 數據分割原則 ,根據背景進程中的單一字串數據行或單一 datetime 數據行來重新分割範圍。 當大部分查詢使用分割區索引鍵來篩選、匯總或兩者時,數據分割可以提供顯著的效能改善。

注意

數據分割進程本身會使用 CPU 資源。 不過,查詢時間期間的CPU縮減應該超過用於分割的CPU。

使用具體化檢視預先匯總您的數據

預先匯總您的數據,以大幅降低查詢時間的 CPU 資源。 範例案例包括摘要減少時間間隔的數據點、保留指定記錄的最新記錄,或重複數據刪除數據集。 使用 具體化檢視 ,輕鬆設定源數據表的匯總檢視。 這項功能可簡化建立和維護這些匯總檢視的工作。

注意

背景匯總程式會使用 CPU 資源。 不過,查詢時間期間的CPU縮減應該超過匯總的CPU耗用量。

設定快取原則

設定快取原則,讓查詢在儲存在經常性儲存區的數據上執行,也稱為磁碟快取。 只在冷記憶體或外部數據表上執行有限且精心設計的案例。

設定領導者遵循的架構模式

追蹤者資料庫是一項功能,會從位於相同區域的另一個叢集,追蹤資料庫中的資料庫或一組數據表。 這項功能是透過 Azure Data ShareAzure Resource Manager API 和一組 叢集命令公開。

使用領導者追蹤模式來設定不同工作負載的計算資源。 例如,設定用於擷取的叢集、查詢或提供儀錶板或應用程式的叢集,以及提供數據科學工作負載的叢集。 在此情況下,每個工作負載都會有可獨立調整的專用計算資源,以及不同的快取和安全性設定。 所有叢集都會使用相同的數據,且領導者會以唯讀模式寫入數據,以及使用數據的追隨者。

注意

追蹤者資料庫與領導者有延遲,通常為幾秒鐘。 如果您的解決方案需要沒有延遲的最新數據,此解決方案可能會很有用。 使用追蹤者叢集的檢視,將領導者和追蹤者的數據結合在一起,並查詢來自領導者的最新數據,以及後續數據的其他數據。

若要改善追蹤者叢集上查詢的效能,您可以啟用 預先擷取範圍設定。 請仔細使用此設定,因為它可能會影響追蹤資料庫中數據的新鮮度。

最佳化查詢

使用下列方法,將查詢優化為高並行。

請遵循 查詢最佳做法 ,讓您的查詢盡可能有效率。

使用查詢結果快取

當一個以上的使用者在同一時間載入相同的儀錶板時,儀錶板會從快取中提供第二個儀錶板和下列使用者。 此設定提供幾乎沒有CPU使用量的高效能。 使用查詢結果快取功能,並使用語句來傳送查詢set結果快取組態。

Grafana 包含數據源層級查詢結果快取的組態設定,因此所有儀錶板預設都會使用此設定,而且不需要修改查詢。

設定查詢一致性

默認 查詢一致性 模式為 強式。 在此模式中, 系統管理 節點會管理叢集的元數據和擷取,以及查詢規劃和委派執行至其他節點。

在高併行應用程式中,管理查詢可能會導致 管理 節點的CPU使用率偏高,而其他節點則較不忙碌。 這可能會導致並行查詢數目無法成長的瓶頸。 不過,這在叢集的CPU報表中可能並不明顯(Azure 入口網站 {your_cluster > } > 計量 > CPU 計量),這會顯示叢集的平均 CPU 使用量。

在此案例中,我們建議使用 式一致性模式。 在此模式中,更多的節點能夠管理查詢,這可讓您 水平調整 並行查詢的數目。 此模式中的節點會定期重新整理其元數據復本和新擷取的數據,這會導致在同步處理數據時通常少於一分鐘的延遲。 不過,這種短暫的延遲較好於使用 式一致性模式時可能發生的瓶頸情況。

您可以在工作負載群組查詢一致性原則用戶端要求屬性或 Grafana 數據源組態中設定一致性模式。

設定叢集原則

並行要求數目預設會受到限制,並由要求速率限制原則控制,讓叢集不會超載。 您可以針對高並行狀況調整此原則。 只有在嚴格測試之後,才應該調整此原則,最好是在類似生產環境的使用模式和數據集上調整。 測試可確保叢集可以維持修改的值。 您可以根據應用程式需求來設定此限制。

監視 Azure 數據總管叢集

監視叢集資源的健康情況,可協助您使用上述各節中建議的功能來建置優化計劃。 適用於 Azure 資料總管的 Azure 監視器提供叢集效能、作業、使用量和失敗的完整檢視。 選取 Azure 入口網站 中 Azure 數據總管叢集的 [監視] 區段底下的 [深入解析] 索引標籤,以取得查詢效能、並行查詢、節流查詢和其他各種計量的深入解析。

如需監視叢集的資訊,請參閱 適用於 Azure 數據總管的 Azure 監視器。 如需個別計量的資訊,請參閱 Azure 數據總管計量