Azure 串流分析 在每次工作執行時都會在內部維護狀態資訊，並定期將該狀態儲存到檢查點。 若作業失敗或升級，串流分析可利用最新的檢查點進行復原。 當作業無法使用檢查點時，便會改為執行重播，重新處理近期的輸入事件以重建其狀態。
本文說明了 Azure 串流分析 中檢查點與重播的運作方式，以及它們如何影響工作恢復所需的時間。
時態性元素中的具狀態查詢邏輯
Azure 串流分析 工作的獨特功能之一是執行有狀態處理，例如視窗聚合、時間連接及時間分析函數。 這些運算元在工作執行時會保留狀態資訊。 這些查詢元素的時間範圍上限是七天。
時間範圍概念出現在數個「串流分析」查詢元素中：
- 視窗彙總 (Tumbling、Hopping 及 Sliding 視窗的 GROUP BY)
- 時間聯結 (含 DATEDIFF 的 JOIN)
- 時間分析函數（ISFIRST、LAST 和 LAG 限制持續時間）
節點故障後的工作復原，包括作業系統升級
每次 Stream Analytics 工作執行時，服務會在內部擴展，跨多個工作節點進行工作。 服務每隔幾分鐘檢查每個工作節點的狀態，有助於在發生故障時恢復。
有時，某個工作節點可能會失敗，或該工作節點可能進行作業系統升級。 為了自動恢復，Stream Analytics 會取得一個新的健康節點，並從最新的可用檢查點恢復前一個工作節點的狀態。 若要繼續執行工作，該作業會重播少量的資料，以從上一個檢查點還原狀態。 通常，恢復間隔只有幾分鐘。 當你選擇足夠的串流裝置完成任務時，重播會很快完成。
在完全平行查詢中，工作節點故障後追趕所需的時間與以下成正比：
[輸入事件率] x [間隙長度] / [處理分割區數量]
如果你發現節點故障和作業系統升級導致處理延遲，可以考慮讓查詢完全平行，並擴展工作以分配更多串流單元。 欲了解更多資訊，請參閱 「擴展 Azure 串流分析 工作以提升吞吐量」。
Stream Analytics 目前不會顯示這類復原過程發生時的報告。
服務升級後的工作恢復
Microsoft 偶爾會升級執行 Azure 服務中 Stream Analytics 工作所需的二進位檔。 此時，Microsoft 會將執行中的作業升級到新版本，並自動重啟。
Azure 串流分析會在可行時使用檢查點，從上次建立檢查點的狀態還原資料。 當串流分析無法使用內部檢查點時，重播技術會恢復整個串流查詢的狀態。 要讓 Stream Analytics 的工作重播完全相同的輸入，請將來源資料的保留政策設定為至少與查詢視窗大小相同。 若未做到，可能會導致服務升級時出現錯誤或部分結果，因為 Stream Analytics 可能無法保留足夠早的來源資料以涵蓋完整視窗大小。
一般而言，所需的重播時間與視窗大小乘以平均事件率成正比。 例如，對於輸入速率為每秒 1,000 個事件的作業，若視窗大小超過一小時，重播量就會很大。 服務可能需要重新處理最多一小時的資料來初始化狀態，才能產生完整且正確的結果，這可能導致輸出延遲（無法輸出）一段時間。 沒有視窗或其他時間運算子的查詢，例如 JOIN 或 LAG，其重播量為零。
估計重播追趕時間
要估算因服務升級所造成的延遲時間，請遵循以下技術：
- 以預期的事件速率，將足夠的資料載入輸入事件中樞，以涵蓋查詢中最大的視窗大小。 事件的時間戳記在該段期間內應該要接近實際時間，就像是即時輸入的資料流一樣。 例如，如果您的查詢有三天的時間範圍，請連續三天將事件傳送至事件中樞，並持續傳送事件。
- 開始工作時，先用 「現在 」作為開始時間。
- 測量從開始時間到工作產生第一個輸出之間的時間。 這段時間大致等同於服務升級過程中工作造成的延遲。
- 如果延遲太久，試著將工作分割並增加串流單元數量，讓負載分散到更多節點。 或者，考慮縮小查詢視窗大小，並對 Stream Analytics 工作在下游匯產生的輸出進行進一步聚合或其他有狀態處理（例如使用 Azure SQL Database）。
針對升級關鍵任務時的一般服務穩定性問題，建議在成對的 Azure 區域中執行重複工作。 欲了解更多資訊，請參閱 「服務更新期間的 Guarantee Stream Analytics 工作可靠性」。
由使用者啟動的停止與啟動後的作業復原
要編輯串流工作的查詢語法，或調整輸入輸出，你需要暫停工作來進行修改並升級工作設計。 在這種情況下，當你停止串流工作再重新啟動時，恢復情境類似於服務升級。
由使用者起始的作業重新啟動無法使用檢查點資料。 要估算此類重啟期間的輸出延遲，請使用前述相同程序，若延遲過長則採取類似緩解措施。
相關內容
欲了解更多關於可靠性與可擴展性的資訊，請參閱以下文章：