3. 数据源接入层设计：多数据源适配器、CDC实时采集、Schema Registry统一管理

数据源接入层，说白了就是实时特征平台的「入口」。

我见过不少团队，一上来就埋头写 Flink 作业，结果数据源一换、Schema 一变，整个管道就得重来。嗯，这里要提前想清楚。

跨云环境下，你的数据可能散落在 AWS RDS、阿里云 MySQL、自建 Kafka、甚至某个老旧的 Oracle 里。接入层如果不能统一抽象，后面每接一个数据源，都是噩梦。

3.1 多数据源适配器：统一接入的「万能插座」

我的习惯是，先定义一套 SourceConnector 接口。不管底层是 MySQL、PostgreSQL、MongoDB 还是 Kafka，都实现同一套 SPI。

public interface SourceConnector {
    void connect(SourceConfig config);
    void start(SourceEmitter emitter);
    void stop();
    SourceMetadata getMetadata();
}

每个数据源写一个实现类。比如：

• MysqlConnector：基于 Binlog 的 CDC 采集
• KafkaConnector：直接订阅 Topic
• MongoConnector：基于 Oplog 或 Change Stream
• HttpConnector：轮询拉取 API 数据

我在项目中遇到过一个问题：某个业务方想接入自研的消息队列，没有现成的 Connector。幸好我们提前设计了 SPI 机制，团队花了两天就写了一个适配器，完全不影响主线。

3.2 CDC 实时采集：Binlog 与 WAL 的实战选择

CDC（Change Data Capture）是实时特征平台最核心的数据来源。你想想看，业务数据库里的用户下单、状态变更，如果不能秒级同步到特征平台，那实时特征就是空话。

目前主流的 CDC 方案就两种：

方案	原理	延迟	一致性	跨云适用性
MySQL Binlog	解析 binlog row-based 事件	< 1s	Exactly-once	需公网或专线
PostgreSQL WAL	逻辑复制槽解析 WAL	< 1s	Exactly-once	需公网或专线
Oracle LogMiner	解析 redo log	1-3s	At-least-once	需公网或专线
MongoDB Change Stream	订阅 oplog	< 2s	At-least-once	需公网或专线

我个人习惯用 Debezium 作为 CDC 引擎。它天然支持多种数据库，而且和 Kafka Connect 深度集成。跨云场景下，我会在每个云区域部署一个 Debezium 集群，通过专线或公网 TLS 把变更事件投递到中心 Kafka。

3.3 Schema Registry：统一管理，避免「字段对不上」

数据源多了，Schema 管理就成了大问题。你想想看，MySQL 表加了个字段，下游 Flink 作业没更新，直接报错。或者两个数据源的同名字段，类型不一样，特征计算出来全是 null。

我的方案是：强制使用 Schema Registry。所有写入 Kafka 的数据，都必须注册 Schema。

核心流程：

1. CDC 采集到数据后，先序列化为 Avro 格式
2. 向 Schema Registry 注册或校验 Schema
3. Kafka 消息中只带 Schema ID，不携带完整 Schema
4. 消费者根据 Schema ID 反序列化

这样做的好处很明显：

• 兼容性检查：新增字段不会破坏下游
• 版本管理：可以回溯历史 Schema
• 跨云统一：所有云区域的 Schema 都指向同一个 Registry

3.4 整体架构图

下面这张图，展示了数据源接入层的核心组件和流转关系：

3.5 跨云部署要点

最后，聊几个跨云场景下的实操要点：

• 网络连通性：CDC 采集器和目标 Kafka 之间，建议走专线或 VPN。公网方案要做好 TLS 加密和 IP 白名单。
• 数据压缩：Binlog 数据量很大，我习惯在 Connector 层开启 Snappy 或 Zstd 压缩，能省 60% 带宽。
• Schema 兼容策略：我建议用 BACKWARD 模式。这样新增字段时，旧作业不会挂，新作业能读到新字段。
• 监控告警：每个 Connector 都要暴露延迟指标。我习惯设置延迟超过 10s 就告警，超过 30s 自动重启。