简介：这是一份已编译完成的 Azkaban 单机版部署包，面向大数据开发者、初学者及小规模团队，解决快速搭建工作流调度环境的问题。压缩包采用 tar.gz 格式，大小约 42.28MB，无需额外编译，解压后即可进行配置与运行，适合在本地环境中验证项目创建、作业依赖编排、定时调度与日志监控等核心操作。目前已有 256 人浏览学习，是入门 Hadoop 生态调度工具的轻量级选择。资源内含可直接启动的 Web 服务、执行器与内嵌 H2 数据库，通过修改 conf/azkaban.properties 即可调整服务器端口、日志路径等参数，配合 bin 目录脚本可完成数据库初始化与启停管理。借助 Web 界面，使用者能直观体验多项目任务管理、DAG 依赖执行流程，并观察执行日志与错误信息，有助于快速理解 Azkaban 工作流引擎的工作机制；需要注意该版本为 SNAPSHOT 构建，更适用于实验验证而非生产环境。
1. 拿到 azkaban 任务调度这套 solo server 包，先别急着解压
在 azkaban 任务调度的场景里，azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz这种构建产物，第一眼看上去像是一个开箱即用的安装包，但它比想象中“挑环境”。这个包是 Azkaban 单机模式（solo server）的部署产物，把 Web 服务、任务执行器、调度存储全部压进一个进程，内置 H2 数据库，不需要额外装 MySQL，适合刚接触工作流调度的人在小团队或测试环境里快速跑通定时任务。但正因为“内置”了很多东西，启动失败时排查链路也长。我习惯先把它当成一个黑匣子来验：解压、看目录、确认依赖，再谈配置和启动。
2. solo server 的组成与选型：一个进程里到底塞了什么
2.1 三种部署模式打在同一个项目里：solo 省掉的复杂度具体在哪
Azkaban 官方提供三种部署形态：solo server、双机模式（two-server mode）、多执行器模式（multi-executor mode）。不少第一次接触的人以为 solo 只是“少两台机器”，实际上差异不止是机器数量，而是组件拆分方式。
| 部署模式 | 进程数量 | 数据库 | 适用规模 | 主要代价 |
|---|---|---|---|---|
| solo server | 1 个 Java 进程 | 内嵌 H2 | 学习、测试、单机触发 | 无高可用，状态存本地 |
| two-server mode | Web Server + Executor Server | MySQL | 小团队生产 | 要单独维护 MySQL |
| multi-executor mode | 1 个 Web + N 个 Executor | MySQL | 中大型集群 | 要处理 executor 分组与负载 |
solo server 把 Web Server 和 Executor Server 合并成一个 JVM 进程，数据库用 H2 的文件模式，整个应用的边界就是bin、conf、lib几个目录。它的价值不是处理高并发调度，而是把“部署一套调度系统”这件事的复杂度降到最低。常见做法是拿它当开发环境或临时复现工具，生产环境不建议直接沿用。
2.2 一个调度请求在 solo 里的完整路径
理解 solo server 的运行方式，关键是记住一条流转链：用户通过 Web UI 上传项目包（zip 格式，内含 .job 文件）→ 项目被存进 H2 数据库 → 调度线程按 cron 表达式触发 → 内嵌的 Executor 读取 DAG 依赖关系并逐个执行 job → 执行日志回写到 UI。
这个路径决定了你在排错时该看哪里：项目传不上去查 Web 端口和数据库；任务触发了但没跑查 executor 状态；任务跑了但结果不对查.job文件本身。我在实际使用中见过有人反复重启服务去“试”问题，其实只要打开logs/solo-server.log按时间戳对一遍就能定位到具体环节。
2.3 边界：什么场景不该用它
solo 模式的短板不是 bug，是设计边界。第一，H2 文件数据库不适合多客户端并发写，如果多个开发人员同时传项目、改调度，可能出现数据库锁等待。第二，重启会中断正在执行的任务流，没有故障转移。第三，所有数据都在本地磁盘，如果服务器磁盘损坏，历史调度记录和项目包会全部丢失。
所以我的选型建议是：单机验证、课程实验、自动化测试环境用 solo；一旦涉及多团队协作、需要稳定 SLA 的批量任务，尽早迁移到 two-server 模式或 multi-executor 模式。
3. 部署实战：解压、配置、启动，三步把调度器拉起来
3.1 环境准备：先照清单核四件事
拿到azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz之后，第一件事不是解压，是确认环境。重点看四样：JDK 版本、JAVA_HOME环境变量、端口占用、解压目录的写权限。这个步骤最容易被跳过，但大部分“起不来”都出在这里。
# 1. 确认 JDK 版本，Azkaban 要求 8 或 11，推荐 8 java -version # 2. 确认 JAVA_HOME 已设置，solo 启动脚本依赖它 echo ${JAVA_HOME} # 3. 检查 8081 和 8082 端口是否被占用 netstat -tlnp | grep -E '8081|8082' # 4. 解压到固定目录，避免放在 /tmp 下被自动清理 mkdir -p /opt/azkaban tar -zxvf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz -C /opt/azkaban逻辑说明：java -version和echo ${JAVA_HOME}是连锁的，只有JAVA_HOME指向有效的 JDK 8 安装路径，bin/start-solo.sh才能找到 Java 进程；检查端口是因为 solo 模式默认会占用 8081（Web UI）和 8082（Executor 通信），任何一个被别的服务占了，启动就会报Address already in use。
参数说明：-C指定解压目标目录，/opt/azkaban是常见部署位置。如果你想换目录，后续所有azkaban.properties里的相对路径都要重新确认。解压后建议看一眼目录结构，确认bin、conf、lib、plugins四个目录都完整。
3.2 两处必须改的配置：端口、时区、数据库路径
进入conf/azkaban.properties，这是 solo server 的唯一核心配置文件。绝大多数启动异常和调度时间错乱都源于这个文件里的三个配置项没改对。
# Web UI 端口，默认 8081 jetty.port=8081 # Executor 通信端口，默认 8082 executor.port=8082 # 时区，务必写全，否则定时任务会差 8 小时 azkaban.server.timezone=Asia/Shanghai user.timezone=Asia/Shanghai # H2 数据库文件路径，默认在内存或临时目录，必须改成固定路径 database.type=h2 h2.path=/opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT/data/h2逻辑说明：jetty.port控制的是浏览器访问的 Web UI 端口；executor.port是内嵌执行器监听调度请求的端口，两个端口值不能相等，否则会冲突。azkaban.server.timezone和user.timezone两个都改，只改其中一个会出现 UI 上显示的时间正常、实际触发时间不对的怪现象。
参数说明：h2.path的值会自动创建目录，如果填的是相对路径，会相对于启动脚本的工作目录解析，一旦你换了启动方式就可能找不到数据库文件，所以这里一律写绝对路径。
3.3 启动与验证：从日志确认服务健康
配置完成后，启动、验证、看日志要按顺序来。solo server 的启动脚本对执行目录敏感，建议先cd到解压目录再执行。
cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 前台启动，观察启动日志输出 bin/start-solo.sh # 另开一个终端，等待 30 秒后确认进程存在 ps -ef | grep azkaban # 用 curl 验证 Web UI 是否返回正常状态码 curl -I http://localhost:8081逻辑说明：bin/start-solo.sh默认以后台方式启动，日志写入logs/solo-server.log。如果进程存在但curl没有返回200或302，说明 Web 容器还没完全初始化，等几秒再试。我一般会用tail -f logs/solo-server.log同时盯着日志看有没有Starting Azkaban Server和Server started两行关键记录。
参数说明：curl -I只发 HEAD 请求，适合快速探测服务存活，不会触发实际任务。solo 模式的默认登录账号是azkaban / azkaban，第一次登录后建议立即在用户管理里改密，这个默认口令在任何公网可达的服务器上都是风险点。
4. 避坑与常见问题排查：五条真实踩坑记录
4.1 现象：服务进程活着，但浏览器一直连不上
原因：azkaban.properties里改了jetty.port，但防火墙规则只放行了安装前的初始端口；或者是 H2 数据库初始化失败，导致 Web 容器启动到一半就卡住。
解决：先看logs/solo-server.log，如果最后几行有Database connection failed，优先检查h2.path的目录权限是否允许当前用户写文件；如果日志显示端口绑定异常，用netstat -tlnp确认端口实际监听情况，然后同步修改防火墙白名单。
4.2 现象：上传项目 zip 包时一直卡在 Preparing 状态
原因：zip 包里的 job 文件名包含中文字符或特殊符号，Azkaban 在解析项目包时对文件名编码敏感；另外 zip 包根目录下混入了.DS_Store之类的隐藏文件，也会导致解析流程卡住。
解决：把所有 job 文件名改成小写英文字母和下划线，重新打包上传；在压缩时排除隐藏文件。我在本地打包时加过一层检查，确认 zip 内没有以.开头的条目。
4.3 现象：定时任务每次触发都比预期晚 8 小时
原因：只改了azkaban.server.timezone，没有改 JVM 级别的user.timezone；Azkaban 的调度线程读取的是 JVM 默认时区，UI 显示的是配置时区，两边不一致就会出现这种“时间显示正常、触发不对”的错位。
解决：在bin/start-solo.sh的 JVM 参数里加一行-Duser.timezone=Asia/Shanghai，同时保留 properties 里的两个时区配置，重启验证。
4.4 现象：重启一次，项目、调度全部消失
原因：database.type=h2但h2.path没有配置，H2 默认跑在内存模式；或者h2.path配置的是相对路径，启动脚本工作目录换了，数据库文件实际散落在不同位置。
解决：把h2.path改成固定绝对路径，例如/opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT/data/h2，重启后再查看该目录下是否生成.mv.db文件。这个文件就是你的全部调度数据，备份它就是备份整个 solo 服务状态。
4.5 现象：SNAPSHOT 包启动时报 UnsupportedClassVersionError
原因：这个包编译时用的 JDK 版本和本机JAVA_HOME指向的版本不一致，最常见的是包基于 JDK 8 编译，而本机默认 JDK 是 11 或更高。
解决：安装对应版本的 OpenJDK，然后显式导出JAVA_HOME再启动。
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=${JAVA_HOME}/bin:${PATH} bin/start-solo.sh这条命令的本质是强制启动脚本使用指定的 JDK，不依赖系统默认版本。
5. 进阶用法：用 solo server 跑通第一个带依赖的工作流
5.1 写一个最小可跑的 job 文件
Azkaban 的调度单位是 job，job 之间可以用dependencies字段组织成 DAG。在 solo 里验证功能时，最常见的做法是写几个 command 类型的 job，从最简单的一个节点开始。
# hello.job type=command command=echo "hello azkaban"# world.job type=command command=echo "world" dependencies=hello逻辑说明：hello.job不依赖任何节点，启动后立即执行；world.job声明依赖hello，只有hello执行成功，world才会进入调度队列。两个文件打包成 zip 后，在 Web UI 上创建项目、上传、执行流，就能看到两个节点的执行顺序是先后而非并行。
5.2 用 Web UI 验证执行与日志
上传 zip 包后，项目里会自动生成一个 flow，flow 名默认是hello（以第一个 job 文件名为准）。点击 execute 按钮，在 Execution 页面能看到每个 job 的状态流转：READY → RUNNING → SUCCEEDED。如果某个节点失败，点进 job 详情就能看到完整的标准输出和错误流。这一步是验证整个 solo 服务是否健康最直观的方式。
5.3 把手动执行改成定时调度
在 flow 页面点击 schedule 按钮，填 cron 表达式。Azkaban 的 cron 是标准 7 段格式，和 Linux crontab 相比多了秒位。
# 每天早上 8 点触发一次，秒位固定为 0 0 0 8 * * * ?参数说明：第一位是秒，第二位是分，第三位是小时，?表示不指定具体值。配置完成后，调度列表里能看到这条 cron 记录。从那以后我每次部署 solo server，都强制走一遍固定流程：先改时区、再固定数据库路径、再启动、再看日志，顺序不乱，问题自然少一半。希望这套流程也能帮你在 azkaban 任务调度上少走弯路。
本文还有配套的精品资源，点击获取
