6.3 单机部署与配置

6.3 单机部署与配置

单机部署是验证 DataX 能力的最快路径：解压、跑通官方样例、再换成自己的 job。这一节给一份最小可操作步骤。

解压即用

DataX 是绿色包，解压到任意目录即可。python bin/datax.py job/xxx.json 就能跑。第一次建议跑自带的 stream2stream 样例，确认 JDK/Python 没问题，再上真实数据源。

# 6.3 单机部署与配置
tar -xzf datax.tar.gz -C /opt/
# 跑官方自检样例（不依赖任何外部数据源）
python /opt/datax/bin/datax.py /opt/datax/job/job.json
# 看到 Total 行且任务成功即环境 OK
​

第一个真实任务

从 MySQL 读一行、写一行到 Hive 的最小配置，建议先小表试跑，确认插件连通、类型对得上，再放大到全量。我们坚持「先用最小样本验证链路，再放量」，避免一上来就跑几亿行然后卡在某个类型转换上。

{
  "job": {
    "content": [
      {
        "reader": { "name": "mysqlreader", "parameter": {
          "connection": [{ "jdbcUrl": ["jdbc:mysql://h:3306/d"], "table": ["t1"] }],
          "column": ["id", "name"], "splitPk": "id" } },
        "writer": { "name": "streamwriter", "parameter": { "print": true } }
      }
    ],
    "setting": { "speed": { "channel": 1 } }
  }
}
​

常见部署坑

解压路径含中文或空格，个别插件加载会出问题，建议放纯英文路径。机器时间不准会导致日志混乱、证书类连接失败，我们部署脚本里会先校时。这些小事不显眼，却能省下大半排错时间。

我们的建议

单机阶段就养成「配置进 git、密码进环境变量、日志落固定目录」的习惯。等上集群时，这些习惯直接复用，不会因为换环境而手忙脚乱。

小样本验证再放量

我们从 MySQL 读一行写一行到 streamwriter 的最小配置，先小表试跑，确认插件连通、类型对得上，再放大到全量。坚持「先用最小样本验证链路，再放量」，避免一上来就跑几亿行然后卡在某个类型转换上。

我们单机阶段就养成「配置进 git、密码进环境变量、日志落固定目录」的习惯，上集群时直接复用，不会因为换环境手忙脚乱。

延伸与提醒

任务的读写速率差，比绝对速率更能说明瓶颈在哪一段。
配置进版本库、密码进环境变量，是跨环境复用的基础。
日志里周期打印的读写速率，是定位瓶颈的第一手材料。
eswriter 的批量 bulk 写入，比逐条插入快一个数量级。
preSql 里带 truncate 的任务，上线前必须二次确认目标表名。
插件目录名必须和 job.json 的 name 完全一致，大小写都不能错。
调优的本质是在 CPU、网络带宽和磁盘 IO 之间找平衡点，不是堆资源。
JVM 堆要给 Channel 缓冲留足空间，否则 GC 频繁拖慢吞吐。
querySql 与 column 二选一，混用会直接报错。
脏数据阈值设得太高，会掩盖源端的数据质量问题，反而埋雷。
权限收得越紧，凭据泄露的爆炸半径越小。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
writeMode 必须和数据更新语义对齐，不能凭感觉选。
数据湖贴源层保留原始形态，方便后续 schema 演化。
测试样本先小后大，几分钟校验能省下几小时排错。
Reader 和 Writer 互不知晓，正是插件能独立扩展的原因。
源库索引评审应作为同步查询上线的前置环节。
把复杂 join 留在计算引擎，DataX 只做贴源搬运。
DataX 的设计哲学是把连接差异收敛到插件，让核心只管调度与缓冲。
orc 加 snappy 是 Hive 落地的常见稳妥组合，省空间且查询快。
监控指标和 DataX 日志交叉看，能锁定九成瓶颈。
把转换逻辑下推到源库，通常比在 DataX 内部处理更高效。
Web 平台解决协作与可观测，不提升同步能力本身。
反压机制保护内存，看到任务变慢应去优化下游而非加并发。
任务可重跑幂等，是生产上线前的硬指标。
自定义插件最容易踩的坑是依赖冲突，provided 范围能治本。

背景

单机部署是把 DataX 用起来的最小形态：一台机器、一个解压包、一份 job。它适合中小数据量或作为开发验证环境。

操作：单机运行一次同步

# 1) 准备一份 mysql -> hdfs 的 job
cat > job/first.json <<'JSON'
{
  "job": {
    "content": [ { "reader": { "name": "mysqlreader", "parameter": {
      "connection": [ { "jdbcUrl": ["jdbc:mysql://db:3306/demo"], "table": ["t_demo"], "splitPk": "id" } ],
      "column": ["id","name"] } },
      "writer": { "name": "hdfswriter", "parameter": {
        "defaultFS": "hdfs://ns", "path": "/data/demo", "fileType": "text",
        "column": [ {"name":"id","type":"bigint"}, {"name":"name","type":"string"} ] } } } ],
    "setting": { "speed": { "channel": 2 } } }
}
JSON
# 2) 运行
python bin/datax.py job/first.json
​

启动命令

# 查看运行日志，确认无报错且写出文件
tail -n 30 log/datax.log
hdfs dfs -ls /data/demo
​

结果解读

单机部署的核心是「解压即用」。所有 Task 在同一 JVM 内以多线程并发，channel 直接对应线程数。受单机 CPU、内存、磁盘 IO 限制，单机适合日同步量在千万级以内或作为联调环境。日志里能看到每个 channel 的起止与汇总，是后续上集群前的「压力预演」。

变式

开发期可把 core.json 的 JVM 内存调小避免占满本机，生产单机则按需调大；也可把 job 与日志挂到独立磁盘，减少 IO 争用。

单机要点对照

💡 关键直觉：单机部署像「一台水泵接一根总管」，简单可靠但上限受这台机器约束。先把单机跑顺，再去想怎么多台协作。

⚠️ 常见坑：在本机把 channel 设到几十，结果所有 Task 抢同一核与同一块内存，单机上反而比适中 channel 更慢；单机资源有限，channel 要按「核数一半、内存余量」来定。