題幹與適用情境
在 BigQuery 變更資料擷取（Change Data Capture，CDC）表設定的 max_staleness 窗口內，看板可以用正常延遲讀取允許陳舊的基線；待處理變更超過窗口後，查詢時合併會回傳最新結果，但延遲升高。監控需要用平台水位與作業指標區分這兩種狀態和背景套用積壓。
面試官考察重點
- 是否用
upsert_stream_apply_watermark量測已套用變更水位。 - 是否區分允許陳舊、背景積壓和 runtime merge。
- 是否將背景資源不足與查詢延遲關聯。
- 是否用業務閾值與持續時間避免告警噪聲。
回答前需要釐清的問題
確認業務容忍時間、各表 max_staleness、寫入峰值、背景作業計費或 reservation，以及看板頻率。刪除事件也要有時效要求，因為水位越過寫入時間後才算套用。
30 秒回答架構
週期讀取 INFORMATION_SCHEMA.TABLES.upsert_stream_apply_watermark，以 now - watermark 比較表設定與業務閾值；同時聚合背景 apply job 的 P95、排隊、失敗，以及 runtime merge 數與查詢延遲。水位持續超限且背景資源飽和時告警平台團隊。
分步深入解析
按資料產品建立水位年齡、max_staleness、背景套用 P95、失敗與 runtime merge 指標。允許窗口內查詢讀取基線；超出窗口時可能即時合併待處理變更，增加延遲，而且不推進水位。
告警分兩層：水位連續兩次超過業務閾值為 warning；再加上 reservation 飽和、作業超時或看板延遲才升級 page。源端心跳用來區分靜默與積壓。
處置依序核對寫入、背景作業、資源與 runtime merge，再增加容量、平滑峰值或重新評估窗口。不能只為消除告警放寬承諾。
高品質示範回答
主信號是已套用水位，背景作業和查詢合併是解釋信號。每分鐘比較水位年齡、業務閾值與表設定，再關聯 apply P95、資源飽和和查詢尾延遲。
處置後要求水位恢復、runtime merge 降低、看板延遲回歸，並以峰值重放證明容量。
常見錯誤
- 只看寫入成功或任務綠燈。
- 把事件時間當成 BigQuery 套用水位。
- 認為 runtime merge 會推進水位。
- 為消除告警無限增大窗口。
- 沒有源端心跳。
追問與回答
runtime merge 為何讓查詢變慢？
查詢需即時合併基線與待套用變更以取得最新結果。
水位為空怎麼辦？
結合 CDC 設定、最近變更與背景作業判斷；未知狀態不可視為零延遲。
刪除何時算完成？
水位越過刪除寫入時間後，才視為已套用。
如何證明擴容有效？
比較 apply P95、水位、runtime merge 和看板尾延遲，四者同時改善才通過。