使用 Machine Learning Studio (傳統) 函式調整串流分析作業
提示
強烈建議使用 Azure Machine Learning UDF，而非 Machine Learning Studio (傳統) UDF，以改善效能和可靠性。
重要
對於 Azure Machine Learning 工作室 (傳統) 的支援將於 2024 年 8 月 31 日結束。 建議您在該日期之前轉換成 Azure Machine Learning。
自 2021 年 12 月 1 日起，您就無法建立新的 Machine Learning 工作室 (傳統) 資源 (工作區與 Web 服務方案)。 在 2024 年 8 月 31 日之前，您可以繼續使用現有的 Machine Learning 工作室 (傳統) 實驗與 Web 服務。 如需詳細資訊，請參閱
Machine Learning 工作室 (傳統) 文件即將淘汰，未來將不再更新。
本文討論如何有效率地調整使用 Machine Learning Studio (傳統) 函式的 Azure 串流分析作業。 如需有關如何調整串流分析作業的一般資訊，請參閱 調整作業文章。
什麼是串流分析中的 Studio (傳統) 函式？
串流分析中的 Machine Learning Studio (傳統) 函式可如同一般函式呼叫使用於串流分析查詢語言中。 不過，在幕後，這些函式呼叫實際上是 Studio (傳統) Web 服務要求。
您可以藉由在相同的 Web 服務 API 呼叫中同時「批次處理」多個資料列，來改善 Studio (傳統) Web 服務要求的輸送量。 此群組稱為「迷你批次」。 如需詳細資訊，請參閱 Machine Learning Studio (傳統) Web 服務。 串流分析中的 Studio (傳統) 支援。
使用 Studio (傳統) 函式設定串流分析作業
有兩個參數可設定串流分析作業所使用的 Studio (傳統) 函式：
- Studio (傳統) 函式呼叫的批次大小。
- 為串流分析作業佈建的串流單位 (SU) 數目。
若要判斷 SU 的適當值，請決定您要最佳化串流分析作業的延遲或是最佳化每個 SU 的輸送量。 可以隨時將 SU 新增至作業，以提高妥善資料分割的串流分析查詢輸送量。 額外的 SU 會增加執行作業的成本。
判斷串流分析作業的「容許」延遲。 增加批次大小會增加 Studio (傳統) 要求的延遲，以及串流分析作業的延遲。
增加批次大小可讓串流分析作業以相同數量的 Studio (傳統) Web 服務要求處理更多事件。 Studio (傳統) Web 服務延遲的增加，通常與批次大小的增加有著次線性關係。
在任何特定情況下，請務必針對 Studio (傳統) Web 服務考慮最符合成本效益的批次大小。 Web 服務要求的預設批次大小為1000。 您可以使用串流分析 REST API 或適用於串流分析的 PowerShell 用戶端 變更此預設大小。
決定批次大小後，您可以根據函式每秒需要處理的事件數目，設定串流單位 (SU) 的數目。 如需串流單位的詳細資訊，請參閱串流分析調整作業。
每 6 個 SU 可和 Studio (傳統) Web 服務有 20 個同時連線。 不過，1 SU 的作業和 3 SU 的作業能有 20 個同時連線。
如果您的應用程式每秒產生 200,000 個事件，批次大小為 1000，則產生的 Web 服務延遲為 200 毫秒。 這個速率表示每個連線每 1 秒可以向 Studio (傳統) Web 服務提出五個要求。 透過 20 個連線，串流分析作業可以在 200 毫秒內處理 20,000 個事件，在 1 秒內可處理 100,000 個事件。
若要每秒處理 200,000 個事件，串流分析作業需要 40 個同時連線，結果出現 12 個 SU。 下圖說明串流分析作業向 Studio (傳統) Web 服務端點提出的要求︰每 6 個 SU 最多有 20 個對 Studio (傳統) Web 服務的同時連線。
一般而言，B 代表批次大小，L 代表批次大小 B 的 Web 服務延遲 (以毫秒為單位)，而具有 N 個 SU 的串流分析作業的輸送量為：
您也可以設定 Studio (傳統) Web 服務的「同時呼叫數上限」。 建議將此參數設定為最大值 (目前為200)。
如需此設定的詳細資訊，請參閱 Machine Learning Studio (傳統) Web 服務的調整文章。
範例 – 情感分析
以下範例包含具有情感分析 Studio (傳統) 函式的串流分析作業，如 串流分析 Machine Learning Studio (傳統) 整合教學課程所述。
此查詢是一個簡單的完全分割查詢，其後接著 sentiment 函式，如下列範例所示：
WITH subquery AS (
SELECT text, sentiment(text) as result from input
)
Select text, result.[Score]
Into output
From subquery
讓我們來檢查建立串流分析作業所需的設定，此作業以每秒 10,000 則推文的速率執行推文的情感分析。
使用 1 個 SU，此串流分析作業是否能夠處理此流量？ 使用預設批次大小 1000 時，作業可以跟得上輸入。 情感分析 Studio (傳統) Web 服務的預設延遲 (預設批次大小為 1000) 不會產生超過一秒的延遲。
串流分析作業的整體或端對端延遲通常是幾秒鐘的時間。 更深入了解此串流分析作業，尤其是 Studio (傳統) 函式呼叫。 若批次大小為 1000，則 10,000 個事件的輸送量大約需要對 Web 服務提出 10 個要求。 即使是一個 SU，也有足夠的同時連線可容納此輸入流量。
如果輸入事件速率增加 100 倍，則串流分析作業每秒需要處理 1,000,000 則推文。 有兩個選項可完成這種增加規模：
- 增加批次大小。
- 分割輸入串流以平行處理事件。
使用第一個選項時，會增加作業延遲。
使用第二個選項時，您必須佈建更多 SU，以擁有更多的同時 Studio (傳統) Web 服務要求。 這個較大量的 SU 會增加作業成本。
讓我們看看以下各種批次大小與延遲測量值的變化：
| Latency | 批次大小 |
|---|---|
| 200 毫秒 | 一批次 1000 個事件或以下 |
| 250 毫秒 | 一批次 5000 個事件 |
| 300 毫秒 | 一批次 10,000 個事件 |
| 500 毫秒 | 一批次 25,000 個事件 |
- 使用第一個選項 (不要佈建更多 SU)。 批次大小可以增加到 25,000。 以這種方式增加批次大小將可讓作業利用對 Studio (傳統) Web 服務的 20 個同時連線來處理 1,000,000 個事件 (每次呼叫的延遲為 500 毫秒)。 所以因為對 Studio (傳統) Web 服務要求的情感函式要求而產生的額外串流分析作業延遲會從 200 毫秒增加至 500 毫秒。 不過，批次大小無法無限增加，因為 Studio (傳統) Web 服務所需的要求承載大小是 4 MB 或更小，且Web 服務會在作業 100 秒後要求逾時。
- 使用第二個選項，批次大小會保留為 1000、Web 服務延遲為 200 毫秒，則每 20 個對 Web 服務的同時連線就能夠處理 1000 * 20 * 5 個事件 = 每秒 100,000。 因此若要每秒處理 1,000,000 個事件，作業會需要 60 SU。 相較於第一個選項，串流分析作業會產生更多 Web 服務批次要求，進而使成本提高。
下表是不同 SU 和批次大小的串流分析作業輸送量 (以每秒的事件數目表示)。
| 批次大小 (ML 延遲) | 500 (200 毫秒) | 1,000 (200 毫秒) | 5,000 (250 毫秒) | 10,000 (300 毫秒) | 25,000 (500 毫秒) |
|---|---|---|---|---|---|
| 1 SU | 2,500 | 5,000 | 20,000 | 30,000 | 50,000 |
| 3 SU | 2,500 | 5,000 | 20,000 | 30,000 | 50,000 |
| 6 SU | 2,500 | 5,000 | 20,000 | 30,000 | 50,000 |
| 12 SU | 5,000 | 10,000 | 40,000 | 60,000 | 100,000 |
| 18 SU | 7,500 | 15,000 | 60,000 | 90,000 | 150,000 |
| 24 SU | 10,000 | 20,000 | 80,000 | 120,000 | 200,000 |
| 60 SU | 25,000 | 50,000 | 200,000 | 300,000 | 500,000 |
現在，您應該已充分了解串流分析中 Studio (傳統) 函式的運作方式。 您可能也了解串流分析作業會從資料來源「提取」資料，而且每次「提取」會傳回一批事件以供串流分析作業處理。 此提取模型如何影響 Studio (傳統) Web 服務要求？
一般來說，我們為 Studio (傳統) 函式設定的批次大小不會正好可被每次串流分析作業「提取」所傳回的事件數目除盡。 發生此狀況時，會以「部分」的批次呼叫 Studio (傳統) Web 服務。 使用部分批次可避免在將各次提取的事件聯合時產生額外的作業延遲負荷。
新的函式相關監視計量
在串流分析作業的 [監視] 區域中，已加入三個額外的函式相關計量。 分別是 [函式要求]、[函式事件]、[失敗的函式要求]，如下圖所示。
其定義如下：
函式要求︰函式要求的數目。
函式事件︰函式要求中的事件數目。
失敗的函式要求︰失敗的函式要求數目。
重要心得
若要使用 Studio (傳統) 函式調整串流分析作業，請考慮下列因素：
- 輸入事件速率。
- 執行中串流分析作業容許的延遲 (和 Studio (傳統) Web 服務要求的批次大小)。
- 佈建的串流分析 SU 和 Studio (傳統) Web 服務要求數目 (額外的函式相關成本)。
以完全分割的串流分析查詢為例。 如果需要更複雜的查詢，Microsoft Q&A 的 Azure 串流分析問題頁面是可向串流分析小組取得其他協助的絕佳資源。
下一步
若要深入了解串流分析，請參閱：