擴展 Azure 串流分析工作以提升吞吐量

本文說明如何調整 Azure 串流分析查詢以提升吞吐量。利用這些縮放模式來處理較高負載，使用更多頻寬、CPU 和記憶體資源。

Azure 串流分析以串流單元（SU）來衡量計算容量。每個 SU V2 代表單一運算節點的完整容量。 極易平行化查詢是指每個輸入分割區都可以獨立處理，且分割區之間不共用資料的查詢。

Prerequisites

在開始之前，請先閱讀以下文章：

擴展一個完全可平行化的查詢

如果您的查詢在輸入分割區之間極易平行化，請遵循下列步驟：

請撰寫你的查詢，使用 「PARTITION BY」 關鍵字。欲了解更多資訊，請參閱 Azure 串流分析中使用查詢平行化。

根據查詢中使用的輸出類型，部分輸出可能無法平行化，或需要進一步組態，才能完全平行化。例如，設定輸出為平行化。並非所有輸出類型都支援平行寫入：

輸出類型	平行化支援
Azure Blob 儲存體， Azure 資料表儲存體， Azure Data Lake Storage， Azure 服務匯流排， Azure Functions	自動
Azure SQL Database， Azure Synapse Analytics	Optional. 需要設定
Azure 事件中樞	需要將 `PartitionKey` 設為與 PARTITION BY 欄位相符（通常為 `PartitionId`）。使輸入與輸出的分區數量一致，以避免交錯。
Power BI	無法平行化。輸出一律會先合併，再傳送至接收器

用 1 SU V2 （即單一運算節點的全部容量）執行你的查詢，以衡量最大可達成的吞吐量。如果你使用 GROUP BY，請評估該作業可處理多少個群組（基數）。

檢查系統資源限制。以下症狀表示您的 Azure 串流分析工作已達到資源限制：

癥狀	可能的原因	Action
SU % 利用指標超過 80%	記憶體使用率高。請參閱「了解並調整串流單位」。	再新增更多個 SU V2。
輸出時間戳記落後於牆壁時鐘時間	根據你的查詢邏輯，輸出時間戳可能會與牆壁時鐘時間有邏輯偏移。不過，他們的進展速度應該大致相同。如果輸出時間戳越來越落後，這表示系統正在過度負荷。這可能是下游輸出匯流限速，或是高 CPU 利用率所致。 Stream Analytics 目前沒有提供 CPU 利用率指標，因此兩者差異可能較為困難。	如果問題是因為接收器節流，請增加輸出分割區 (以及輸入分割區以維持平行處理)，或增加接收器資源 (例如 Azure Cosmos DB 的要求單位)。
每個分區的積壓事件指標持續增加（可見於工作圖）	輸出接收端節流或 CPU 使用率過高	同上。

線性推算容量。確定 1 個 SU V2 能處理什麼後，假設分割區間沒有資料偏差，按比例增加更多 SU。

備註

選擇正確數量的 SU V2： Azure 串流分析為每個 SU V2 建立一個處理節點。將 SU V2 的數量設為輸入分割計數的除數，使分割均勻分布。

範例： 1 SU V2 作業使用 4 個輸入分割區時，處理速度為 4 MB/s。使用2個SU V2可為~8 MB/s，或4個SU V2為約16 MB/s。根據你的目標輸入率選擇 SU V2 數量。

擴展非平行查詢

如果您的查詢不容易平行化，請遵循下列步驟：

開始時不要用 PARTITION BY ，以避免複雜度。用 1 個 SU V2 執行查詢以測量最大吞吐量。檢查前一節描述的資源限制症狀（SU 超過 80%、輸出時間戳延遲、積壓增加）。
只要達成目標吞吐量，就完成了。可選擇性地測試 2/3 SU V2 和 1/3 SU V2，找出你情境下的最低 SU V2 數量。
如果無法達到預期吞吐量，就將查詢拆分成多個步驟。為每個步驟配置最多 1 個 SU V2。例如，一個三步驟查詢需要 3 個 SU V2。 Azure 串流分析將每個步驟放在獨立的專用節點上。
如果你還沒達到吞吐量目標，可以在靠近輸入的步驟上加上 PARTITION BY 。對於無法自然分割的 GROUP BY 操作，請使用本地/全域聚合模式：先執行分割的 GROUP BY ，再執行非分割的 GROUP BY。例如，若要在流量超過 1 個 SU V2 所能處理的範圍時，每 3 分鐘統計一次通過各個收費站的車輛數：
```
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
```
此查詢在 Step1 中依各分割區的每個收費亭計算車輛數量，然後在最後一步彙總各分割區的計數結果。

劃分查詢後，每個步驟的每個分區分配 1 個 SU V2，讓每個分區都能在自己的處理節點上執行。

備註

如果你的查詢無法分割，在多步驟查詢中加入更多 SU V2 可能無法提升吞吐量。為了提升效能，請在初期階段使用步驟 4 所示的局部/全域彙總模式來減少交易量。

在單一作業中擴充多個獨立查詢

對於多租戶獨立軟體供應商（ISV）情境，當你在單一 Azure 串流分析工作中處理多個租戶的資料（每個租戶有獨立的輸入與輸出），每個子查詢的負載通常都很小。請遵循下列步驟：

查詢時不要使用 PARTITION BY 。
如果你使用 Azure 事件中樞，請將輸入分割區數量減少到最小值 2。
用 1 個 SU V2 執行查詢。不斷增加子查詢，直到工作達到資源限制。症狀與完全可平行化的查詢相同：SU 使用率超過 80%、輸出時間戳延遲，或積壓清單增加。
達到子查詢數量上限後，請將新的子查詢加入另一個獨立的作業中。工作數量會隨著獨立查詢數量線性增加（假設沒有負載偏斜）。接著你可以根據想要服務的租戶數量，預測需要執行多少 SU V2 工作。
對於參考資料的連接，先將所有輸入合併，再與參考資料合併，然後再拆分事件。否則，每個參考資料連接都會在記憶體中保留獨立的參考資料副本，這可能導致不必要的記憶體使用。

備註

每個工程的最大租戶數： 1/3 的 SU V2 工作要保持在 40 名租戶以下，2/3 和 1 SU V2 的租戶人數要維持在 60 名。大量子查詢會產生複雜的拓撲結構，工作控制器可能無法處理，導致作業無法啟動。

尋求幫助

如需進一步協助，請參考 Microsoft 關於 Azure 串流分析的問答頁面。

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-06-11