定时任务调度——oozie总结

（翻译自 官网 ）

Oozie是一个用于管理Apache Hadoop作业的工作流调度程序系统。

Oozie Workflow job是由多个Action组成的有向无环图（DAG）。

Oozie Coordinator job是根据时间（频率）和数据可用性触发的可重复执行的Oozie Workflow job（简单讲就是根据时间或数据条件，规划workflow的执行）。

Oozie与Hadoop技术栈的项目集成，支持多种类型的Hadoop作业（例如Java map-reduce，Streaming map-reduce，Pig，Hive，Sqoop和Distcp，Spark）以及系统特定的工作（例如Java程序神宏和shell脚本）。

Oozie是一个可水平扩展，可靠和可使用扩展插件（scalable, reliable and extensible）的系统。

这里使用cdh虚拟机自带的oozie examples中的例子，执行hdfs dfs -put examples examples，将examples上传到hdfs。

打开apps/shell/ 可以看到job.properties和workflow.xml两个文件桐轮，在workflow.xml中定义action和workflow，在job.properties中定义各种变量。示例如下：

job.properties

workflow.xml

可以看到这里定义了一个shell workflow，它的DAG如下：

首先是start,end,kill三个控制节点，分别指定了workflow开始时，结束时，kill时的行为。

start指向了一个名为shell-node的action，该action执行了ehco命令，并使用capture-output获取标准输出。如果执行成功，则进入decision node check-output如果输出结果正确则顺利结束，否则输出错误信息。

然后使用以下命令测试（这里的config是使用的是本地文件）

oozie job -oozie http://quickstart.cloudera:11000/oozie -config ~/oozie-examples/examples/apps/shell/ job.properties -dryrun

如果成功，会显示OK

然后使用一下命令执行该workflow

oozie job -oozie http://quickstart.cloudera:11000/oozie -config ~/oozie-examples/examples/apps/shell/ job.properties -run

最后，使用oozie job -oozie http://quickstart.cloudera:11000/oozie -info workflowID查看任务运行状态

也可以在hue中或游轮册者oozie web控制台中查看任务运行状态。

数据准备：使用了权力与荣耀2017 ios的addcash的数据，test.hql(插入一条数据)

首先需要上传hive-site.xml到hdfs，Oozie需要通过该文件找到Hive Metastore，另外上传写好的hql文件到hdfs。然后向workflow中加入hive script action。并按图中的配置设置好hive脚本和hive-site.xml。保存即可。

写workflow.xml和使用hue配置action，两者是等价的。

最后使用coordinator设定每小时执行一次。也可以设置输入，当指定位置有数据时才开始执行；设置输出，将数据输出到指定位置。

如果coordinator设定的开始时间比当前时间早的话，会先将开始时间和当前时间之间应该执行的workflow全部执行一遍。

参考文献：

Oozie官方文档

Hue官方文档

cloudera community

所谓工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模春桐块化和结构化）和d性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是亮谈这个问题：如果应用程序缺乏扒键坦强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。

就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的d性就好比引擎转速方面的性能，加速到100 公里需要1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？

工作流解决方案与传统管理软件的关系传统的管理软件注重解决企业应用层现存的问题（例如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格的效率、财务软件可以规范财务人员的工作并提高帐目查询的效率、CRM 可以规范客户管理从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实现最大化配置。 workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如ERP 关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样workflow也不能完全解决传统管理软件所能解决的问题，例如对生产管理的MRP 系统所能解决的生产过程控制通过workflow很难实现。但一个好的传统软件如果希望能自动化地在整个企业中应用起来，必须有一个强大的逻辑层，用以解决信息传递的逻辑判断和自动流转，这个时候就需要workflow的平台。所以说： 1.workflow 和传统管理软件不是同一种软件，不具可比性； 2.workflow 对于已经有传统管理软件的企业的作用非常明显，可以籍此平台整合企业的各种应用系统，使之成为一个完整的企业级应用，也就是通常所说的EAI. 3. 具备workflow功能的管理软件（workflow与传统管理软件的结合）对于传统管理软件有绝对的优势；4.workflow可以根据企业的需要开发解决信息传递问题的流程以及帮助企业开发与现有应用系统的接口

