面向大数据的分布式调度

作者：梁福坤，百度外卖大数据首席架构师。
责编：魏伟
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅《程序员》，给我们投稿，请联系邮箱weiwei@csdn.net。

前言：大数据的分布式调度是在进行数据ETL过程中起到了总体的承上启下的角色，整个数据的生产、交付、消费都会贯穿其中，本文从调度、分布式调度的特征展开，再对大数据调度个性化特征的一些阐述，由满足大数据使用的架构和业务场景的需求上娓娓道来，从实践的角度分享如何打造一个高可用、高效率、灵活性的大数据调度平台。

一、调度

从上个世纪50年代起，调度问题的研究就受到数学、运筹学、工程技术学等领域科学的重视[1]，人们主要从数学的角度来研究调度问题，调度问题也同样被定义为”分配一组资源来执行一组任务”，以获得生产任务执行时间或成本的最优[2]。调度在计算机任务的实现可以依赖操作系统的定时任务进行触发（例如Linux系统的Crontab），主要针对单任务机制的触发，调度最基本的需要能够按时或者按照事件进行触发（At-least-once），如果任务不符合预期，还需要在应用端进行重试，最大可能保证任务被按时执行，并且成功执行，同时不能多次执行（Exactly once）；但是在业务场景能保证可重复执行、一致性操作情况下对于争取能正常调度执行多次执行也是不可或缺的，比如给商户进行1min前的例行结算，如果结算是按照30min的时间窗口查找未结算的商户，那么就会容忍30min延迟，并且多次被执行也不会给商户多结算，因为在结算付款和重置是否结算标志位可以设计成原子性操作。所以在调度上能够做到按时、正确的执行，在业务方设计为了保证最终一致性也有一些架构上的取舍。

如果应用场景有上下游的协作，或者在任务执行会存在不同的宿主机来完成，或者为了保证任务高可用场景，就需要引入分布式调度的架构。

二、分布式调度

分布式调度是在单机的基础上发展起来，在综合考虑高可用、高效率、分布式协作的背景下逐步演进的调度方式，从单点调度到分布式协作是一个质变的过程，这个过程涉及到许多在单机并不存在的特征，下面针对重点展开聊下：

图1 分布式调度组件化分解图

2.1 调度器去中心化&高可用

涉及到分布式调度的协作，就需要有调度中心节点，同时要保证高可用的目的就需要调度中心节点是多节点发布，主备的方式去单点依赖。

2.2 宿主选择

分布式调度在任务执行阶段，可以在目标宿主中进行全部执行、N选M（N>=M>=1）的选择，宿主机具备相同类型任务互备的机制，在MPP(Massively Parallel Processor)架构中尤为常见，把大任务分而治之快速完成。也存在场景（比如外卖给商户结算）为了一致性和准确性只能由一台主机进行执行，并且需要成功执行。

• 被动选择策略：宿主的被动选择机制一般可以随机或者按照顺序选择策略，也可以按照当前宿主机进行的任务执行数量的方式进行常规的调度分配。当然，也可以进行高级的操作，参照宿主机的处理能力（吞吐量和响应时间）、资源使用情况（CPU、Memory、Disk I/O、Net I/O等）进行反馈机制的动态分配。后者需要有集中节点存储当前宿主机的处理能力、资源情况，便于在决策选择中提供参照。

• 主动选择策略：宿主的主动选择具备更加丰富的选举策略，任务在下达到具体算子时，会比较明确的定义出当前任务需要由多少个宿主参与执行，通过zookeeper的分布式锁来实现锁的抢占机制，抢占成功则执行，否则放弃。这种选举策略让宿主机得到了更多的参与，降低了对调度器的依赖。这种主动选择的方式，避免被动选择因不具备执行条件被选中，在执行的能力在时间上的损耗。

2.3 任务故障转移

调度任务的从任务级别job到transformer、operator，整个链条都存在具体局部失败的情况，调度器需要在原目标宿主机重试和失败后转移到其他备宿主机的功能，最大力度的保证任务被成功执行。

2.4 执行算子抽象

以往