简介面向大数据任务调度场景的Azkaban单服务器版预编译包适合需要快速搭建工作流引擎的开发者、数据工程师也适合希望掌握任务依赖调度与定时执行机制的技术人员。该版本采用Solo Server单机模式将Web服务、任务执行器与H2数据库整合在同一环境中压缩包为tar.gz格式体积仅42.28MB解压配置后即可直接启动省去源码编译与Maven构建的繁琐环节。借助直观的Web界面用户能够创建项目、定义作业、按依赖关系编排工作流并设置定时触发同时支持Hadoop MapReduce、Shell脚本、Java程序等多种任务类型覆盖常见的大数据处理与ETL流程。目前已有255人学习使用该预编译包既可作为小规模环境下的轻量调度工具也非常适合作为入门Azkaban的实践资源帮助数据开发者快速理解工作流引擎的核心设计。 第一次接触 Azkaban是我在做一个内部数据平台选型的时候。当时团队需要一个轻量级的调度器既要能跑定时任务又要支持任务间的依赖关系还不能太重。调研了一圈Airflow 依赖 Python 生态OOZIE 配置让人头大最后看到 Azkaban 官方提供的azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz这个包才发现原来调度器也可以做到解压即用。Solo Server 把 Web Server 和 Executor Server 合并成了一个进程内置 H2 数据库不需要额外装 MySQL也不需要单独起执行器整个调度系统在本地五分钟就能跑起来。这篇就记录我从解压这个 tar.gz 到跑通第一个工作流的完整过程包括我踩过的坑和最后的排查思路。很多人看到版本号上的 SNAPSHOT 就直接劝退了其实在本地实验环境跑一下就会发现这个包的基础功能非常完整足以用来评估 Azkaban 是否适合你的业务也适合第一次接触调度系统的同学快速理解任务编排的核心模型。1. 理解这个包Solo Server 到底解决了什么问题Azkaban 的部署模式一共有三种搞懂这三种模式的区别你就知道我去下载这个 solo-server 包而不是直接搭集群的原因了。Solo ServerWeb Server、Executor Server、H2 数据库全部塞进同一个 JVM 进程启动一个脚本全搞定数据默认存在本地文件里不需要任何外部依赖。Two ServerWeb Server 和 Executor Server 分开部署数据库换成 MySQL支持更稳定的生产调度场景。Multiple Executor在 Two Server 基础上扩展多个 Executor 节点适合任务量大、需要横向扩展的团队。这三种模式的核心调度逻辑一模一样区别只在部署拓扑和存储层。也就是说你在 solo-server 上写的 job 文件、建立的依赖关系到了生产环境基本原样可用。我当时选 solo-server核心诉求就是一个用最快的速度验证 Azkaban 的任务编排方式适不适合我们团队。部署模式的对比看这张表就清楚部署模式Web ServerExecutor Server数据库适用场景Solo Server内置内置H2 内嵌本地开发、功能验证、学习Two Server独立独立MySQL小规模生产调度Multiple Executor独立多节点MySQL大规模生产调度这里有个反直觉的点虽然名字叫 solo但它内部依然是 Web Server 和 Executor Server 两套服务协同工作只不过进程合并了。这个认知在后面排错时特别有用——当你看到日志里既有 web 相关的输出又有 executor 相关的输出不要觉得奇怪那是两个服务在同一个进程里各自干活。另一个容易忽略的点是solo-server 使用的是 H2 数据库。H2 是纯 Java 实现的嵌入式数据库数据文件就落在本地目录里做备份时直接把整个数据目录复制走就行不需要像 MySQL 那样先做 dump。这在你后面想迁移数据到正式环境时是个小小的便利。2. 把 tar.gz 变成能跑起来的服务解压、环境与目录结构2.1 环境要求与解压命令solo-server 的核心依赖只有两个JDK 8 和 tar 命令。JDK 8 这个要求看着简单其实暗藏了很多坑后面专门说。先看解压tar -zxvf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz解压之后目录结构是这样的azkaban-solo-server-0.1.0-SNAPSHOT/ ├── bin/ │ ├── start-solo.sh │ └── shutdown-solo.sh ├── conf/ │ ├── azkaban.properties │ └── azkaban-users.xml ├── lib/ ├── plugins/ ├── h2/ └── logs/2.2 启动与访问启动命令就一条cd azkaban-solo-server-0.1.0-SNAPSHOT ./bin/start-solo.sh启动成功后浏览器访问http://localhost:8081默认账号密码都是azkaban。此时你就能看到 Azkaban 的 Web 控制台了。先别急着点任何按钮先把logs/azkaban-webserver.log这个文件打开看一眼确认日志里没有红色的 ERROR 或者 WARN。这个习惯我从那之后一直保留——很多看似正常启动的服务其实内部已经在报错只是控制台没显示而已。需要特别留意的是停止服务时不要用 kill -9 直接杀进程要执行./bin/shutdown-solo.sh这个脚本会触发完整的关闭流程让正在执行的任务有足够时间保存状态。我见过有人直接 kill 进程结果 H2 数据库的写缓存没落盘导致整个项目配置丢失的情况。2.3 关键目录的作用conf/配置文件所在地改配置就是改这里的文件。lib/Azkaban 自身的 jar 包。plugins/插件目录Solo Server 默认会加载这里的 job 类型插件。h2/H2 数据库文件存放位置。这是你的项目定义、执行历史、调度记录的最终归宿备份就备份这个文件夹。logs/日志目录。排错第一站后面排坑章节会反复提到。这一套目录结构摸清楚之后你对 Azkaban 的运作方式就有了一个整体画面配置驱动启动任务数据落 H2执行过程记日志插件扩展任务类型。3. 启动前的配置功课azkaban.properties 到底改了哪些参数3.1 核心配置项解读solo-server 的解压即用是相对的至少有以下几处配置我建议在启动前就改好否则后面写任务调度时会遇到各种对不上的诡异问题。打开conf/azkaban.properties重点看这几个参数# Jetty 服务端口默认 8081如果你本机 8081 被占用改成其他端口 jetty.port8081 # 时区设置强烈建议改成 Asia/Shanghai default.timezone.idAsia/Shanghai # 数据库类型solo 模式固定为 h2 database.typeh2 h2.path./h23.2 时区看似无所谓实际影响巨大default.timezone.id是最容易忽略的配置。Azkaban 默认使用 UTC 时间如果你设置的调度时间是每天早上 9 点实际上会在北京时间下午 5 点触发整整差 8 个小时。我第一次跑定时任务时看到任务在错误的时间点被触发第一反应是时区设置有问题结果发现配置文件里默认就是这个只能改完重启。改成Asia/Shanghai之后Web 页面的时间显示和执行时间都会统一到北京时间。这一步在 project 里看执行历史时尤其重要否则你看到的时间戳总感觉差了点什么。3.3 用户管理与权限默认账号azkaban/azkaban拥有管理员权限测试用没问题但如果你和其他人共享这个服务建议在conf/azkaban-users.xml里新增普通用户。最简单的用户配置是这样的user usernamedev passworddev123 rolesmetrics/加完用户之后需要重启服务才生效。Azkaban 的权限模型比较接近 Linux 的组概念先用简单配置把用户和密码加上后面需要更细粒度的项目权限控制时再研究角色体系也不晚。我踩过的一个教训是别在 solo 模式下过度配置。Azkaban 的azkaban.properties里其实还包含很多 two-server 模式才会用到的配置项比如 MySQL 连接串、Executor 主机端口等。solo 模式下这些配置虽然存在但根本没启用你把它们改来改去反而容易引发奇怪的问题。solo 模式基本只要管端口、时区、用户这三类就够了。4. 从控制台到第一个工作流项目创建与任务提交全链路配置完成并启动成功后接下来就是 Azkaban 最核心的使用链路创建项目、打包 job、上传 zip、执行任务。4.1 创建项目Web 控制台首页右上角有一个创建项目的按钮填一个项目名称和描述就可以了。项目会对应后续上传的所有工作流定义这里不需要选任何引擎或执行器因为 solo-server 已经在本地把一切都备好了。4.2 job 文件格式与依赖设计Azkaban 的工作流定义是以.job文件为基本单位的一个 job 文件就是一个任务节点。文件格式本质上是 Java properties 格式每一行都是keyvalue。下面我建一个最简单的依赖链示例包含两个 job 文件第一个 jobfirst.jobtypecommand commandecho hello azkaban第二个 jobsecond.jobtypecommand dependenciesfirst commandecho second job donedependenciesfirst表示second.job依赖first.jobAzkaban 在执行时会先跑完first再启动second。这是 Azkaban 最核心的编排方式——任务间通过依赖关系表达拓扑而不是通过脚本里的顺序判断。4.3 打包上传Azkaban 的 Web UI 不支持在线编辑 job 文件必须本地打包成 zip 上传。这个设计和很多新一代调度平台不太一样我第一次用的时候在 UI 上找了好久的新建任务按钮最后才发现压根没有。打包命令zip -r test-flow.zip first.job second.job然后回到 Web 控制台进入项目页面点击上传按钮把 zip 传上去。上传成功之后页面上会出现一个test-flow的 Flow这就是你定义的工作流。4.4 执行与定时调度点击 Flow 右侧的 Execute Flow 按钮选一个执行时间默认是当前时间确认后就能在 Executions 页面看到任务执行状态。绿色的 SUCCEEDED 表示成功红色的 FAILED 表示失败。如果验证定时调度就点 Schedule 按钮设置 cron 表达式或者简单的周期配置。Azkaban 的 cron 表达式和 Linux 的 cron 格式基本一致比如每天凌晨 2 点执行0 0 2 * * ?经验分享第一次跑任务时建议先用手动执行把整个链路跑通再配定时调度。这样排查问题时变量最少不会出现任务没跑还是定时配置错了这种二选一的问题。另外我发现一个实用的维护技巧把项目里的 job 文件统一放在一个本地目录每次修改完直接重新打 zip 上传覆盖原有的 Flow 定义而不是新建一个项目。这样项目的执行历史是连续的方便回溯每一次改动前后的行为差异。5. 排坑实录我这样定位卡住的启动过程与执行失败这一部分是我最想写的因为 solo-server 的问题大多不是显性报错而是看起来正常但实际不对的隐性故障。我整理了自己真实遇到的五类问题每条都给出了完整的排查链路。5.1 启动失败但控制台无报错现象执行start-solo.sh后进程很快退出终端没有任何提示8081 端口也没监听。排查链路看日志tail -200 logs/azkaban-webserver.log。发现UnsupportedClassVersionError下面写着unsupported class file version。根因本机 JDK 版本太高。Azkaban 这个版本基于 JDK 8 编译如果用 JDK 17 跑会直接报 class 版本不兼容。解决安装 JDK 8并把JAVA_HOME指向它export JAVA_HOME/path/to/jdk1.8 export PATH$JAVA_HOME/bin:$PATH然后重新启动。这个问题很隐蔽因为启动脚本本身不会做 JDK 版本检查它只负责拉起 JVMJVM 起不来就静默退出。5.2 端口被占用现象启动日志显示Port 8081 already in use。排查链路lsof -i :8081然后根据进程 PID 判断是谁占了端口。解决要么杀掉占用进程要么改掉azkaban.properties里的jetty.port。这里我建议优先改配置而不是杀进程因为 8081 这个端口往往被各种 IDE 调试端口占用杀来杀去容易误伤。5.3 页面右上角红色警报插件未启用现象Web 控制台能打开但右上角有一个红色警告图标提示找不到azkaban-executor-server插件或者 commonjob 插件未启用。排查链路检查plugins/目录下是否存在 job 类型插件。如果存在看plugins/jobtypes/下有没有.jar包。检查日志里有没有关于插件加载的 ERROR 记录。解决这个问题的本质是 Azkaban 通过插件机制加载 job 类型command 类型并不是内置于核心代码的而是通过 commonjob 插件提供的。如果插件目录被误删或者解压不完整就会导致可用 job 类型为空。最常见的情况是第一次解压时 tar 包没解全重新解压一遍即可恢复。5.4 任务一直 RUNNING 但实际脚本已经跑挂了现象手动执行 Flow任务状态一直停留在 RUNNING点进去看不到任何输出。排查链路进入执行详情页点击 job 节点查看日志。发现日志里脚本执行报错但 Azkaban 没有把这个退出码标记为 FAILED。根因这个问题其实有两种可能。一种是你脚本最后一条命令返回 0导致 Azkaban 认为任务成功另一种是任务进程 fork 出来的子进程卡住了没释放文件句柄。解决在 command 脚本内部加set -e让脚本在任一条命令失败时立即退出非 0。把脚本输出重定向到本地日志文件例如commandsh /path/to/script.sh /tmp/script.log 21这样即使 Azkaban 抓不到状态你也能通过日志判断真实情况。如果 fork 出的子进程卡死检查脚本里是否有等待外部资源的情况比如等待数据库连接、等待网络超时。这个坑的可怕之处在于任务看起来在运行但实际上业务逻辑早就挂了如果没设超时机制调度系统会永远认为任务在跑。5.5 时间对不上调度时间总是差 8 小时现象明明配置了每天早上 9 点调度实际执行却在凌晨 1 点。排查链路查azkaban.properties里的default.timezone.id配置发现是默认的 UTC。改掉配置后还要检查 Web 页面右上角的用户时区设置是否和服务器一致。解决先改配置再重启然后在浏览器里把页面时区也调成Asia/Shanghai。很多人只改了服务器配置浏览器页面缓存里还带着旧的时区信息看起来还是差 8 小时其实数据已经对了纯粹是显示层的问题。这个时候强制刷新页面即可。这五类问题汇总成一张表方便遇到问题时快速定位现象可能原因排查优先级进程启动后立即退出JDK 版本不兼容1. 看日志8081 端口无监听端口被占用1. 看日志 2. lsof页面红色警报插件加载失败1. 看目录结构 2. 看日志任务卡在 RUNNING退出码异常 / 子进程阻塞1. 看执行日志调度时间偏差 8 小时时区配置错误1. 检查配置 2. 刷新页面5.6 关于容器化部署的一点提示最近很多人习惯用 Docker 来跑这类组件确实能少踩环境依赖的坑。但容器里跑 solo-server 也有三个容易忽略的点一是容器内的时间要挂载主机的时区否则又会出现 8 小时偏差二是端口映射要同时映射 8081 管理端口和 executor 需要的内部端口三是日志和 h2 数据目录最好挂到宿主机否则容器一删数据全没了。我在本机验证时还是更习惯直接跑 tar 包变量少出了问题好定位。6. 从 solo-server 起步后续迁移多 Executor 集群时要注意什么solo-server 最大的价值是让你低成本跑通整套调度逻辑但如果业务量上来了最终还是要把这套东西迁移到更可靠的分布式部署形态上。注意这个迁移并不是推倒重来而是拓扑变换。6.1 数据库切换第一步是把 H2 换成 MySQL。Azkaban 支持通过配置直接切换存储层主要改动在azkaban.properties里把database.type从h2改成mysql配置mysql.host、mysql.port、mysql.database、mysql.user、mysql.password执行 Azkaban 自带的建表 SQL 脚本H2 里已有的项目数据可以通过相同 job 文件重新上传的方式搬迁不建议直接跨库迁移因为两边表结构有差异而且项目定义补传一遍很快。6.2 Executor 拆分与调度策略solo-server 里 Web Server 和 Executor 在同一个进程迁移到 two-server 或 multiple-executor 时要把 executor 配置独立出来。Azkaban 的 Web Server 支持通过azkaban.executorselector.filters指定向哪些 executor 分发任务比如按剩余内存或按静态过滤标签选择。这部分是生产环境要认真研究的内容但你在 solo-server 上写的 job 文件、依赖关系、调度 cron 表达式全部可以无缝迁移过来。这正是我推荐先用 solo-server 起步的原因——你学到的核心概念在分布式架构下完全复用。6.3 版本兼容性从SNAPSHOT版本往正式版迁移时要注意 zip 包里 job 文件的格式有没有变化。Azkaban 的 job 文件格式多年来保持了很好的兼容性但 type 类型的支持范围可能会随着插件版本变化生产环境建议先在一个测试项目上跑通再大规模迁移。最后再说两句回头来看我用azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz这个包从零跑通整个调度流程前后折腾了大半天但收获非常大。调度系统这类组件第一次跑通是最难的一旦跑通了后面所有概念就都活了job 文件定义了任务dependencies 定义了依赖schedule 定义了时间execution 记录了结果剩下的无非是把这四个概念组合成你的业务逻辑。我最想分享的一个技巧是所有 job 文件管理一定要用本地目录 zip 打包的方式别在页面上反复创建同名项目。每次修改之后重新打 zip 上传同一个项目既能保持执行历史连续又能用 git 记录 job 文件的演进过程出问题时可以快速对比是哪次改动引入的故障。这套工作方式我在后来的生产环境里也一直在用。另外如果只是临时验证一个想法solo-server 完全够用但如果你发现每天的任务量已经超过几百个或者需要多个执行节点分担负载那就应该着手研究 two-server 模式了。从 solo 到 two-server 的跨度没有想象中大因为你已经理解了 Azkaban 的任务模型剩下的只是部署拓扑的调整。本文还有配套的精品资源点击获取