Azkaban集群内部调度原理分析

Azkaban是一个非常简单实用，而且开源的作业调度系统。在2.x版本中不支持集群模式部署，在3.x版本中支持集群模式部署，适用于作业量比较大一些的应用场景。有关Azkaban更多详细信息，如特点、功能、特性、作业定义等，可以参考官方文档，这里不再详述。

Azkaban集群架构

下面我们看一下Azkaban集群模式的架构，如下图所示：

从上图可见，Azkaban集群部署模式，主要有3个核心的组件：

• Azkaban WebServer

Azkaban WebServer，是整个调度集群的核心，负责所有作业的管理和调度。

• Azkaban ExecutorServer

Azkaban ExecutorServer，整个调度集群中实际运行作业的节点，该类节点可能是作为一个作业提交的客户端，比如Spark on YARN部署模式下，cluster运行模式时只作为客户端使用，client运行模式时会有部分计算逻辑；比如普通的Java程序需要处理量级较小的数据作业，这时Executor Server节点可能有较大的工作负载，占用较多节点资源（内存、CPU）。

• DB

DB，是集群中所有节点运行共用的数据存储，包含作业信息、各种调度元数据等等。

核心调度概述

Azkaban WebServer需要根据Executor Server的运行状态信息，选择一个合适的Executor Server来运行WorkFlow，然后会将提交到队列中的WorkFlow调度到选定的Executor Server上运行。我们整理了与核心调度相关的各个组件，主要包括Azkaban WebServer端和Azkaban ExecutorServer端，他们之间的关系如下图所示：

其实，从调度层面来看，Azkaban WebServer与Executor Server之间的交互方式非常简单，是通过REST API的方式来进行交互，基本的模式是，Azkaban WebServer根据调度的需要，主动调用Executor Server暴露的REST API来获取相应的资源信息，比如Executor Server的状态信息、分配WorkFlow到指定Executor Server上运行，等等。

我们可以在QueueProcessorThread.selectExecutorAndDispatchFlow()方法中看到，选择Executor Server并进行调度的实现，代码片段如下所示：

final Executor selectedExecutor = selectExecutor(exflow, availableExecutors);
        if (selectedExecutor != null) {
          try {
            dispatch(reference, exflow, selectedExecutor);
            ExecutorManager.this.commonMetrics.markDispatchSuccess();
          } catch (final ExecutorManagerException e) {
            ExecutorManager.this.commonMetrics.markDispatchFail();
            logger.warn(String.format(
                "Executor %s responded with exception for exec: %d",
                selectedExecutor, exflow.getExecutionId()), e);
            handleDispatchExceptionCase(reference, exflow, selectedExecutor,
                availableExecutors);
          }
        }

QueueProcessorThread是运行在Azkaban WebServer端的一个线程，它在ExecutorManager中定义，是内部调度中最核心的线程。selectExecutor()方法处理如何选择一个合适的Executor Server，然后通过dispatch()方法将需要运行的WorkFlow调度到该Executor Server上运行。