快照概念详解：全量快照、增量快照、差异快照的区别

说实话，刚接触数据管道那会儿，我也搞不清楚这三种快照到底有啥区别。每次跟同事讨论，对方说「做个增量快照」，我心里就发虚——到底啥算增量？跟差异有啥不同？后来踩过几次坑，才算真正吃透了。

其实核心就一句话：快照就是数据在某个时间点的「复印件」。但「复印件」怎么做、做多大，决定了全量、增量、差异这三种路子。咱们一个个掰开说。

全量快照（Full Snapshot）

全量快照最直白——把源数据整个儿复制一遍。我刚开始带项目时，这种方案用得最多，因为简单、好理解、恢复起来也省心。

举个例子，你有个订单表，里面有 1000 万条记录。全量快照就是每周日凌晨 2 点，把这 1000 万条全部导出到快照目录里，一条不落。

我个人习惯把全量快照用在两类场景：一是数据量不大的核心表（比如配置表、用户表），二是作为周/月级别的「基线快照」，用来兜底。

增量快照（Incremental Snapshot）

增量快照只记录 从上次快照到现在发生变化的数据。说白了就是「只存变化的部分」。这招在数据量大的时候特别香。

咱们还是拿订单表举例。第一次做增量快照，因为没有任何历史记录，就得先导一次全量。之后每一次，只导新增的订单和状态变更的订单。

具体怎么识别变化呢？常见做法有两种：

• 基于时间戳：每条记录有个 updated_at 字段，查大于上次快照时间的数据。
• 基于变更日志：从数据库的 binlog（MySQL）或 WAL（PostgreSQL）里捞变更。

我在项目中遇到过一个问题：用时间戳做增量快照，万一某个订单的 updated_at 忘记更新了怎么办？结果就是「数据丢丢补补」，折腾了好几天才定位到。

增量快照的存储效率非常可观。同样的 1000 万订单表，每日增量快照可能只有几万到几十万条，占空间不到全量的 1%。但恢复时比较麻烦——得从最近一次全量开始，依次叠加所有增量快照，才能还原出指定时间点的完整数据。

差异快照（Differential Snapshot）

差异快照介于全量和增量之间。它记录的是 从最后一次全量快照开始 到当前时间点之间的所有变化。你想想看，它不看「上次差异快照之后」，只看「上次全量之后」。

这格局一变，问题就简化了。假设你每周日做一次全量快照，周一到周六做差异快照。那么周三的差异快照就包含：周一、周二、周三这三天所有变化的数据，而不是只存周三当天的新变化。

恢复时，只需要「最近一次全量快照 + 最近一次差异快照」两样东西，不用像增量快照那样逐个叠加。说白了，就是拿存储换恢复速度。

快照类型	记录范围	恢复依赖	存储成本	恢复速度
全量快照	全部数据	无依赖	高	最快
增量快照	上次快照之后的变化	依赖全量 + 所有后续增量	最低	最慢
差异快照	上次全量之后的变化	依赖全量 + 最近一次差异	中等	较快

我用差异快照用得最多的是在数据仓库的定期刷新场景里。比如我们有个数仓，每天凌晨跑一次差异快照，周末做一次全量。这样每天恢复数据时，只需拿上周日的全量 + 今天的差异快照，40 多分钟就能搞定。

嗯，这里要注意：差异快照会随着时间推移越来越大。假如一周都不做全量，到了周六，差异快照里的变化数据可能已经接近全量大小了。所以最好定期做一次全量，把差异「清零」。

三种快照的工作流对比

光讲概念不够直观，我用一个流程图把它们的关系理清楚。下面这张图展示了一个完整周期（1 次全量 + 若干增量/差异）的工作机制。

实际场景怎么选？

我见过不少团队一上来就用增量快照，觉得「省空间就是王道」。结果恢复的时候，因为增量链条太长（有的甚至积累了上千个增量文件），跑一次恢复要十几个小时。你想想看，半夜数据库挂了，运维小哥等着恢复，结果等了半天进度条还在 30%——那场面，谁经历过谁知道。

我的个人习惯是：

• 核心业务表（用户、订单、支付）：每周全量 + 每日差异
• 日志类大表（访问日志、操作日志）：每月全量 + 每日增量
• 配置类小表（字典、分类、规则）：每次变更做全量

说白了，没有哪个快照策略是万能的。你得根据自己的数据量、恢复窗口、存储成本来权衡。但你至少可以记住一条：全量是保底的，增量是省钱的，差异是折中的。搞清楚这三者的本质区别，后面的 pipeline 设计才能心里有数。