DataWorks 调度装备最佳实战

内容简介：

1.调度根本介绍

2.依靠联系简介

3.依靠联系实战

1.调度根本介绍

（1）节点

节点是描绘 DataWorks 数据剖析和处理进程的根本单元。比方 Shell、ODPS SQL、ODPS MR、PyODPS 等，这些都一致称为节点使命。如下图在开发面板里边都能看到这些节点组件。

（2）实例

在 dataworks 的后台每天会依照用户装备调度的特点去进行周期性的调度，调度便是依靠每天生成的实例。实例是在前一天 23:30 的节点快照，一致生成的运转实例。对用户去装备调度的最大感受是假如在 23:30 之前去提交的调度的最大装备，那么会在 23:30 之后收效；假如是在 23:30 之后去装备调度的一些依靠联系，那么将会在隔天生成实例。

实例会对非天使命进行拆分，如一小时一次的小时节点将会拆分成详细的 24 个实例。

（3）调度规矩

首要满足依靠联系：即上游节点有必要完结，才干调度下流节点。也便是说上游的节点有必要要返回成功，而且完结整个数据处理的进程，才干调度下流节点。

其次，下流节点能不能运用，还要判别守时时刻是否现已到了，假如到了，立即履行。假如没有到，等候时刻。

（4）依靠联系

依靠联系是描绘两个或多个节点之间的语义连接联系，其中上游节点的状况将影响其他下流节点的运转状况，反之则不建立。如下图有必要要完结上游节点才干运转下流节点，颠倒不建立。

（5）跨周期依靠

跨周期依靠其实分了跨周期及跨版别两个概念：

Ø 跨周期依靠是针对小时使命：即小时使命依靠同一天的上一个周期。

比方说一个节点是依照一个小时调度一次，那当时节点能否调度要依靠于上一个小时的节点是否调度完结。

Ø 跨版别依靠即跨天依靠：即依靠前一天的使命。

比方今日使命能否运转依靠于昨日的使命是否成功履行返回。

（6）自依靠

自依靠是天然的跨周期跨版别依靠：

Ø 针对天使命即依靠昨日的使命。

Ø 针对小时使命即依靠上一周期，每天第一个周期依靠昨日最终一个周期。

比方说凌晨一点的使命依靠于十二点的使命是否完结。

2.依靠联系简介

调度特点：冻住

（1）概念介绍

l 周期实例中的冻住只针对当时实例，且正在运转中的实例，冻住操作无实践效果，并不会kill掉正在运转的实例。

l 冻住状况的使命会生成实例，可是不会运转。若需求运转冻住的实例，您需冻结实例，单击重跑，实例才会开端运转。

（2）犯错机制

假如敞开了犯错机制，则默许失利后重试3次，每次距离2分钟。假如仍是失利，则会进行当时节点失利的返回。

注：默许为“能够重跑”，当设置“不行重跑”时，节点运转一次成功后，该使命实例不行重跑。

调度周期分为分钟，小时，日，周，月。需求留意的是假如周期大于天的，由于调度的实例区分是按天生成的，所以周月使命在不运转的那一天实践是依照空跑处理的。若挑选日调度，而且不勾选守时调度的，守时时刻一致依照0点处理。

跨周期依靠里有四个选项：

1）不依靠上一调度周期

2）自依靠，等候上一调度周期完毕，才干持续运转

3）等候下流使命的上一周期完毕，才干持续运转

4）等候自定义使命的上一周期完毕，才干持续运转

依靠项有三个选项：

本节点：即为自依靠，等候上一周期运转成功后才可履行。

自定义：能够挑选本 project 或许其他 project 的节点作为依靠，即等候自定义节点上一周期运转成功后，才可履行。

一层子节点：依靠第一层子使命的上周期

当使命对之前的周期有依靠的时分，能够勾选依靠上一周期，然后依据自己的要求挑选详细的依靠项。

这儿遍及一个概念，跨周期和跨版别，版别能够理解为一个事务日期，假如今日的使命依靠昨日使命即跨版别，今日的多个周期之间相互依靠，即跨周期，需求留意的跨周期依靠不能指定依靠详细哪个周期，只能依靠上一个周期！

（3）自依靠的运用

虚线即跨周期依靠，实线是正常的依靠。

3.依靠装备实战

（1）天使命依靠 

天使命相互依靠，箭头表明数据流向，天守时使命相互依靠，上游未完结时下流即便守时时刻到了也不运转。只需上游使命完结时，下流使命才会跑起。

