逻辑复制与批量 ETL：如何选择同步方式

我们在“同步数据”时要解决什么问题？

团队在系统之间复制数据，因为工作很少只发生在一个地方。销售可能在 CRM，支付在计费工具，运营在内部仪表盘。支持需要完整背景而不想在多个工具间切换，领导需要与实际发生一致的报表。

“值得信赖的同步”说起来容易，做起来难：正确的记录按时到达，没有重要数据丢失，且更新足够快以便有用。所谓“足够快”取决于具体任务。反欺诈可能需要几分钟，月度财务报表可以容忍数小时。

当同步出问题时，通常表现为缺失记录、重复、字段陈旧或部分更新（例如订单头出现但明细没有）。

一个有用的心理模型是事件 vs 快照。

事件是单个变更：“订单 #1842 已创建”，“状态变为已发货”，“发起退款”。基于变更数据的方法倾向于传输事件，并能支持近实时行为。

快照是按计划的拷贝：“每晚复制昨天的订单”。批量 ETL 常常这样做，可能更简单，但数据不够新。

关于逻辑复制与批量 ETL 的大多数争论，实质上是在讨论这个选择：你需要持续的事件流，还是周期性快照足以让使用者对所见数据保持信心？

简单解释逻辑复制和批量 ETL

逻辑复制意味着源数据库按变更顺序发送一条变更流。不再是复制整张表，而是发布“行被添加”、“行被更新”或“行被删除”。目标按顺序应用这些变更，因此能与源保持紧密一致。

批量 ETL 意味着按计划拍摄快照。作业提取数据（通常是“自上次运行以来的一切”）、在必要时转换，然后加载到目标。如果把复制比作实时更新，批量 ETL 更像是每小时（或每晚）检查一次并追赶进度。

它们通常运行的位置不同。复制靠近数据库的变更日志并持续运行。批量 ETL 通常是调度作业：运行、停止、再运行。

无论哪种方式，你都必须回答同样的信任问题：

• 删除如何表示，以免目标保留“幽灵”行？
• 如果同一个变更到达两次怎么办（幂等性）？
• 在大量行快速变更时，如何保持顺序正确？
• 重启或重新部署期间如何避免漏掉变更？
• 如何发现缺口，而不只是“作业成功”？

举例：一个订单先被创建，然后状态从“待处理”变为“已付款”，接着退款。复制会发送三条变更事件。一次每日快照可能只捕获最终状态，除非你特别设计批处理来保留中间状态。

新鲜度与延迟：你需要多接近实时？

在比较复制与批量 ETL 之前，用业务术语定义“足够新”。从一个数字开始：比如“支持可以接受最多 5 分钟旧的数据”或“财务可以接受昨天的汇总”。

新鲜度是用户使用数据时数据的年龄。延迟是源发生变更到目标出现相同变更之间的延迟。即使平均延迟低，如果同步经常停滞，你也会得到“旧”数据。

延迟实际上来自哪里

即使是简单的同步也包含多重延迟：捕获（何时检测到变更）、传输（移动数据）、处理（转换与去重）和应用（在目标写入与建立索引）。

连续不断的小量流（复制或频繁微批）带来更平滑的新鲜度，但意味着整天都在运行同步。计划批次更易于理解，但会造成峰值：凌晨 2 点的高负载，然后到下一次运行之前数据陈旧。

近实时在用户需迅速决策或客户能立即看到结果时很有用。支持仪表盘应该快速显示新订单，避免坐席承诺已缺货的商品会被卖出。另一方面，如果主要用途是每周报表或月度开票，立即推送每个小更新会增加复杂度，却不会改善结果。

一个实用的决策方法：

• 谁在使用同步数据，他们用它做出什么决策？
• 如果数据迟到 15 分钟，会有什么被打破？
• 持续运行的成本是多少（基础设施与值班时间）？
• 目标方何时最不繁忙？
• 你会承诺（并告知他人）什么样的新鲜度？

故障恢复：在出问题后如何回到正确状态

同步很少以剧烈方式失败。它们以小而无聊的方式失败：服务器重启、网络抖动断开连接、作业在加载中途崩溃。目标不是“永不失败”，而是“恢复到正确的终态”。

常见故障模式包括源端不可用、目标不可用、处理过程中作业崩溃，或违反约束的脏数据。

对于逻辑复制，恢复通常意味着从保存的位置（通常是日志偏移）重放变更。如果目标宕机，变更会排队，等它恢复后按序继续。这很好用，但需要管理复制槽（或等效概念），以免在长时间故障期间无限增长。

对于批量 ETL，恢复通常意味着重新运行一个时间窗口（例如“重载昨天”或“重载最近 2 小时”）。这在操作上通常更简单，但你的加载逻辑必须安全可重复运行。

最大的信任破坏来自部分写入。一次崩溃在写入 70% 批次后，若没有提前设计，会留下重复或缺失行。两种方式都有助益的模式：

