★ FEATURED ARTICLE 简介Azkaban Solo Server 0.1.0-SNAPSHOT 面向个人开发者及小团队提供轻量级工作流执行与任务调度环境适合正在学习大数据作业调度、需要搭建本地练习环境的初中级开发者可用于项目管理、作业定义、依赖编排、定时运行以及 Web 端状态监控和日志查看等场景。压缩包为已编译的 tar.gz 单机版本省去源码编译环节包体信息显示文件总数为 0文件类型明细暂未提供整体大小约 42.28MB下载后需以实际目录内容为准。已有 260 人学习对了解 Azkaban 单机部署形态与调度流程有一定参考价值。读者可借助它熟悉 Web 服务器、执行器与内嵌数据库同机运行的结构理解 Shell、Java 或 Hadoop 作业按依赖顺序执行的方式并积累状态跟踪和日志排查经验由于 SNAPSHOT 版本稳定性有限更适合学习测试不宜直接承担大规模生产调度。1. Azkaban 任务调度选型Solo 模式到底替代了什么需求往往很朴素凌晨把三个脚本按顺序跑完先提取、再转换、最后加载中间哪一步出问题第二天都要从那一步接着跑而不是从头再来。用 crontab 拼时间、用 shell 拼依赖再补一个失败告警撑不了两周维护成本就全耗在「昨天到底跑到哪一步」这种问题上。Azkaban 任务调度在这里的定位很清楚——把依赖关系、执行顺序、执行日志和重跑入口收进一个 Web 界面.job文件里声明命令和依赖任务之间的依赖关系、排队和执行记录都交给服务端负责。这个 tar.gz 是 Solo 模式的单机发行包Web 服务、调度器、执行器跑在同一个 JVM 里默认内嵌数据库不需要另起 MySQL也不需要单独部署 executor。它适合只有一台机器、日任务量几十到上百、需要 DAG 依赖和可回溯执行记录的场景如果任务本身跨机器分布或者单节点要并发上百个 flow就该换成多 executor 部署硬用 Solo 会被单机线程池和堆内存限制卡住。2. 解压到首次登录Solo 发行包的目录和端口配置2.1 解压后先确认实际存在的目录tar -zxvf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz cd azkaban-solo-server-0.1.0-SNAPSHOT ls -la ls bin/ conf/打包时的顶层目录名以实际解压结果为准别把cd后面的目录名当成固定值。解压完成后先看bin/和conf/里有什么再决定改哪个文件。几个关键目录的用途和是否建议改动目录作用处理建议bin/启动、关停脚本一般不改真要加 JVM 参数就在启动脚本里改并留档conf/azkaban.properties、用户文件、日志配置必须改端口、时区、项目目录都在这lib/运行时 jar 包不加自定义依赖就别往这里放东西plugins/job 类型插件只有用到特定类型如 hive、spark时才动web/前端静态资源不动projects/上传的项目包按版本写入磁盘首次执行后才会出现是备份的重点对象projects/这个目录要特别注意它是在第一次上传项目之后才生成的很多人装完发现没有这个目录就以为包不完整其实是还没上传过东西。后面做备份的时候它是除了数据库文件之外最需要保护的对象因为里面保存的是每个项目的每个历史版本。2.2 azkaban.properties 里必须先确认的几项# conf/azkaban.properties 中优先级最高的几项 jetty.port8081 jetty.host0.0.0.0 default.timezoneAsia/Shanghai azkaban.project.dirprojects逐项说明为什么要动jetty.port是 Web 访问端口默认 8081。公司内网机器上 8081 被占用的概率不低起不来第一件事就是查这个端口。jetty.host默认可能是localhost那就只有本机能用浏览器打开。想让同一网段的其他机器访问改成0.0.0.0如果机器有多张网卡也可以直接绑内网 IP。default.timezone是很容易漏掉的一项。漏了就会按系统默认时区走容器里通常是 UTC配好的凌晨三点调度会变成上午十一点。azkaban.project.dir是项目包解压后保存的根目录。这里写的是相对路径相对的是启动时的工作目录所以启动命令必须在解压后的根目录下执行不能在bin/里执行./start-solo.sh。数据库相关的那几行先不用管。Solo 模式默认用内嵌数据库数据存放在启动目录下不需要提前建库建表。如果后面确实要换成外部数据库需要额外的驱动包和建表脚本那已经算升级到分布式部署的准备了不是 Solo 该做的事。# conf/azkaban-users.xml 里默认用户的写法第一次登录后就要改 user usernameazkaban passwordazkaban rolesadmin groupsazkaban/默认账号是azkaban/azkaban权限是 admin。装完之后在能访问之前先改掉密码改完重启一次确认生效别留着默认口令直接暴露在内网。2.3 启动、验证与关停# 调试阶段前台启动日志直接打到终端报错能第一时间看到 bin/start-solo.sh # 稳定之后改成后台日志单独落到文件 nohup bin/start-solo.sh /tmp/azkaban-solo.boot.log 21 echo $! /tmp/azkaban-solo.pid启动命令本身没参数所有配置都从conf/azkaban.properties读。前台启动的价值在于第一次装的时候如果端口冲突或者配置项写错异常栈会直接打印出来不用去翻日志文件猜。验证分三步走# 1. 端口是否真的在监听 ss -lntp | grep 8081 # 2. HTTP 是否能通拿到 200 或 302 都算 Web 层起来了 curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8081/index # 3. 启动日志里有没有异常 tail -n 50 /tmp/azkaban-solo.boot.log第 2 步返回000一般是端口没起来或者绑错了地址返回500一般是数据库初始化或者配置解析出问题这时候去看第 3 步的日志异常栈的最后一行通常就是根因。关停用脚本脚本失效时按 pid 再处理一次bin/shutdown-solo.sh # 脚本没反应的时候比如 pid 文件丢失手动补刀 kill $(cat /tmp/azkaban-solo.pid 2/dev/null) 2/dev/nullshutdown-solo.sh依赖启动时写下的 pid 文件如果之前是前台启动或者 pid 文件被清掉了脚本会提示找不到进程但服务其实还在跑。这时候用ss -lntp | grep 8081找出真正的 pid 再 kill别以为脚本执行完就关干净了。3. job 文件写通 DAG命令类型、依赖和 flow 2.0 的写法3.1 从一个最小 job 文件开始先在本地准备一个能上传的项目目录结构大致如下my-etl/ ├── extract.job ├── transform.job ├── load.job └── scripts/ ├── extract.sh ├── transform.sh └── load.shextract.job的内容# extract.job typecommand command/bin/bash scripts/extract.sh逐行说明typecommand是内置的作业类型表示执行一条 shell 命令不需要装额外插件。command后面跟真正的命令。这里用/bin/bash全路径而不是bash是为了绕开 executor 进程 PATH 和登录 shell 不一致的问题。scripts/extract.sh是相对路径是否能命中取决于服务端执行时的工作目录。第一次跑可以临时把command改成pwd; ls -la确认一下当前目录到底在哪确认完再换回正式命令。三个 job 分别写好之后把它们连同scripts/目录一起打成 zip 上传。Azkaban 的上传入口接收的是 zip不是单个.job文件这一点新手最容易踩坑——传单个文件会提示格式不对传一个不带.job文件的目录也能上传但项目里一个 flow 都看不到。作业级别的通用参数也直接写在.job文件里# transform.job typecommand command/bin/bash scripts/transform.sh retries2 retry.backoff30000retries是失败自动重试次数retry.backoff是两次重试之间的间隔单位毫秒。这两个参数适合放在有瞬时抖动风险的作业上比如依赖外部接口拉数据的步骤纯计算的脚本加上去意义不大失败了重试大概率还是失败不如人工看日志。3.2 dependencies 与 flow 1.0 的依赖约定transform.job要等extract.job跑完就在transform.job里加一行# transform.job typecommand command/bin/bash scripts/transform.sh dependenciesextractload.job同理# load.job typecommand command/bin/bash scripts/load.sh dependenciestransform规则很直接依赖写的是对方 job 的名字也就是文件名去掉.job后缀多个依赖用英文逗号分隔不要带空格。写错名字不会有任何提示Azkaban 会认为这个依赖不存在作业会直接执行然后因为依赖的上游数据没准备好而失败——这种报错看起来像业务问题实际是配置问题。上传 zip 之后在项目的 Graph 视图里能看到三节点串行的 DAG。这一层是 Azkaban 相比 crontab 最直接的价值依赖关系可视化不用靠人脑记「B 必须在 A 之后」。flow 1.0 的隐式规则有两条值得先心里有数上游作业失败后下游节点不会执行最终状态是跳过而不是跟着报失败。看到下游一排都是「跳过」的时候往上翻第一个红色的节点才是根因。同一层级里的并行分支默认是各跑各的。一个分支挂了其他分支不会停下来最终整个 flow 标记为失败。如果业务上要求「任一失败全部终止」需要在 flow 级别配置失败策略而不是在单个 job 里处理。3.3 flow 2.0把参数和节点写进一个文件依赖关系一多散在十几个.job文件里就不好维护了。flow 2.0 允许把整条流程收进一个.flow文件# daily_etl.flow config: retries: 1 retry.backoff: 60000 nodes: - name: extract type: command config: command: /bin/bash scripts/extract.sh - name: transform type: command config: command: /bin/bash scripts/transform.sh dependsOn: - extract - name: load type: command config: command: /bin/bash scripts/load.sh dependsOn: - transform几处写法和 flow 1.0 的差别要留意顶层config:是 flow 级配置里面的retries会作为默认值传给所有节点节点自己再写就覆盖。nodes:是一个列表每个节点至少要有name和type。依赖从dependenciesextract,transform这种逗号字符串变成了dependsOn:的列表每个元素一行前面带横杠。节点自己的参数都放在节点级config:下面command、retries这些键名和.job文件里一样。flow 2.0 和 flow 1.0 不要混在同一个项目里用。混着写的时候项目里会出现两种来源的 flow界面上的节点归属和依赖图看起来会很别扭出问题时第一反应都是「这依赖到底谁连的」排查成本明显上升。要么整套都是.job文件要么整套都是.flow文件切换时新建一个项目做迁移不要在旧项目里直接换格式。4. 定时与传参cron 表达式、参数覆盖和失败重跑4.1 定时调度与 cron 表达式Azkaban 的调度配置走的是 Quartz cron 格式字段顺序是「秒 分 时 日 月 周」比 Linux crontab 多一个秒位。这是最容易配错的地方——直接把 crontab 里抄来的0 3 * * *填进去解析结果会变成「每天 0 点 0 分 3 秒」看起来能保存实际执行时机完全不对。常见的几条对照需求cron 表达式每天凌晨 03:000 0 3 * * ?每小时整点0 0 * * * ?每 15 分钟一次0 0/15 * * * ?每周一 02:300 30 2 ? * MON每月 1 号 01:000 0 1 1 * ?「日」和「周」这两个字段在 Quartz 里互斥其中一个必须有值本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