比方说上游使命零点，下流使命零点或七点，整个流程都会依靠于规矩和守时时刻去履行。

天使命相互依靠，上游存在跨周期依靠，上游昨日的周期不成功则今日的使命不会运转，今日的下流使命相同被堵塞。

比方说14年12月31日的使命没有完结，那么依靠于这一天的15年1月1日的使命也不会去运转。

为天使命相互依靠，上游使命依靠于上一周期的一层子节点，上游昨日的使命未成功会同时堵塞昨日和今日的下流。

如图2014年12月31日两个使命有相互的依靠联系，2015年1月1日两个使命有相互的依靠联系，由虚线联系能够得出上游使命依靠于上一周期的一层子节点。

（2）小时使命依靠上一周期

小时使命依靠上一周期，只需一个周期未成功，后续一切周期都会堵塞，而且能够有效防止一个周期使命运转慢了导致后续周期守时到了之后并发运转。

比方说零点钟，五点钟，十点钟都有实例，零点钟的实例没有运转成功，那么后续两个使命都会被堵塞。

（3）小时使命依靠天使命

小时使命依靠天使命，待天使命完结后开端调度小时使命，守时时刻已到的周期会并发开端履行。

比方说实例 B1,B2,B3 依靠于实例 A，实例 A 在每天的十二点跑起，实例 B1,B2,B3别离是零点，八点和下午四点的使命，那么这些小时会在等候天使命完结之后，再开端调度小时使命，而且在守时时刻上并发履行。隔天再会生成相同的依靠联系，如15年1月1日。

（4）天使命依靠小时使命

天使命依靠小时使命，需求等小时使命的一切周期都完结才干调度天使命，即便天使命守时时刻现已到了，可是小时使命还有周期未完结就不会被调度。

比方实例 A 是 实例 B1,B2,B3 下流的一个节点，依靠于上游三个节点，假如依照每八个小时跑一个使命，即实例 B1,B2,B3 都成功运转完结之后，实例A的守时时刻已到，实例A的节点才会开端运转。

（5）小时使命依靠小时使命且周期数相同

父子都为小时使命，且周期数相同，则每个运转周期一一对应的依靠，下流守时若晚于上游守时，守时时刻到了并不会调度，需求等上游对应周期运转完结才会开端调度。

比方说实例 A1 和实例 B1，实例 A2 和实例 B2 等的依靠联系，上游使命为小时使命，下流使命也为小时使命，而且两个小时使命的周期都为一个小时或许两个小时，生成的实例数相同，周期相同，这样就能够看作为父子节点，一切的 A 和 B 形成一一对应的联系。而且需求等八点运转的实例 A1 运转成功之后，六点的 B1 才会开端运转。

（6）小时使命依靠小时使命周期数不相同

小时使命依靠小时使命，且下流周期数大于上游周期数，会依据就近原则挂依靠（时刻小于等于自己且不重复依靠）。

比方说上游依照每十二个小时运转一次，那么上游一天形成两个实例，下流依照每六个小时运转一次，那么下流一天形成四个实例，假如下流的实例数大于上游的，就会就近挂依靠，实例 B1 和 B2 在零点和六点就会挂依靠于较近的实例 A1 的零点

案例一：小时使命依靠天使命 

