Azkaban是LinkedIn开发并开源的批量工作流作业调度系统，用于解决Hadoop作业之间的依赖与执行顺序问题，最初以单服务器方案上线，后逐步演化为可分布式部署的调度平台。它通过作业依赖关系确定执行次序，并提供基于Web的界面来维护和跟踪工作流，被广泛用于ETL处理、数据分析等大数据场景。
定义
Azkaban是一个开源的批量工作流作业调度器，用来创建、执行和管理带有复杂依赖关系的作业流[1]。它的定位是分布式工作流管理器，最初由LinkedIn实现，目的是处理Hadoop作业之间的依赖问题，让从ETL任务到数据分析产品的各类作业能够按既定顺序运行。
在Azkaban的模型里，用户把一个可执行单元称为作业(Job)，把一组存在先后依赖关系的作业称为工作流，工作流的依赖关系构成有向无环图，被依赖的作业先执行[2][3]。若依赖关系形成环，工作流会被判为无效[3]。这套系统在LinkedIn的生产环境中运行多年，支撑了该公司大量Hadoop与数据仓库流程。
原理
Azkaban的核心由3个组件构成：关系型数据库、Azkaban Web Server与Azkaban Executor Server。数据库用于保存系统状态，Web Server和Executor Server都会访问它；Web Server借助数据库管理项目、项目权限、已上传文件、正在执行的流程状态、历史流程与作业及其日志、调度器状态和SLA规则；Executor Server则从数据库读取项目文件、更新执行中的流程与作业数据、写入日志，并在流程运行于其他Executor时读取跨流程依赖的状态。
Web Server是整个系统的主管理器，负责项目管理、身份认证、调度和执行的监控，同时充当Web界面；Executor Server负责工作流与作业的实际执行。作业以扩展名为.job的键值属性文件定义，其中type说明作业类型，command给出要执行的命令，dependencies用逗号分隔的作业名列表声明前置依赖；这些文件连同所需二进制文件打包为Zip后上传[1]。上传时系统会校验依赖是否缺失、是否存在循环依赖，不通过则上传失败。
在分布式多执行器模式下，多个Executor Server连接到同一数据库，Web Server从数据库队列中按优先级和提交时间取出待执行流程并派发给Executor，Executor侧的队列处理器按过滤条件与权重比较器，结合剩余流程数、空闲内存、CPU状态等因素选择目标节点。流程执行期间，Executor维护每个流程的线程池以支持作业并行，并以独立进程启动单个作业，同时持续更新数据库中的流程与作业状态[4]。
发展历程
Azkaban最初在LinkedIn被实现，用于解决Hadoop作业的依赖问题，早期是单服务器方案；随着Hadoop用户数量增长，它逐步演化为更健壮的系统。在3.0版本之前，Web Server与Executor Server的功能运行在同一个服务器进程中，此后Executor被拆分为独立服务。拆分的原因包括：可以扩展执行数量，在某个Executor故障时回退到其他Executor运行，并能让升级对用户的影响降到最低。
3.0版本提供了3种部署形态：独立的solo-server模式、较重的双服务器模式和分布式多执行器模式。solo模式使用内嵌的H2数据库，Web Server与Executor Server在同一进程内运行，适合试用和小规模场景；双服务器模式面向较正式的生产环境，数据库由MySQL以主从方式支撑，Web Server与Executor Server分进程运行，使升级和维护不影响用户；多执行器模式面向最严苛的生产环境，数据库同样由主从式MySQL支撑，Web Server与Executor Server尽量部署在不同主机上，以获得健壮性和可扩展性。
相关文档还提到，3.0此前曾以2.5、2.7等版本存在，从2.1或2.7升级到3.0需要执行相应的SQL脚本改动数据表，例如新增triggers表、executors表和executor_events表。在3.0中，原有的调度系统被合并进新的触发机制，调度信息持久化到数据库的triggers表中，官方还提供了把既有调度导入新表的脚本[5]。
应用
Azkaban的常见落点是Hadoop等大数据平台，其作业类型插件机制使其可以对接多种生态组件。内置的command类型可以执行本地UNIX命令，javaprocess类型用于启动带main方法的Java程序，VoldemortBuildAndPush类型用于把Hadoop中的数据推送到Voldemort存储。通过插件，还可以运行HadoopShell、hadoopJava、Pig、Hive等类型的作业，同一实例上能够并存不同版本的Pig、Hive以适配不同集群。
在功能上，Azkaban支持定时调度工作流、上传和共享工作流、认证与授权、按用户记录操作，以及作业失败或成功时的邮件告警、SLA告警与超时自动终止、失败作业重试等。3.3版本引入了基于Quartz语法的灵活调度，用户可以定义cron表达式，但Azkaban最多只支持分钟级粒度，因此界面中的秒字段被固定为0。此外还提供AJAX API，可在不打开网页界面的情况下通过HTTP请求完成登录、创建项目、上传项目包、执行与取消流程、设置SLA等操作。
在安全方面，Azkaban可以对接启用Kerberos认证的Hadoop集群：Executor在执行作业前代表用户获取NameNode、JobTracker等令牌并写入令牌文件，由用户作业进程读取；作业结束后再注销这些令牌。3.0版本起，作业默认以提交用户或流程指定的代理用户身份运行，从而借助Linux权限机制实现隔离，便于资源监控与可见性。
局限
Azkaban内置的作业类型有限，只能运行本地UNIX命令和简单的Java程序，使用Hadoop生态中的其他组件通常需要另行安装作业类型插件[5]。在与其他调度系统的比较中，Azkaban被视为轻量级调度器，配置和使用相对简单，但在功能全面性上不如Oozie这类重量级系统[6][7]。
存储层面，Azkaban长期仅支持MySQL一种数据存储类型，官方文档说明当时正在评估其他存储系统，因为检索历史作业记录仍需关系型数据存储的支持。令牌机制也带来时长约束：Azkaban只在作业开始时获取一次令牌，执行过程中不会申请新令牌或续期，因此作业运行时间不应超过配置的令牌有效期；在单个Pig脚本内部，某个MapReduce步骤如果在完成时注销令牌，会导致后续步骤在认证时全部失败。此外，Hadoop安全插件中面向Hadoop 2的实现出于令牌被提前注销的问题，在作业结束后并不注销令牌。
部署与运维方面也有若干限制。3.0及之后版本不再提供现成的安装包，需要基于Gradle从源码编译，并要求Java 8或更高版本[8]。在多执行器模式下，新增Executor需要写入数据库的executors表并重启Web Server才能被注册识别[8]。执行资源也需人工规划：每个作业可申请的内存存在上限（默认初始内存1GB、最大2GB，超出则不会启动），每个Executor可同时运行的流程数、每个流程内可并发运行的作业数都是可配置的固定上限，设置过高可能引发Executor内存溢出[4]。
参见
参考资料
- use-azkaban-to-schedule-xihe-sql-jobs-1 [引用日期2026-10-14]
- 大数据Azkaban（一）：工作流管理器概述 [引用日期2026-10-14]
- tencent.cn 上的网页 [引用日期2026-10-14]
- Scheduler [引用日期2026-10-14]
- getStarted [引用日期2026-10-14]
- Hadoop工作流引擎之Azkaban与Oozie对比（四） [引用日期2026-10-14]
- azkaban的部署以及简单使用 [引用日期2026-10-14]
- Azkaban 3.0 分布式安裝部署文檔 [引用日期2026-10-14]