4、跨平台元数据同步策略：事件驱动、定时批量与CDC

元数据同步这件事，说白了就是让不同平台的数据字典、表结构、血缘关系保持一致。我见过不少团队，一开始觉得同步很简单，写个定时任务拉一下就行。结果数据量一上来，延迟、冲突、丢失全来了。

这一章，我把自己踩过的坑和常用的三种策略拆开讲。你想想看，没有一种策略是万能的，关键看场景。

4.1 三种策略概览

先给个全景图，方便你建立整体认知。

4.2 事件驱动同步

事件驱动，就是「有变化才同步」。元数据发生变更时，立即触发一个事件，推送到目标平台。

我在项目中遇到过这样的情况：数据治理平台里，业务方改了一个字段的注释，希望立刻反映到数据地图上。如果用定时任务，可能要等半小时。事件驱动就能做到秒级同步。

实现方式

• 消息队列：Kafka、RabbitMQ 作为事件总线
• Webhook：源平台主动回调目标平台接口
• 事件日志：记录变更事件，由消费者拉取

代码示例：基于 Kafka 的事件发布

// 元数据变更事件发布
public class MetadataEventPublisher {
    
    private final KafkaTemplate<String, MetadataChangeEvent> kafkaTemplate;
    
    public void publishChange(MetadataChange change) {
        // 先持久化到本地事件表
        eventRepository.save(change.toEventRecord());
        
        // 再发送到 Kafka
        MetadataChangeEvent event = new MetadataChangeEvent(
            change.getEntityId(),
            change.getChangeType(),  // CREATE, UPDATE, DELETE
            change.getPayload(),
            Instant.now()
        );
        
        kafkaTemplate.send("metadata-changes", event);
    }
}

4.3 定时批量同步

定时批量同步，是最简单粗暴的方式。每隔一段时间，把源平台的元数据全量或增量拉一次。

嗯，这里要注意。我早期做数据仓库时，就吃过全量同步的亏。每天凌晨跑一次全量，结果某个表有 10 万列元数据，同步一次要跑 40 分钟，还经常超时。

适用场景

• 元数据变更不频繁（每天几次）
• 对实时性要求不高（小时级或天级）
• 源平台不支持事件推送

增量同步示例

-- 基于时间戳的增量同步
SELECT 
    table_name,
    column_name,
    data_type,
    description,
    last_modified_time
FROM 
    metadata_catalog
WHERE 
    last_modified_time > '2024-01-01 00:00:00'  -- 上次同步时间
    AND last_modified_time <= NOW();

4.4 CDC（变更数据捕获）机制

CDC 是三种策略里最「硬核」的。它直接读取数据库的事务日志（比如 MySQL 的 binlog、PostgreSQL 的 WAL），捕获每一行数据的变更。

说白了，CDC 不依赖业务代码埋点，也不靠定时扫描。它从底层日志里拿到最原始的变更记录，连「谁改了、改了什么、改之前是什么」都能拿到。

我个人习惯用 Debezium + Kafka 做 CDC 管道。Debezium 监听 binlog，把变更转成统一的事件格式，推送到 Kafka。下游的消费者再更新元数据存储。

CDC 架构图

CDC 的优势

• 无侵入：不需要修改业务代码
• 完整历史：可以回溯任意时间点的元数据状态
• 低延迟：秒级甚至毫秒级捕获变更
• 高可靠性：基于日志的机制，不会漏掉变更

4.5 策略选择矩阵

最后给一个选择矩阵，帮你快速决策。

场景	推荐策略	理由
字段注释频繁修改，需实时反映	事件驱动	变更量小，实时性要求高
每天凌晨全量刷新数据字典	定时批量	简单可靠，对实时性无要求
数据库表结构频繁变更，需完整审计	CDC	捕获所有变更，支持历史回溯
混合场景：部分实时、部分批量	事件驱动 + 定时批量	实时变更走事件，全量校验走定时