题干与适用场景
团队已有上游变更流，想把结果维护到动态表中，并覆盖软删除、流静态连接或有状态聚合。请说明如何判断 CUSTOM_INCREMENTAL 是否合适、如何定义增量逻辑、验证结果并准备回退。不要只复述 Snowflake 的发布说明。
面试官考察点
- 是否知道自定义增量刷新由开发者定义 MERGE 或 INSERT 逻辑，平台负责调度、重试与事务保证。
- 是否能区分增量刷新、全量刷新和流/Task 编排的边界。
- 是否能处理主键、变更顺序、重复事件、软删除和首次回填。
- 是否把刷新延迟、失败重试、成本、可观测性与回退方案说完整。
回答前需要澄清的问题
- 上游是 append-only、CDC 流还是会修正历史记录？删除是否需要在目标表保留墓碑？
- 目标动态表的唯一键是什么？重复事件、迟到事件和同一键多次更新如何排序？
- 逻辑是否能被增量化，还是必须定期全量重算？允许多长刷新延迟？
- 首次创建、失败重试、模式变更和回退期间，谁负责核对结果与告警？
30 秒回答框架
我会先确认数据变化能否由稳定键和水位表达，再判断自定义增量是否能安全维护目标。若选择它，就明确每次刷新读取的变更范围、MERGE/INSERT 的幂等条件、软删除和迟到事件规则；同时用对账查询比较增量结果与抽样全量结果。平台的调度、重试和事务保证不能替代业务语义。上线前要设置刷新延迟、失败、回退到标准刷新或全量重建的指标与开关。
分步骤深入解答
1. 先判断增量边界
把目标定义拆成投影、过滤、连接、聚合和删除语义。只有能明确受影响的输入行与目标键时，增量逻辑才有可验证边界；无法定位影响范围的全局排序或非确定性逻辑，应保留全量刷新方案。
2. 设计变更应用协议
为每条变更定义业务键、版本或事件时间，并规定同键冲突的胜出规则。MERGE 的匹配条件必须幂等；软删除要记录删除标志或墓碑，避免迟到的旧事件把已删除行重新写回。
3. 处理首次运行与异常
首次运行先用受控数据集比较自定义增量结果和全量基线，再扩大范围。失败重试必须能重复执行而不产生重复行；遇到模式变更、无法解释的漂移或水位断裂时暂停发布，回退到可验证的全量刷新或重建。
4. 监控正确性与成本
监控刷新延迟、受影响行数、失败次数、重试次数和上游水位；定期抽样做增量与全量对账。将仓储计算、存储、重建和下游查询成本分开估算，避免只看单次刷新耗时。
高质量示范回答
我会先把 CUSTOM_INCREMENTAL 当作一个需要证明正确性的增量维护协议。先确认每条变更有稳定业务键、版本或水位，并明确软删除、迟到事件和同键冲突规则；若无法定位受影响目标行，就保留全量刷新。随后设计幂等的 MERGE/INSERT 逻辑，用受控样本与全量基线对账，再验证重复执行、失败重试、首次回填和模式变更。动态表平台提供调度、重试和事务保证，但不替业务决定事件顺序或删除语义。上线后监控水位、刷新延迟、受影响行数、漂移和成本，并准备暂停、全量重建或回退到标准刷新模式的路径。
常见错误
- 把
CUSTOM_INCREMENTAL当成任意 SQL 都能自动增量化。 - 只写 MERGE 语句，却没有稳定键、版本和重复事件规则。
- 忽略软删除、迟到数据和首次全量回填。
- 把平台事务保证误解为业务结果天然正确。
- 没有增量与全量对账、漂移告警或回退路径。
- 只比较延迟，不估算持续刷新与重建成本。
追问及应对
什么时候坚持全量刷新？
当变更影响范围无法界定、逻辑包含全局排序或非确定性函数，或者增量结果无法通过对账证明时，优先全量刷新。可先缩小数据范围和频率，再评估是否值得增量化。
如何处理同一键的迟到事件？
为事件携带单调版本或可比较的事件时间，并在 MERGE 条件中只接受更新版本。无法建立可靠顺序时，应把冲突记录到隔离表并告警，不能静默覆盖。
怎样证明增量结果没有漂移？
按分区或键范围定期重算全量基线，比较行数、校验和和关键业务指标；把差异样本留存到审计表，超过阈值就暂停发布或触发重建。