📚 课程目录第4章批量数据集成

批量数据集成：Sqoop/DataX 与离线同步策略

批量数据集成，说白了就是把数据从源端搬到目标端。这件事看起来简单，但真做起来坑不少。我这些年经手过几十个数据集成项目，从早期的 Sqoop 到后来的 DataX，踩过的坑能写一本小册子。

今天咱们就聊聊批量集成的两个主流工具，以及离线同步中最重要的策略——全量和增量。

Sqoop 与 DataX：选哪个？

先说说这两个工具的区别。Sqoop 是 Hadoop 生态的老将，DataX 是阿里开源的后来者。我个人的习惯是：新项目优先考虑 DataX。

为什么？你看这张对比表就明白了。

对比维度	Sqoop	DataX
架构	MapReduce 作业	独立框架 + 插件
数据源支持	JDBC + HDFS/Hive/HBase	30+ 插件，含 NoSQL、消息队列
断点续传	不支持	支持
内存管理	依赖 YARN	独立 JVM 控制
社区活跃度	低（Apache 已进入维护期）	高（阿里持续更新）

我在项目中遇到过一个问题：用 Sqoop 从 MySQL 同步 500GB 数据到 Hive，跑到一半集群资源紧张，作业被 YARN kill 了。重启后得从头再来，那叫一个崩溃。换成 DataX 后，同样的场景，断点续传功能帮我省了至少 3 个小时。

我的建议：如果团队已经深度绑定 Hadoop 生态，且数据量不大（百 GB 以内），Sqoop 够用。但如果追求稳定性和运维友好度，DataX 是更好的选择。

DataX 实战：一个完整的同步任务

咱们直接看代码。下面是一个从 MySQL 同步到 HDFS 的 DataX 配置，我加了详细的注释。

{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "username": "data_user",
            "password": "******",
            "connection": [
              {
                "jdbcUrl": ["jdbc:mysql://10.0.0.1:3306/order_db"],
                "table": ["orders"],
                "splitPk": "order_id"  // 分区键，用于并行读取
              }
            ],
            "column": ["order_id", "user_id", "amount", "create_time"],
            "where": "create_time >= '2024-01-01'"
          }
        },
        "writer": {
          "name": "hdfswriter",
          "parameter": {
            "defaultFS": "hdfs://namenode:8020",
            "path": "/data/ods/orders",
            "fileType": "text",
            "writeMode": "append",
            "column": [
              {"name": "order_id", "type": "bigint"},
              {"name": "user_id", "type": "bigint"},
              {"name": "amount", "type": "double"},
              {"name": "create_time", "type": "string"}
            ]
          }
        }
      }
    ],
    "setting": {
      "speed": {
        "channel": 8,  // 并行度，根据资源调整
        "byte": 1048576  // 每秒限速 1MB
      },
      "errorLimit": {
        "record": 100,  // 允许 100 条脏数据
        "percentage": 0.02
      }
    }
  }
}

这里有个关键点：splitPk 和 channel 的配合。我刚开始用 DataX 时，把 channel 设成 16，结果源端数据库连接池被打满，业务方投诉了。后来我学乖了，channel 数一般不超过源端 CPU 核数的 2 倍。

离线同步策略：全量 vs 增量

这是批量集成的核心问题。选错了策略，轻则浪费存储，重则影响下游数据时效性。

全量同步

全量同步就是每次把源表的所有数据都拉一遍。适合小表（百万级以内）或首次初始化。

优点：逻辑简单，数据一致性高
缺点：随着数据增长，耗时线性增加
适用场景：维度表、配置表、历史数据归档

我曾经接手过一个项目，每天全量同步一张 5 亿行的订单表。跑一次要 6 小时，下游报表天天延迟。这就是典型的策略选型失误。

增量同步

增量同步只拉取变化的数据。常见的实现方式有三种。

方式	原理	优点	缺点
时间戳	根据 update_time 字段过滤	实现简单	依赖业务表有更新时间字段
自增 ID	记录上次同步的最大 ID	性能好	只能处理新增，无法捕获修改
Binlog	解析数据库变更日志	实时性高，无侵入	运维复杂，需要额外组件

我的经验：80% 的场景用「时间戳 + 自增 ID」组合就能搞定。时间戳处理修改，自增 ID 兜底新增。只有对实时性要求极高的场景才上 Binlog。

全量 + 增量混合策略

实际项目中，我很少只用一种策略。更常见的做法是：首次全量，后续增量。

具体流程是这样的：

第一次运行：全量同步，把历史数据全部拉过来
记录同步完成的时间戳和最大 ID
后续每次运行：增量同步，只拉取变化的数据
定期（比如每月）做一次全量校验，修复数据不一致

这个策略看起来简单，但有个坑要注意：增量数据的时间窗口。我遇到过一个问题：增量任务在 00:00 触发，但源端 23:59 修改的数据还没落盘，导致漏数据。解决方案是把增量窗口往前偏移 5 分钟，或者用 DataX 的 where 条件加一个缓冲区间。

避坑指南：我曾经因为没处理「删除」操作，导致目标表比源表多了 10 万条已删除数据。后来在增量同步中加了软删除标记同步，才解决这个问题。如果你的业务有物理删除，记得在同步逻辑中处理。

核心流程：一张图说清楚

下面这张图展示了批量数据集成的完整流程，从源端到目标端，以及全量/增量的切换逻辑。

实战中的几个关键点

最后分享几个我在项目中沉淀下来的经验。

限速很重要：DataX 的 byte 参数一定要设，不然会把源端打爆。我一般从 1MB/s 开始，逐步调大。
监控不能少：每个同步任务都要有耗时、数据量、脏数据率的监控。我习惯在任务结束时打印这些指标到日志里。
重试机制：网络抖动是常态。DataX 默认有重试，但建议自己再加一层，比如失败后等待 30 秒再重试，最多 3 次。
数据校验：全量同步后，一定要做行数校验。我见过因为字符集问题导致数据丢失的情况，行数对不上才发现。

一个小技巧：用 DataX 同步大表时，可以按时间分区拆成多个子任务。比如把 1 个月的数据拆成 30 天，每天一个任务。这样即使某个子任务失败，也不会影响整体进度。

批量数据集成看起来是脏活累活，但做好了，能给下游省很多事。记住一句话：全量保一致，增量保效率，混合策略保平安。