4、数据采集层设计：源系统数据抽取策略、增量与全量抽取、CDC技术选型、数据质量初检

数据采集层，说白了就是监管报送的“水龙头”。

你想想看，如果源头的水质不行，后面管道再干净、水厂处理再先进，出来的水也干净不到哪去。我在项目中见过太多团队，花大把精力搞报送逻辑、搞校验规则，结果源系统数据一抽上来就是错的——那真是白忙活一场。

所以这一章，咱们就聊聊怎么把这个“水龙头”设计好。我个人习惯把数据采集层拆成四个核心问题：抽什么、怎么抽、用什么技术抽、抽上来怎么验。

4.1 源系统数据抽取策略

先说说“抽什么”。

监管报送的数据源，通常来自核心系统、信贷系统、风险系统、财务系统等等。每个系统的数据模型、存储方式、访问权限都不一样。我建议你一开始就做一件事：梳理数据源清单。

源系统	数据类型	存储方式	访问方式	数据量级
核心系统	交易流水、账户信息	Oracle	JDBC/OGG	日均500万+
信贷系统	贷款合同、借据、还款计划	MySQL	JDBC/Canal	日均50万+
风险系统	客户评级、风险分类	SQL Server	JDBC	日均1万+
财务系统	科目余额、会计分录	DB2	JDBC/DataStage	日均10万+

有了这张清单，你才能针对每个系统设计不同的抽取策略。千万别想着“一刀切”——不同系统的数据特征差异太大了。

4.2 增量与全量抽取

接下来是“怎么抽”。

说白了就两种方式：全量抽取和增量抽取。

全量抽取：每次把源表的所有数据都拉一遍。简单粗暴，但数据量大时效率极低。适合数据量小、变化不频繁的参考数据表，比如“产品类型字典表”、“机构层级表”。

增量抽取：只拉取上次抽取之后发生变化的数据。效率高，但实现复杂。适合交易流水、账户变动这类高频变化的数据。

我个人习惯的选型原则是这样的：

• 数据量小于10万行：全量抽取，省心省力
• 数据量10万~100万行：看变化频率，变化少用全量，变化多用增量
• 数据量大于100万行：必须用增量，否则系统扛不住

增量抽取的实现方式，常见的有三种：

1. 时间戳方式：源表有更新时间字段，每次按时间范围拉取。最简单，但依赖源系统维护好时间戳。
2. 日志解析方式：解析数据库的binlog或redo log，捕获数据变更。实时性高，但需要额外配置。
3. 触发器方式：在源表上建触发器，把变更记录写入日志表。侵入性强，不推荐。

4.3 CDC技术选型

CDC（Change Data Capture）是增量抽取的“高阶玩法”。

说白了，CDC就是实时捕获源系统的数据变更，然后推送给下游。对于监管报送来说，CDC最大的价值是低延迟和低侵入。

市面上主流的CDC技术，我列个对比表：

技术	原理	支持数据库	延迟	侵入性	成熟度
Oracle GoldenGate	解析redo log	Oracle、MySQL等	秒级	低	高
Debezium	解析binlog	MySQL、PostgreSQL等	毫秒级	低	中
Canal	解析binlog	MySQL	毫秒级	低	中
Maxwell	解析binlog	MySQL	毫秒级	低	中
DataStage	轮询+时间戳	多种	分钟级	中	高

我个人的选型建议：

• 如果源系统是Oracle，优先考虑GoldenGate，成熟稳定，但贵。
• 如果源系统是MySQL，Debezium或Canal都行，开源免费，社区活跃。
• 如果预算有限、团队技术能力强，Debezium + Kafka是绝配。

4.4 数据质量初检

数据抽上来了，不代表就能直接用。

我见过太多案例：数据抽上来后，跑报送逻辑时才发现字段为空、格式不对、主键重复……那时候再回头查源系统，成本就高了。

所以，我建议在采集层就做一道数据质量初检。说白了，就是“进门先查身份证”。

初检的内容，我一般分四类：

1. 完整性检查：必填字段是否为空？主键是否唯一？
2. 准确性检查：数值范围是否合理？日期格式是否正确？
3. 一致性检查：关联字段是否能在字典表中找到？
4. 时效性检查：数据时间戳是否在合理范围内？

举个例子，假设我们抽取了“贷款借据表”，初检规则可以这样设计：

-- 完整性检查：合同号不能为空
SELECT COUNT(*) FROM loan_io WHERE contract_no IS NULL;

-- 准确性检查：贷款金额必须大于0
SELECT COUNT(*) FROM loan_io WHERE loan_amount <= 0;

-- 一致性检查：机构代码必须在机构表中存在
SELECT COUNT(*) FROM loan_io l
LEFT JOIN org_dim o ON l.org_code = o.org_code
WHERE o.org_code IS NULL;

-- 时效性检查：借据日期不能是未来日期
SELECT COUNT(*) FROM loan_io WHERE io_date > CURRENT_DATE;

如果初检发现异常数据，我建议的处理策略是：

• 严重异常（如主键重复、关键字段为空）：直接告警，暂停抽取，人工介入。
• 一般异常（如格式不规范、范围超限）：记录日志，标记数据，继续处理但后续校验时重点关注。
• 轻微异常（如时间戳偏差在1小时内）：自动修正，记录日志。

知识体系总览

最后，我用一张图把这一章的核心逻辑串起来：

嗯，这一章的内容就这些。数据采集层设计好了，后面的报送逻辑才能跑得稳。记住一句话：源头治理，事半功倍。

---

公众号:蓝海资料掘金营，微信deep3321