題幹與適用場景
你要計算每 5 分鐘的訂單金額與訂單數。客戶端離線、網路重試和多區域傳輸會讓事件晚到，同一訂單也可能重複送出。業務希望 1 分鐘內看到初值，最終報表在 24 小時內可校正。
回答要區分事件時間與處理時間，說明視窗何時發射、遲到事件進入哪條路徑，以及下游如何識別修正結果。
面試官考察點
時間語義
強回答先定義事件時間戳、處理時間、視窗邊界與時區，再解釋 watermark 只是系統對「視窗內大多數資料已抵達」的估計。
結果生命週期
候選人應區分早期結果、視窗結束結果、遲到修正與超時丟棄，不能把一次輸出假設成永久正確。
狀態與成本
需要說明狀態保留、allowed lateness、重算範圍、熱點 key 與檢查點，否則視窗越等越久會造成狀態失控。
可觀測性
要能監控 watermark lag、遲到分布、修正比例、丟棄數量、重複率與結果新鮮度。
回答前需要澄清的問題
- 指標按事件發生時間還是到達時間統計？
- 初值允許多大誤差，最終一致的截止時間是多少？
- 遲到事件是否必須修正已發布報表？
- 事件是否帶穩定的 event_id，重複應如何去重？
- 單個 key 的最大吞吐和可接受狀態大小是多少？
- 超過截止時間的事件要丟棄、隔離，還是進入離線重算？
30 秒回答框架
「我採用事件時間視窗，讓輸入攜帶 event_id 與事件時間。主流處理器用 watermark 觸發視窗初值，設定有限的 allowed lateness 接收遲到修正；修正以同一視窗鍵和版本號寫出。超過截止時間的事件進入隔離與批量重算，不靜默改寫歷史。指標涵蓋 watermark 延遲、遲到分位數、修正率、丟棄量和狀態大小。」
分步驟深入解答
第一步：定義視窗與時間
以 UTC 事件時間切固定視窗，例如 [10:00, 10:05)。處理時間只用於延遲告警和觸發早期結果，不能替代業務時間。視窗鍵包含租戶、商品或地區，避免跨維度混算。
第二步：產生 watermark
每個分區根據已觀察到的事件時間推進 watermark，再由全域策略取安全下界。低流量分區必須有 idle 偵測，否則一個沒有新事件的分區會拖住整條管道。
第三步：安排觸發與累積
先用 processing-time trigger 發出近似結果，再在 watermark 越過視窗結束時發出主結果。選擇 accumulating 或 discarding 模式，並讓輸出攜帶 windowend、revision 和 isfinal。
第四步：處理遲到與重複
在 allowed lateness 內，按 event_id 去重後更新視窗狀態並發出新 revision。重複事件不增加金額；同一事件的重放必須得到相同結果。視窗狀態要保留到截止時間之後再清理。
第五步：設定超時回退
超過 allowed lateness 的事件寫入 quarantine，記錄原因和原始 payload。離線任務按視窗重算最近 24 小時，並用冪等 upsert 或更高 revision 覆蓋可修正結果。
第六步：驗證與發布
用可控時間戳測試亂序、重複、閒置分區、重啟恢復和遲到邊界。發布端按 (metric, windowend, revision) 去重，最終報表只消費 isfinal=true 或已過業務截止時間的版本。
高品質示範回答
「我先把事件時間、視窗和截止策略寫成契約。每個事件帶穩定 eventid、eventtime 和 schema_version，串流處理器按租戶與指標做 5 分鐘視窗。分區 watermark 推進時考慮 idle 分區，全域 watermark 作為視窗完成的保守估計。
系統立即發出 early revision，watermark 越過視窗結束後發出主 revision，並在 30 分鐘 allowed lateness 內接受遲到事件。每次輸出包含視窗邊界、revision 和最終標記，下游按鍵冪等寫入。超過 30 分鐘的事件進入隔離表，由 24 小時重算任務產生更高 revision；超過報表截止時間則只做稽核，不回寫業務帳本。
我會監控 watermark lag、p50/p95/p99 遲到時長、修正率、丟棄率、重複率、狀態位元組數、重算積壓和最終結果延遲。容量估算按活躍視窗數乘以每視窗狀態，並用 checkpoint 與狀態 TTL 控制故障恢復成本。」
常見錯誤
- 用處理時間代替事件時間 → 離線客戶端的資料落入錯誤視窗 → 保留 event_time，處理時間只用於運維觸發。
- 把 watermark 當成全域真相 → 遲到事件被靜默丟失 → 明確它是估計值，配置 allowed lateness 和隔離路徑。
- 只發一次視窗結果 → 修正無法傳播 → 使用 revision 與最終標記讓下游可冪等更新。
- 無限制等待遲到事件 → 狀態和成本無界 → 設業務截止時間，超時轉離線重算。
- 只按事件 payload 去重 → 重試改變順序就重複計數 → 使用穩定 event_id 和持久去重狀態。
- 忽略閒置分區 → watermark 停滯、延遲告警失真 → 識別 idle 分區並從全域下界暫時排除。
- 只測順序輸入 → 邊界行為上線才暴露 → 注入亂序、重複、晚到、重啟和恢復測試。
追問及應對
追問一：watermark 為什麼會停滯？
某個分區可能沒有新資料、連線異常或估計器保守。用 idle timeout、分區心跳和 watermark lag 告警區分真實靜默與故障。
追問二：allowed lateness 如何取值？
根據歷史遲到分布、業務截止時間和狀態成本選擇，並以 p99 遲到時長為起點做回放驗證。它不是越長越正確，過長會擴大狀態和修正視窗。
追問三：如何避免修正風暴？
對遲到事件做微批合併、限制每視窗修正頻率，並在下游按 revision 只保留最新值；高峰期可把非關鍵指標降級為批量修正。
追問四：超過截止時間的事件能否直接丟棄？
不能靜默丟棄。先寫隔離與稽核，統計業務影響；若帳務或合規要求完整性，就必須執行重算或人工處理。
追問五：重啟後如何保證結果不倒退？
檢查點保存視窗狀態、去重狀態和 watermark；輸出使用單調遞增 revision，下游拒絕舊 revision，恢復後從日誌重播並做一致性校驗。
來源一：Apache Beam Programming Guide
Beam 文件定義 watermark、trigger、allowed lateness 與累積模式，並說明遲到資料可以觸發新的 pane。
來源二：Apache Kafka Streams Core Concepts
Kafka Streams 文件說明 grace period 如何決定視窗繼續接收亂序記錄，以及超過視窗結束加 grace 後的丟棄語義。
來源三：Dataford 串流處理面試題
公開面試題將 watermark、遲到路由、重算和監控列為回答要點，為本題的面試場景與追問提供依據。