3. 实时数据采集：Kafka原理、Flume集成、CDC技术、数据接入规范

实时数据采集，说白了就是流批一体架构的「水龙头」。水龙头开得稳不稳、水质干不干净，直接决定了下游所有资产运营工作的质量。我这些年踩过的坑，有一半都出在数据接入这一层。今天咱们就把这块硬骨头啃透。

3.1 Kafka：流数据的「高速公路」

Kafka 在实时采集中的地位，就像 MySQL 在 OLTP 中的地位一样稳固。它本质上是一个分布式消息队列，但它的设计哲学让它成了流式数据的首选载体。

3.1.1 核心概念速览

我习惯用「高速公路」来类比 Kafka 的架构：

• Producer（生产者）：往高速公路上发车的司机。数据就是车上的货物。
• Broker（代理节点）：高速公路的服务区。车在这里停靠、中转。
• Topic（主题）：高速公路的车道。不同车道跑不同的货。
• Partition（分区）：车道上的并行车道线。一条车道可以有多条并行线，提升吞吐。
• Consumer（消费者）：在出口卸货的收货人。
• Offset（偏移量）：每辆车的车牌号。消费者靠它知道自己读到哪了。

3.1.2 生产端调优要点

我个人习惯在生产端关注三个参数：

参数	默认值	我的建议	说明
acks	1	all	所有副本确认后才算写入成功，保证不丢
linger.ms	0	5-10	攒一批再发，提升吞吐，代价是增加几毫秒延迟
batch.size	16KB	32KB-64KB	批次越大，压缩率越高，但内存占用也大

你想想看，如果 acks=0，数据发出去就不管了，网络抖动一下就是丢数据。我见过有人为了追求极致性能这么配，结果数据对不上账，查了三天才发现是这里的问题。

3.2 Flume集成：日志采集的「老黄牛」

Flume 虽然不如 Kafka Connect 新潮，但在日志采集场景下依然能打。它的核心设计是 Source → Channel → Sink 三段式流水线。

3.2.1 典型架构：Flume → Kafka

我常用的模式是 Flume 采集服务器日志，直接写入 Kafka。这样 Flume 负责「搬砖」，Kafka 负责「存粮」。

# flume-kafka.conf 示例
agent.sources = tailSource
agent.channels = kafkaChannel
agent.sinks = kafkaSink

# Source：实时 tail 日志文件
agent.sources.tailSource.type = spooldir
agent.sources.tailSource.spoolDir = /var/log/app
agent.sources.tailSource.fileHeader = true

# Channel：用内存通道保证低延迟
agent.channels.kafkaChannel.type = memory
agent.channels.kafkaChannel.capacity = 10000
agent.channels.kafkaChannel.transactionCapacity = 1000

# Sink：写入 Kafka
agent.sinks.kafkaSink.type = org.apache.flume.sink.kafka.KafkaSink
agent.sinks.kafkaSink.kafka.topic = app-log-topic
agent.sinks.kafkaSink.kafka.bootstrap.servers = kafka1:9092,kafka2:9092
agent.sinks.kafkaSink.kafka.producer.acks = 1

3.2.2 什么时候该用Flume？

• 适合：采集服务器本地日志、支持多种 Source（TailDir、SpoolDir、Syslog）
• 不适合：需要复杂 ETL 的场景、需要 Exactly-Once 语义的场景

3.3 CDC技术：数据库变更的「实时镜像」

CDC（Change Data Capture）是实时采集中最有技术含量的部分。它能让下游实时感知数据库的 INSERT、UPDATE、DELETE 操作。

3.3.1 主流CDC方案对比

方案	原理	延迟	对源库影响	典型工具
基于日志	解析 Binlog/Redo Log	秒级	极小	Canal、Debezium、Maxwell
基于触发器	在表上建 Trigger	毫秒级	较大	自制方案
基于时间戳	轮询更新时间戳列	分钟级	中等	DataX、Sqoop
基于快照	定期全量对比	小时级	大	离线同步工具

我个人强烈推荐基于日志的方案。为什么？因为它对源库几乎无侵入，而且能捕获删除操作。时间戳方案只能捕获新增和更新，删除操作就漏了。

3.3.2 Debezium实战：MySQL → Kafka

Debezium 是目前最成熟的 CDC 框架之一。它基于 Kafka Connect 运行，配置起来很清爽。

# 注册 MySQL 连接器
{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "192.168.1.100",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "debezium",
    "database.server.id": "184054",
    "database.server.name": "dbserver1",
    "database.include.list": "inventory",
    "table.include.list": "inventory.orders,inventory.customers",
    "database.history.kafka.bootstrap.servers": "kafka:9092",
    "database.history.kafka.topic": "schema-changes.inventory"
  }
}

3.4 数据接入规范：没有规矩，不成方圆

数据接入规范是我在多个项目中反复强调的「软实力」。技术选型再牛，接入规范一团糟，资产运营就是空中楼阁。

3.4.1 命名规范

• Topic 命名：{数据域}.{业务系统}.{表名}.{事件类型}，例如 order.trade.orders.cdc
• 字段命名：统一使用小写蛇形，例如 user_id、create_time
• 元数据字段：每条消息必须包含 _op_type（操作类型）、_ts_ms（事件时间戳）、_source（数据来源）

3.4.2 质量规范

维度	要求	监控方式
完整性	关键字段不可为 NULL	Kafka Streams 校验 + 告警
时效性	端到端延迟 < 30秒	Prometheus + Grafana 监控
一致性	主键唯一，无重复消息	下游去重 + 离线对账
可用性	Topic 分区数 >= 3，副本数 >= 2	Kafka Manager 巡检

3.4.3 接入流程规范

1. 需求评审：确认数据源、数据量、延迟要求
2. Schema 设计：输出 Avro/Protobuf 定义文件
3. 接入测试：在测试环境跑 24 小时，验证数据量和质量
4. 灰度上线：先切 10% 流量，观察 2 小时
5. 全量上线：切换全部流量，保留旧链路 3 天作为回退方案

3.5 知识体系总览

下面这张图把实时数据采集的核心脉络串起来了。你可以把它当作本章的「导航地图」。

从这张图可以看得很清楚：数据源五花八门，但最终都汇聚到 Kafka 这个「中枢神经」上。而数据接入规范就像交通规则，保证每条数据都能安全、准时地到达目的地。