题干与适用场景
在 BigQuery 变更数据捕获（Change Data Capture，CDC）表配置的 max_staleness 窗口内，看板可以以正常延迟读取允许陈旧的基线；待处理变更超过窗口后，查询时合并会返回最新结果，但延迟上升。监控需要用平台水位与作业指标区分这两种状态和后台应用积压。
面试官考察点
- 是否用
upsert_stream_apply_watermark测量已应用变更的水位。 - 是否区分允许的陈旧窗口、后台 apply job 积压和 runtime merge。
- 是否把后台预留资源不足与用户查询延迟关联起来。
- 是否用业务阈值和持续时间告警，避免逐表瞬时噪声。
回答前需要澄清的问题
确认业务容忍的陈旧时间、每张表的 max_staleness、变更写入峰值、后台作业使用按需还是 reservation，以及看板查询频率。还要确认删除事件的时效要求，因为 CDC 删除只有在水位越过其写入时间后才算应用。
30 秒回答框架
我会周期读取 INFORMATION_SCHEMA.TABLES.upsert_stream_apply_watermark，计算 now - watermark，与表的 max_staleness 和业务阈值比较；同时聚合后台 apply job 的 P95 时长、排队和失败，以及 runtime merge 的数量与查询延迟。水位持续超限且后台资源饱和时告警数据平台；查询时合并上升但水位随后恢复时，优先调整后台容量或陈旧窗口。
分步骤深入解答
监控任务按数据产品而非全局表名建立低基数指标：水位年龄、配置的 max_staleness、后台应用 P95、失败数和运行时合并查询数。Google Cloud 文档说明，查询在允许窗口内读取基线；若水位超过窗口，查询可能即时合并待处理变更，换取最新结果但增加延迟，且该运行时合并不会推进水位。
告警采用两层门禁：水位超过业务阈值持续两个采样周期触发 warning；同时出现后台 reservation 饱和、apply job 超时或关键看板延迟上升才升级 page。没有新变更时要结合源端心跳，避免把静默误判成积压。
处置顺序是核对写入仍在进行、查看后台作业与资源分配、确认 runtime merge 是否增加，再决定增加后台容量、降低写入峰值或重新评估 max_staleness。Google 建议该值至少覆盖业务可容忍陈旧度，并结合后台应用最长耗时留出缓冲，不能为消除告警随意放宽。
高质量示范回答
我会把已应用水位作为主信号。每分钟采集 upsert_stream_apply_watermark，与业务新鲜度和表配置比较；再把后台应用 P95、资源饱和和 runtime merge 延迟作为解释信号。这样能区分“允许的 5 分钟旧数据”“后台没追上”和“查询为追最新而临时合并”。
告警需要持续违约并带业务影响。处置后要求水位恢复、运行时合并下降、看板尾延迟回归，并用一段峰值流量重放证明容量余量。
常见错误
- 只看写入成功或流水线绿色状态。
- 把查询时间减事件时间直接当成 BigQuery 已应用水位。
- 看到 runtime merge 就认为水位已经推进。
- 为消除告警无限增大
max_staleness。 - 没有源端心跳，无法区分无数据与积压。
追问及应对
runtime merge 为什么会让查询变慢？
水位超出允许窗口时，查询要即时合并基线与待应用变更以返回最新结果，因此增加延迟和计算成本。
水位为空怎么办？
结合表是否启用 CDC、是否收到变更及最近后台作业判断。未知状态单独告警，不能当作零延迟。
删除操作何时算完成？
只有 upsert_stream_apply_watermark 越过该删除写入时间后，才把 CDC 删除视为已应用。
如何证明扩容有效？
在代表性峰值下比较扩容前后的 apply P95、水位年龄、runtime merge 数与看板尾延迟，所有指标同时改善才通过。