了解和調整串流分析串流單位
瞭解串流單位和串流節點
串流單位 （SU） 代表配置以執行串流分析作業的計算資源。 SU 的數目愈大，為您的作業配置的 CPU 和記憶體資源就愈多。 此容量可讓您專注於查詢邏輯，並抽象化管理硬體以及時執行串流分析作業的需求。
Azure 串流分析支援兩個串流單元結構：SU V1（即將淘汰）和 SU V2（建議）。
SU V1 模型是 ASA 的原始供應專案，每 6 個 SU 會對應至作業的單一串流節點。 作業也可以搭配 1 和 3 SU 執行，這些作業也會與小數串流節點對應。 藉由新增更多提供分散式運算資源的串流節點，相應增加6個以上的6個 SU作業，到12、18、24個以上。
SU V2 模型（建議） 是簡化的結構，適用於相同計算資源的優惠定價。 在 SU V2 模型中，1 SU V2 會對應至作業的一個串流節點。 2 SU V2 對應至 2、3 到 3 等等。 具有 1/3 和 2/3 SU V2 的作業也適用於一個串流節點，但計算資源的一小部分。 1/3 和 2/3 SU V2 作業可為需要較小規模的工作負載提供符合成本效益的選項。
V1 和 V2 串流單位的基礎計算能力如下所示：
如需 SU 定價的相關信息，請流覽 Azure 串流分析定價頁面。
瞭解串流單元轉換及其套用位置
串流單位從 REST API 層自動轉換成 UI（Azure 入口網站和 Visual Studio Code）。 您會在活動記錄中注意到這項轉換，以及 SU 值與 UI 上的值不同之處。 這是設計的原因，原因是 REST API 字段僅限於整數值，ASA 作業支援小數節點（1/3 和 2/3 串流單位）。 ASA 的 UI 會顯示節點值 1/3、2/3、1、2、3、... 等，而後端（活動記錄、REST API 層）則分別顯示相同的值乘以 10 與 3、7、10、20、30。
| 標準 | 標準 V2 （UI） | 標準 V2 （後端，例如記錄、Rest API 等） |
|---|---|---|
| 1 | 1/3 | 3 |
| 3 | 2/3 | 7 |
| 6 | 1 | 10 |
| 12 | 2 | 20 |
| 18 | 3 | 30 |
| ... | ... | ... |
這可讓我們傳達相同的粒度，並消除 V2 SKU API 層的小數點。 此轉換是自動的，不會影響作業的效能。
瞭解耗用量和記憶體使用率
為了達到低延遲的串流處理，Azure 串流分析作業會在記憶體中執行所有處理。 記憶體不足時，串流作業會失敗。 因此，對於生產作業，請務必監視串流作業的資源使用量，並確定有足夠的資源配置讓作業保持 24/7 執行。
SU % 使用率計量，範圍從 0% 到 100%，描述工作負載的記憶體耗用量。 對於使用量最低的串流作業，此計量通常介於 10% 到 20% 之間。 如果 SU% 使用率很高（高於 80%），或輸入事件被積壓（即使低 SU% 使用率，因為它未顯示 CPU 使用量），您的工作負載可能需要更多計算資源，這需要您增加串流單位的數目。 最好讓 SU 計量保持在 80% 以下，以考慮偶爾的尖峰。 若要回應工作負載增加和增加串流單位，請考慮在 SU 使用率計量上設定 80% 的警示。 此外，您可以使用浮浮浮水印延遲和待處理事件計量來查看是否有影響。
設定串流分析串流單位 （SU）
登入 Azure 入口網站。
在資源清單中，尋找您想要調整的串流分析作業，然後加以開啟。
在 [作業] 頁面的 [設定 ] 標題底下，選取 [ 調整]。 建立作業時的預設 SU 數目為 1。
選擇下拉式清單中的 SU 選項，以設定作業的 SU。 請注意，您僅限於特定的 SU 範圍。
您可以在作業執行時變更指派給作業的 SU 數目。 如果您的作業使用 非資料分割輸出 ，或具有 具有不同 PARTITION BY 值的多重步驟查詢，您可能會受限於從一組 SU 值中選擇。
監視作業效能
使用 Azure 入口網站，您可以追蹤作業的效能相關計量。 若要瞭解計量定義，請參閱 Azure 串流分析作業計量。 若要深入瞭解入口網站中的計量監視，請參閱使用 Azure 入口網站 監視串流分析作業。
計算工作負載的預期輸送量。 如果輸送量低於預期，請微調輸入分割區、微調查詢，並將 SU 新增至您的作業。
一個作業需要多少 SU？
選擇特定作業所需的 SU 數目取決於輸入的數據分割組態，以及作業內定義的查詢。 [ 調整] 頁面可讓您設定正確的 SU 數目。 最佳作法是配置比所需的更多 SU。 串流分析處理引擎會以配置額外記憶體的成本，針對延遲和輸送量進行優化。
一般而言，最佳做法是從 1 SU V2 開始，用於不使用 PARTITION BY 的查詢。 然後，使用試用和錯誤方法來判斷甜蜜點，在傳遞代表性的數據量並檢查 SU% 使用率計量之後，您可以修改 SU 數目。 串流分析作業可以使用的串流單位數目上限取決於針對作業所定義的查詢中的步驟數目，以及每個步驟中的數據分割數目。 您可以在這裡深入瞭解限制。
如需選擇正確 SU 數目的詳細資訊，請參閱此頁面： 調整 Azure 串流分析作業以增加輸送量。
注意
選擇特定作業需要多少 SU，取決於輸入的數據分割組態，以及針對作業定義的查詢。 您可以針對作業在 SU 中選取最多配額。 如需 Azure 串流分析訂用帳戶配額的相關信息，請流覽 串流分析限制。 若要增加超過此配額的訂用帳戶 SU，請連絡 Microsoft 支援服務。 每個作業的 SU 有效值為 1/3、2/3、1、2、3 等等。
增加 SU% 使用量的因素
時態性（時間導向）查詢元素是串流分析所提供的一組具狀態運算元的核心集合。 串流分析會代表使用者管理內部這些作業的狀態，方法是管理記憶體耗用量、復原檢查點，以及服務升級期間的狀態復原。 雖然串流分析完全管理狀態，但用戶應該考慮的許多最佳做法建議。
請注意，即使沒有持續接收輸入事件，具有複雜查詢邏輯的作業仍可能會具有高 SU% 使用率。 這可能會在輸入和輸出事件突然暴增之後發生。 如果查詢很複雜，作業可能會繼續維持記憶體中的狀態。
SU% 使用率可能會在短時間內突然下降至 0，然後再回到預期的水準。 這是因為暫時性錯誤或系統起始的升級。 如果您的查詢未 完全平行，作業的串流單位數目可能不會減少 SU% 使用率。
在比較一段時間內的使用率時，請使用 事件速率計量。 InputEvents 和 OutputEvents 計量會顯示讀取和處理的事件數目。 也有計量指出錯誤事件的數目，例如還原串行化錯誤。 當每個時間單位的事件數目增加時，大部分情況下 SU% 就會增加。
時態元素中的具狀態查詢邏輯
Azure 串流分析作業的唯一功能之一是執行具狀態處理，例如窗口匯總、時態聯結和時態分析函式。 每個運算子都會保留狀態資訊。 這些查詢元素的視窗大小上限為七天。
時態視窗概念會出現在數個串流分析查詢元素中：
視窗匯總：輪轉、跳動和滑動視窗的 GROUP BY
時態聯結：JOIN 與 DATEDIFF 函式
時態分析函式：具有 LIMIT DURATION 的 ISFIRST、LAST 和 LAG
下列因素會影響串流分析作業所使用的記憶體（串流單位計量的一部分）：
視窗式匯總
視窗匯總所耗用的記憶體（狀態大小）不一定與視窗大小成正比。 取用的記憶體會與數據基數成正比，或每個時間範圍中的群組數目成正比。
例如，在下列查詢中，與相關聯的 clusterid 數位是查詢的基數。
SELECT count(*)
FROM input
GROUP BY clusterid, tumblingwindow (minutes, 5)
為了減輕先前查詢中高基數所造成的任何問題，您可以將事件傳送至所 clusterid分割的事件中樞，並允許系統使用 PARTITION BY 個別處理每個輸入分割區，以相應放大查詢，如下列範例所示：
SELECT count(*)
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)
一旦查詢分割出來，就會分散到多個節點。 因此，傳入每個節點的值數目 clusterid 會減少，藉此減少依運算符分組的基數。
事件中樞分割區應該由群組索引鍵分割，以避免需要縮減步驟。 如需詳細資訊，請參閱 事件中樞概觀。
時態聯結
時態聯結的記憶體耗用（狀態大小）與聯結時態性搖擺空間中的事件數目成正比，這是事件輸入速率乘以搖擺室大小。 換句話說，聯結所耗用的記憶體會與 DateDiff 時間範圍乘以平均事件速率成正比。
聯結中不相符的事件數目會影響查詢的記憶體使用率。 下列查詢用來尋找能產生點擊率的廣告曝光項目︰
SELECT clicks.id
FROM clicks
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.
在此範例中，可能會顯示許多廣告，且很少有人按一下它，而且需要將所有事件保留在時間範圍中。 視窗大小和事件出現率與記憶體耗用程度成正比。
若要補救此問題，請將事件傳送至由聯結索引鍵分割的事件中樞（在此案例中為識別碼），並允許系統使用 PARTITION BY 個別處理每個輸入分割區，以相應放大查詢，如下所示：
SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10
一旦查詢分割出來，就會分散到多個節點。 因此，進入每個節點的事件數目會減少，進而減少聯結視窗中保留的狀態大小。
時態分析函式
時態分析函式所耗用的記憶體（狀態大小）會與事件速率乘以持續時間成正比。 分析函式所耗用的記憶體與視窗大小不成正比，而是與每個時間範圍中的資料分割計數成正比。
補救類似于時態聯結。 您可以使用 PARTITION BY 相應放大查詢 。
順序不足的緩衝區
使用者可以在 [事件順序設定] 窗格中設定順序不足的緩衝區大小。 緩衝區用來保存視窗持續時間的輸入，並重新排序它們。 緩衝區的大小會與事件輸入速率成正比，乘以順序錯亂的視窗大小。 預設視窗大小為 0。
若要補救順序不足緩衝區的溢位，請使用 PARTITION BY 相應放大查詢。 一旦查詢分割出來，就會分散到多個節點。 因此，傳入每個節點的事件數目會減少，因而減少每個重新排序緩衝區中的事件數目。
輸入資料分割計數
作業輸入的每個輸入分割區都有緩衝區。 輸入分割區數目愈多，作業所耗用的資源越多。 針對每個串流單元，Azure 串流分析可以處理大約 7 MB/秒的輸入。 因此，您可以比對串流分析串流單位數目與事件中樞中的資料分割數目來進行優化。
一般而言，以 1/3 串流單位設定的作業就足以用於具有兩個分割區的事件中樞（這是事件中樞的最小值）。 如果事件中樞有更多分割區，則串流分析作業會耗用更多資源，但不一定使用事件中樞所提供的額外輸送量。
對於具有 1 V2 串流單位的作業，您可能需要來自事件中樞的 4 或 8 個分割區。 不過，請避免太多不必要的分割區，因為這會導致過多的資源使用量。 例如，串流分析作業中具有 16 個數據分割或更大的事件中樞，其具有 1 個串流單位。
參考資料
ASA 中的參考資料會載入記憶體中，以便快速查閱。 使用目前的實作時，每個具有參考資料的聯結作業都會保留記憶體中的參考資料複本，即使您與相同的參考資料聯結多次也一樣。 對於 PARTITION BY 的 查詢，每個分割區都有參考資料的複本，因此分割區會完全分離。 使用乘數效果時，如果您多次聯結參考資料與多個分割區，記憶體使用量可能會很快變得很高。
使用 UDF 函式
當您新增 UDF 函式時，Azure 串流分析會將 JavaScript 執行時間載入記憶體中。 這會影響 SU%。