正文
2.3 任务故障转移
调度任务的从任务级别job到transformer、operator，整个链条都存在具体局部失败的情况，调度器需要在原目标宿主机重试和失败后转移到其他备宿主机的功能，最大力度的保证任务被成功执行。
2.4 执行算子抽象
以往单机任务的调度可以比较灵活的执行多样的任务，可以是脚本、Webservice调用、HDFS Client命令行等，但是对于分布式协作需要接收外部命令运行，这就需要算子通过标准的数据通讯协议对外提供调用服务，常规的WebService、RPC（thrift/protocol buffer）等协议在跨语言通讯上具有较为广泛的应用。所以具体执行单元可以是具体任务的抽象，例如提供了Rest API方式，调用的URL和参数都是执行方填入，最大程度上支撑了灵活性；数据库操作算子可以包含数据库验证信息、具体执行的SQL等。执行算子抽象后，满足规范和灵活性，灵活是一个双刃剑，可以最大限度的满足用户需求，但也会导致大数据层面无法很细粒度的去感知数据的表、字段数据的完成情况，对数据生产无法更加精细粒度的产出交付。
2.5 弹性扩展
任务具体执行的宿主机需要在调度层面满足弹性的扩展，扩展最主要的需要是满足高可用和任务随着水平扩展进行分摊压力。在集群目标宿主机选择时，一般目标集合可以指定具体IP-List，也可以是一个BNS(百度机器的NameServer服务)。IP-List方式设置比较简单直观，但是存在每次调整依赖变更调度系统服务，变更之后还需要进行刷新宿主机的情况。而通过BNS服务比较简单，同时和线上服务发布部署进行结合，不存在延迟部署和刷新，推荐通过BNS的方式介入。
2.6 触发机制
常规触发是按照执行间隔或者具体时间的Crontab语法，开始时间，截止时间参数完成，但是在分布式调度任务中，最重要的就是完成协作，所以如果要进阶的话，就是依赖触发的机制。这种就很好的形成了上下游依赖触发，是分布式协作的关键步骤。从最初的任务节点按照常规触发，下游节点形成依赖链条，这里如果在高级进阶的话，就是依赖的某个/某些频次触发，比如每小时的12分钟开始被执行，下游可以选择具体的2:12 ，4:12进行触发，而非每个整点12分都被调用。这三种方式目前在外卖的大数据平台都有不同场景诉求，架构设计在3个需求上都有灵活的交付。
2.7 堵塞机制
对于相同任务的不同时间的运行实例，会存在前面的实例还没有正常结束的情况，这种在高频次调用，第三方依赖故障延迟等情况下会出现，如果继续调用会造成调用链条恶化，所以防止这种情况，堵塞机制会提供三种模式：常规例行（默认模式）、丢弃后续、丢弃前例。后面2种方案都需要提供容错重放机制，这个场景比较类似1.1章节提到的结算案例。
2.8 图形化进展查看
调度可以根据调用链条和不同事件频次的实例，通过树状图形化的方式查看执行的进度情况，例如可以查看job中transformer、算子的运行机器状况、状态和具体的实时执行日志。图形化是根据调用的触发机制分析出来的一个链条，是在烦冗复杂的调用关系中找到清晰脉络的数据直观表达的方式，是调度中常规的展示方式。在进阶中可以查看相应的参数传递，并发算子的执行进度条，预估完成周期等。
2.9 报警
通过邮件或者短信的方式对不符合预期返回标识的进行中止，同时通过邮件或者短信等方式对预先设置的用户或者用户组发出警告。报警触发的机制可以在宿主机单台时候触发，也可以在一定占比的宿主机在一定的时间窗口超过了阈值，触发报警。同时也要支持报警的屏蔽，用在进行运维或者升级部署、运维接管的情况。
上面是很多常规调度拥有的一些特征，这些是在分布式场景下的延伸需求，从单点简单的逻辑到多节点的协作统筹在工程层面无疑增加了额外辅助，这些都是在业务演进中逐步完善起来，而高可用、高效率是在分布式环境下做出的改变。
