目录前言前置红线声明（3条不满足，禁止使用该方案）一、源头业务库建表规范【强制规范】字段定义标准【强制规范】权限与索引规范【推荐规范】兜底约束【避坑红线】【标准建表SQL模板（MySQL）】二、同步水位线与时间边界规范【强制规范】水位线元数据表设计（分区表方案兼、容低版本Hive）【强制规范】水位线更新规则【强制规范】时间边界与缓冲区设置【强制规范】时间开闭原则【推荐规范】时区统一规范【避坑红线】【水位线操作SQL模板（分区表方案）】三、ODS层抽取与去重规范【强制规范】抽取SQL固定模板（含去重）【强制规范】分区与写入规则【强制规范】脏数据过滤规则【避坑红线】四、幂等性与重跑规范【强制规范】幂等性核心原则【强制规范】常规重跑规则【强制规范】延迟数据回溯规则【避坑红线】五、ODS→DWD层合并落地规范【场景1】T+1日级全量表（90%场景首选）MERGE INTO合并模板（推荐）全外连接合并模板（兼容低版本引擎）【场景2】小时级近实时全量表【强制规范】删除操作处理规则【避坑红线】六、监控告警与对账规范【强制监控项】P0级核心告警（必须15分钟内响应）【强制监控项】P1级数据质量告警（必须2小时内响应）【推荐监控项】P2级稳定性告警【强制规范】每日对账规则1. ODS 内部对账（当天增量）2. ODS ↔ 业务库 增量对账（最核心！）3. DWD 全量 ↔ 业务库全量对账（最终一致性）4、固定对账规则1. 对账时机2. 对账口径（绝对不能变）七、应急处理与兜底方案场景1：增量漏同步（数据丢失）场景2：增量重复同步（数据冗余）场景3：业务侧违规修改update_time场景4：出现物理删除数据【强制兜底方案】月度全量修复前言在数仓治理体系中，增量同步是衔接业务系统与数仓的核心链路，也是控制存储成本、提升数据流转效率的关键机制。update_time 作为增量同步的唯一时间锚点，其规范性直接决定数据一致性、同步稳定性与整体治理成效，是数仓生产稳定运行的基础前提。生产场景中，具体表现为：（1）业务代码手动赋值update_time字段，导致时间戳异常，出现“更新时间早于创建时间”、“重复时间戳”等脏数据，直接造成增量同步漏数、重复同步等问题；