使用 Azure 資料總管最佳化高並行
在具有大型使用者基底的案例中，需要高度並行的應用程式，其中應用程式會同時處理具有低延遲和高輸送量的許多要求。
使用案例包括大規模監視和警示儀錶板。 範例包括 Microsoft 產品和服務，例如 Azure 監視器、Azure 時間序列深入解析 和 Playfab。 所有這些服務都會使用 Azure Data Explorer 來提供高並行工作負載。 Azure Data Explorer 是快速、完全受控的巨量數據分析服務，可用於從應用程式、網站、IoT 裝置等大量數據串流進行即時分析。
注意
可以同時在叢集上執行的查詢數目取決於叢集 SKU、數據磁碟區、查詢複雜度和使用模式等因素。
若要設定高並行應用程式，請設計後端架構，如下所示：
本文提供上述每個主題的建議，您可以實作這些主題，以最佳且符合成本效益的方式達成高並行性。 這些功能可以單獨或組合使用。
優化數據
針對高並行，查詢應該會耗用最少的CPU資源數量。 您可以使用下列任一或所有方法：
使用數據表架構設計最佳做法
使用下表架構設計建議，將所使用的CPU資源降到最低：
- 不論值是否為數值，標識符數據行都應該定義為字串數據類型。 字串數據行的索引比數值數據行更複雜，並提供更佳的篩選效能。
- 以最佳方式比對數據行數據類型與儲存在這些數據行中的實際數據。 例如，不要將 datetime 值儲存在字串數據行中。
- 避免具有許多數據行的大型疏鬆數據表，並使用動態數據行來儲存疏鬆屬性。
- 使用非動態數據類型，將常用屬性儲存在自己的數據行中。
- 將數據反正規化，以避免聯結需要相對大型的 CPU 資源。
分割資料
數據會以範圍的形式儲存 (數據分區) ，且預設會依擷取時間進行分割。 您可以使用 數據分割原則 ，根據單一字串數據行或背景進程中的單一 datetime 數據行來重新分割範圍。 當大部分的查詢使用分割區索引鍵來篩選、匯總或兩者時，數據分割可以提供顯著的效能改善。
注意
數據分割進程本身會使用 CPU 資源。 不過，查詢時間期間的CPU縮減應該超過用於分割的CPU。
使用具體化檢視預先匯總您的數據
預先匯總您的數據，以大幅減少查詢時間期間的CPU資源。 範例案例包括摘要數據點超過縮短的時間間隔數目、保留指定記錄的最新記錄，或重複數據刪除數據集。 使用 具體化檢視 ，輕鬆設定源數據表上的匯總檢視。 此功能可簡化建立和維護這些匯總檢視的工作。
注意
背景匯總程式會使用 CPU 資源。 不過，查詢時間期間的CPU縮減應該超過匯總的CPU耗用量。
設定快取原則
設定快取原則，讓查詢在儲存在經常性記憶體的數據上執行，也稱為磁碟快取。 只在冷記憶體或外部數據表上執行有限、謹慎設計的案例。
設定領導者遵循的架構模式
追蹤程式資料庫是一項功能，會從位於相同區域的另一個叢集，追蹤資料庫中的資料庫或一組數據表。 此功能會透過 Azure Data Share、Azure Resource Manager API 和一組叢集命令公開。
使用領導者追蹤模式來設定不同工作負載的計算資源。 例如，設定用於擷取的叢集、查詢或提供儀錶板或應用程式的叢集，以及提供數據科學工作負載的叢集。 在此情況下，每個工作負載都會有可獨立調整的專用計算資源，以及不同的快取和安全性設定。 所有叢集都會使用相同的數據，讓領導者以唯讀模式寫入數據，以及使用該數據的粉絲。
注意
追蹤者資料庫與領導者有延遲，通常是幾秒鐘的時間。 如果您的解決方案需要沒有延遲的最新數據，此解決方案可能很有用。 使用追蹤者叢集的檢視，將領導者和追蹤者的數據聯集在一起，並查詢來自領導者的最新數據，以及來自追蹤者的數據其餘部分。
若要改善追蹤者叢集上查詢的效能，您可以啟用 預先擷取範圍設定。 請仔細使用此組態，因為它可能會影響追蹤資料庫中數據的有效性。
最佳化查詢
使用下列方法將查詢優化為高並行。
遵循 查詢最佳做法 ，讓您的查詢盡可能有效率。
使用查詢結果快取
當一位以上的使用者在同一時間載入相同的儀錶板時，儀錶板會從快取提供到第二個儀錶板並追蹤使用者。 此設定提供幾乎沒有CPU使用量的高效能。 使用 查詢結果快取 功能，並使用語句以查詢傳送查詢結果快取組 set 態。
Grafana 包含數據源層級查詢結果快取的組態設定，因此所有儀錶板預設都會使用此設定，且不需要修改查詢。
設定查詢一致性
默認 查詢一致性 模式為 強式。 在此模式中， 系統管理 節點會管理叢集的元數據和擷取，以及查詢規劃和委派執行給其他節點。
在高併行應用程式中，管理查詢可能會導致 系統管理 節點的CPU使用率偏高，而其他節點則較不忙碌。 這可能會造成並行查詢數目無法成長的瓶頸。 不過，在叢集的CPU報告中，這可能不會明顯 (Azure 入口網站 > {your_cluster} > 計量 > CPU計量) ，其中顯示叢集的平均CPU使用量。
在此案例中，我們建議使用 弱 式一致性模式。 在此模式中，更多節點能夠管理查詢，這可讓您 水平調整 並行查詢的數目。 此模式中的節點會定期重新整理其元數據複本和新擷取的數據，這會導致同步處理數據時，延遲通常少於一分鐘。 不過，這種簡短延遲最好是使用 強 式一致性模式時可能發生的瓶頸情況。
您可以在 工作負載群組查詢一致性原則、 用戶端要求屬性或 Grafana 數據源組態中設定一致性模式。
設定叢集原則
並行要求數目預設會受到限制，並由 要求速率限制 原則控制，因此叢集不會超載。 您可以針對高並行狀況調整此原則。 只有在嚴格測試之後，才應該調整此原則，最好是在類似生產環境的使用模式和數據集上進行調整。 測試可確保叢集可以維持修改的值。 您可以根據應用程式需求來設定此限制。
監視 Azure Data Explorer 叢集
監視叢集資源的健康情況，可協助您使用上一節中建議的功能來建置優化計劃。 適用於 Azure 的 Azure 監視器 Data Explorer 提供叢集效能、作業、使用量和失敗的完整檢視。 選取 Azure 入口網站 中 Azure Data Explorer 叢集的 [監視] 區段下的 [深入解析] (預覽) 索引卷標，以取得查詢效能、並行查詢、節流查詢和其他各種計量的深入解析。
如需監視叢集的資訊，請參閱適用於 Azure Data Explorer 的 Azure 監視器。 如需個別計量的資訊，請參閱 Azure Data Explorer 計量。