目录：

正文：

这一篇分享 Infa 开发中一些常见的问题以及注意事项，内容比较零碎，有的内容也不再详细介绍，了解有这个功能，开发时可以再深入研究。

Infa workflow 可以设置定时任务 schedule（db 中称 job），以什么样的频率重复执行，什么时候开始，什么时候结束。这样任务可以自动跑，不需要人工干预。schedule 可以做成可蠢汪闹复用，但使用范围仅限于当前的 folder。下面看看 schedule 怎么建的，在 workflow 视图，按以下步骤，如下图所示：

当想暂停 schedule 时，可以勾选 "Run on demand"。这部分很简单，不做过多的解释。做好的 schedule 需要设置在 workflow，设置方法如下图所示：

也可以不选择可重用的 schedule，可以勾选 "Non Resuable"，设置方法跟 Resuable 的 schedule 是一样的。

在定时执行 workflow 时有一个场景是 schedule 解决不了的，假如我们想在一天之中的某些时间段执行，在另外的时间段不执行，有什么办法？其实，可以在 workflow 利用系统的变量做，点击 session 之间的 线 ，如下图所示：

可以猜到，这个 session 在上午 7 点以后执行，根据系统的参数可以做些其他灵活的控制。

source、target 开始导入后，可能会根据需求调整结构，如果结构调整的比较大，一般重新导入覆盖就可以了。如果调整不大，其实可以手动调整的，比如新增了字带罩段，修改了字段长度，前提是保证与 db 的 table 结构一致，如下图所示：

在设置了 schedule 的 workflow 运行过程中会出现 workflow 出现错误，这时候设置的 scheduled 状态就会变成 unscheduled，也就是不管用了。其实可以采取一种迂回的方法来控制，即用另一个基本不会跑失败的 workflow 去控制实际的业务 workflow，这个控制的 workflow 的作用是启动业务 workflow。说了这么多，不如看看示例，先看下怎么建这个控制 workflow，如下图所示：

首先，拖一个 cmd 组件进来，我们要用它写一段命令，去启动另一个 workflow，编辑 cmd 组件，如下图所示：

可以看到这个 session 将通过 pmcmd 启动业务 workflow，我们再对这个控制 workflow 设置一个 schedule，因为这个 workflow 失败的可能性基本为零，所以可以保证 workflow 的不间断性。

Infa 很多东西都可以做成可复用的，比如 transformation、mapping、session、workflow 等，比如下面是一个 lookup 的复用组件（属于 transformation）：

mapping 的复用，称为陵仔 maplet，如下图所示：

可以看到这个 maplet 传入了一个参数，通过一个 lookup 组件，输出了两个参数值。开发不同的东西需要切换到不同的视图下，注意看截图中上面的小按钮。workflow 也可以做成 worklet，就是把 workflow 拆成一个个小的，worklet 的开发视图如下图所示：

Infa workflow 的监控还是很有必要，执行失败后如果能推送出来（邮件），就可以及时解决。基本思路是：主要通过记录 session 的执行状况来做，session 可以在执行成功、失败后执行一段脚本，可以将 session 的运行结果记录下来，插入到 Infa 的日志表。session 的设置方法，如下图所示：

其中，$PMFolderName、PMWorkflowName、PMWorkflowRunId、PMSessionName 一看就知道；0 代表成功（自定义），Events__c 是 target 的名字；@numAffectedRows、@numAppliedRows、@numRejectedRows 分别是对 target 的影响记录数、采用记录数、拒绝记录数。

到此为止，Informatica 基础系列就完结了，共 9 篇，每一篇文章都配置了目录，方便系统阅读，希望对您有益，谢谢关注！

At 2017.11.10

---