• 让加载幂等，重复应用相同输入应达到相同状态。
• 优先使用以稳定主键为键的 upsert。
• 只有在成功提交后才推进“已处理到”的标记。
• 把被拒绝的行保存到可检查并重放的位置。

回填（重做历史）是痛点所在。批量 ETL 在需要重处理一个月数据时通常更占优势，因为重跑就是其设计的一部分。复制也能回填，但通常走不同路径（先做快照，再应用变更），因此在真正需要之前值得测试。

示例：如果订单同步在写入明细后但在写入头信息前崩溃，按订单（或按批）做单事务的 upsert 能防止半同步订单残留。

模式演进：数据模型变化时会发生什么？

模式变更是很多同步悄悄失去信任的地方。管道可能继续运行，但数据的含义在下面悄然改变。复制可能在数据库层面就挂掉，而 ETL 往往在转换或报表阶段才暴露问题。

新增通常最容易：新列、新表、可选字段。如果消费者把它们当作“额外项”并且默认值合理，通常没问题。陷阱是以为每个下游消费者都会注意到新字段或知道如何回填它。

破坏性变更风险很大：重命名、类型变化、删除列或改变某个值的含义。这些会导致快速失败（作业报错）或缓慢失败（数据到位但错误）。

如何安全演进

保持兼容性足够长，以便迁移：

• 对模式或载荷版本化（v1、v2），让旧版和新版并存。
• 在兼容期同时保留旧字段与新字段。
• 在切换依赖新版结构前先回填数据。
• 只有在确认没人读取旧字段后再删除它们。

映射通常在哪儿出问题

大多数真实的破坏发生在系统间的胶水层。例如：ETL 用 orders 和 customers 通过 customer_id 连接。如果它被重命名为 client_id，连接可能变成全空匹配但仍然产生行。

关注脆弱点：类型强转、假设键永不变的连接、以及像“状态必须是这些值之一”的下游规则。

安全与归属：谁被允许同步什么？

安全问题在两种方法中看起来相似，但风险出现在不同位置。复制通常持续运行并拥有较广的只读变更访问权限。批量 ETL 按计划运行，但一次可能拉取更大的数据切片。两者都应以最小权限原则为目标，保证能完成任务即可。

使用专用服务账号，而不是某人的登录。授予只读访问，仅限需要的表、列或视图，并限制连接来源。若可能，公开专用的“同步视图”，该视图已经过滤掉目标不应看到的数据。

敏感字段常常让团队吃惊。即便目标需要一条记录，也可能不需要其中所有内容。尽早决定是否省略、掩码或令牌化个人联系信息、支付信息或内部备注。对传输中数据加密，把密钥和机密保存在专用密钥库而非管道配置中。

归属能防止日后无休止的争论：

• 为每个字段（而不仅是表）选择事实来源。
• 说明目标是否被允许写回。
• 决定冲突如何处理（最后写入生效、忽略目标修改、或人工审核）。
• 为复制到目标的数据设定保留规则。

审计是信任的最后一块。你应该能回答：谁访问了数据、什么被改动、何时落地。一个简单做法是携带可追踪的同步运行 id 和时间戳，以便端到端追踪更新。

为了让同步保持可信你该监控什么

同步只有在你能在某个随机星期二相信它时才有用。无论采用哪种方法，监控应告诉你落后了多少、失败发生的频率以及数据是否仍然符合预期。

三个每日健康信号：

• 滞后/延迟：目标落后源端多少
• 错误率：失败、重试、以及发送到死信或“失败行”桶的记录
• 吞吐量：每分钟处理的行或事件数，以及突然降到接近零的情况

然后添加一小组数据质量检查来捕捉静默问题。挑选几张重要表（订单、发票、工单），用可重复方式验证它们。如果源端昨天有 1,240 条订单，目标端不应是 1,180 条，除非你知道原因。

通常能覆盖大量问题的检查：

• 按日（对关键流按小时）统计行数
• 应匹配的汇总（金额总和、已支付订单数）
• 必需字段的空值率（邮箱、状态、时间戳）
• 键的唯一性（没有重复的 order_id）
• “删除事实”：取消或删除的记录在下游也消失（或被标记）

一致性问题常藏在缝隙中：晚到的更新、缺失的删除、或事件乱序应用。追踪最旧的未处理时间戳，并定期抽样记录以确认最新版本存在。

告警要平淡且可执行。设定阈值（例如：滞后超过 15 分钟、错误率超过 1%、吞吐量低于基线并持续 10 分钟），并维护运行手册回答：先检查什么、如何安全回放、以及如何确认恢复正确。

逐步流程：如何选择合适的同步方式

明确谁会使用数据。财务报表、支持仪表盘和自动定价规则都可能消费相同的表，但用途不同。如果决策对时间敏感，迟到的数据不仅令人烦恼——可能是错误的。

一个简单的决策流程：

