4. 数据源接入策略：Kafka、数据库CDC、日志文件采集的时效性保障
聊到特征新鲜度，最核心的战场其实不在存储层，而在数据源接入这一关。你想想看，数据从业务系统出来，到进入特征平台，中间经过的每一毫秒延迟，最终都会体现在特征值的老化程度上。我这些年踩过的坑，十有八九都跟数据源接入策略有关。
说白了，不同的数据源，天生就有不同的时效性天花板。Kafka 能做到秒级，CDC 能做到亚秒级到分钟级，日志文件采集嘛……嗯，能做到分钟级就已经算不错了。我们得根据业务对新鲜度的要求，给每种数据源选最合适的接入姿势。
核心原则：数据源接入的时效性，不是由管道决定的，而是由源头的数据产生方式和传输协议决定的。选错了接入策略，后面再怎么优化都没用。
4.1 Kafka：实时特征的事实标准
Kafka 是我个人最偏好的实时特征数据源。为什么？因为它天然支持高吞吐、低延迟、可回溯。我在项目中遇到过好几次，业务方要求特征延迟不超过 5 秒，最后都是用 Kafka 搞定的。
Kafka 接入的时效性保障，关键看三点：
- 分区数与消费者并行度：分区数决定了并行消费的上限。我建议分区数至少是消费者线程数的 2-3 倍，这样在消费者宕机时还能有缓冲。
- 消费位移提交策略：自动提交（enable.auto.commit=true）虽然省事，但容易丢数据或重复消费。我个人习惯用手动提交，在特征处理完成后再提交位移。
- 消息体大小与序列化：特征消息一般不大，但如果你把整个业务对象塞进去，序列化开销会吃掉延迟预算。我建议只保留特征计算所需的字段。
// 一个典型的 Kafka 消费者配置（Java 示例）
Properties props = new Properties();
props.put("bootstrap.servers", "kafka-cluster:9092");
props.put("group.id", "feature-consumer-group");
props.put("enable.auto.commit", "false"); // 手动提交
props.put("max.poll.records", "500"); // 控制批大小
props.put("session.timeout.ms", "10000");
props.put("max.partition.fetch.bytes", "1048576"); // 1MB
// 特征处理逻辑
while (true) {
ConsumerRecords<String, byte[]> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, byte[]> record : records) {
FeatureValue feature = deserialize(record.value());
featureStore.put(feature.getKey(), feature);
}
consumer.commitSync(); // 处理完再提交
}小技巧：如果特征对延迟极其敏感（比如风控场景），可以考虑用 Kafka 的 exactly-once 语义 + 事务性生产者。代价是吞吐量会下降 20%-30%，但能换来数据一致性。
4.2 数据库CDC：准实时的最佳拍档
CDC（Change Data Capture）是我在特征平台项目中用得最多的数据源接入方式。为什么？因为大部分业务数据都躺在数据库里，你不可能让业务系统为了特征平台改代码。CDC 能无侵入地捕获数据变更，然后实时推出来。
常见的 CDC 工具有 Debezium、Canal、Maxwell。我个人的经验是：
- Debezium：适合 MySQL/PostgreSQL，生态最完善，支持 Schema 变更自动适配
- Canal：阿里开源的 MySQL binlog 解析工具，延迟极低（毫秒级），但只支持 MySQL
- Maxwell：轻量级，适合中小规模场景，但功能相对简单
CDC 接入的时效性瓶颈，往往不在工具本身，而在数据库的 binlog 配置。我曾经遇到过一个问题：MySQL 的 binlog 格式设置成了 STATEMENT，导致 CDC 工具解析出来的数据不完整，特征计算全错了。后来改成 ROW 格式才解决。
| CDC 工具 | 支持数据库 | 典型延迟 | 适用场景 |
|---|---|---|---|
| Debezium | MySQL, PostgreSQL, MongoDB, Oracle | 100ms - 1s | 多数据库、复杂 Schema 变更 |
| Canal | MySQL | 10ms - 100ms | 高并发、低延迟的 MySQL 场景 |
| Maxwell | MySQL | 500ms - 2s | 中小规模、快速部署 |
避坑指南：我曾经在生产环境中遇到过 CDC 工具因为 binlog 文件清理策略导致数据丢失的情况。建议将 binlog 保留时间设置为至少 24 小时，并配置 CDC 工具的 offset 持久化到外部存储（如 Kafka 或 Zookeeper），这样即使 CDC 工具重启，也能从断点继续消费。
4.3 日志文件采集：批处理的老兵新传
日志文件采集，说白了就是 tail -f 的工业版。虽然听起来不够「实时」，但在很多场景下，它反而是最稳定的数据源。比如服务器访问日志、应用错误日志、用户行为日志，这些数据量巨大，但时效性要求没那么苛刻（分钟级就够了）。
常用的工具有 Filebeat、Fluentd、Logstash。我个人的选择是：
- Filebeat：轻量级，资源占用极低，适合部署在每台机器上
- Fluentd：插件丰富，适合复杂的数据处理管道
- Logstash：功能强大，但吃内存，适合集中式处理
日志文件采集的时效性保障，核心在于「轮询间隔」和「文件指针管理」。我建议：
- 轮询间隔设置为 1-5 秒，太短会增加 CPU 开销，太长会引入延迟
- 使用 inode 而非文件名来跟踪文件，避免日志轮转（log rotation）导致数据丢失
- 配置多行合并规则（multiline），处理 Java 异常栈等跨行日志
# Filebeat 配置示例（feature-log.yml）
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/features/*.log
scan_frequency: 3s # 每 3 秒扫描一次
close_inactive: 5m # 5 分钟无新数据则关闭文件句柄
multiline:
pattern: '^\d{4}-\d{2}-\d{2}'
negate: true
match: after
output.kafka:
hosts: ["kafka-cluster:9092"]
topic: "feature-log-raw"
partition.round_robin:
reachable_only: true小技巧：如果日志文件采集的延迟要求较高（比如 10 秒以内），可以考虑用 Filebeat 的 Harvester 模式，它会持续监控文件变化，而不是轮询。代价是会增加少量的内存占用。
4.4 三种接入策略的时效性对比
为了让你更直观地理解这三种方式的差异，我画了一张对比图。你可以看到，Kafka 和 CDC 在延迟上明显优于日志采集，但日志采集在稳定性和资源消耗上有优势。
4.5 混合接入策略：没有银弹
在实际项目中，我很少只用一种接入方式。比如一个典型的特征平台，可能会同时接入：
- Kafka：处理用户实时行为事件（点击、浏览、下单）
- CDC：同步用户画像、商品信息等基础数据变更
- 日志文件：采集服务端性能指标、错误日志等辅助特征
这种混合策略的好处是：每种数据源都能用最合适的方式接入，互不干扰。坏处是：运维复杂度上去了，需要统一管理数据源的元数据和接入状态。
我的建议：在特征平台设计初期，就把数据源接入抽象成统一的「Source Connector」接口。每种数据源实现一个 Connector，对外暴露相同的元数据（数据源类型、延迟指标、吞吐量、状态）。这样后续切换或新增数据源时，对上层特征计算逻辑完全透明。
嗯，数据源接入这块就聊这么多。记住一句话：没有最好的接入策略，只有最适合业务场景的接入策略。Kafka 快但不一定稳定，CDC 准但依赖数据库配置，日志采集慢但最可靠。根据你的特征新鲜度要求，选对策略，后面的事就好办了。