ODS 层全量表、增量表和快照表怎么设计？
面试怎么回答
我会先看源端是否支持可靠增量，再根据历史追溯和恢复要求选表。全量表保存当前完整状态，逻辑简单但成本高且不保留变化；增量表保存新增、更新和删除事件，适合重放，但要处理重复、乱序和水位；快照表保存某个日期的完整状态，查询审计方便但存储大。生产中通常保留原始增量，维护当前全量，并对关键数据按周期生成快照。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
同一张业务表接入 ODS，有的团队每天覆盖一份全量，有的保留 CDC，有的每天落一个快照分区。
这三种方式保存的不是同一种时间语义。
全量表回答“现在是什么”，增量表回答“发生了什么变化”，快照表回答“某天结束时是什么状态”。
全量表适合当前状态消费
每天从源端抽取全部记录，覆盖 ODS 当前表，逻辑简单，也方便下游直接读取最新状态。
但源表很大时，全量抽取对数据库、网络和计算资源压力都高；覆盖后无法解释某条记录什么时候变化，也不利于恢复误删数据。
增量表保留变化过程
增量可以来自更新时间字段、递增 ID、日志或 CDC。理想的增量记录应包含业务主键、操作类型、变更时间、采集时间和顺序信息。
增量链路要处理重复、乱序、迟到和删除。只有 upsert 后的最终值，没有 delete 语义和顺序，重放时就可能恢复出错误状态。
快照表保留历史时点状态
每日快照按日期保存当天结束时的完整状态，适合历史对比、审计和直接按天查询。
它的代价是存储重复、生成和回刷成本高。并不是所有业务表都值得永久保留每日全量快照，可以根据合规要求、历史价值和恢复目标设置保留周期。
生产上通常是组合设计
我更倾向保留可重放的原始增量，用它维护一张最新状态表；对强审计或高价值数据，再生成周期快照。
无论哪种方式，都要验证源端总量、增量条数、主键唯一、删除数量和抽样状态，并记录同步水位。这样出现断点后才能确定从哪里续跑。
一个典型场景
某业务表每天全量覆盖，月底发现一批记录一周前被误删。ODS 只有当天状态，无法判断删除时间，也无法还原删除前内容。
后来增加了原始 CDC 保留，并在消费层维护当前表。相同问题再出现时，可以按主键回放变更，而不是依赖业务方临时恢复数据库备份。
ODS 的价值不只是落地成功，还包括数据可追溯和链路可恢复。