3. 数据源接入层设计：批式与流式数据源、API对接、数据库CDC、日志采集

数据源接入层，说白了就是数据流水线的“水龙头”。

你想想看，一个企业里数据源五花八门——有业务数据库、有用户行为日志、有第三方API、还有IoT设备上报。怎么把这些数据稳定、高效、不丢不重地接入到你的流水线里？这就是接入层要解决的问题。

我个人习惯把接入层拆成四个核心场景：批式数据源、流式数据源、API对接、数据库CDC。再加上一个常被忽略的日志采集。今天咱们一个一个聊透。

3.1 批式数据源接入

批式数据源是最传统的接入方式。典型场景：每天凌晨从ERP系统拉取昨天的订单数据，或者每周从财务系统同步一次报表。

我在项目中遇到过最典型的批式接入坑——全量同步导致源库锁表。有一次，某电商团队每天凌晨用SELECT * FROM orders全量拉取，结果跑了40分钟，把MySQL的读库直接打挂了。嗯，这里要注意：

• 优先使用增量同步：利用updated_at或自增ID做断点续传
• 分页拉取：每页1000条，避免大事务
• 限流与重试：源端扛不住时，主动降速

批式接入的典型工具链：

工具	适用场景	我踩过的坑
Sqoop	Hadoop生态与RDBMS互导	大表不加--split-by会导致数据倾斜
DataX	异构数据源批量同步	内存配置不当容易OOM
Spark批量读取	大规模数据ETL	小文件太多时，分区数要手动调

3.2 流式数据源接入

流式数据源，说白了就是“数据一直在来”。用户点击、设备上报、交易流水……这些数据要求秒级甚至毫秒级处理。

流式接入的核心挑战有三个：顺序性、去重、背压。

• 顺序性：Kafka分区内有序，但跨分区就乱了。我建议业务上按主键hash到同一分区，或者下游用事件时间做窗口。
• 去重：流式数据天然可能重复。我习惯在接入层用幂等写入+去重表（比如Redis或HBase）来兜底。
• 背压：生产者太快，消费者太慢，怎么办？Kafka的消费者可以暂停拉取，Flink有自动背压机制。但千万别让背压打爆源端。

流式接入的典型架构：

数据源 → 采集Agent → 消息队列(Kafka/Pulsar) → 流处理引擎(Flink/Spark Streaming) → 下游存储

3.3 API对接

API对接是接入层里最“脏”的活。为什么？因为每个第三方API都有自己的脾气——限流策略不同、返回格式不同、鉴权方式不同。

我曾经对接过一个物流API，它的限流策略是“每分钟100次，但超过后不是返回429，而是返回200但数据为空”。你想想看，这种坑如果不提前发现，下游数仓就会收到一堆空数据。

API对接的设计要点：

1. 限流适配器：为每个API配置独立的令牌桶或滑动窗口
2. 重试策略：指数退避 + 最大重试次数，避免雪崩
3. 数据校验层：对接入的JSON/XML做schema校验，拒绝脏数据
4. 调用日志：记录每次调用的请求/响应/耗时，方便排查

我常用的API接入框架对比：

框架	优势	劣势
Apache Camel	路由规则灵活，组件丰富	学习曲线陡
Spring Cloud Gateway	与微服务生态集成好	不适合大数据量
自研采集服务	完全可控	开发成本高

3.4 数据库CDC

数据库CDC（Change Data Capture）是近几年的热门技术。它让你能实时捕获数据库的变更——插入、更新、删除，然后把这些变更流式地同步到下游。

CDC的实现方式主要有三种：

• 基于日志解析：如Debezium读取MySQL的binlog、PostgreSQL的WAL。性能最好，对源库影响最小。
• 基于触发器：在源库建触发器，将变更写入变更表。简单但影响源库性能。
• 基于时间戳轮询：定期查询updated_at字段。实现简单，但无法捕获删除操作，延迟高。

我个人强烈推荐基于日志解析的方案。为什么？

1. 对源库几乎无侵入——你想想看，binlog本来就是MySQL用来做主从复制的，Debezium只是“偷听”一下。
2. 能捕获所有变更——包括删除，包括DDL变更。
3. 延迟低——毫秒级。

Debezium + Kafka的典型架构：

MySQL binlog → Debezium Connector → Kafka Topic → Flink/下游消费者

3.5 日志采集

日志采集，听起来简单，但做起来门道很多。服务器上的应用日志、容器标准输出、系统日志……这些数据往往是排查问题的第一手资料。

日志采集的核心链路：

应用服务器 → 日志采集Agent(Filebeat/Fluentd) → 缓冲层(Kafka) → 消费端(ES/ClickHouse/S3)

我在项目中遇到过最经典的日志采集问题——日志丢失。有一次，Filebeat的配置里close_inactive设得太短，导致文件还没读完就被关闭了，丢了大概2%的日志。排查了两天才找到原因。

日志采集的关键配置：

参数	建议值	说明
close_inactive	5m	文件多久没新内容就关闭句柄
scan_frequency	10s	多久扫描一次新文件
harvester_buffer_size	16384	读取缓冲区大小，单位字节

3.6 接入层整体架构

好了，四种接入方式都聊完了。最后，我用一张图来总结接入层的整体架构：

这张图展示了从数据源到消费端的完整链路。你会发现，无论数据源是什么类型，最终都会汇聚到消息队列这一层。为什么？因为消息队列提供了解耦、缓冲、削峰填谷的能力。这是接入层设计的核心思想。