之前案例讲到，假如上游天使命完结时下流有多个周期守时时刻已到，会导致这些周期被并发调度起来，假如不希望下流并发调度起来，则需求将下流小时使命设置成自依靠，即依靠上一周期→本节点。需求留意的是，自依靠会依靠跨版别(跨天），假如昨日最终一个周期未完结，会导致今日的使命无法调度。

比方上游实例 A 是天使命，下流实例 B 是周期为八小时的小时使命，在实例 A 完结之后，实例 B 依据虚线顺序逐渐完结，在赤色框框内是一个跨天的依靠联系，2015年1月1日零点的实例 B1 不只要依靠于实例 A 的完结，也要依靠于上一周期实例 B3 的完结。

案例二：天使命依靠小时使命 

天使命依靠小时使命，需求等小时使命一切周期都完结才干开端调度。假如需求天使命尽量依照守时时刻开端调度。则能够装备上游小时使命自依靠，待上游小时使命守时时刻最近（且小于）的周期完结后，下流天使命就会被调度。

比方图中的连线联系是一个依靠联系，下流的十二点的天使命会依据就近原则就近依靠上游的八点钟，由于要依照小于它的时刻去进行就近的依靠。

案例三：小时使命依靠天使命 

小时使命依靠天使命且天使命存在跨周期依靠，则小时使命的一切周期都会依靠昨日的天使命。

比方实例 B1,B2,B3 按八个小时进行实例的生成，可是上游的实例 A 为一个天使命，而且存在跨周期的依靠，即15年1月1日的实例要去依靠14年12月31日的实例，等到14 年 1 2 月 31 日的实例都完结后，才干开端履行。

案例四：天使命依靠小时使命

依靠一层子节点：上游的小时使命跨周期依靠下流的守时天使命，效果即上游小时使命会在每一周期都会依靠上一版别的下流使命。

比方说15年1月1日上游的小时使命跨周期要依靠于上一周期即14年12月31日实例B的天使命，天使命完结后，小时使命才会开端运转。

案例五：小时使命依靠小时使命

下流节点设置依靠自定义节点（父节点 ID）：

此 case 比较特别，即可看出其实这个依靠图中存在两个概念，既有跨周期（依靠上游小时使命的上一周期），又存在跨版别（依靠上游小时使命的上一版别的一切周期）。

比方图中实现为存在的依靠联系，虚线为自依靠。

调度依靠联系的详细实现示意图

调度依靠联系的详细实现：

调度的守时功能实践上是运用了 quartz 守时器，在每个使命完结的时分都会将一切下流使命查询出来。然后下流使命会返查是否一切上游都是完结了的。假如完结了，就会将下流使命注册到守时器中，所以可知在调度中存在越多的依靠联系，调度引擎的开支就越大。

比方上图左边装备了上游三个节点，下流一个节点这种依靠联系，那我们会每天依照 23:30 一致进行节点开造，生成能够去运转的实例。运转规矩为先运转上游第一个节点，再运转上游第二个节点，当三个节点都运转并返回成功，会开端判别下流节点是否到守时时刻，到了运转，没到等候。假如在上游三个节点中某个节点运转失利，会导致下流节点一直处于等候状况中。

针对跨周期跨版别依靠的优化 

和之前的依靠联系比照，能够看到有了自依靠后，跨周期依靠的边少了很多。这是由于假如有了自依靠，当时周期成功的条件有必要是前一个周期成功了，所以下流跨周期并跨版别依靠就减少成了跨周期依靠。

天使命依靠小时使命（1）

【事务场景】

体系需求计算截止到每小时的事务数据增量，然后在最终一个小时的数据汇总完结后需求一个使命进行一整天的汇总。

【需求剖析】

1）每个小时的增量，即每整点起使命计算上个小时时刻段的数据量，需求装备一个每天每整点调度一次的使命，每天最终一个小时的数据是在第二天第一个实例进行计算。

2）最终的汇总使命为每天履行一次，且有必要是在每天最终一个小时的数据计算完结之后才干履行，那么需求装备一个天使命，依靠小时使命的第一个实例。

天使命依靠小时使命（2）

【事务场景】

体系需求计算截止到每小时的事务数据增量，然后在最终一个小时的数据汇总完结后需求一个使命进行一整天的汇总。

【需求剖析】

1）每个小时的增量，即每整点起使命计算上个小时时刻段的数据量，需求装备一个每天每整点调度一次的使命，每天最终一个小时的数据是在第二天第一个实例进行计算。

2）最终的汇总使命为每天履行一次，且有必要是在每天最终一个小时的数据计算完结之后才干履行，那么需求装备一个天使命，依靠小时使命的第一个实例。

小时使命依靠分钟使命（1）

【事务场景】

现已有使命每 30 分钟进行一次同步，将前 30 分钟的体系数据增量导入到MaxCompute，使命守时为每天的每个整点和整点 30 分运转，现在需求装备一个小时使命，每 6 个小时进行一次计算，即每天别离计算 0 点到 6 点之间、6 点到 12点之间、12 点到 18 点之间、18 点到明日 0 点整之间的数据。

小时使命依靠分钟使命（2）

【事务场景】

现已有使命每 30 分钟进行一次同步，将前 30 分钟的体系数据增量导入到MaxCompute，使命守时为每天的每个整点和整点 30 分运转，现在需求装备一个小时使命，每 6 个小时进行一次计算，即每天别离计算 0 点到 6 点之间、6 点到 12点之间、12 点 到 18 点之间、18 点到明日 0 点整之间的数据。