Azure 串流分析作業中的檢查點和重新執行概念

本文說明「Azure 串流分析」中的內部檢查點和重新執行概念,以及這些概念對作業復原的影響。 每次「串流分析」作業執行時,都會在內部維護狀態資訊。 該狀態資訊會定期儲存在檢查點中。 在某些情況下,當發生作業失敗或升級時,會使用檢查點資訊來進行作業復原。 在其他情況下,則無法使用檢查點來進行復原,而是必須使用重新執行。

時態性元素中的具狀態查詢邏輯

Azure 串流分析作業的其中一個獨特功能是執行具狀態的處理工作,如視窗型彙總、時態性聯結及時態性分析函式。 這當中的每個運算子都會保留作業執行時的狀態資訊。 這些查詢元素的時間範圍上限是七天。

時間範圍概念出現在數個「串流分析」查詢元素中:

  1. 視窗型彙總 (輪轉視窗、跳動視窗和滑動視窗的 GROUP BY)

  2. 時態性聯結 (搭配 DATEDIFF 的 JOIN)

  3. 時態性分析函數 (搭配 LIMIT DURATION 的 ISFIRST、LAST 和 LAG)

從節點失敗 (包括 OS 升級) 復原作業

每次「串流分析」作業執行時,都會在內部相應放大規模以跨多個背景工作節點執行工作。 每隔幾分鐘都會對每個背景工作節點的狀態執行檢查點檢查,這有助於在發生失敗時復原系統。

有時,指定的背景工作節點可能會發生失敗,或該背景工作節點可能會進行作業系統升級。 若要自動復原,「串流分析」必須要有一個狀況良好的新節點,而先前背景工作節點的狀態會從最新可用的檢查點還原。 若要繼續執行工作,必須要有少量的重新執行,才能從建立檢查點的時間還原狀態。 通常,還原間距只有幾分鐘的時間。 為作業選取的「資料流單位」足夠時,重新執行應該會快速完成。

在完全平行的查詢中,於背景工作節點失敗後,其趕上進度所花費的時間會與下列值成比例:

[輸入事件速率] x [間距長度] / [處理中分割區數目]

如果您觀察到因節點失敗和 OS 升級而造成的明顯處理延遲,請考慮讓查詢變成完全平行,然後調整作業以配置更多的「資料流單位」。 如需詳細資訊,請參閱調整 Azure 串流分析作業以增加輸送量

目前「串流分析」在這種復原程序正在進行時,並不會顯示報告。

從服務升級復原作業

Microsoft 偶爾會升級在 Azure 服務中執行「串流分析」作業的二進位檔。 在這些時間,系統會將執行工作的使用者升級至較新的版本,而工作則會自動重新啟動。

Azure 串流分析會盡可能使用檢查點,從最後一個檢查點狀態還原資料。 在無法使用內部檢查點的情況下,串流查詢的狀態會完全使用重新執行技術予以還原。 為了允許「串流分析」作業重新執行與之前完全相同的輸入,請務必將來源資料的保留原則設定為至少與您查詢中的時間範圍相同。 如果未能這樣做,可能會造成服務升級期間結果不正確或只產生部分結果,因為來源資料的保留期間可能不足以往回涵蓋到整個時間範圍。

一般而言,所需的重新執行量會與時間範圍乘以平均事件速率成比例。 舉例來說,如果作業的輸入速率為每秒 1000 個事件,當時間範圍大於一小時時,重新執行大小就會被視為偏大。 最多可能需要重新處理一個小時的資料來將狀態初始化,如此就能產生完整且正確的結果,這樣可能會在某個延長期間導致延遲輸出 (沒有輸出)。 不含時間範圍或其他時態性運算子 (例如 JOINLAG) 的查詢不會進行任何重新執行。

估計重新執行趕上時間

若要估計因服務升級所導致的延遲時間長度,您可以依照這項技術進行操作:

  1. 以預期的事件速率,在輸入事件中樞內載入足夠的資料,以涵蓋您查詢中的最大時間範圍大小。 事件的時間戳記應該在該整個期間都接近時鐘時間,就像是即時輸入摘要一樣。 例如,如果您查詢中的時間範圍是 3 天,則請將事件傳送至事件中樞長達三天,然後繼續傳送事件。

  2. 使用 [立即] 作為開始時間來啟動作業。

  3. 測量從開始時間到產生第一個輸出之間的時間。 此時間大約就是服務升級期間作業會產生的延遲時間。

  4. 如果延遲時間太長,請嘗試分割作業,然後增加 SU 數目,以便將負載分散到更多節點。 或者,請考慮縮小查詢的時間範圍大小,並對下游接收器中串流分析工作所產生的輸出執行進一步彙總或其他具狀態處理 (例如,使用 Azure SQL Database)。

若是對升級任務關鍵性作業期間的一般服務穩定性有疑慮,請考慮在配對的 Azure 區域中執行重複的作業。 如需詳細資訊,請參閱在服務更新期間確保串流分析工作可靠性

從使用者所起始的停止和啟動復原作業

若要編輯串流作業的相關查詢語法,或是調整輸入和輸出,必須將作業停止以進行變更,然後升級作業設計。 在這類案例中,當使用者停止串流作業再重新啟動它時,復原案例會與服務升級類似。

檢查點資料無法用於使用者所起始的作業重新啟動。 若要估計這類重新啟動期間的輸出延遲,請使用與上一節所述相同的程序,如果延遲時間太長,便套用類似的風險降低措施。

下一步

如需有關可靠性和延展性的詳細資訊,請參閱下列文章: