企业官网建设流程全解析

1. 项目概述：为什么我们需要Azkaban？

如果你在数据团队待过，或者负责过任何需要定时、按顺序执行一系列任务的工作，那你一定对“调度”这个词不陌生。想象一下，每天凌晨1点，你需要先从一个数据库里拉取昨天的销售数据，然后清洗、转换，接着推送到另一个分析数据库，最后还要发一封邮件报告给老板。这个过程里，任何一个环节出错或者延迟，都可能让整个链条瘫痪。手动操作？那意味着你得定个闹钟，半夜爬起来点鼠标，这显然不现实。写个脚本用Cron定时跑？当任务之间有依赖关系时（比如B任务必须等A任务成功完成才能开始），Cron那简单的“时间触发”逻辑就完全不够用了，依赖管理会变成一场噩梦。

这就是工作流调度系统存在的意义。它就像一个智能的、可视化的“任务管家”，帮你定义好谁先谁后（依赖关系），在什么时间或条件下触发（调度策略），失败了怎么办（重试、告警），并且把整个执行过程清晰地展示给你看。在开源世界里，Azkaban、Airflow和Oozie是三个最常被提及的名字。今天我们要聊的，就是由LinkedIn开源并广泛使用的Azkaban。

Azkaban的设计哲学是“简单够用”。它不像Airflow那样用代码（Python）来定义工作流，灵活性极高但学习曲线也陡峭；也不像早期的Oozie那样与Hadoop生态绑定过深，配置繁琐。Azkaban使用简单的job文件（属性文件）和flow文件（DAG描述文件）来定义工作流，并通过一个非常直观的Web UI进行管理和监控。对于大多数以Shell脚本、Python脚本、Spark作业、Hive SQL等为核心的数据处理任务来说，Azkaban提供的功能已经绰绰有余，而且上手速度极快。

最近在技术社区里，结合Docker来部署Azkaban成了一个热门话题。这很好理解，传统的安装方式需要你在服务器上配置Java、数据库、Web服务器等一堆依赖，步骤繁琐且容易因环境差异出错。用Docker则能把Azkaban及其依赖打包成一个标准化的、隔离的容器，真正做到“一键部署”，极大降低了运维复杂度。所以，我们这个系列的第一篇，就会从最核心的“是什么”和“怎么装”开始，特别是会详细讲解如何使用Docker这种现代方式来快速搭建一个Azkaban环境，让你能立刻上手体验。

2. Azkaban核心架构与组件解析

在动手安装之前，花点时间理解Azkaban的“五脏六腑”是很有必要的。这能帮助你在后续配置、排错甚至二次开发时，心里有一张清晰的地图。Azkaban主要包含三个核心组件，它们各司其职，共同协作。

2.1 三大核心组件：Executor Server、Web Server和DB

Azkaban Web Server这是整个系统的“大脑”和“门面”。它提供了用户操作的Web界面（UI），你所有的工作流上传、项目管理、定时调度设置、手动执行、查看日志和监控状态等操作，都是通过它与Web Server交互来完成的。此外，Web Server还负责用户认证、权限管理、触发工作流执行（但自身不执行任务），并将任务分发给可用的Executor。你可以把它理解为一个指挥中心。

Azkaban Executor Server这是系统的“四肢”和“执行者”。真正跑你脚本、执行你任务的就是它。Executor Server会从Web Server那里领取任务，然后在它所在的服务器上启动相应的进程（比如一个Shell或Python解释器）来运行你的作业。一个Azkaban集群可以配置多个Executor Server，从而实现负载均衡和高可用。Web Server和Executor Server之间通过HTTP API进行通信。

关系型数据库 (DB)这是系统的“记忆中枢”。Azkaban的所有元数据都存储在这里，包括：用户信息、项目定义、工作流（Flow）和作业（Job）的配置、执行历史记录、日志索引、调度计划等等。Web Server和Executor Server在运行时都会频繁地读写数据库。Azkaban官方支持MySQL，这也是生产环境最常用、最稳定的选择。

它们三者的关系可以简单概括为：用户通过Web Server的界面进行操作，Web Server将任务和调度信息持久化到数据库，并根据调度触发或手动触发，将任务派发给Executor Server去执行。Executor Server执行完毕后，将状态和日志索引回写数据库，用户再通过Web Server界面查看结果。

2.2 工作流定义：Job与Flow

这是Azkaban的灵魂概念。在Azkaban里，最基本的执行单元叫做一个Job。一个Job对应一个可执行的任务，比如一个Shell脚本 (command.job)、一个Python程序 (python.job)，或者一个Hive查询 (hive.job)。每个Job都是一个独立的.job文件，里面用键值对（Key-Value）的属性格式来定义这个任务。

光有独立的Job还不够，我们需要把它们组织起来。一个Flow就是由多个Job及其依赖关系构成的一个有向无环图（DAG）。Flow的定义通常放在一个.flow文件或者通过将多个.job文件打包成Zip包来隐式定义依赖。在Flow里，你可以指定Job A是Job B的依赖（dependencies=B），这样Azkaban就会确保B只在A成功完成后才会启动。

举个例子，一个典型的数据处理Flow可能包含：extract.job（数据抽取） ->transform.job（数据转换） ->load.job（数据加载） ->report.job（发送报告）。Azkaban会严格按照这个依赖顺序来执行。

2.3 单机模式 (Solo Server) vs 多执行器模式 (Multiple Executor)

理解这两种部署模式，有助于你根据需求选择安装方式。

单机模式 (Solo Server)这是最简单、最经典的模式。它将Web Server和Executor Server的功能合并到同一个JVM进程中。也就是说，你启动一个Azkaban的Solo Server，它就同时具备了Web UI管理和任务执行的能力。这种模式架构简单，部署容易，非常适合学习、测试、开发环境以及小规模的生产场景。它内部使用一个内置的H2数据库，无需额外安装MySQL，真正做到开箱即用。我们后续用Docker安装，主要也是针对这种Solo模式，因为它能最快地让你看到效果。

多执行器模式 (Multiple Executor)这是面向生产环境的分布式模式。Web Server和Executor Server是分开部署的，并且可以启动多个Executor Server。这种模式的优势很明显：

1. 解耦与高可用：Web Server和Executor互不影响，一个挂了另一个可能还能工作。可以部署多个Executor，避免单点故障。
2. 水平扩展：当任务非常多时，可以轻松地增加Executor服务器来提高整体的任务并发执行能力。
3. 资源隔离：可以将不同类型的任务（如CPU密集型、IO密集型）分配到不同的Executor上，或者根据物理资源来分配。

生产环境通常都会采用这种模式。它的安装配置比单机模式复杂，需要单独部署MySQL数据库，并分别配置Web Server和Executor Server。

注意：对于刚接触Azkaban的朋友，强烈建议从单机模式（Solo Server）开始。它能让你在几分钟内完成安装并运行第一个工作流，快速建立感性认识。等到你熟悉了基本概念和操作后，再根据实际需求考虑是否升级到多执行器模式。

3. 基于Docker的Azkaban Solo Server安装实战

传统安装需要下载发行包、配置数据库、修改一堆属性文件，过程比较琐碎。而使用Docker，我们可以将这一切封装起来。社区已经有维护得不错的Azkaban Docker镜像，比如azkaban/azkaban-web-server和azkaban/azkaban-executor-server。但对于Solo模式，我们可以使用一个集成的镜像，或者通过Docker Compose来编排。这里我演示一个非常直接、高效的方法，使用一个整合好的Solo模式镜像。

3.1 环境准备与Docker安装

首先，确保你有一台已经安装好Docker和Docker Compose的Linux服务器或本地开发机（Mac/Windows也可）。这里以Linux Ubuntu为例。

1. 安装Docker：如果你的系统还没有Docker，可以使用官方脚本快速安装。

   curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER # 将当前用户加入docker组，避免每次用sudo

   安装完成后，退出终端重新登录，运行docker --version和docker run hello-world验证安装成功。

2. 安装Docker Compose：Docker Compose是一个用于定义和运行多容器Docker应用的工具。虽然我们单机模式可能只用到一个容器，但用Compose来管理配置更为清晰。

   sudo curl -L "https://github.com/docker/compose/releases/download/v2.20.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose docker-compose --version # 验证安装

3.2 使用Docker Compose一键部署

我们创建一个专门的项目目录，并在里面编写docker-compose.yml文件。这里我选用一个在Docker Hub上比较活跃的、专为Solo Server设计的镜像，例如gcr.io/azkaban/azkaban-solo-server的替代品（因为gcr.io国内访问可能有问题）。我们可以使用社区镜像mingfang/azkaban-solo或类似版本。

首先，新建一个目录并创建配置文件：

mkdir azkaban-solo-docker && cd azkaban-solo-docker vim docker-compose.yml

将以下内容写入docker-compose.yml文件。这个配置做了几件事：拉取一个集成了Web和Executor的Solo镜像，将容器内的Azkaban工作目录和日志目录映射到宿主机方便查看，并暴露Web UI的8081端口。

version: '3' services: azkaban-solo: # 使用一个维护较新的Solo模式镜像 image: mingfang/azkaban-solo:latest container_name: azkaban-solo restart: unless-stopped ports: - "8081:8081" # 将容器的8081端口映射到宿主机的8081端口 environment: # 设置时区，避免任务调度时间错误 TZ: Asia/Shanghai volumes: # 持久化Azkaban的数据库（H2）和日志，即使容器删除数据也不会丢失 - ./azkaban-data:/opt/azkaban-solo/data - ./azkaban-logs:/opt/azkaban-solo/logs # 可以挂载一个本地目录用于存放项目文件，方便上传 - ./projects:/opt/azkaban-solo/projects networks: - azkaban-network networks: azkaban-network: driver: bridge

保存文件后，在同一个目录下，执行一条命令启动Azkaban：

docker-compose up -d

-d参数表示在后台运行。Docker会自动拉取镜像（如果本地没有），然后创建并启动容器。

3.3 验证安装与初次登录

启动完成后，我们可以通过几条命令来检查服务状态：

1. 查看容器状态：

   docker-compose ps

   你应该看到azkaban-solo容器的状态是Up。

2. 查看启动日志（排查问题时非常有用）：

   docker-compose logs -f azkaban-solo

   当你看到日志中出现类似“Azkaban Solo Server started on port 8081!”这样的信息时，说明启动成功了。按Ctrl+C退出日志跟踪。

3. 访问Web UI： 打开你的浏览器，访问http://你的服务器IP:8081。如果是在本地安装，直接访问http://localhost:8081。 你应该能看到Azkaban的登录界面。默认的用户名是azkaban，密码也是azkaban。

成功登录后，你会进入Azkaban的主界面。到这里，一个完整的Azkaban Solo Server就已经安装并运行起来了！整个过程可能只需要两三分钟，相比传统安装方式，效率提升不是一点半点。

实操心得：使用Docker安装时，务必注意端口冲突。如果宿主机上的8081端口已经被其他服务（比如另一个Web应用）占用，Azkaban容器将无法启动。你可以通过修改docker-compose.yml中ports映射的前一个端口号来解决，例如- "8082:8081"，这样你就要通过8082端口来访问了。检查端口占用可以用命令netstat -tlnp | grep 8081。

4. 第一个Azkaban工作流：从Hello World开始

安装好了系统，就像拿到了一把新工具，不亲手试试怎么行？让我们创建一个最简单的“Hello World”工作流，体验从项目创建、作业定义到执行监控的完整流程。这个流程是理解Azkaban所有高级功能的基础。

4.1 创建Azkaban项目

项目（Project）是Azkaban中管理工作的顶层容器。一个项目里可以包含多个工作流（Flow）。

