資料工程面試：如何設計資料新鮮度 SLO 與監控？

題幹與適用場景

題目考察資料工程師能否把「資料要新」變成可驗證的端到端承諾。假設訂單事件從業務庫進入串流或批次管道，最後供銷售看板使用；任務成功不代表最新事件已可查詢。回答應區分事件發生、到達、處理完成與消費者可見時間，並說明遲到資料、回填和業務降級。

面試官考察點

強回答會先問業務能容忍多久的陳舊，再定義 freshness SLI/SLO、統計視窗和錯誤預算；接著沿每個階段記錄時間戳，區分上游無資料、傳輸積壓、處理變慢和查詢層延遲。它會把 source freshness 與最終產品 freshness 分開，提供分層告警、可信快照、重播和復盤指標，而不是只看 DAG 綠燈。

回答前需要釐清的問題

• 看板要求「最後一筆事件」還是完整時間窗？可容忍多久陳舊，按 p95、p99 還是最大值承諾？
• 時間戳由誰產生，時鐘是否同步？事件可能重複、亂序或遲到多久？
• 監控對象是原始來源、主題、模型、實體化表還是最終查詢結果？
• 過期時可以顯示上一份快照嗎？結算、風控等不可逆動作是否必須暫停？
• 需要支援回填、重播、跨時區和多租戶嗎？告警 owner 與升級窗口是什麼？

30 秒回答框架

「我先把業務承諾寫成 SLO，例如最近 30 天內 99% 的訂單事件在發生後 10 分鐘內可被看板查詢。每筆記錄保留 event、ingest、process 和 visible 時間，計算端到端 age 及各階段耗時，並分別監控來源停更與處理積壓。超過閾值時先標記資料延遲，顯示上一份可信快照；不可逆鏈路隔離新資料。修復後透過冪等重播、對帳和 SLO 復盤關閉事件。」

分步深入解答

第一步：把業務承諾寫成 SLO

明確「可見」的定義，例如事件進入查詢層並通過品質門禁後才算可用。用視窗化成功率表達目標，避免只寫平均延遲；同時記錄分母、排除項和錯誤預算。

第二步：統一時間語意

事件時間表示業務發生，攝取時間表示平台收到，處理完成時間表示模型產出，visible 時間表示消費者可讀。所有時間使用 UTC，並檢查時鐘偏差。若只有 updated_at，必須標註它不能代表端到端新鮮度。

第三步：拆解延遲預算

為 source、transport、queue、transform、warehouse apply 和 query cache 分配預算。端到端延遲可寫成 visibleat - eventat，階段延遲用相鄰時間戳相減；p95 超預算時即可定位瓶頸。

第四步：處理無資料與遲到資料

沒有新事件時不能把舊資料誤判為健康。以 source heartbeat 或最大已知事件時間監控停更，並單獨記錄 watermark。遲到事件在允許視窗內補算；超窗資料進隔離區並觸發對帳。

第五步：設計指標、標籤和告警

最小指標包括 freshness age、各階段延遲、watermark lag、積壓量、成功可見事件比例和快照年齡。標籤包含資料集、租戶、分割區、管道版本和 owner；告警按 warning、SLO burn 和 page 分級。

第六步：連接品質與血緣

新鮮不等於正確。把缺失率、重複率、主鍵衝突、模式變化和業務對帳結果與 freshness 關聯，沿血緣識別受影響看板。source freshness 不能代替最終產品測量。

第七步：設計降級、修復與回放

可逆展示可顯示上一份可信快照並標記最後更新時間；結算、權限、風控等不可逆動作應暫停或隔離。保留原始事件，修復後用冪等鍵重播、重算受影響視窗，再與來源對帳。

第八步：用演練證明方案有效

模擬上游停更、消費者積壓、倉庫 apply 變慢和遲到事件。確認每種故障都能在正確階段告警，runbook 給出 owner、升級時間和安全恢復步驟。復盤首次發現位置、誤報率、恢復時間與錯誤預算消耗。

可執行的檢查偽代碼

for dataset in monitored_datasets:
    source_age = now - dataset.source_max_event_time
    product_age = now - dataset.product_max_visible_event_time
    if source_age > dataset.source_slo:
        alert("source_stale", dataset.owner)
    if product_age > dataset.product_slo:
        serve_last_trusted_snapshot(dataset)

設計取捨與邊界

來源沒有更新時應報 source 停更，不應懲罰處理任務；產品表更新正常但查詢快取過期時應報 serving 層。SLO 也不能脫離完整性：一張快速但缺半數訂單的表不算達標。

落地計畫與證據

先選一個消費者少、業務影響明確的資料集。登記 owner 和時間語意，採集四類時間戳，建立 source 與 product 兩層 freshness 檢查，再接入快照降級和回放 runbook。dbt Labs 建議監控頻率與 SLA 對齊；Google Cloud CDC 文件則用應用延遲分位數評估最新資料可見性。

試點的退出條件

連續多個視窗中，SLO 成功率、首次發現位置和恢復時間可計算；故障演練能通知正確 owner；快照不會被誤用於不可逆決策；遲到和回放結果能與來源對帳。

如何證明收益不是巧合

比較試點前後 freshness 違約率、下游發現次數、p95 端到端延遲、錯誤預算消耗、恢復時間和快照使用時長，同時控制發布量和上游負載。若誤報率升高，修正閾值或分區標籤。

常見誤區與追問

只看任務成功狀態

任務成功只說明程式回傳成功，不能證明來源有新資料、所有分割區已處理或最終查詢可見。必須測量資料時間和產品時間。

用處理時間代替事件時間

處理很快但事件已在來源滯留數小時，處理時間會掩蓋陳舊。應保留 event time，並報告 source age 與端到端 age。

只設定一個全域閾值

即時風控、日報和探索分析的可接受延遲不同。按資料集、消費者和業務動作分層 SLO。

如何處理時鐘漂移？

統一 UTC，監控節點時鐘偏差；不可信時間戳應標為不確定，使用攝取時間和平台單調時間輔助。

遲到資料已經發布怎麼辦？

標記受影響視窗，隔離超窗事件，按冪等鍵重播並重算派生表，完成來源對帳後更新報表並保留審計記錄。

告警一直響但沒有事故怎麼辦？

檢查 SLO 是否與業務定義一致、分母是否包含無資料視窗、分區標籤是否遺失。用 burn-rate 和合併告警降低噪聲。