8.2 DataX在数据湖、数据仓库建设中的应用

8.2 DataX在数据湖、数据仓库建设中的应用

DataX 在湖仓体系里扮演「贴源搬运工」：把业务系统的数据搬进湖或仓的贴源层，后续的建模、计算交给专用引擎。它的位置很清晰，不该越界。

入仓初始化

数仓 ODS 层的数据，多数来自业务库全量+增量。DataX 用关系型 Reader 抽到 Hive/仓，按天分区落 ODS。全量用 querySql 拉整段，增量用 where 按时间或主键推进。这条链路是数仓最基础的「血液供应」。

{
  "reader": { "name": "mysqlreader", "parameter": {
    "connection": [{ "jdbcUrl": ["jdbc:mysql://h:3306/ods"], "table": ["orders"] }],
    "column": ["id", "user_id", "amount", "created_at"], "splitPk": "id",
    "where": "created_at >= '${bizdate}'" } },
  "writer": { "name": "hdfswriter", "parameter": {
    "path": "/warehouse/ods/orders/dt=${bizdate}", "fileType": "orc" } }
}
​

入湖贴源层

数据湖的贴源（raw）层常落在 OSS/HDFS。DataX 把各种源的数据原样搬进来，保留原始形态，供后续清洗和 schema 演化。它不负责湖的格式治理，只保证「源数据完整到场」。

与增量的配合

DataX 是批的利器，实时增量要靠 CDC（如 Canal）捕获变更日志，再决定怎么补。我们常用「DataX 做全量基线 + CDC 做增量补充」的组合，既稳又新。把 DataX 当批的底座，不要把它的批能力硬拗成流。

我们的架构观

DataX 在湖仓里就该待在「贴源搬运」这一格，别让它做join、做聚合。职责清，链路才稳，出问题也才好定位——这和我们一贯的边界划分一致。

批与流各司其职

DataX 是批的利器，实时增量要靠 CDC 捕获变更日志。我们常用「DataX 做全量基线 + CDC 做增量补充」的组合，既稳又新。把 DataX 当批的底座，不要把它的批能力硬拗成流。

生产环境的稳定性，常常取决于部署习惯而非某个高级特性。
数据湖贴源层保留原始形态，方便后续 schema 演化。
配置进版本库、密码进环境变量，是跨环境复用的基础。
反压机制保护内存，看到任务变慢应去优化下游而非加并发。
把复杂 join 留在计算引擎，DataX 只做贴源搬运。
rowkey 的散列前缀设计，能避免 HBase 写入热点。
限速不是限制能力，而是给其他任务留出生存空间。
监控指标和 DataX 日志交叉看，能锁定九成瓶颈。
全量基线加增量补充，是批流配合的常见稳妥组合。
querySql 与 column 二选一，混用会直接报错。
Redis 同步重跑要防重复 key，靠固定模板才能幂等。
Reader 和 Writer 互不知晓，正是插件能独立扩展的原因。
preSql 里带 truncate 的任务，上线前必须二次确认目标表名。
eswriter 的批量 bulk 写入，比逐条插入快一个数量级。
测试样本先小后大，几分钟校验能省下几小时排错。
星型拓扑把 N 乘 M 的对接降到 N 加 M，变更成本随之下降。
插件目录名必须和 job.json 的 name 完全一致，大小写都不能错。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
源库索引评审应作为同步查询上线的前置环节。

入湖贴源层常用 orc 落地，下面是 Writer 的简写。

{
  "writer": {
    "name": "hdfswriter",
    "parameter": { "path": "/warehouse/ods/orders/dt=${bizdate}", "fileType": "orc", "compress": "snappy" }
  }
}
​

背景

无论是数据仓库还是数据湖，「先把数据搬进来」都是第一步。DataX 的稳定性与插件广度，使它成为这些架构里最常被用作「进水口」的同步工具。

操作：业务库到 Hive 数仓的落库配置

{
  "job": {
    "content": [
      {
        "reader": { "name": "mysqlreader", "parameter": {
          "connection": [ { "jdbcUrl": ["jdbc:mysql://db:3306/dwd"], "table": ["t_user"], "splitPk": "id" } ],
          "column": ["id","name","age","city"]
        } },
        "writer": { "name": "hdfswriter", "parameter": {
          "defaultFS": "hdfs://ns",
          "path": "/user/hive/warehouse/dwd.db/t_user/dt=20240101",
          "fileType": "orc",
          "column": [ {"name":"id","type":"bigint"}, {"name":"name","type":"string"}, {"name":"age","type":"int"}, {"name":"city","type":"string"} ]
        } }
      }
    ],
    "setting": { "speed": { "channel": 10 } }
  }
}
​

启动命令

# 8.2 DataX在数据湖、数据仓库建设中的应用
hive -e "ALTER TABLE dwd.t_user ADD IF NOT EXISTS PARTITION (dt='20240101');"
​

结果解读

在数仓分层里，DataX 通常承担 ODS / DWD 层的「贴源同步」：把业务库数据按天分区搬进 HDFS，再由 Hive / Spark 做后续清洗与聚合。在数据湖场景，它把多源数据统一落进湖存储，供不同引擎按需读取。它的价值是「让上游多种数据源，以统一、稳定的方式汇入同一个底座」，屏蔽了源端差异。

变式

若目标是 Iceberg / Hudi 等湖表格式，可用对应的 writer 插件，DataX 负责把增量数据写进湖表的变更日志，支撑 ACID 与时间点查询。

架构角色对照

💡 关键直觉：在数仓 / 数据湖里，DataX 是「进水口」——它不生产数据，但决定了上游各种水源能否稳定、保真地流进同一个底座。进水口稳，下游才好做文章。

⚠️ 常见坑：落盘格式与 Hive 表声明不一致（如 DataX 写 text 但表是 ORC），外表读到 NULL 或乱码；湖仓底座的「格式契约」必须由 DataX 的 writer 配置严格履约。