1. 登录Azkaban Web UI (http://localhost:8081)。
2. 在首页，点击右上角的“Create Project”按钮。
3. 在弹出的对话框中，填写项目信息：
   • Name:HelloAzkaban(项目名称，只能包含字母、数字、下划线和横线)。
   • Description:My first Azkaban project for testing.(项目描述，可选)。
4. 点击“Create Project”。创建成功后，会自动跳转到该项目的主页。

4.2 编写你的第一个Job文件

Job文件是Azkaban执行的基本单元。我们创建一个最简单的Shell Job。

在你的本地电脑上（不是容器里），创建一个临时目录，比如hello-azkaban。在里面新建一个文本文件，命名为hello.job。文件内容如下：

# hello.job type=command command=echo "Hello, Azkaban! Today is $(date '+%Y-%m-%d %H:%M:%S')"

这个文件只有两行：

• type=command：指明这个Job的类型是执行命令行命令。这是最通用的一种类型。
• command=...：指定要执行的具体命令。这里我们让系统输出一段包含当前时间的问候语。

注意：Job文件的后缀必须是.job，并且文件内容必须是键值对格式，每行一个属性。type属性是必须的。

4.3 打包与上传

Azkaban通过上传Zip压缩包的方式来接收工作流定义。一个Zip包可以包含多个.job文件，Azkaban会根据文件中的dependencies属性自动解析出依赖关系，构建出工作流（Flow）。对于单个Job，它本身就是一个最简单的Flow。

1. 将hello.job文件打包成ZIP文件。在Linux/Mac终端中，进入hello-azkaban目录，执行：

   zip hello.zip hello.job

   你会得到一个hello.zip文件。

   Windows用户注意：请使用压缩软件（如7-Zip）创建ZIP包，确保压缩包内直接是hello.job文件，而不是带了一层文件夹。避免使用系统自带的“发送到压缩文件夹”功能，因为它可能会创建包含父目录的压缩包。

2. 回到Azkaban的HelloAzkaban项目页面。

3. 点击页面上方的“Upload”选项卡。

4. 点击“Choose File”或“浏览”按钮，选择你刚创建的hello.zip文件。

5. 点击“Upload”按钮。上传成功后，你会在下方的“Recent Uploads”中看到你上传的ZIP包版本。

4.4 执行与监控

上传成功后，项目主页的“Flows”部分会显示你刚刚上传的Flow，名字就是你的Job文件名hello。

1. 点击“Execute Flow”按钮（一个播放图标）。
2. 在弹出页面，你可以配置一些执行参数，比如“通知设置”（失败时发邮件）、“并发设置”等。对于第一个任务，我们保持默认即可。
3. 点击页面底部的“Execute”红色按钮。

现在，你将被带到这个Flow的执行详情页面。这是Azkaban UI最核心的部分之一。请关注以下几个区域：

• 流程图 (Flow Diagram)：以图形化方式显示Flow的结构。因为我们只有一个Job，所以这里只显示一个节点。
• 状态栏：显示整个Flow的当前状态，如 “RUNNING”, “SUCCEEDED”, “FAILED”。
• 作业列表 (Job List)：列出Flow中的所有Job及其状态、开始时间、结束时间。
• 日志 (Log)：点击Job列表中的Job名称（如hello），再点击“Log”按钮，就可以看到这个Job执行时输出的所有日志信息。这是我们排查问题最重要的依据。

稍等几秒钟，刷新页面，你应该会看到状态变成了绿色的“SUCCEEDED”。点击helloJob的Log，你就能看到终端输出的“Hello, Azkaban! Today is 2023-10-27 14:30:00”。

恭喜！你已经成功运行了第一个Azkaban工作流。这个过程虽然简单，但涵盖了Azkaban最核心的操作闭环：定义Job -> 打包上传 -> 触发执行 -> 查看结果。

5. 深入配置：解锁Azkaban更多能力

跑通Hello World只是第一步。Azkaban的强大在于它对复杂任务流程和运维需求的支持。让我们深入了解一下Job文件的关键配置和Web UI上的核心管理功能。

5.1 Job文件配置详解

.job文件的配置项非常丰富，通过它们可以精细控制任务行为。以下是一些最常用和关键的配置：

• 基础配置：

  • type: 任务类型。除了command，还有hive,pig,java,spark,hadoopJava等，用于执行特定生态的任务。
  • command: 当type=command时，指定要执行的完整shell命令。
  • dependencies: 定义当前Job所依赖的父Job。例如dependencies=jobA,jobB，表示必须等jobA和jobB都成功完成后，本Job才会启动。这是构建DAG的核心。

• 资源与环境配置：

  • working.dir: 任务执行时的工作目录。默认是每个Job独立的临时目录。
  • env.property: 可以设置环境变量，供任务中的脚本使用。例如env.property=KEY=value。
  • job.max.attempts: 任务失败后的最大重试次数，默认是0（不重试）。生产环境通常设置为1或2。
  • retry.backoff: 重试之间的等待时间（毫秒）。

• 条件与流程控制：

  • condition: 基于上游Job的运行状态来决定是否执行本Job。例如condition=jobA == success。
  • failure.emails: 任务失败时，通知的邮箱列表（逗号分隔）。需要先在Azkaban全局配置中设置邮件服务器。
  • success.emails: 任务成功时，通知的邮箱列表。

一个更复杂的Job文件示例 (data_pipeline.job)：

# 数据管道任务 type=command dependencies=extract_data, clean_data # 依赖前两个任务 command=sh /opt/scripts/load_to_warehouse.sh ${table_name} job.max.attempts=2 retry.backoff=300000 # 失败后等5分钟再重试 failure.emails=team@example.com env.property=table_name=user_behavior

5.2 Web UI核心功能导航

Azkaban的Web界面设计得非常直观，主要功能都集中在项目页面和Flow执行页面。

1. 项目管理 (Project Page):

   • Flows: 查看本项目下所有已上传的工作流。
   • Permissions: 管理项目权限（查看、执行、管理），可以添加其他用户或用户组。
   • Schedule: 为核心功能！在这里可以为工作流设置定时调度。你可以配置类似Cron表达式的时间计划（如0 2 * * * ?表示每天凌晨2点执行），实现完全自动化的任务流水线。
   • History: 查看本项目所有Flow的执行历史记录，包括成功、失败、取消的，方便回溯和审计。

2. Flow执行监控 (Execution Page):

   • Flow Diagram: 可视化DAG，绿色节点表示成功，红色表示失败，蓝色表示运行中，灰色表示未开始。一目了然。
   • Summary/Job List: 查看每个Job的详细状态、开始结束时间、持续时间。
   • Logs: 如前所述，是调试和排查问题的生命线。不仅可以看到标准输出(stdout)，还能看到标准错误(stderr)。
   • Kill: 如果发现Flow执行有问题，可以点击“Kill”按钮立即终止整个Flow。
   • Retry Failed Jobs: 如果Flow部分失败，可以只重试失败的Job，而不必从头开始，节省时间和资源。

5.3 调度配置实战

让我们为刚才的helloFlow设置一个定时任务，让它每天上午9点自动执行。

1. 在HelloAzkaban项目主页，找到helloFlow，点击其右侧的“Schedule”按钮（日历图标）。
2. 在调度配置页面，你会看到一个类似于Cron表达式的配置器。
   • 分钟 (Min): 设置为0。
   • 小时 (Hour): 设置为9(24小时制，代表上午9点)。
   • 日 (Day of Month):*(代表每天)。
   • 月 (Month):*(代表每月)。
   • 星期 (Day of Week):?(Cron中通常用?表示不指定，与“日”互斥)。
   • 下方的表达式会显示为0 0 9 * * ?（Azkaban使用的Quartz Cron格式，前两位是秒和分）。
3. 你还可以设置调度的开始日期和结束日期（可选）。
4. 点击“Schedule”按钮。创建成功后，你会在项目页面的“Schedules”面板中看到这条定时任务。

现在，每天上午9点，Azkaban就会自动触发这个helloFlow，无需人工干预。你可以在“History”中查看它每天的执行记录。

6. 常见问题与故障排查实录

在实际使用中，你肯定会遇到各种问题。下面我整理了一些初期最常见的“坑”和解决方法，希望能帮你少走弯路。

6.1 安装与启动问题

问题1：Docker容器启动后，无法通过8081端口访问Web UI。

• 排查步骤：
  1. 检查容器状态：docker-compose ps或docker ps，确认容器是否处于Up状态。如果是Exited，用docker-compose logs查看启动日志。
  2. 检查端口占用：在宿主机执行netstat -tlnp | grep 8081，看8081端口是否被其他进程占用。如果被占，修改docker-compose.yml中的宿主机端口映射（如改为8082:8081）。
  3. 检查防火墙：如果是在云服务器上，确保安全组/防火墙规则允许了对8081端口的入站访问。
  4. 检查日志：最常见的启动失败原因是数据库连接失败（多执行器模式）或内存不足。日志里会有明确的错误信息。

问题2：上传ZIP包时失败，提示“Invalid zip file”或类似错误。

• 原因与解决：
  • ZIP包结构不对：Azkaban要求ZIP包解压后，根目录下直接就是.job文件。如果你在Mac上用Finder压缩，或者Windows上右键“发送到压缩文件夹”，可能会创建一个包含文件夹的压缩包。请使用命令行zip -j hello.zip hello.job(-j参数表示不保存目录结构)，或确保压缩软件设置为“仅存储文件”。
  • Job文件格式错误：确保.job文件是纯文本格式，编码为UTF-8或ASCII，并且键值对格式正确（每行一个key=value，不能有多余的空格，特别是=两边）。

6.2 任务执行问题

问题3：Job执行状态一直是“PREPARING”或“RUNNING”，长时间不结束。

• 排查思路：
  1. 查看Executor日志：对于多执行器模式，需要登录到Executor服务器查看日志。对于Solo模式，查看容器日志docker-compose logs azkaban-solo。
  2. 检查资源：可能是任务本身是个死循环，或者等待某个永远不会就绪的外部资源（如数据库连接、网络服务）。在Job的Log里可能看不到输出，因为进程卡在启动阶段。需要结合系统监控（如top,docker stats）看是否有进程在消耗CPU/内存。
  3. 检查命令路径：如果command中使用了相对路径或未在PATH环境变量中的命令，可能会找不到。建议使用绝对路径，或者在命令前加上source ~/.bash_profile &&之类的语句来加载环境。

问题4：Job执行失败（FAILED），如何查看具体错误？

• 标准操作流程：
  1. 在Flow执行页面，点击失败的Job名称。
  2. 点击“Log”按钮。重点查看日志末尾的“stderr”部分，这里通常包含了脚本或命令执行失败的具体原因，如“Permission denied”（权限不足）、“command not found”（命令不存在）、“Syntax error”（语法错误）等。
  3. 根据错误信息进行修复。例如，如果是权限问题，可能需要修改脚本的可执行权限（chmod +x script.sh）或在容器内以合适用户运行。

问题5：依赖关系未按预期工作，Job在依赖Job失败后仍然启动了。

• 原因：这通常是由于对Azkaban依赖逻辑的误解。Azkaban的依赖是“成功依赖”，即只有所依赖的Job状态为“SUCCEEDED”时，下游Job才会启动。如果上游Job是“KILLED”、“FAILED”或“SKIPPED”，下游默认不会执行。
• 高级控制：如果需要更复杂的逻辑，比如上游失败后下游做补偿处理，可以使用condition属性进行基于状态的条件判断，但这属于更高级的用法。

6.3 配置与运维问题

问题6：如何修改Azkaban的配置，比如邮件报警、时区？

• 对于Docker Solo模式：Azkaban Solo Server的配置文件通常内嵌在镜像中。修改配置有两种方式：
  1. 通过环境变量：有些镜像支持通过环境变量覆盖常用配置。查阅你所使用镜像的Docker Hub页面或GitHub文档。
  2. 挂载自定义配置文件：这是更彻底的方式。你需要找到镜像中Azkaban的配置文件路径（通常是/opt/azkaban-solo/conf或/azkaban/conf），然后在docker-compose.yml中通过volumes将宿主机的配置文件目录挂载进去，覆盖容器内的默认配置。前提是你需要知道默认配置的内容，可以先从运行的容器中复制出来：docker cp azkaban-solo:/opt/azkaban-solo/conf ./my-conf。

问题7：任务日志文件越来越大，如何管理？

Azkaban会将每个Job执行的日志存储在磁盘上。默认配置下，这些日志会一直保留，可能占满磁盘。

• 清理策略：Azkaban Web Server有一个内置的“日志清理”作业，但默认可能未启用或配置。你需要参考官方文档，配置azkaban.properties中的log.retention.ms等相关参数，让系统自动清理过期的执行日志。
• 对于Docker部署：由于我们将日志目录./azkaban-logs挂载到了宿主机，你也可以在宿主机上设置一个Cron任务，定期清理该目录下过旧的日志文件。

避坑技巧：对于生产环境，强烈建议将Azkaban的数据库（即使是Solo模式，也建议使用外部MySQL而非内置H2）和日志目录进行持久化存储（Volume挂载），就像我们在Docker Compose文件中做的那样。这样即使容器崩溃或重建，你的项目元数据和历史记录也不会丢失。同时，定期备份数据库是必须的运维操作。