1. 名单化消费者与他们的决策。列出依赖同步的屏幕、报表和流程以及它们的影响。
2. 设定目标，而不是凭感觉。就新鲜度（秒、分钟、小时）、正确性（可接受什么错误）与成本（基础设施、工程时间、运维负担）达成一致。
3. 选择满足目标的最简单模式。需要近实时和可预测变更捕获时用复制；“每几分钟一次”用微批；夜间批处理适合报表与历史快照。混合很常见。
4. 规划恢复。决定能重放多远、如何执行回填，以及加载如何保持幂等。
5. 定义信任检查与归属。选择证明健康的验证（计数、汇总、最后更新时间、抽样检查），并指定谁会被告警、谁来修复数据。

具体示例：如果支持在与客户通话时需要订单状态，那么分钟级很重要，适合复制或微批。如果财务只需每日收入数字，夜间批处理通常足够。

让同步数据不可靠的常见错误

最常见的陷阱是把“新”当作“正确”。流水线可能延迟几秒但仍然错误：连接条件变更、过滤器被加入、或行被重复。没有验证，你常常要等到仪表盘看起来奇怪或客户抱怨时才发现问题。

删除是另一个常被忽视的点。复制和 ETL 都需要明确“移除”的含义。如果系统 A 硬删除一条记录，但系统 B 只做插入和更新，报表会随时间漂移。软删除同样麻烦，若同步没有携带删除标志和时间戳，目标也不会更新。

经常重复出现的错误：

• 把新鲜度当作主要目标，跳过基本的计数、汇总与抽样检查
• 同步插入与更新，但不处理删除、合并或停用状态
• 把字段映射写死，当列被重命名、拆分或改类型时悄无声息地失效
• 没有历史回填计划以修正历史数据
• 仅对作业失败告警，而不对滞后、缺失数据或缓慢漂移预警

示例：你的 CRM 将客户标记为“inactive”而不是删除。你的 ETL 仅复制 status = active 的客户。一个月后，收入看起来没问题，但留存率指标被高估，因为不活跃客户没有被同步（或没有被删除）。一切看起来很新，但正确性早已偏离。

在你称同步“完成”之前的快速检查表

用明确数字、清晰归属和经过验证的恢复来定义“完成”。第一天看着正常的同步，随着真实变更与故障发生会发生漂移。

• 新鲜度承诺已书面化。 定义目标延迟、何时测量以及未达标时的处理方式。
• 事实来源明确。 对关键字段（状态、价格、客户邮箱）记录哪个系统为准，更新是单向还是双向。
• 恢复已做端到端测试。 模拟故障并确认能重放或重跑而不产生重复或缺失行。
• 存在模式变更规则。 决定谁批准变更、如何发布以及如何处理重命名、类型变更与删除列。
• 监控可执行。 跟踪滞后、错误率与核心数据检查，并配套告警和运行手册，告诉值班人员下一步怎么做。

现实检验：如果 delivery_instructions 被加入订单，你的流程应能明确表明它是自动同步、会大声失败，还是安全地被忽略。

一个现实的示例：在两个系统间同步订单

想象一家公司把订单存放在 PostgreSQL。两个团队需要这些数据：支持需要一个实时仪表盘回答“我的订单在哪儿？”，财务需要稳定的每日数字用于关账与报表。

他们采用混合方法，而不是把一个工具逼到适配所有场景。

对支持，他们使用逻辑复制，让新订单和状态更新快速出现在用于仪表盘的只读优化数据库中。对财务，他们在下班后每天运行批量 ETL，将最终化的订单加载到报表仓库，应用业务规则（税、折扣、退款），并产出不会随意变动的每日快照。

随后发生一次模式变更：产品团队添加了 refund_reason。支持希望立即可见。复制能快速传递新列，而批处理可先把它视为可选（默认“unknown”），直到报表逻辑准备好。

某天支持的目标宕机了 3 小时。恢复后，复制从保存的位置赶上进度。关键步骤不仅是“它恢复了”，而是“它是正确的”：他们核对了故障窗口内的订单计数并抽查了几条最近订单的端到端状态。

每天早晨他们在信任数据前查看一组简短信号：复制滞后、源与目标在过去 24 小时内的订单计数、财务表的重复、批次成功与每次加载的行数，以及对部分高价值订单在两系统间的抽样校验。

后续步骤：让同步可见且易于运维

在你选择一种方法（或混合）之后，真正的工作是把同步打造成团队每天都能信任的产品。选一个可度量的目标并把它当作产品指标。对大多数团队而言，第一个目标通常是新鲜度（数据有多新）或准确性（错误率是多少）。

先从小处做起：一张表、一个事件流或一个重要工作流（比如订单或工单）。把那条路径稳定下来，再复制模式。过早扩展而不能快速检测和修复问题，会更快地制造更大的烂摊子。

一个面向非技术团队的“同步状态”视图通常包含：当前滞后 vs 目标、上次成功同步时间、上次失败尝试、今日处理量 vs 预期范围，以及状态为红色时的简短处理指引。

如果你想快速构建内部管理界面，像 AppMaster 这样的无代码平台可以帮助你发布监控视图，并在模式或工作流演进时调整它，而不用在每次变更时重写全部代码。