調整 Azure 串流分析作業以增加輸送量

  • 發行項

本文說明如何微調串流分析查詢，以增加串流分析作業的輸送量。 您可以使用下列指南來調整作業以處理更高的負載，並利用更多系統資源（例如更多頻寬、更多 CPU 資源、更多記憶體）。 作為必要條件，您可能需要閱讀下列文章：

案例 1 – 您的查詢原本就可在輸入分割區之間完全平行處理

如果您的查詢原本就可在輸入分割區之間完全平行處理，您可以遵循下列步驟：

  1. 使用 PARTITION BY 關鍵詞撰寫查詢，以令人尷尬地平行處理。 如需詳細資訊，請參閱此頁面的尷尬平行作業一節。
  2. 視查詢中使用的輸出類型而定，某些輸出可能無法平行處理，或需要進一步的組態才能令人尷尬地平行。 例如，Power BI 輸出無法平行處理。 輸出一律會在傳送至輸出接收之前合併。 Blob、數據表、ADLS、服務匯流排 和 Azure 函式會自動平行處理。 SQL 和 Azure Synapse Analytics 輸出有平行處理的選項。 事件中樞必須設定 PartitionKey 組態以符合 PARTITION BY 欄位（通常是 PartitionId）。 針對事件中樞，也請特別注意比對所有輸入和所有輸出的數據分割數目，以避免在分割區之間交叉。
  3. 使用 1 SU V2 執行您的查詢（這是單一運算節點的完整容量），以測量可達到的最大輸送量，如果您使用 GROUP BY，請測量作業可以處理的群組數（基數）。 作業達到系統資源限制的一般徵兆如下。
    • SU% 使用率計量超過 80%。 這表示記憶體使用量很高。 此處將說明造成此計量增加的因素。
    • 輸出時間戳在時鐘時間方面落後。 視您的查詢邏輯而定，輸出時間戳可能會有時鐘時間的邏輯位移。 不過，他們應該以大致相同的速度進行。 如果輸出時間戳進一步落後，表示系統過度使用。 可能是下游輸出接收節流或高CPU使用率的結果。 我們目前不提供 CPU 使用率計量，因此很難區分這兩者。
      • 如果問題是由於接收節流，您可能需要增加輸出分割區的數目（以及輸入數據分割以保持作業完全平行處理），或增加接收的資源量（例如 Cosmos DB 的要求單位數目）。
    • 在作業圖表中，每個輸入都有每個數據分割待辦專案事件計量。 如果待辦專案事件計量持續增加，這也是系統資源受到限制的指標（可能是因為輸出接收節流或高 CPU）。
  4. 一旦您判斷 1 SU V2 作業可達到的限制，就可以在新增更多 SU 時，以線性方式推斷作業的處理容量，假設您沒有任何數據扭曲會使特定分割區「熱」。

注意

選擇正確的串流單位數目：因為串流分析會為每個新增的 1 個 SU V2 建立處理節點，所以最好讓節點數目成為輸入分割區數目的除數，因此分割區可以平均分散到節點。 例如，您已測量 1 SU V2 作業可以達到 4 MB/秒的處理速率，而您的輸入分割區計數為 4。 您可以選擇使用 2 個 SU V2 來執行作業，以達到大約 8 MB/秒的處理速率，或 4 個 SU V2 以達到 16 MB/秒。 然後，您可以決定何時將作業的 SU 數目增加為值，做為輸入速率的函式。

案例 2 - 如果您的查詢不是令人尷尬的平行。

如果您的查詢不是尷尬的平行查詢，您可以遵循下列步驟。

  1. 先從沒有 PARTITION BY 的查詢開始，以避免分割複雜度，並使用 1 SU V2 執行查詢，以測量案例 1 的最大負載。
  2. 如果您可在輸送量方面達到預期負載，即已完成。 或者，您可以選擇測量以 2/3 SU V2 和 1/3 SU V2 小數節點執行的相同作業，以找出適用於您案例的串流單位數目下限。
  3. 如果您無法達到所需的輸送量，如果查詢還沒有多個步驟，請嘗試將查詢分成多個步驟，並針對查詢中的每個步驟配置最多 1 個 SU V2。 例如，如果您有 3 個步驟，請在 [調整] 選項中配置 3 個 SU V2。
  4. 執行這類作業時，串流分析會將每個步驟放在具有專用 1 SU V2 資源的專屬節點上。
  5. 如果您仍然未達到負載目標，您可以從離輸入更近的步驟開始，嘗試使用 PARTITION BY 。 對於 可能不可自然分割的 GROUP BY 運算符，您可以使用本機/全域匯總模式來執行分割 的 GROUP BY ，後面接著非 分割的 GROUP BY。 例如，如果您想要計算每 3 分鐘通過每個收費站的汽車數目，且數據量超出 1 SU V2 所能處理的量。

查詢：

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

在上述查詢中，您會為每個數據分割計算每個收費站的車輛，然後將所有分割區的計數加在一起。

分割后，針對步驟的每個分割區，配置 1 SU V2，讓每個分割區可以放在它自己的處理節點上。

注意

如果您的查詢無法分割，在多步驟查詢中新增額外的 SU 不一定會改善輸送量。 獲得效能的其中一種方法是使用本機/全域匯總模式減少初始步驟上的磁碟區，如步驟 5 中所述。

案例 3 - 您正在作業中執行許多獨立查詢。

對於某些ISV使用案例，在單一作業中處理多個租用戶的數據，針對每個租使用者使用不同的輸入和輸出，您可能會最終在單一作業中執行相當多（例如20個）獨立查詢。 假設每個這類子查詢的負載相對較小。 在此情況下，您可以遵循下列步驟。

  1. 在此情況下，請勿在查詢中使用 PARTITION BY
  2. 如果您使用事件中樞，請將輸入分割區計數縮減為 2 的最低可能值。
  3. 使用 1 SU V2 執行查詢。 針對每個子查詢的預期負載，請盡可能新增許多這類子查詢，直到作業達到系統資源限制為止。 請參閱案例 1，以取得這種情況發生時的徵兆。
  4. 一旦您達到上述的子查詢限制，請開始將子查詢新增至新的作業。 以獨立查詢數目作為函式執行的作業數目應該是相當線性的，假設您沒有任何負載扭曲。 然後，您可以預測您需要執行的 1 個 SU V2 作業數目，做為您想要服務的租用戶數目函式。
  5. 搭配這類查詢使用參考數據聯結時，請先將輸入聯集在一起，再與相同的參考數據聯結。 然後，視需要分割事件。 否則，每個參考數據聯結都會保留記憶體中的參考數據複本，可能會造成不必要的記憶體使用量。

注意

每個作業要放入多少個租使用者？ 此查詢模式通常會有大量的子查詢，而且會產生非常大且複雜的拓撲。 作業的控制器可能無法處理這類大型拓撲。 根據經驗法則，在 1/3 SU V2 作業中保留 40 個租使用者，以及 2/3 和 1 個 SU V2 作業的 60 個租使用者。 當您超過控制器的容量時，作業將不會成功啟動。

取得說明

如需進一步的協助，請嘗試 Azure 串流分析的 Microsoft Q&A 問題頁面。

下一步