1. 增量更新到底要解决什么问题——先搞清楚“变化”的三种形态先说个我遇到过很多次的场景。你高高兴兴接了个数仓需求业务方说“给我跑一张每日用户明细表”你第一版图省事每天全量覆盖一次数据量小的时候一切岁月静好。突然某天业务爆了几千万行变几个亿全量同步越来越慢凌晨的调度任务天天空跑报警这时候你才意识到全量同步撑不住了得改成增量。但真正让你头疼的还不是量大而是“变化”本身。数据表里每天发生的变化仔细拆开其实是三种形态新增、修改、删除。新增最好办每天往里追加就行修改就麻烦一点你得找到那条旧数据把它覆盖掉删除最恶心因为如果源系统物理删除了记录目标表里根本感知不到只能靠比对或特殊标记。增量更新方案选型本质上就是在回答你今天要处理这三种变化的哪几种愿意花多大成本去识别它们。还有个很多人忽略的点数仓里的“增量更新”不光是ODS层的事。你在ODS层用某种方式把数据同步过来到DWD层做清洗加工时同样面临“今天跑出来的结果怎么跟昨天的历史数据合并”的问题。见过不少团队ODS层增量做得挺溜结果到DWD层一张拉链表整张重建之前省下的时间全搭进去了。所以增量更新是贯穿数仓多层的一个全局设计问题不是某个任务单独的事。另外一个容易被业务逼疯的点是回刷怎么办上游业务系统补录了三天前的数据或者上游修复了某条历史数据你的增量任务如果只认“今天的变化”那补录的数据就永远进不来。这是增量更新方案里最容易翻车的地方后面我会单独讲。2. 三种主流的增量更新方式我用一张表先给你拉开数仓圈子里聊增量更新翻来覆去绕不开三种路子时间戳增量、全量比对增量、日志解析增量CDC。倒不是说只有这三种而是这三种基本覆盖了90%以上的实际场景剩下的是它们的变体和组合。先说时间戳增量这是最朴素也是用得最多的方式。源表里如果有一个“最后修改时间”字段那你每天同步时就取max(etl_time)之后的记录纯新增或覆盖到目标表。实现简单对源库压力小但致命弱点是依赖那个时间字段够不够准、够不够全。很多业务表压根没有修改时间字段或者有但业务代码不更新它那你取到的增量就是个残缺品。全量比对增量通常的做法是把源表全量拉到临时表然后和目标表做关联找出新增和变化的记录再合并进去。这种方式对源库有压力因为每天要全量读一遍源表但好处是对源表没任何侵入性不依赖业务字段发现变化的能力强。数据量在千万级以内时这个方案非常稳。日志解析增量就是通过解析数据库的 binlog / redo log拿到每一行数据的增删改事件然后回放到数仓里。像 Flink CDC、Canal 都是干这个的。这种方式最精准、对源库侵入最小实时性也最好但引入的组件多运维复杂度直线上升。你要是只有几张表要同步专门搭一套 CDC 链路边际成本不划算。三种方式没有绝对的好坏取决于你的数据量、源库类型、团队运维能力和时效性要求。我把它们的差异整理成了一张表方便你快速对照。对比维度时间戳增量全量比对增量日志解析增量CDC依赖条件表必须有可靠的时间字段无特殊依赖全靠计算比对数据库需开启 binlog 且格式为 row实现难度低中高对源库压力小只查增量区间大每天全表扫描很小日志解析实时性离线批次T1为主离线批次T1为主可做到秒级实时发现修改依赖时间字段准确能发现能发现发现删除难通过比对可发现能发现运维成本低中高适用数据量中中小大顺带提一句很多团队实际用的是“组合拳”日常用时间戳增量跑每周做一次全量比对兜底再把少量核心表用 CDC 接实时链路。增量更新从来不是单选题。3. 把三种方式掰开揉碎从原理讲到实操3.1 时间戳增量简单但不省心五个字别太天真时间戳增量的核心SQL逻辑长这样假设源表 a 里有update_time字段。-- 抽取增量数据 INSERT OVERWRITE TABLE ods_user_info_delta SELECT * FROM source_db.user_info WHERE update_time ${biz_date} AND update_time ${next_day};这里有个关键选择你拿业务时间过滤还是拿 ETL 抽取时间过滤我强烈建议固定用update_time这类业务侧的变更时间而不是etl_time这类系统时间因为系统时间等于“数据进入源库的时间”业务侧回刷历史数据时update_time会变而etl_time不会前者才能捕捉到真正的数据变化。而且只靠一条 SQL 远远不够。你还要解决一个问题增量区间内的数据既包含新增也包含修改你在目标表里执行的时候不能用简单的insert得做upsert也就是“有则更新无则插入”。Hive 里没有现成的 upsert 语法通常用full outer join或left join union all来实现。大致是这个思路-- 用左连接找出目标表中不存在或已变化的记录 INSERT OVERWRITE TABLE dwd_user_info SELECT COALESCE(b.id, a.id) AS id, COALESCE(b.name, a.name) AS name, COALESCE(b.update_time, a.update_time) AS update_time FROM ( -- 新增量数据 SELECT id, name, update_time FROM ods_user_info_delta WHERE dt ${biz_date} ) a FULL OUTER JOIN ( -- 目标表全量 SELECT id, name, update_time FROM dwd_user_info ) b ON a.id b.id;这段SQL看着简单实际跑起来会让你痛苦的地方在于每次全量 join 目标表代价并不比全量重建低。你为了节省计算量选择了增量结果 merge 的时候还是把全表 join 了一遍属于“省了个寂寞”。所以做时间戳增量目标表最好按更新时间做分区或者用 Hive 的 ACID 表 merge语句否则数据量一大性能立刻崩掉。更麻烦的是回刷场景。业务侧经常干这种事昨天发现一批数据录错了直接把源表里这几条记录改了但改的时候update_time更新成今天了好你的增量任务能抓到。但如果你是“按调度日期增量”而业务直接改了三天前的数据且没动时间字段那这条变化就永远消失在增量里。所以做时间戳增量的表我强烈建议你保留一个全量快照分区每周或每月做一次全量对账把漏掉的变更捞回来。这个兜底手段说白了就是给方案买保险。3.2 全量比对增量看起来笨其实最稳全量比对增量有一个经典的说法“如果不知道该相信什么就全表拉下来比一比。”它的核心思路是每天把源表全量数据拉过来放在一张临时表里然后跟目标表做关联比对找出新增、修改、删除三类变化再统一合并。实现上你可以每天先建一个临时分区表-- 把源表全量拉入 ODS 临时分区 INSERT OVERWRITE TABLE ods_user_info_tmp SELECT * FROM source_db.user_info;然后和正式表做比对找出新增和修改的记录-- 新增和修改以临时表为准关联不上或内容不一致的 INSERT OVERWRITE TABLE dwd_user_info SELECT t.id, t.name, t.update_time FROM ods_user_info_tmp t LEFT JOIN dwd_user_info d ON t.id d.id WHERE d.id IS NULL -- 新增 OR t.update_time d.update_time; -- 修改严格来说上面的写法有问题left join会把所有关联不上的新记录和内容有变化的记录都筛出来但无法“更新”历史记录因为你看不到目标表里面那些没变的记录。所以更严谨的做法是把目标表所有数据分成两部分保留没变的 覆盖有变的 插入新增的。全量比对增量最大的优点是它对源表结构零侵入。你不需要求业务方加“修改时间”字段不需要改业务代码纯粹在数仓侧通过计算来识别变化。对那种“我们也不知道业务表有没有时间字段”的老旧系统这是唯一的选择。而且它能发现删除——只要比对时发现目标表里有、临时表里没有的记录那就是被删了。缺点也很明显每天全量拉取源表对源库的查询压力非常大。我见过一个订单表三亿行做全量比对时每天把源库的 IO 打满直接影响了线上交易。后来没办法只能放弃这个方案先让业务给表加了gmt_modified字段再切回时间戳增量。所以全量比对更适合数据量在千万级以下、源库压力可控、且查询时间窗口允许的场景。如果数据量太大全量比对还有一个变体叫“增量比对”。做法是把源表按分区或分片切块每天只比对最近 N 天的分区再加上定期全量对账。等于把全量比对拆细了牺牲部分发现能力换取性能。3.3 日志解析增量CDC高精度、高成本的“吞金兽”CDC 全称是 Change Data Capture翻译过来就是“变更数据捕获”。它不走业务表查询而是直接解析数据库的 binlog拿到每一行数据的事务级变更记录。比如 MySQL 的 binlog 里会记录第 10001 号事务把 id9527 这行的 name 从“张三”改成了“李四”。这些变更被工具捕获后可以实时或准实时地投递到消息队列、数据湖或数仓里。最常见的方案组合是Canal Kafka Flink。Canal 伪装成 MySQL 的从库连上主库拉取 binlog解析成 JSON 格式的消息打到 KafkaFlink 消费 Kafka 里的消息经过清洗后写入 Hive 或 HDFS。如果不想搞那么重的链路现在 Flink CDC 可以直接用 YAML 或 DataStream API 直接连数据库省掉 Canal 和 Kafka 两个中间件简单场景下很香。有一点必须提醒你开启 binlog 不是无代价的。它会把所有数据变更以文本形式额外落盘占用磁盘 IO 和存储空间。有的 DBA 对这个很敏感你提需求时也得把收益讲清楚。还有一个坑是 binlog 格式必须是row级别如果数据库配的是statement或mixed拿到的可能只有 SQL 语句而没有变更前后的数据解析价值大打折扣。CDC 的实时性优势在数仓里的应用分两派一派做实时数仓直接把变更数据做成实时宽表支撑大屏和实时风控另一派做离线数仓的增量源把 CDC 数据落成 ODS 的增量分区再走离线调度。很多大厂现在是两条腿走路实时链路算结果离线链路做回刷和校对。我还得说一句大实话如果只是 T1 离线同步且数据量没过亿真没必要上 CDC。它引入的监控、告警、数据一致性校验成本比业务价值高得多。CDC 是给“实时性刚需”和“数据量大到没法全量比对”的场景准备的别把简单问题复杂化。3.4 别忘了还有个兄弟拉链表专门处理“缓慢变化维”聊增量更新离不开拉链表。很多人在增量更新上纠结半天其实漏了一个重要的思路有些变化你不需要“更新”只需要“记录历史”。拿用户状态举例用户从“普通会员”变成“VIP会员”如果你直接覆盖旧状态历史就没了但如果你用拉链表就能同时保住“之前是什么、现在是什么、什么时候变的”三段信息。拉链表的核心设计是给每条记录加两个时间字段start_date和end_date表示这条记录的生效区间。今天发现用户状态变了就把旧记录的end_date改成昨天再插一条新记录start_date是今天end_date设为 9999-12-31。这样查历史直接用日期过滤查当前状态就筛end_date 9999-12-31。拉链表的更新 SQL本质上就是一个增量更新过程。它是“SCDSlowly Changing Dimensions”里的常见模型很多场景下比做“覆盖式更新”更符合业务需求。所以当你接到“用户维度表”这类缓慢变化维的需求时别一上来就设计成覆盖更新先问问产品要不要看历史要的直接上拉链表省得以后再推倒重来。4. 增量更新的场景选型我给你一套可抄作业的判断逻辑增量更新方案选型很多人喜欢抓着“哪种方式最优”来讨论。我的观点很直接不讲场景谈方案都是耍流氓。判断方式其实可以固化成几步每一步问自己一个问题。第一步先看源表有没有可靠的更新时间字段。有且业务侧保证每次变更都会更新这个字段那时间戳增量是首选成本最低、实现最快。没有或不可靠就跳到第二步。第二步问业务方需要看历史变化吗如果要看历史状态、变化轨迹直接上拉链表。如果只需要当前最新值进入第三步。第三步评估数据量和源库压力。数据量在千万级以下、查询窗口允许用全量比对稳且零依赖。数据量大到全量查询直接影响线上业务进入第四步。第四步看时效性需求。要实时就上 CDC。T1 也扛不住但数据量又大通常的做法是折中给源表加时间字段后做时间戳增量或者用分区裁剪后的增量比对。这套判断逻辑下来你基本能选出一个合理的方案。但有一点我必须强调从来没有一劳永逸的增量方案。数据量大了方案要变业务需求变了方案也要变。我做过一个项目刚开始用全量比对半年后数据量涨了十倍全量比对跑不动业务方配合加了时间字段切到时间戳增量又跑了一年业务要求实时看数据最后上了一套 Flink CDC。整个过程中方案换了两次但每一阶段的切换都是有预判、有准备、可执行的这才叫健康的方案演进。如果要把选型浓缩成一张速查表大概是这样业务场景推荐方案核心理由小表 无时间字段 需求简单全量比对零侵入、稳定、实现最快大表 有时间字段 T1 够用时间戳增量成本低、对源库压力小需要看历史变化轨迹拉链表 时间戳增量既能增量又能保留历史实时性要求高日志解析增量CDC秒级捕获、事务级准确大表 无时间字段 离线全量比对 分区裁剪用少量扫描换能力大表 有时间字段 回刷频繁时间戳增量 定期全量对账增量为主、对账兜底5. 数仓建模里和数据更新强相关的三条经验这里想单独聊一下数仓建模和增量更新的关系因为这两件事看着独立实际是连体婴儿。你建模时怎么设计表结构直接决定了日后的增量更新能不能顺利跑起来。我总结了三条最实战的经验。第一条ODS 层设计增量分区时一定要保留“全量快照”的能力。很多团队图省事ODS 只认dt分区做增量结果数据出问题要回溯时发现历史分区缺数据只能痛苦地整表重灌。我建议 ODS 层做两层一个ods_table_delta存每日增量另一个ods_table_snapshot存每日全量快照或者至少保留近 7 天全量。看起来多了一份存储但回溯时能救命。第二条DWD 层的更新策略要和表的主键设计绑定。如果你的 DWD 表用的是业务主键比如订单号那增量更新时 upsert 很容易做但如果你用的是自增代理键每次修改都要维护“代理键→业务键”的映射关系更新复杂度上升一个量级。能用业务自然键做主键的别造代理键。第三条建模时减少不必要的维度冗余能大幅降低更新成本。星型模型里事实表只存维度外键更新时只要处理事实本身但如果你做了大宽表把维度的几十个字段都冗余进去维度一变化宽表就要跟着刷更新链路瞬间变得又长又脆。主题域拆分做不好后面增量更新全是泪。6. 增量更新实操中高频踩坑汇总看完少走弯路6.1 时间字段的“脏数据”怎么防时间戳增量最怕的不是没时间字段而是有时间字段但值不靠谱。常见的情况有新插入的记录update_time为 NULL、业务代码只 insert 不 update、批量导入工具带入了错误的时间。我的经验是在增量抽取 SQL 里加一道时间字段完整性校验-- 先检查异常记录提前发现时间字段的坑 SELECT COUNT(*) AS cnt FROM source_db.user_info WHERE update_time IS NULL OR update_time 1970-01-01 OR update_time CURRENT_TIMESTAMP();如果这个检查跑出来异常记录数量不是 0就说明源表时间字段可信度有问题必须找业务方确认。硬着头皮同步后面就是数据事故。6.2 目标表分区策略会导致更新失效增量更新写目标表时分区策略极易踩坑。比如你的 DWD 表按dt分区但业务表的数据变更发生在三天前如果你用dt today去写变更的数据会进今天的分区而昨天的分区里还是旧数据查询时就会出现“同一订单昨天和今天结果不一致”的问题。这种问题的根源是把“数据变更时间”和“业务发生时间”混为一谈。我的建议是目标表增加一个“变更时间分区”的概念比如etl_time分区业务查询时再按biz_date过滤两者解耦。6.3 幂等性增量任务失败重跑不能重复写入增量任务最容易翻的车就是跑失败了重跑结果重跑了两次数据翻倍。解决思路有两个层面一是同步过程要用“先删后插”或“覆盖写”的语法比如 Hive 的INSERT OVERWRITE天然具备分区级幂等性二是调度系统要设计好“任务成功”的标志位下游任务只认成功的分区。很多团队在这一点上吃过亏任务跑了七八个小时最后一步失败了重跑时没做防重ODS 里塞了两份同样的数据对所有下游造成毁灭性影响。6.4 删除数据的三种处理套路源系统删数据这件事在增量更新里永远是个坎。我的建议是分场景处理如果源表有“删除标记”字段逻辑删除那就把它当作普通修改增量任务正常识别如果没有删除标记且是物理删除而业务又需要感知删除就得靠全量比对或 CDC如果业务不关心删除那最简单增量任务直接忽略删除操作。别硬刚“必须发现删除”这件事和业务确认清楚需求边界能省掉 80% 的复杂度。7. 最后的实操心得增量更新的本质是“算账”做了这么多年数仓我越发觉得增量更新这件事的底层逻辑跟“算账”是一模一样的。你每天从源系统拿到一笔“收入”新增和修改再给目标表“支出”一笔“合并”更新和插入中间还要处理“坏账”删除、回刷、脏数据。规划增量更新方案就是规划一套账务体系要能回答三个问题今天进了多少、今天变了多少、账平不平。所以我不建议你上来就闷头写 SQL 或者搭组件。先拿出一张纸把你们的数据表从“产生变化”到“进入数仓”的全链路画一遍标出每一环节的“数据量级”“变更频率”“回刷可能”再结合我上面讲的判断逻辑选一个最匹配的方案。技术选型到最后都是选择题不是证明题。如果你正在为增量更新发愁从时间戳增量开始是最不容易出错的上手姿势。跑通之后再根据业务需要逐步叠加全量对账甚至 CDC这条成长路径我验证过多回稳。