简介：Azkaban Solo Server 单机版编译包，面向个人开发者与小型团队，用于快速搭建轻量级工作流调度环境，解决 Hadoop 作业及 Shell、Java 任务按依赖顺序执行与定时调度的问题。压缩包为 tar.gz 格式，整体约 42.28MB，解压后可直接运行，无需额外编译。包内包含 Web 服务、执行器与内嵌 H2 数据库等组件，通过 conf 配置与 bin 脚本即可完成初始化、启动与访问，适合本地测试与学习。目前已有 256 人学习下载，可作为入门 Azkaban 的实践素材。借助其直观的 Web 界面，读者能创建项目、定义作业依赖、设计工作流、设置定时任务，并查看执行状态与日志，从而理解调度引擎的核心机制。需注意该版本为 SNAPSHOT 开发版，稳定性有限，生产环境建议改用稳定版或集群部署。
1. 从一份 azkaban-solo-server 包说起：单机任务调度到底能跑多快
手里这份azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz，第一次看到的人多半会愣一下：版本号带 SNAPSHOT，说明它不是正式 release，而是某个构建流水线里打出来的快照包。它解决的事情很具体——把 Azkaban 的 solo 模式（单机模式）打包成一个可以直接解压运行的目录，不需要 MySQL 外部库，不需要 executor、web、exec 三件套分开部署，一个进程里同时扛下 Web 服务和执行器。适合谁？适合想快速验证工作流调度逻辑的人、适合在本地或测试机上跑定时任务编排的人、适合拿它当学习 Azkaban 内部调度模型的入口。不适合谁？不适合生产环境多节点高可用，solo 模式本身就是单点，挂了就是挂了，没有后悔药。下面按「它是什么 → 怎么跑起来 → 参数怎么调 → 坑在哪 → 怎么验证」的顺序拆开讲。
2. solo 模式的调度原理与解压即用流程
2.1 solo 模式到底把哪些组件塞进了一个进程
标准 Azkaban 是三节点架构：Web Server 负责界面和 API，Executor Server 负责实际跑任务，MySQL 存元数据。solo 模式把这三者压缩成一个 JVM 进程，元数据落到本地 H2 数据库文件里，执行器线程池直接内嵌。这意味着你不需要装 MySQL，不需要配 executor 的 host 和 port，启动脚本一跑，Web 端口和执行线程同时就绪。代价是并发能力受限于单机内存和 CPU，任务多了会排队，H2 在大量写入时性能会掉。常见做法是 solo 只用来做流程验证和开发调试，正式跑批还是拆成多节点。
2.2 解压与目录结构确认
拿到 tar.gz 之后先别急着启动，看一眼解压出来的目录，确认关键文件都在。
# 解压到当前目录 tar -xzf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz # 进入解压后的目录，目录名通常与包名一致 cd azkaban-solo-server-0.1.0-SNAPSHOT # 查看顶层结构 ls -la正常会看到bin/、conf/、lib/、plugins/这几个目录。bin/下是启动和停止脚本，conf/下是azkaban.properties和日志配置，lib/是全部依赖 jar，plugins/放 job 类型插件。如果解压后没有conf/azkaban.properties，说明包不完整，别往下走了。
2.3 启动脚本与首次运行
solo 模式的启动入口在bin/下，通常是start-solo.sh。启动前先确认 Java 版本，Azkaban 0.1.0 这个代际的代码对 JDK 8 兼容最好，JDK 11 以上会有模块化相关的反射警告甚至启动失败。
# 确认 Java 版本，建议 1.8 java -version # 赋予脚本执行权限 chmod +x bin/*.sh # 前台启动，方便看日志 bin/start-solo.sh启动过程中控制台会打印 Web 服务器绑定端口和 H2 数据库初始化信息。默认端口是 8081，如果被占用会在日志里报Address already in use。启动成功后浏览器访问http://localhost:8081就能看到登录页。默认账号密码在conf/azkaban.properties里由azkaban.users相关配置决定，solo 包通常内置一个默认用户，首次登录后建议改掉。
2.4 用 API 提交一个最小工作流
界面操作谁都会点，但真正要集成到 CI 或脚本里，得走 API。solo 模式同样暴露了 REST 接口，先拿 session id，再创建项目、上传 zip 包、触发执行。
# 1. 登录获取 session.id curl -k -X POST http://localhost:8081 -d "action=login&username=azkaban&password=azkaban" -c cookies.txt # 2. 创建项目 curl -k -X POST http://localhost:8081/manager?action=create \ -b cookies.txt -d "name=test_project&description=demo" # 3. 上传工作流 zip 包 curl -k -X POST http://localhost:8081/manager?action=upload \ -b cookies.txt -F "file=@flow.zip" -F "project=test_project" # 4. 触发执行 curl -k -X POST http://localhost:8081/executor?action=execute \ -b cookies.txt -d "project=test_project&flow=my_flow"这里-k是因为 solo 默认用自签证书起 HTTPS，本地调试跳过校验。cookies.txt保存会话，后续请求都带上。flow.zip里必须包含.job文件和可选的.flow文件，zip 根目录直接放 job 文件，不要多套一层文件夹，这是最常见的上传失败原因。
3. 关键配置参数与 job 文件写法
3.1 azkaban.properties 里必须关注的几项
solo 的配置文件不长，但有几项改错了直接起不来。
| 配置项 | 默认值 | 作用 | 调整建议 |
|---|---|---|---|
azkaban.webserver.port | 8081 | Web 监听端口 | 冲突时改 |
azkaban.webserver.ssl | true | 是否启用 HTTPS | 本地可改 false |
database.type | h2 | 元数据库类型 | solo 固定 h2 |
h2.path | ./h2db | H2 数据文件目录 | 确保有写权限 |
executor.port | 12321 | 内嵌执行器端口 | 一般不用动 |
azkaban.max.threads | 30 | 执行线程上限 | 按内存调 |
h2.path指向的目录如果不存在，启动时会自动建，但如果父目录没有写权限就会静默失败，日志里只报一句Failed to initialize database，很容易看漏。我一般会先手动mkdir -p并chmod 755。
3.2 写一个带依赖的 job 文件
Azkaban 的 job 文件是 key=value 格式，type=command表示跑 shell 命令，dependencies声明前置 job。
# extract.job type=command command=echo "extracting data" && sleep 2 # transform.job type=command command=echo "transforming data" && sleep 3 dependencies=extract # load.job type=command command=echo "loading data" && sleep 1 dependencies=transform三个 job 形成 extract → transform → load 的链。dependencies写的是 job 文件名去掉.job后缀。如果依赖的 job 名字写错，Azkaban 不会报错说找不到，而是直接把这个 job 当成无依赖的起点跑，结果就是顺序全乱。这是血泪经验，上传后一定在界面上看一眼 DAG 图确认依赖关系。
3.3 用 flow 文件控制整体参数
.flow文件可以给整个流程设参数，也能覆盖 job 里的配置。
# my_flow.flow nodes: - name: extract type: command config: command: echo "flow-level extract" - name: transform type: command dependsOn: - extractflow 文件适合把参数集中管理，但注意它和 job 文件同时存在时，flow 里的 config 优先级更高。如果两边都写了 command，以 flow 为准。混用时容易搞不清哪个生效，建议要么全用 job 文件，要么全用 flow 文件。
4. 避坑与常见问题排查
4.1 启动报端口占用但改端口后仍失败
现象：日志报Address already in use，改了azkaban.webserver.port后还是起不来。原因：solo 模式内嵌执行器也占一个端口，默认 12321，这个端口冲突不会在 Web 端口报错里体现。解决：用netstat -tlnp | grep 12321确认，改executor.port为其他值再启动。
4.2 上传 zip 后项目里看不到 flow
现象：上传成功提示，但项目页面里没有可执行的 flow。原因：zip 包多套了一层目录，或者 job 文件不在 zip 根目录。解决：重新打包，确保zip -r flow.zip *.job在 job 文件所在目录执行，解压验证unzip -l flow.zip看到的是extract.job而不是folder/extract.job。
4.3 任务一直处于 running 不结束
现象：job 状态卡在 running，日志里没有输出。原因：command 里跑的是交互式命令或需要 TTY 的命令，solo 执行器没有分配终端。解决：把命令改成非交互式，比如ssh加-o BatchMode=yes，或者用nohup包一层。另外检查azkaban.max.threads是否被占满，排队中的任务不会显示 running。
4.4 H2 数据库文件损坏导致无法启动
现象：之前能跑，某次异常退出后启动报数据库相关异常。原因：H2 在进程被 kill 时可能留下未提交的锁文件。解决：停掉进程，删除h2db/下的.lock文件，必要时用 H2 的Recover工具修复。预防做法是每次停服务用bin/shutdown-solo.sh而不是直接 kill。
4.5 中文日志乱码
现象：job 输出里的中文在 Web 界面显示为问号。原因：JVM 默认字符集与页面编码不一致。解决：在启动脚本里加-Dfile.encoding=UTF-8，同时确认azkaban.properties里没有覆盖日志编码的配置。这个坑在只跑英文命令时不会暴露，一旦有中文输出就翻车。
5. 验证调度是否真的按预期执行
跑起来不等于跑对。我习惯用三个手段交叉验证：第一，看 DAG 图，确认依赖箭头方向正确；第二，看每个 job 的日志时间戳，extract 的结束时间应该早于 transform 的开始时间；第三，在最后一个 job 里写一个带时间戳的标记文件，跑完后检查文件内容。
# 在 load.job 里加一行，把完成时间写入文件 command=echo "load done at $(date +%s)" >> /tmp/azkaban_verify.log跑完后cat /tmp/azkaban_verify.log，如果时间戳递增且间隔合理，说明调度链是串行执行的。如果发现时间戳几乎相同，说明依赖没生效，回去检查dependencies拼写。另外可以用 API 拉执行状态：
# 查询最近一次执行的详情 curl -k "http://localhost:8081/executor?ajax=fetchexecflow&execid=123&project=test_project" -b cookies.txt返回的 JSON 里status字段为SUCCEEDED才算真正跑完。我一般会在 CI 脚本里轮询这个接口，直到状态变为终态再继续下一步。从那以后我每次改完 job 依赖，都强制先跑一遍这个验证流程，确认时间戳顺序对了才提交。希望帮到你。
本文还有配套的精品资源，点击获取
