Apache Oozie 的执行模型理解

Oozie的执行模型是什么？Oozie是怎样把作业提交给Hadoop集群执行的？

一，执行模型

Oozie通过一个“launcher job”来运行 action，比如通过Oozie的命令行来发起作业：首先，Oozie命令行作为一个客户端向Oozie Server 提交作业，Oozie Server得到作业之后，并不是在它所在的机器上发起Pig或Hive等具体的执行操作，而是在Hadoop集群的某台机器上启动一个 launcher job，由这个launcher job调用相应的Hadoop、Hive的lib包执行。（注意：Oozie 命令行客户端与Oozie Server可以不在同一台机器上）

二，采用这种执行模型的好处：

①Oozie Server所在机器的负载不会过大。因为，若Oozie Client提交给Oozie Server时，若作业是直接在Oozie Server上执行，当有大量作业提交时势必造成Oozie Server负载过大。而采用由Hadoop系统选择某台机器启动一个launcher job，再由launcher job 调用相关的依赖包执行作业可以做到负载均衡。

②通过隔离 user code 与 Oozie的 workflow code，可以使Oozie Server提供更稳定的服务能力。因为，Oozie Server现在是负责执行workflow code了，而用户编写的具体操作的代码是代理给 launcher job，由它负责分配执行 user code(用户编写的可执行jar文件)

③保证了Oozie Server的无状态性以及Oozie Server可以借助Hadoop本身的错误处理和重启机制。

三，该执行模型对作业提交的影响
Oozie的这种执行模型使得必须将作业的配置文件和可执行的jar文件组织在一起存储到HDFS上。这是因为Hadoop会在任一节点上启动launcher job，然后由该launcher job来调用具体作业的依赖包执行。

This architecture also means that the action code and configuration have to be packaged as a self-contained application and must reside on HDFS for access across the cluster. 

通常情况下，launcher job会等待action node执行完成后才退出，这意味着在整个action执行期间，launcher job一直会占用一个task slot。但是对于MR作业而言，launcher job负责启动MR作业之后，立即退出。

下图是OOzie的提交执行模型，图中以一个Hive Action为例。可以看出：Client把作业提交给Server，然后Server启动一个workflow，Hadoop集群首先选择一台机器启动一个launcher job，由launcher job来代理具体的Hive action的执行。

四，如果同一时刻有大量的作业提交到Hadoop集群时怎么办？

这种情况下可能会发生死锁。因为，一般情况下一个 launcher jobs需要一个task slot，若作业过多，所有的slot都被launcher jobs给占用了，那么就没有slot分配给具体的action了。这可以通过配置 launcher 队列来解决。

If many Oozie actions are submitted simultaneously on a small Hadoop cluster, all the task slots could be occupied by the launcher jobs. These launchers will then be waiting forever to run the action’s Hadoop jobs that can’t be scheduled due to unavailability of slots, causing a messy deadlock. This deadlock can be solved by configuring the launcher and the actual action to run on different Hadoop queues and by making sure the launcher queue cannot fill up the entire cluster. 


参考：Apache Oozie 第四章