数据采集与接入：实时与批量方案对比

大家好，我是老张。今天咱们聊聊数据采集这块。

做交易审计，第一步就是数据采集。说白了，你得先把数据弄进来，才能谈后续的分析。我见过不少团队，审计模型建得挺漂亮，结果数据采集环节就翻车了——不是延迟太高，就是数据丢了，甚至精度对不上。嗯，这章咱们就把这块讲透。

一、实时采集 vs 批量采集：核心差异

先问个问题：交易数据什么时候需要实时采集？

我个人习惯这样判断——如果业务要求秒级响应，比如风控拦截、实时对账，那必须上实时方案。如果只是T+1的报表分析、历史审计，批量采集完全够用。

对比维度	实时采集（Canal/Kafka）	批量采集（Sqoop/DataX）
延迟	毫秒~秒级	分钟~小时级
资源消耗	较高（常驻进程）	较低（定时任务）
数据一致性	最终一致性	强一致性（快照）
适用场景	实时风控、在线对账	离线报表、历史审计
典型工具	Canal + Kafka	Sqoop、DataX

你想想看，实时采集就像水龙头一直开着，数据源源不断流进来。批量采集呢，更像定时去水库打水，一次打一桶。各有各的用处。

二、实时采集方案：Canal + Kafka

先说说Canal。这玩意儿是阿里巴巴开源的，专门监听MySQL的binlog。我在项目中遇到过一个问题——业务库的binlog格式没设置成ROW模式，结果Canal解析出来的数据全是错的。后来我养成了习惯，部署前先检查一下数据库配置。

Kafka在这里扮演的角色，说白了就是个缓冲层。Canal把数据推到Kafka，下游的审计系统再从Kafka消费。这样做的好处是解耦——万一审计系统挂了，数据不会丢，Kafka会帮你存着。

这里有个避坑指南：我曾经遇到Kafka消息积压导致审计延迟飙升。排查下来发现，是消费者处理能力跟不上。后来加了分区数，又调整了消费线程池大小，才算稳住。嗯，实时系统最怕的就是背压。

三、批量采集方案：Sqoop vs DataX

批量采集这块，Sqoop和DataX是主流。我个人的经验是：如果团队技术栈偏Hadoop，Sqoop更顺手；如果数据源五花八门，DataX的插件生态更丰富。

拿Sqoop举个例子，从MySQL导数据到Hive：

sqoop import \
  --connect jdbc:mysql://host:3306/trade_db \
  --username audit_user \
  --password ****** \
  --table trade_log \
  --hive-import \
  --hive-table ods.trade_log \
  --split-by id \
  --num-mappers 8

注意那个--split-by id参数。我见过有人没指定这个，结果Sqoop只启动了一个map任务，几千万的数据跑了两个小时。指定了主键或索引字段后，并行度就上来了。

DataX的配置方式类似，但更灵活：

{
  "job": {
    "content": [{
      "reader": {
        "name": "mysqlreader",
        "parameter": {
          "connection": [{"jdbcUrl": ["jdbc:mysql://host:3306/trade_db"], "table": ["trade_log"]}],
          "column": ["id", "trade_no", "amount", "create_time"],
          "splitPk": "id"
        }
      },
      "writer": {
        "name": "hdfswriter",
        "parameter": {
          "path": "/user/audit/ods/trade_log",
          "fileName": "trade_log",
          "writeMode": "append"
        }
      }
    }]
  }
}

DataX的好处是，它自带数据转换功能。比如金额字段，源库存的是分，目标库要存元，直接在配置里写个转换器就行，不用额外写代码。

四、数据质量校验规则

数据采进来了，但质量怎么样？我见过最离谱的情况——某次批量导入后，审计报表里出现了金额为负数的交易记录。查了半天，原来是源库有个字段允许负数，但业务上根本不应该出现。所以，数据质量校验必须前置。

我个人习惯在采集层做三层校验：

1. 非空校验：关键字段不能为空。比如交易流水号、交易金额、交易时间。如果为空，直接告警或丢弃。
2. 唯一性校验：交易流水号必须全局唯一。重复数据会导致后续对账、统计全部出错。
3. 金额精度校验：这个最容易被忽略。金额字段必须保留两位小数，且不能出现精度丢失。我建议用Decimal类型，别用Float。

五、知识体系总览

下面这张图，是我自己总结的数据采集全流程。你把它存下来，以后做方案设计时对照着看，基本不会漏掉关键点。

这张图把整个流程串起来了。从数据源开始，经过采集方式的选择，再到工具落地，最后是质量校验和输出。每一步都有坑，但每一步也都有解法。

好了，这章就到这里。数据采集是审计分析的地基，地基不稳，上面建什么都白搭。下一章咱们聊聊数据清洗和标准化，那又是另一番天地了。

---

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