精华内容
下载资源
问答
  • 2020-09-13 09:53:55

    一、什么是调度系统

    调度系统,更确切地说,作业调度系统(Job Scheduler)或者说工作流调度系统(workflow Scheduler)是任何一个稍微有点规模,不是简单玩玩的大数据开发平台都必不可少的重要组成部分。除了Crontab,Quartz这类偏单机的定时调度程序/库。开源的分布式作业调度系统也有很多,比较知名的比如:oozie,azkaban,chronos,zeus等等,此外,还有包括阿里的TBSchedule,SchedulerX和腾讯的Lhotse。

    二、为什么需要调度系统

    我们都知道大数据的计算、分析和处理,一般由多个任务单元组成(Hive、Sparksql、Spark、Shell等),每个任务单元完成特定的数据处理逻辑。

    多个任务单元之间往往有着强依赖关系,上游任务执行并成功,下游任务才可以执行。比如上游任务结束后拿到 A 结果,下游任务需结合 A 结果才能产出 B 结果,因此下游任务的开始一定是在上游任务成功运行拿到结果之后才可以开始。

    而为了保证数据处理结果的准确性,就必须要求这些任务按照上下游依赖关系有序、高效的执行。一个较为基础的处理方式是:预估出每个任务处理所需时间,根据先后顺序,计算出每个任务的执行的起止时间,通过定时跑任务的方式,让整个系统保持稳定的运行。

    一个完整的数据分析任务最少执行一次,在数据量较少,依赖关系较为简单的低频数据处理过程中,这种调度方式完全可以满足需求。然而在企业级场景中,更多的是需要每天执行,如果任务数量较多,在任务启动的时间计算上就将耗费大量时间,另外如果出现上游任务执行时长超出原定预计时间或者运行异常的问题,上述的处理方式将完全无法应对,也会对人力物力造成重复损耗。因此,对于企业数据开发过程来说,一个完整且高效的工作流调度系统将起到至关重要的作用。

    三、调度系统的两大种类

    调度系统分为作业调度系统资源调度系统两大类,但很多时候大家往往把这两类的概念混为一谈。

    1、资源调度系统

    资源调度系统的关注的重点底层物理资源的分配管理,目标是最大化地利用集群机器的CPU、磁盘、网络等硬件资源,所调配和处理的往往是与业务逻辑没有直接关联的诸如通用程序进程这类的对象。

    2、作业调度系统

    作业调度系统关注的重点在正确的时间点启动正确的作业,确保作业按照正常的依赖关系及时准确地执行。资源的利用率通常不是第一关注要点,业务流程的正确性才是最重要的。作业调度系统有时也会考虑负载均衡问题,但保证负载均衡更多的是为了系统自身的健壮性,而资源的合理利用作为一个可以优化的点,往往依托底层的资源调度系统来实现。

    那么,为什么市面上会存在这么多的作业调度系统项目,作业调度系统为什么没有像HDFS、Hive、 HBase 之类的组件那样形成一个相对 标准化的解决方案呢?归根结底,还是由作业调度系统的业务复杂性决定的。

    一个成熟易用、便于管理和维护的作业调度系统,需要和大量的周边组件对接,不仅包括各种存储计算框架,还可能要处理或使用到血缘管理、权限控制、负载流控、监控报警、质量分析等各种服务或事务。这些事务环节,每家公司都有自己的解决方案,所以作业调度系统所处的整体外部环境千差万别,而且,各公司各种业务流程的定制化需求又进一步加大了环境的差异性,所以,调度系统很难做到既能灵活通用地适配广大用户的各种需求,又不太晦涩难用。

    市面上现有的各种开源作业调度系统,不是在某些环节、功能上是缺失的,使用和运维的代价很高,需要大量二次开发;就是只针对特定的业务场景,形态简单,缺乏灵活性;要不就是在一些功能环节上是封闭自成体系的,很难和外部系统进行对接。

    那么,理想中的完备作业调度系统,到底都要处理哪些事务呢?要做好这些事务都有哪些困难要克服,有哪些方案可以选择,市面上的开源调度系统项目又是如何应对这些问题的,下面就让我和大家一起来探讨一 下。

    四、作业调度系统的两大种类

    根据实际的功能定位,市面上的作业调度系统主要分为以下两大类:定时分片类作业调度系统DAG工作流类作业调度系统。这两类系统的架构和功能实现通常存在很大的差异。

    1、定时分片类作业调度系统

    定时分片类系统的方向,重点定位于任务的分片执行场景,这类系统的代表包括TBSchedule、SchedulerX、 Elastic-job、 Saturn。

    这种功能定位的作业调度系统,其最早的需求来源和出发点往往是做一个分布式Crontab和Quartz。

    一开始各个业务方自成一体,自己搞自己的单机定时任务,随着越来越多,分散管理的代价越来越高。再加上有些业务随着数据量的增加,各种定时任务为了提高运行效率,也需要以分布式的方式在多台机器上并发执行。这时候,分布式分片调度系统也就应运而生了。

    这类系统的实际应用场景,往往和日常维护工作或需要定时执行的业务逻辑有一定的关联。比如需要定时批量清理一批机器的磁盘空间, 需要定时生成一批商品清单,需要定时批量对一批数据建索引, 需要定时对一批用户发送推评通知等。

    这类系统的核心目标基本是以下两点:

    (1)对作业分片逻辑的支持:将一个大的任务拆成多个小任务,分配到不同的服务器上执行,难点在于要做到不漏、不重,保证负载均衡,节点崩溃时自动进行任务迁移等。

    (2)高可用的精确定时触发要求:因为往往涉及实际业务流程的及时性和准确性,所以通常需要保证任务触发的强实时和可靠性。

    所以,负载均衡、弹性扩容、状态同步和失效转移通常是这类调度系统在架构设计时重点考虑的特性。

    从接入方案和流程上来说,因为要支持分片逻辑和失效转移等,这类调度系统对所调度的任务通常都是有侵入性要求的。

    常见的做法是用户作业需要依赖相关分片调度系统的客户端库函数,扩展一个作业调度类作为作业触发的入口类。一般还需要接收和处理分片信息用于对数据进行正确的分片处理。通常还需要实现一些接口用于满足服务端的管理需求,比如注册节点、注册作业、启动任务、停止任务、汇报状态等。有些系统还要求作业执行节点常驻守护进程,用于协调本地作业的管理和通信。

    2、DAG工作流类调度系统

    DAG工作流类调度系统的关注重点定位于任务的调度依赖关系的正确处理,分片执行的逻辑通常不是系统关注的核心,或者不是系统核心流程的关键组成部分,如果某些任务真的关注分片逻辑,往往交给后端集群(比如MR任务自带分片能力)或具体类型的任务执行后端去实现。

    这类系统的代表包括oozie、azkaban、chronos、zeus、 Lhotse, 还有各种大大小小的公有云服务提供的可视化工作流定义系统。

    DAG工作流类调度系统所服务的往往是作业繁多、作业之间的流程依赖比较复杂的场景。比如大数据开发平台的离线数仓报表业务,从数据采集、清洗,到各个层级的报表的汇总运算,再到最后教据导出到外部业务系统,一个完整的业务流程可能涉及成百上千个相互交叉,依赖关联的作业。

    所以DAG工作流类调度系统关注的重点通常包括以下几点:

    (1)足够丰富和灵活的依赖触发机制:比如时间触发任务、依赖触发任文混合触发任务

    而依赖触发任务自身可能还要考虑多亲依赖、长短周期依赖(如小时村任务依赖天任务,或者反过来)、依赖范围判定(比如所依赖任务最后一次成功就可以触发下游,还是过去一个星期的所有任务都成功才可以触发下游)、自身历史任务依赖、串并行触发机制等。

    (2)作业的计划、变更和执行流水的管理和同步

    定时分片类调度系统中固然也要考虑这个需求,但通常相对简单。而在DAG工作流类调度系统中,因为任务触发机制的灵活性和作业依赖关系的复杂性,这个需求就尤为重要,需要提供的功能更加复杂,具体的问题解决起来也困难很多。

    (3)任务的优先级管理、业务隔离、权限管理

    在定时分片类调度系统中,具体执行端的业务在很多情况下本来就是隔离的,注册了特定业务的节点才会去执行特定的任务。而且业务链路一般都比较短,再加上强实时性要求,所以对优先级的管理通常要求也不高,基本靠资源隔离来实现资源的可用,一般不存在竞争资源的问题,权限管理也是一样的。

    而在DAG工作流类调度系统中,往往一大批作业共享资源执行,所以优先级、负载隔离和权限管控的问题也就突显出来了。

    (4)各种特殊流程的处理,比如暂停任务、重刷历史数据、人工标注失败或成功、临时任务和周期任务的协同

    这类需求本质上也是业务流程的复杂性带来的,比如业务逻辑变更、脚本写错、上游数据有问题、下游系统挂掉等,而业务之间的网状关联性,导致处理问题时需要考虑的因素很多,也就要求处理的手段应足够灵活强大。

    (5)完备的监控报警通知机制

    最简单的有任务失败报警、超时报警,复杂一点的有流量负载监控、业务进度监控和预测, 如果做得再完善一点,还可以包括业务健康度监控分析、性能优化建议和问题诊断专家系统等。

    需要注意的是,这两类系统的定位目标并不是绝对冲突矛盾的。只不过要同时圆满地支持这两类系统的需求,从实现的角度来说是很困难的,因为侧重点不同,在架构上多少会对某些方面做些取舍,当前的系统都没有做到完美的两者兼顾。但并不代表这两类系统的实现就一定是不可调和的,好比离线批处理计算框架和流式实时计算框架,长期以来它们各行其道,但是随着理论和实践的深入,也开始有依托一种框架统一处理两类计算业务的可能性出现。

    参考自:刘旭晖《大数据平台架构基础指南》

    更多相关内容
  • 基于QT的AGV智能调度系统 AGV智能调度系统 AGV调度系统 基于QT的AGV调度系统 基于QT的AGV智能调度系统,包含完整注释及源代码
  • 多AGV调度系统软件

    热门讨论 2017-11-10 15:38:45
    一种多AGV调度软件,使用JAVA开发,适合运行在任意运行JRE的操作系统上。
  • 调度系统架构理论与实践 大数据平台工作流调度系统 天火@蘑菇街 - colorant @ Wechat Agenda 调度系统背景知识 工作流调度系统基础理论和流派 我司Jarvis调度系统开发实践 系统架构 设计目标 现状和未来 调度系统...
  • 介绍多种多媒体融合调度系统解决方案及系统架构,方案优势,多媒体融合调度特点,融合调度特点。
  • 基于MATLAB-GUI的生产车间调度系统设计 基于MATLAB-GUI的生产车间调度系统设计 基于MATLAB-GUI的生产车间调度系统设计 基于MATLAB-GUI的生产车间调度系统设计 基于MATLAB-GUI的生产车间调度系统设计 基于MATLAB-GUI...
  • 一款你不得不了解的轻量级分布式任务调度系统! github地址:CronMan 简介 CronMan是一款轻量级的分布式任务调度系统。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构,相应的也需要一个分布式...

    CronMan 分布式任务调度/定时任务系统

    在这里插入图片描述

    github地址:CronMan, 欢迎star
    欢迎朋友们站内私信交流~

    简介

    CronMan是一款轻量级的分布式任务调度系统。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构,相应的也需要一个分布式任务调度系统来管理分布式架构中的定时任务。

    已有的分布式任务调度系统如:Saturn、elastic-job、xxl-job都是非常优秀的开源作品,为了学习与交流,我设计了一款轻量级的分布式任务调度系统CronMan,具有一些崭新的特性如:任务编排任务结果传递高可用任务幂等性触发等,弥补了上述开源系统的部分缺点。

    内容一览

    功能

    • 定时任务:调度系统最基础的功能,定时完成用户提出的任务,可实现秒级任务调度。

    • 任务监控:监控任务运行的状态:已就绪,禁用,执行中等。

    • 任务控制:注册、启用、禁用、删除任务。

    • 任务分片:对于一个大型任务,可以将任务分片置于不同执行器上执行。

    • 弹性扩容、缩容:执行器可以水平扩展 ,同时某个执行器宕机/新增执行器对当前任务的执行无影响。

    • 任务重触发:自动记录错过未触发的任务,重新触发。

    • 失效转移:某台执行器宕机后,归属于该执行器的任务会被重新分发到另外一台执行器上。

    • 任务编排:用户可以编排任务依赖顺序,任务形成一个有向无环图,按照图的顺序依次调用,满足串行,并行,多依赖需求。

    • 任务结果传递:上游任务可以将本次运行结果传递给下游任务。

    • 高可用:调度系统以集群形式部署,当其中一台调度器宕机后,不会影响整体系统的运行。

    • 任务幂等性:精密控制任务的执行次数,用容灾处理来避免任务重复执行。

    系统架构

    整体架构

    在这里插入图片描述

    在这里插入图片描述

    CronMan 可以分为三大模块(调度器集群、控制中心和执行器集群)、两大组件(路由转发组件和持久化存储组件)。这三大模块和两大组件的作用如下:

    • 任务调度器集群:负责调度任务,处理控制中心下发的请求等。
    • 任务控制中心:负责任务的注册、启用、禁用、删除注册等,对任务进行逻辑编排,提供实时监控功能。
    • 任务执行器集群:负责接收调度器下发的任务请求,并执行任务逻辑。
    • 路由转发组件(Nginx):实现调度集群的高可用(如果对高可用不需要,那就可以不使用)。
    • 持久化存储(DB):记录任务的具体细节、已执行情况等。

    在这里插入图片描述

    应用场景

    举例:

    • 场景

      1. 每天凌晨1点跑单查hive,进行每日清算。

      2. 用户下单后长时间未支付,需要修改订单状态。

      3. 电商整点抢购,商品价格0点整开始优惠。

      4. 发放优惠券、发送短信提醒等。

    • 解决

      通过分布式系统来调度任务,最主要的功能就是将任务分解为子分片,每个分片绑定一台机器处理对应的任务。

      对一般场景而言,一个任务可能由多个操作组合而成,而将这些操作分解依次派发给子分片来完成。

      比如`` 发送短信``的任务,需要发送三千万条生日祝福短信,使用十个分片。每个分片只需要发送三百万条短信。
      就极大缓解了机器的压力。
      
      比如`` 发放生日优惠券``的任务,需要先查用户信息库,获取需要派发优惠券的用户信息,再操作用户卡券库,
      检验是否优惠券已存在、增添优惠券等流程,就可以用不同分片来处理不同操作。
      

      对复杂场景而言,如果存在分库分表的情况下,可以对任务继续细分。

      比如`` 发放生日优惠券``的任务,需要先查用户信息库,获取需要派发优惠券的用户信息。
      这时候可以选择让一台分片机器专门负责查询用户信息,一台分片机器专门查询用户卡券信息,
      避免了多台机器对同一数据库资源的竞争。
      
    • 一般场景

    在这里插入图片描述

    • 复杂场景

    在这里插入图片描述

    设计思想

    系统本质

    分布式任务调度系统和rpc系统其实非常相似,rpc系统通常是多个client调用一个server的某个服务,而分布式任务调度系统是一个server通知多个client去执行他们的某个服务。

    服务发现/注册

    作为分布式的系统,最先需要考虑的问题自然是服务发现/注册。主流的两种做法分别是:1.以elastic-job为代表的无中心化解决方案,通过引入Zookeeper来实现分布式协调。优点很明显,缺点则是无法实现高可用(zk本身的缺点),并且系统复杂度提高了很多。2.以xxl-job为代表的中心化解决方案,调度中心通过DB锁保证集群分布式调度的一致性。

    我的理解是:分布式任务调度系统主要的目的是缓解大型定时任务(如在某个时间点发送千万张优惠券)对单台机器的压力,将任务分散到多台机器上,偏向于分布式处理数据,所以调度器本身不参与数据处理,只是单纯地下发任务、发送请求等,没必要引入第三方组件。

    同时,受RocketMQ中NameServer设计的启发,我认为调度器本身和NameServer是非常类似的:1.NameServer节点之间互不通信,调度器也不需要互相通信 2.NameServer本身不参与业务处理,调度器也不需要 3.Producer和Consumer只需要和随机一个NameServer建立连接即可,而用户发送的请求也只需要一个调度器来响应处理即可。 4.NameServer的主要功能是为Client提供路由能力(简单来说就是找到一个活着的节点),而调度器的功能也是为任务找到活着的执行器,下放给它执行。

    所以我参考了NameServer的模式,使执行器与调度器集群的每一个节点建立长连接,通过心跳机制定时注册信息到所有的调度器来向调度器证明自身还存活。在路由注册操作中引入了ReadWriteLock读写锁,允许多个任务控制器并发读,保证了任务发送时的高并发。同一时刻调度器只能处理一个执行器的心跳包,多个心跳包串行处理。

    一致性与任务幂等性

    关于一致性与任务幂等性,系统需要保证请求任务不能重复触发。这里涉及到多种可能的情况:

    • 用户在Web端发送的请求只能有一个调度器来处理

    • 某个发送任务 同一时刻只能由一个调度器触发。

    • 某台执行器与调度器连接断开,但是它并没有宕机,任务还在执行,而调度器在长时间没有接收到它的心跳包后认定它断联,根据失效转移策略,任务又会被发送到另外一台执行器上执行。

    • 某台执行器完成了任务,通知执行器任务已完成的消息刚发送给某台调度器,这台调度器就宕机了。而其他调度器根据失效转移策略,任务又会被发送到另外一台执行器上执行。

    • 某台调度器对数据库的多次操作是否会冲突?比如mapper.selectAll()后进行mapper.update(),在这两步中间另外一个线程也mapper.select(),这时此线程读到的就是旧数据。

    处理情况一:用户通过Web端发送了任务监控与编排请求,通过Nginx来控制请求只发送到一台调度器上。

    处理情况二:调度中心通过竞争DB排他锁来保证,某个任务同一时刻只能由一个调度器拿到,并且调度器会修改任务的状态,从而确保另外的调度器无法拿到这个任务,避免了任务的重复执行。

    处理情况三:执行器与调度器断开后,会立即中断自身所有的执行任务。

    处理情况四:执行器发送完任务已完成的消息后,会等待调度器的响应,如果超时或者错误,就会将任务已完成的消息持久化到本地,定时扫描消息,直到任务已完成的消息被调度器接受。

    处理情况五:为保证数据库的一致性,普通的方法是开启事务保持ACID,本系统为了提供秒级的任务调度,使用读写锁来控制并发问题,在JVM层面提供并发控制而不是丢给数据库处理,尽可能减小时间开销。

    任务编排

    任务编排是一项比较重要的功能,它是指多个任务之间可以编排执行顺序,譬如ABC三个任务,可以编排A任务先执行,等A任务执行完后BC任务方可执行,同时A任务会产生运行结果,这部分运行结果可以传递给BC任务,BC任务以此来进行分支任务执行。

    CronMan实现的编排功能为:

    • 普通任务编排:允许任务以有向无环图(DAG)的依赖关系运行,等所有的前置依赖任务执行完毕后,可以根据任务的类型(被动任务、主动任务)运行。

    • 普通任务结果传递:允许任务将本次允许结果传递给下游任务(暂时只支持1个上游任务对应多个下游任务,不支持多对1)。

    • 任务结果自传递:在DAG图的基础上,允许自环的结构(也就是自己依赖于自己),可以将本次任务的运行结果传递给下一次任务,任务可以根据上一次的运行情况来自我判断该如何执行任务。

    效果一览

    任务配置

    任务在这里进行注册,根据任务类型来配置不同的任务。目前共有四种任务,定时任务需要配置Cron表达式,到达对应时间,任务就会触发;被动任务不需要配置Cron表达式,上游任务全部完成后,被动任务自动开始触发;Java任务是普通Java程序的任务,需要配置类名、方法名、参数类型以及参数;Shell任务则是shell脚本任务,需要配置脚本内容,也可以稍后在监控页面配置。

    在这里插入图片描述


    根据每个任务不同的需求,相应地配置不同的分片数、是否允许失效转移、是否允许错过任务重触发、选择执行器的策略等。

    在这里插入图片描述


    在这里插入图片描述

    可通过依赖任务来配置依赖的上游任务,构成一个DAG图。任务以DAG图的形式执行,只有当上游任务都完成时,下游任务才能开始。



    在这里插入图片描述



    任务监控

    监控任务的状态,共分为:已就绪、执行中、等待上游任务、已停用四种状态。其中,已就绪代表任务就绪,只需等待设定时间一到/上游任务完成即可开始执行;执行中代表任务已交由执行器执行;等待上游任务为被动任务特有,代表上游任务一执行完就可以立马执行;已停用代表任务暂时停止执行。

    控制任务的执行,启用、禁用、删除任务。

    查看任务的DAG依赖图,包括上游和下游的所有关联任务。

    在这里插入图片描述

    shell任务,可以通过控制中心在线修改任务的具体内容。

    在这里插入图片描述

    任务依赖

    针对某项任务,可以查看它的关联DAG图,实时查看各项任务的状态。

    点击 backUp 的查看依赖,就可以看见 backUp 的DAG任务依赖图。可以看出backUp和多个任务相互有关联,它的下游任务是cleanUp。backUp的状态为已就绪,待设定时间到就会开始执行,而cleanUp在backUp完成之后,还需要等待它的上游任务washUp完成才能开始执行。
    在这里插入图片描述

    点击 passive查看依赖,就可以看见 passive的DAG任务依赖图。因为passive任务和其他任务没有依赖关系,所以DAG图只有它自己,当前的状态为已停用。

    在这里插入图片描述

    实践和使用

    CronMan是SpringBoot项目,使用者暂时也需要用SpringBoot来使用执行器。(因为楼主要写论文,所以没有太多空闲时间用来适配各种其他的项目)

    使用流程

    1. 下载项目 & 打包执行器(executor)模块
    
    2. 配置数据库
    
    3. 将1.中打好的包作为依赖引入你自己的项目中
    
    4. 为你的任务添加上@scheduleJob注解,并在数据库/控制台添加上这个定时任务
    

    示例

    设定任务:

    添加定时任务,每分钟备份一次数据库demo和demo2,每个数据库中各有一百万条记录,将sql存储到磁盘中。设置两个分片来完成这个任务。

    1. 首先下载整个项目。

      git clone git@github.com:smmdwa/CronMan.git
      
    2. 使用assembly:assembly 的maven插件可以快速进行打包(PS:这里不要用SpringBoot的打包插件,因为Spring Boot 中默认打包成的 jar 是 可执行 jar,无法被依赖)

    3. 利用项目中的sql/cronjob.sql 配置数据库

    4. 配置调度器的application.yml

      spring:
        datasource:
          driver-class-name: com.mysql.cj.jdbc.Driver
          url: jdbc:mysql://192.168.213.130:3306/cronjob?characterEncoding=utf-8&useSSL=false&useAffectedRows=true
          username: root
          password: 123456
      server:
        port: 8081
      
      #netty监听端口
      remoting:
        address: 127.0.0.1:8088
        
      #mybatis的相关配置
      mybatis:
        mapper-locations: classpath:mapper/*.xml
        type-aliases-package: com.distribute.remoting.bean
        configuration:
          map-underscore-to-camel-case: true
      
    5. 新建一个SpringBoot项目demo,这里采用的是本地依赖,新建lib目录,放入2.中打好的jar包,引入依赖。

              <dependency>
                  <groupId>com.distribute</groupId>
                  <artifactId>executor</artifactId>
                  <version>0.0.1</version>
                  <scope>system</scope>
                  <systemPath>${project.basedir}/lib/executor-0.0.1-SNAPSHOT.jar</systemPath>
              </dependency>
      
    6. 注入bean

      @Configuration
      @ComponentScan(basePackages = {"com.distribute"})
      public class CronConfig {
      }
      
    7. 编写备份任务

      在这里插入图片描述

    8. 配置demo项目的application.yml

      executor:
        name: executor-1
        ip: 127.0.0.1
        port: 8092
      remoting:
        address: 127.0.0.1:8088;127.0.0.1:8089
      server:
        port: 8092
      controller:
        channel:
          expiredTime: 30000
      
    9. 启动一台调度器和两台执行器(记得修改port和remoting.address)

    10. 成功!

    在这里插入图片描述

    在这里插入图片描述

    展开全文
  • 景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx景区调度系统解决方案.docx...
  • 景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度系统解决方案.pdf景区调度...
  • 有线电视运维调度系统研究探讨 .pdf有线电视运维调度系统研究探讨 .pdf有线电视运维调度系统研究探讨 .pdf有线电视运维调度系统研究探讨 .pdf有线电视运维调度系统研究探讨 .pdf有线电视运维调度系统研究探讨 .pdf...
  • 综合指挥调度系统解决方案V10.pdf综合指挥调度系统解决方案V10.pdf综合指挥调度系统解决方案V10.pdf综合指挥调度系统解决方案V10.pdf综合指挥调度系统解决方案V10.pdf综合指挥调度系统解决方案V10.pdf综合指挥调度...
  • -车辆智能调度系统解决方案.docx-车辆智能调度系统解决方案.docx-车辆智能调度系统解决方案.docx-车辆智能调度系统解决方案.docx-车辆智能调度系统解决方案.docx-车辆智能调度系统解决方案.docx-车辆智能调度系统...
  • -车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案.pdf-车辆智能调度系统解决方案....
  • 大数据平台--调度系统

    千次阅读 2021-07-11 11:09:07
    调度系统是数据仓库的重要组成部分,也是每个银行或公司一个基础软件或服务,需要在全行或全公司层面进行规划,在全行层面统一调度工具和规范,由于数据类系统调度作业较多,交易类系统批量优先级高,调度系统的整体...

    调度系统是数据仓库的重要组成部分,也是每个银行或公司一个基础软件或服务,需要在全行或全公司层面进行规划,在全行层面统一调度工具和规范,由于数据类系统调度作业较多,交易类系统批量优先级高,调度系统的整体架构如下:
    在这里插入图片描述

    调度中心

    对调度批次和作业进行创建、管理、监控,它负责所有批量作业的调度和编排;
    在整个作业过程中,作业之间关系分为触发,依赖和互斥。
    1、触发
    触发关系表示一个作业完毕后,生成另一个作业的控制文件,表示该作业可以进行了,一对一关系
    2、依赖
    一般作业跑批时,数据来自不同的表,为了能够保证各个表的时间的同步,需要通过依赖关系,当一个作业的依赖关系都完成了,则该作业可以进入调度队列中
    3、互斥
    不同作业操作相同的表,为了保证由于锁的原因导致作业失败,则设计了互斥作业。

    代理(agent)

    在各需要调度的服务器上需要安装一个agent,agent主要从调度中心获得指令执行服务器上作业,并将结果返回给调度中心,调度系统需要支持多种操作系统,本大数据平台采用的是yarn组件进行任务的分发,利用yarn的优良的资源的调度性,很好的解决了问题。

    大数据平台重点功能及批量设计

    (1)防重复启动

    这个主要是控制一个作业在执行市不能再次被执行,许多设计会设置互斥文件或变量来实现,但在作业各种异常(如网络中断)后,也需要有机制或功能清理互斥文件和变量,以免不能重做作业。通过文件进行控制,将任务成功的控制文件放入complete文件夹中,将错误的任务控制文件放到error文件夹中,

    (2)批量重跑

    许多调度工具可以支持单个作业重跑,但是数据类系统作业关联性较大,如果主数据区作业发现正常结束但是数据异常,修复后需要重新跑依赖该作业的中间层、集市的作业。因此在任一个作业节点可以批量重跑后续作业,避免手动单个作业按顺序重跑,这个功能会对问题处理带来很大的效率提升。比如下图的作业流图中,作业B1数据错误,批量重跑时会将后续依赖B1作业的C1、C2以及后续的D1、E1作业都进行重跑。
    在这里插入图片描述
    (3)对接预警系统和ETL系统

    对接预警系统主要是指将作业异常发送的统一预警系统进行通知,对接ETL系统主要是做好加载、抽取、数据转换作业、数据质量检查作业的调度和日志监控,因为调度系统也是数据仓库一个重要组成部分。大数据平台通过后端任务定时访问yarn的接口,通过接口的返回的数据了解任务执行情况,将错误的任务通过短信平台发送到手机上。

    (4)配置化导入和更新

    由于ETL等作业都是可以根据作业属性和数据库表信息自动生成调度作业,因此为了方便开发,可以将作业批量信息导入到调度系统,批量创建修改作业,避免手工增加修改作业。
    (5)监控可视化

    监控可视化主要是对批量作业流能清楚看到当前哪些作业已完成,执行中,待启动,也可以看到整个批量作业的依赖路径,更智能的话可以通过每天的作业执行情况,自动分析出关键路径。

    批量作业流设计优化

    (1)作业优先级设置

    通过合理设置作业优先级,提前完成批量作业路径中的关键作业,提高整体时效。对于为交易系统以及高时效的监管报送系统的数据批量作业,需要单独分批次并设立高优先级,以确保不受其它作业影响。

    另外作业依赖必须细化到作业级别,而不是依赖整个作业流或批次完成,即精细化管理,虽然复杂些,但能很大提高整体批处理的时效。

    (2)合理设置源系统作业的抽取时间

    由于源系统有些表依赖源系统的日终批处理完成,如内部总账,而有些表不需要依赖如客户信息、交易流水,可以在日切后分批次抽取源系统数据,将作业启动时间提前;

    (3)批量作业分析及优化

    定期如每周、每月对整个数据仓库批量作业进行汇总分析,重点关注源系统提供数据时间、作业时长超过30分钟的作业、作业时长增加比例最高的作业等,通过分析来确定优化作业并启动优化,一般可以通过重建表、优化SQL、重新分布表数据、增加资源等方式来优化作业,减少执行时间;

    (4)关键批量作业监控
    数据仓库中对于交易系统的数据加工往往会影响到银行对客户的服务,因此对关键作业和节点需要进行及时处理,如源系统数据提供时间、重点表的加工作业完成时间、高时效应用的数据提供作业完成时间都需要设置预警,报警时由值班人员及时处理。

    展开全文
  • 景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区指挥调度系统解决方案.pdf景区...
  • 复杂环境下AGVS调度系统设计.docx复杂环境下AGVS调度系统设计.docx复杂环境下AGVS调度系统设计.docx复杂环境下AGVS调度系统设计.docx复杂环境下AGVS调度系统设计.docx复杂环境下AGVS调度系统设计.docx复杂环境下AGVS...
  • 可视化应急指挥调度系统技术方案.docx可视化应急指挥调度系统技术方案.docx可视化应急指挥调度系统技术方案.docx可视化应急指挥调度系统技术方案.docx可视化应急指挥调度系统技术方案.docx可视化应急指挥调度系统...
  • 前面放完建设四个现代化大数据平台乌托邦理想的大卫星,接下来的文章得谈谈具体...本文重点谈理论,会先从大的场景划分的角度对市面上的各种调度系统进行分类讨论,然后再针对具体的作业调度系统,探讨一下各自的优缺点

    前面放完建设四个现代化大数据平台乌托邦理想的大卫星,接下来的文章得谈谈具体组件的生产大跃进了。



    第一篇,先来讨论一下大数据开发平台的核心组件之一:作业调度系统

    作业调度系统是一个相对复杂的系统,涉及的内容繁杂,针对的场景多种多样,实现的方案千差万别,是一个需要理论和实践并重的系统。

    本文重点谈理论,会先从大的场景划分的角度对市面上的各种调度系统进行分类讨论,然后再针对具体的作业调度系统,探讨一下各自的架构流派和实现方案,并简单分析一下各自的优缺点。希望能让大家对作业调度系统要做什么,该怎么做,有一个大致的了解

    那些调度系统们

    调度系统,更确切地说,作业调度系统(Job Scheduler)或者说工作流调度系统(workflow Scheduler)是任何一个稍微有点规模,不是简单玩玩的大数据开发平台都必不可少的重要组成部分。

    除了Crontab,Quartz这类偏单机的定时调度程序/库。开源的分布式作业调度系统也有很多,比较知名的比如:oozie,azkaban,chronos,zeus等等,此外,还有包括阿里的TBSchedule,SchedulerX,腾讯的Lhotse,当当的elastic-job,唯品会的Saturn等等

    可以说,几乎每家稍微有点规模的数据平台团队,都会有自己的调度系统实现方案,要不然自研,要不然在开源的基础上进行一些封装和改造(比如很多公司采取了封装oozie的方式)。

    在继续讨论作业调度系统之前,首先允许我讨论一下作业调度系统资源调度系统(或者集群调度系统)的区别,因为往往有同学把这两者混为一谈。后者的典型代表比如:Yarn/Mesos/Omega/Borg,还有阿里的伏羲,腾讯的盖娅(Gaia),百度的Normandy等等。

    资源调度系统,它的工作重点是底层物理资源的分配管理,目标是最大化的利用集群机器的CPU/磁盘/网络等硬件资源,所调配和处理的往往是与业务逻辑没有直接关联的通用的程序进程这样的对象。

    而作业调度系统,关注的首要重点是在正确的时间点启动正确的作业,确保作业按照正确的依赖关系及时准确的执行。资源的利用率通常不是第一关注要点,业务流程的正确性才是最重要的。

    作业调度系统有时也会考虑负载均衡问题,但保证负载均衡更多的是为了系统自身的健壮性,而资源的合理利用,作为一个可以优化的点,往往依托底层的资源调度系统来实现。

    那么,为什么市面上会存在这么多的作业调度系统项目,作业调度系统为什么没有像Hdfs/Hive/HBase之类的组件,形成一个相对标准化的解决方案呢?归根到底,还是由作业调度系统的业务复杂性决定的。

    一个成熟易用,便于管理和维护的作业调度系统,需要和大量的周边组件对接,不仅包括各种存储计算框架,还可要处理或使用到包括:血缘管理,权限控制,负载流控,监控报警,质量分析等各种服务或事务。这些事务环节,在每家公司往往都有自己的解决方案,所以作业调度系统所处的整体外部环境,千差万别,再加上各公司各种业务流程的定制化需求进一步加大了环境的差异性,所以,调度系统很难做到既能灵活通用的适配广大用户的各种需求,又不落到太过晦涩难用的地步。

    市面上的各种开源的作业调度系统,要不然就是在某些环节/功能上是缺失的,使用和运维的代价很高,需要大量二次开发;要不然就是只针对特定的业务场景,形态简单,缺乏灵活性;又或者在一些功能环节上是封闭自成体系的,很难和外部系统进行对接。

    那么,理想中,完备的作业调度系统,到底都要处理哪些事务呢?要做好这些事务都有哪些困难要克服,有哪些方案可以选择,市面上的开源调度系统项目又是如何应对这些问题的,容我和大家一起来探讨一下。

    两大类作业调度系统

    首先,让我来对作业调度系统进行一下大的分类。市面上的作业调度系统,根据实际的功能定位,主要分为两大类方向:定时分片类作业调度系统和DAG工作流类作业调度系统

    这两类系统的架构和功能实现通常存在很大的差异。所以下文先做一下两者的简单的比较。

    定时分片类作业调度系统



    定时分片类系统的方向,重点定位于任务的分片执行场景,这类系统的代表包括:TBSchedule,SchedulerX,Elastic-job, Saturn。我司自研的Vacuum也是这样的系统。

    这种功能定位的作业调度系统,其最早的需要来源和出发点往往是做一个分布式的Crontab/Quartz。

    一开始各个业务方八仙过海,自己玩自己的单机定时任务,然后,随着业务的增长,各种定时任务越来越多,分散管理的代价越来越高。再加上有些业务随着数据量的增长,为了提高运行效率,也需要以分布式的方式在多台机器上并发执行。这时候,分布式分片调度系统也就孕育而生了。

    这类系统的实际应用场景,往往和日常维护工作或需要定时执行的业务逻辑有一定关联。比如需要定时批量清理一批机器的磁盘空间,需要定时生成一批商品清单,需要定时批量对一批数据建索引,需要定时对一批用户发送推送通知等等。

    这类系统的核心目标基本上就是两点:

    • 对作业分片逻辑的支持:将一个大的任务拆成多个小任务分配到不同的服务器上执行, 难点在于要做到不漏,不重,保证负载平衡,节点崩溃时自动进行任务迁移等

    • 高可用的精确定时触发要求:因为往往涉及到实际业务流程的及时性和准确性,所以通常需要保证任务触发的强实时和可靠性


    所以,负载均衡,弹性扩容,状态同步和失效转移通常是这类调度系统在架构设计时重点考虑的特性

    从接入方案和流程上来说,因为要支持分片逻辑,要支持失效转移等,这类调度系统,对所调度的任务通常都是有侵入性要求的。

    常见的做法是用户作业需要依赖相关分片调度系统的客户端库函数,拓展一个作业调度类做为作业触发的入口点。一般还需要接收和处理分片信息用于对数据进行正确的分片处理。此外通常还需要实现一些接口用于满足服务端的管理需求,比如注册节点,注册作业,启动任务,停止任务,汇报状态等等。有些系统还要求作业执行节点常驻Daemon进程,用于协调本地作业的管理和通讯。

    从触发实现逻辑的角度来说,为了在海量任务的情况下,保证严格精确定时触发,这类调度系统有一大半,其定时触发逻辑,实际上是由执行节点自身在本地触发的,也就是说要求作业或守护进程处于运行状态,向服务端注册作业,服务端分配分片信息和定时逻辑给到客户端,但定时的触发,是由客户端库函数封装的如Quartz等定时逻辑来实际执行触发的。

    这样做的首要目的当然是为了保证触发的精度和效率,降低服务端负载,此外如果服务端短时间内挂掉,只要作业配置保持不变,作业还是能够在客户端正常触发的。

    也有些系统,比如SchedulerX,是采用服务端触发逻辑的。这对服务端的要求就高了很多,因为这时候,服务端不光要协调分片逻辑,还要维护触发队列。所以服务端触发的系统,首先需要保证服务端的高可用,其次还要保障性能,因此,通常都是采用集群方案

    DAG工作流类调度系统



    这一类系统的方向,重点定位于任务的调度依赖关系的正确处理,分片执行的逻辑通常不是系统关注的核心,或者不是系统核心流程的关键组成部分,如果某些任务真的关注分片逻辑,往往交给后端集群(比如MR任务自带分片能力)或者具体类型的任务执行后端去实现。

    这类系统的代表,包括:oozie,azkaban,chronos,zeus,Lhotse,还有各种大大小小的公有云服务提供的那些可视化工作流定义系统。我司自研的Jarvis调度系统也属于这类系统

    DAG工作流类调度系统所服务的往往是作业繁多,作业之间的流程依赖比较复杂的场景,比如大数据开发平台的离线数仓报表处理业务,从数据采集,清洗,到各个层级的报表的汇总运算,到最后数据导出到外部业务系统,一个完整的业务流程,可能涉及到成百上千个相互交叉依赖关联的作业。

    所以DAG工作流类调度系统关注的重点,通常会包括:

    足够丰富和灵活的依赖触发机制:比如时间触发任务,依赖触发任务,混合触发任务


    • 而依赖触发自身,可能还要考虑,多亲依赖,长短周期依赖(比如小时任务依赖天任务,或者反过来),依赖范围判定(比如所依赖任务最后一次成功就可以触发下游,还是过去一个星期的所有任务都成功才可以触发下游),自身历史任务依赖,串并行触发机制等等


    作业的计划,变更和执行流水的管理和同步


    • 这一条,定时分片类调度系统固然也要考虑,但通常都相对简单。

    • 而在DAG工作流类调度系统中,因为任务触发机制的灵活性和作业依赖关系的复杂性,这个需求就尤为重要,需要提供的功能更加复杂,具体的问题解决起来也困难很多。


    任务的优先级管理,业务隔离,权限管理等


    • 在定时分片类调度系统中,通常情况下,具体执行端的业务的隔离很多情况下是天然的,注册了特定业务的节点才会去执行特定的任务。然后,加上业务链路一般都比较短,以及强实时性要求,所以对优先级的管理通常要求也不高,基本靠资源隔离来实现资源的可用,不太存在竞争资源的问题,权限管理也同理。

    • 而在DAG工作流类调度系统中,往往一大批作业共享资源执行,所以优先级,负载隔离,和权限管控的问题也就突显出来


    各种特殊流程的处理,比如暂停任务,重刷历史数据,人工标注失败/成功,临时任务和周期任务的协同等等


    • 这类需求,本质上也是因为业务流程的复杂性带来的,比如业务逻辑变更啦,脚本写错啦,上游数据有问题啦,下游系统挂掉啦等等,而业务之间的网状关联性,导致处理问题时需要考虑的因素很多,也就要求处理的手段要足够灵活强大


    完备的监控报警通知机制


    • 最简单的比如,任务失败报警,超时报警,再进一步,流量负载监控,业务进度监控和预测,如果做的再完善一点,还可以包括业务健康度监控分析,性能优化建议和问题诊断专家系统等



    小结

    需要注意的是,这两类系统的定位目标,并不是绝对冲突矛盾的。只不过,要同时圆满的支持这两大类需求,从实现的角度来说是很困难的,因为侧重点的不同,在架构上多少会对某些方面做些取舍,当前的系统都没有能够做到完美的两者兼顾。但这不代表他们就一定是不可调和的,好比离线批处理计算框架和流式实时计算框架,长期以来各行其路,但是,随着理论,实践的进步,也开始有依托一种框架统一处理两类计算业务的可能性出现。

    DAG工作流调度系统的两种心法流派



    前面说到,DAG工作流调度系统有很多开源实现,各大公司也往往有自己的系统实现。这些系统,从开发语言,支持的任务类型,调度方式,监控报警,到业务接入的方式,周边管理工具的完备性等角度来说,都是千差万别的。这些差别在很大程度上都是产品形态招式上的差异,但是有一条,不止招式那么简单,我认为是心法流派的差异,它在很大程度上影响了一个系统的核心框架设计思想。

    这个差异就是:具体任务的执行,是依托于一个静态的执行列表还是动态的执行列表,此话怎讲?别急,待我详细解释一下。

    两个概念 : 作业计划(Job Plan)和任务实例(Task Instance)

    要谈执行列表的心法流派问题,首先,得明确作业计划和任务实例两个概念

    通常情况下,既然你把一个作业丢到调度系统上去监管执行,那除了个别一次性作业,多数情况下这些作业都是要周期性重复执行的,只是有些纯粹由时间驱动,有些还有前置任务依赖关系要处理。

    那么什么时候执行这个作业,是每个月月底执行一次,还是每天凌晨2点执行一次,又或者还是早上9点到晚上6点之间,每个小时执行一次?任务触发的条件,是前置任务全部成功,还是任一前置任务成功,又或者要求自身的上一次执行结果也要成功? 回答这些问题的,就是所谓的作业计划(Plan)

    而具体落到某年某月某天,一个作业什么时候真正执行一次?这一次具体的执行,就是所谓的任务执行实例(Instance)

    静态执行列表 v.s. 动态执行列表

    回头继续讨论,所谓的静态执行列表流派,是说一个作业的具体执行实例,是跟据作业计划提前计算并生成执行列表的,然后调度系统按照这个提前生成的执行列表去执行任务。 更进一步,有些系统实际上压根就没有区分作业计划和任务执行列表,两者是和二为一的,人工定义一个确定了依赖和先后关系任务列表,定期执行这整个列表。

    对于实际有作业计划和执行列表之分的系统,常见的做法是在头一天晚上接近凌晨的时候,分析所有作业的时间要求和作业间的依赖关系,然后生成下一天所有需要执行的作业的实例列表,将具体每个任务实例的执行时间点和相互依赖关系固化下来。调度系统执行任务时,遍历检查这个列表,触发满足条件的任务的执行。

    oozie,azkaban和大多数公有云上的workflow服务,和我司的第一代Jarvis调度系统,基本上都是属于这个流派。其中oozie,azkaban基本采用的是作业计划和执行列表一体的方案,我司的Jarvis一代采用的是两者分离,由作业计划定期生成执行列表的方案。

    然后,所谓的动态执行列表流派,是说某个作业的具体执行实例,并没有提前固化计算出来,而是在它的上游任务(纯时间周期任务的话就是上个周期的任务)执行完毕时,根据当时时刻点最新的作业计划和依赖关系动态计算出来的。

    zeus,chronos和我司的第二代Jarvis调度系统,基本上是属于这个流派的。

    这两个流派没有绝对的优劣之分,各有优缺点,各有自己擅长处理的场景和不擅长处理的场景,所以有时候系统的具体实现也不完是绝对互斥的,在某些功能方面也是有变化取舍的。

    那么,为什么会有两种流派?提前生成执行列表还是需要的时候再生成,又有什么关系吗?两种流派各自的主要问题和难点是什么?

    罪恶之源



    之所以会有两种流派,问题的源头在于,作业计划和执行实例列表,这两者服务的对象不同。

    从周期性作业管理的角度来说,你面向的对象当然应该是作业计划,当你想改变一个周期性作业的执行策略时,你修改的是作业的执行计划本身。而做为调度系统,在具体任务的执行过程中,它面向的对象则是任务的一次执行实例,而非计划本身。

    所以当计划产生变更时,就涉及到作业计划和执行列表之间的同步问题。

    对于静态执行列表流派来说,处理确定的任务执行列表是它的长项,因为执行列表一旦生成,那你就可以对它进行任意的修改,可以进行各种Hack,不再需要考虑原有的作业计划依赖关系等等。比如你今天想临时跳过一部分任务的执行,直接把它们从实例列表中删除,并从下游任务的依赖列表中移除依赖关系就好。

    而对于动态执行列表流派来说,这种临时的Hack动作就会比较难处理,因为计划和实例是根据规则强关联的。要影相今天的任务实例,可能就要修改作业的计划,而修改了计划,后续比如明天的任务实例也可能会受到影响。

    但是,对于执行实例或者具体实例的依赖关系难以提前确定和生成的场景,比如不等周期的依赖(比如月底的月任务依赖于每天的日任务)或者任意成功条件即可触发,触发实例个数不确定的情况,就几乎无法提前生成静态的执行列表克。

    再比如在一些短周期任务计划变更,或者任务依赖关系调整,任务列表已经有部分任务执行完毕的情况下,静态执行列表方案能否快速,正确的更新执行列表, 都会遇到很大的挑战。

    再比如,一天的所有任务中,有些任务的修改是临时的,有些任务的修改是长期的,这种情况下,静态执行列表的方案因该如何应对呢? 对于计划和执行列表一体的系统,几乎是没法做的,只能再复制生成一份临时执行列表,却别对待。而对于从计划列表定时生成执行列表的系统,则势必需要部分修改已实例化的任务执行列表,部分修改未实例化的作业计划,在这种模式下,如何保证两边的修改不冲突,如果冲突,以谁为主,甚至能否发现冲突,往往都是很困难的。

    小结

    所以,简单总结来说,静态执行列表方案,擅长处理时间范围确定的(最好是当前周期的),已知的,一次性的任务变更,前提是你对如何Hack执行列表有清楚的认识。动态执行列表方案擅长处理尚未发生的,长期的计划变更,对于不等周期和短周期任务的变更时效性也会好很多,临时的一次性变更则需要通过其它方式来辅助完成。

    当然,这两种流派针对自己不擅长的场景,多少也能找到各种的补救手段来应对,并非完全一筹莫展,只是补救手段的复杂程度和代价大小的问题。

    这两种流派,我们都实践过,总体看来,静态执行列表方案,系统架构相对简单,系统运行逻辑相对直白,容易分析问题,但是能处理的场景也比较有限。动态执行列表方案,能覆盖的场景范围更广,计划变更响应更及时,但是系统架构实现相对复杂,运行逻辑也更加复杂,牵扯的因素较多,有时候不容易一眼理顺逻辑。

    所以,如果是在业务场景比较简单,任务依赖容易理清的场景下,静态执行列表方案的系统维护代价会比较小,反之,则应该考虑构建动态执行列表方案的系统。

    最后,这两种方案也并非完全互斥,我司的jarvis二代调度系统,就在一些局部功能中使用了静态执行列表的思想,来辅助处理一些动态执行列表方案比较难应对的问题。比如,用户需要知道今天有哪些任务将要执行,什么时候执行,这就会需要一个实例化的执行列表,总不能跟用户说我们的任务是动态实例化的,所以还没有执行的任务无法展示吧 :)

    工作流调度系统功能特性和需求分析




    谈完心法再来谈谈招式,不论流派如何,最后落实到系统实现,从系统的角度,需要考虑具备哪些特性,可以提高稳定性,降低管理维护成本,从用户的角度,关心的则是能够提供哪些功能,可以提高工作效率,降低开发使用成本。

    工作流的定义方式

    既然是工作流调度系统,用户首先要面对的问题,当然是如何定义和管理工作流。

    静态显式定义和管理工作流

    多数静态执行列表流派的系统,比如oozie,azkaban以及各种公有云的workflow服务,都会包含创建工作流Flow这样一个过程,用户需要定义一个具体的作业流程里面都包含哪些作业,他们的先后依赖关系如何。所不同的是,用户通过什么手段来定义和描述这个工作流:

    比如oozie要求用户提供XML文件(也可以通过API提交),按照规定的格式描述各个工作流的拓扑逻辑和Job的依赖关系,各种任务类型的细节配置等等。

    Azkaban要求用户定义.job文件来描述作业的依赖关系,然后为每个没有依赖关系的作业及其下游作业创建一个工作流,如果要嵌套子工作流,则需要显式的申明和创建。然后将所有的.job文件和作业执行需要的依赖打包成zip包通过服务器上传,最终在服务器上创建出工作流并展示给用户。

    oozie和Azkaban采取的这两种方式,从系统设计的角度来说,对外部系统的关联和依赖比较小,是一个相对独立封闭的环境,演进起来比较自由。但这两个系统最大的问题是,周边的运维使用工具太过缺乏,易用性很差。作为工具使用可以,但是做为平台服务,缺失了太多内容,工作流的定义和维护成本太高。所以有很多公司是在oozie和Azkaban的基础上对工作流的提交管理进行了二次开发封装,来降低使用难度。

    而各种公有云的workflow服务,则多半是通过图形化拖拽作业节点的方式,来让用户显式的定义工作流,本质上和oozie的方式没有太大区别,只是通过可视化的操作来屏蔽配置的语法细节,降低工作流定义的难度。

    动态隐式定义和管理工作流

    Chronos,Zeus和我司的两代Jarvis调度系统,走的则是另一条路。系统中并没有让用户显式的定义一个工作流。实际上,这些系统的管理维度是作业,用户定义的是作业之间的依赖关系,哪些作业构成一个工作流,系统实际上并不关心,用户也不需要申明,系统只负责按规则将所有满足条件的任务调度起来,将一批任务圈定成一个Flow这种行为,对系统来说并非必需。你甚至可以理解为整个系统里的所有作业就是一个多进多出并发执行的大Flow。

    对比

    你要问那比如权限隔离,调度配置这些,没有了Flow的概念怎么处理? 事实上,这些概念和一组任务的执行链路这个概念压根就没有必然的关系。Flow关注的是的依赖关系,其它上面提到的那些概念关注的是资源的管控,这两者涉及的对象可以重叠,但是并非一定要重叠,有些时候也不适合重叠。

    那两种处理方式各有什么优缺点呢?

    显式定义工作流Flow这种方式,优点是用户明确的知道哪些任务是一组的,适合处理工作流内作业规模较小,工作流之间的作业没有交叉依赖,不会频繁变更的场景,用户的掌控感可能较强,但是反之,作业规模大,关联复杂,变更频繁的场景实际上是不太适合的,另外对依赖和触发逻辑的支持,局限性也较大(下一节详解)

    而不显式定义工作流的方式,用户无需理会和手工定义和处理工作流这个概念,使用灵活,作业之间依赖变更,业务调整等行为,都会自动反映到整体的任务执行流程中,对于用户而言,管理的压力较小,作业流程变更操作简单。相对不足的地方是作业的分组这个概念没有Flow来承接,资源的管理需要通过其它方式来实现。

    作业运行周期的管理

    显式静态定义工作流的系统,对作业运行周期的管理,通常都是以整个工作流为单位来定义和管理的。当调度时间到达时,启动整个工作流,工作流内部的作业按照依赖关系依次执行。所以如果一个工作流内部存在需要按不同周期进行调度的作业,就会很难处理,需要想各种补救手段去间接规避,比如拆分工作流,创建子工作流,或者复制多份作业等。

    非显式动态定义工作流的系统,对作业运行周期的管理,通常是以单个作业为单位的(因为压根就没有固定的Flow这个单位可以管理 ),所以用户只需要按需定义自己作业的运行周期就好了。相对的,对调度系统开发者来说,实现的难度会比较大,因为正确的自动判定依赖触发关系的逻辑会比较复杂。

    作业依赖关系的管理



    在开始讨论依赖管理之前,我们先来看看通常用做判断一个作业的具体任务实例是否可以开始运行的条件都有哪些?

    首先当然是时间依赖,大量的定时触发任务,依托时间来判断是否满足运行条件。其次是任务依赖,需要根据前置任务的执行情况,来决定当前任务是否满足运行条件。

    通常情况下,这两种依赖条件构成了大多数调度系统启动任务运行的核心判定依据。但是有时候还有第三种依赖条件,就是数据依赖,通过判断任务运行所依托的数据是否存在来决定是否启动任务。

    理论上,如果所有生成数据的任务的运行状态和结果都能被调度系统所控制或者感知,那么数据依赖这种依赖关系就是一个伪命题,既非必要,往往也不是最佳解决方案。

    为什么这么说?因为数据依赖意味着对调度系统而言,业务逻辑不再是透明的,一方面,你需要知道获取数据信息的途径,另一方面,如何判定一个任务依赖的数据是否完备了,本身也不是一件容易的事,容错性往往也不好。

    比如你通过文件是否存在来判断,那么文件里的内容是错的呢?或者生成文件的任务跑了一半失败了,文件内容不完整呢?即使你能保证文件的正确性和原子性,那么如果上游任务重跑刷新了数据呢?你如何判定这种情况?

    总体来说,个人认为,一个调度系统,如果对数据依赖这种依赖关系依托得越多,那么相对来说整个系统就越不成熟和完备,需要人工干涉的可能性越高。当然,事事无绝对,也有一些使用数据依赖才是最合理有效的解决方案的场景。而且,退一步说,调度系统再完善,也是一个有边界的系统,总难免一些依赖要通过外部数据的判定来实现。

    回头继续讨论作业依赖关系的管理

    对于采用人工显式定义工作流的系统而言,作业依赖的管理,在很大程度上,其实是通过对工作流的拓扑逻辑的管理来实现的,用户改变工作流的拓扑逻辑的过程,实际上也就改变了作业间的依赖关系。 而作业的任务依赖关系,其边界,基本上就是在当前的工作流范围之类。

    对于非显式定义工作流的系统而言,用户直接管理作业的依赖,所以这类系统一般都会提供给用户配置上游任务和触发条件的接口/界面。用户通过改变作业之间的依赖关系,间接的影响相关联作业的运行流程拓扑逻辑

    所以,你要问,这两种定义和管理作业依赖的方式,看起来只是角度不同而已,换汤不换药,采用那种,只是流程的需要,实际效果没有什么区别吧?实际上,并不完全如此,比如,从用户的角度来说:

    前面一种管理方式,需要用户对工作流内部的作业比较了解,对当前的工作流拓扑逻辑也足够清晰,才能较好的保证将新的作业安排放置到正确的位置上去。但只要满足依赖,作业节点的安排位置也可以比较自由。

    举个简单的例子,比如BC两个作业分别依赖作业A,其它没有相互依赖关系。那么,我可以把BC作业并行的放在A作业后面,也可以为了控制资源使用,让BC作业串联的放置在A后面(相当于人工将作业C改为依赖作业B)。

    而后面一种管理方式,用户只需要关心当前任务的前置任务有哪些就可以了,因此对用户的要求降低了不少。不过这样一来拓扑逻辑图是唯一且自动生成的(上例ABC作业,就只能是BC作业并行放在A作业后面),缺点是你无法自由调整工作流程,但实际上你多半也没有调整的必要。如果是为了控制作业优先级,大可通过其它方式实现

    后者还有一个很大的优势,就是如果你的任务的依赖关系可以自动分析出来的话(比如hive任务,可以通过解析脚本,自动判断上下游数据表,然后再通过数据表关联自动找到上下游任务),那么多数情况下,用户甚至都可以不用配置作业依赖关系,直接添加具体作业就完事了,工作流的拓扑关系全部交给系统自动分析,添加和调整。比如,我司的Jarvis调度系统,结合Hive元数据血缘分析工具,就基本上达到了这样的效果 ;)

    最后,用户显式定义工作流这种模式,对跨工作流的任务依赖也很难处理,原本在一个工作流内部可以通过任务依赖来实现的控制,在跨工作流以后,通常就只能通过数据依赖的手段来辅助实现了,但如前所述,这么做的话,一来用户可能需要定制数据依赖检测逻辑,二来在遇到数据重跑之类的场景,任务的正确执行就需要进一步的人工干预处理了。

    作业异常管理和系统监控



    常在河边走,哪有不湿鞋,运行作业多了,总会出问题。所以对用户来说,作业异常流程管理能力的好坏,也是工作流调度系统是否好用的一个重要考虑因素。

    比如,如果一个中间任务的脚本逻辑有错,需要重跑自身及后续下游任务,该如何处理?用户通过什么样的方式完成这件工作?需要手工重新创建一个新的工作流?还是可以通过勾选作业,自动寻找下游任务的方式实现?

    比如一个任务运行失败,但是结果数据通过其它手段进行了修复,那么如何跳过该任务继续运行后续任务?

    再比如,任务失败是否能够自动重试?重试有什么前提条件,需要做什么预处理,任务失败应该报警,向谁报警?以什么方式报警?什么情况下停止报警?任务运行得慢要不要报警? 怎么知道比以前慢?多慢该报警?不同的任务能否区别对待?等等

    所有这些方面都决定了用户的实际体验和系统的好用/易用程度,同时,对系统的整体流程框架设计也可能会带来一些影响。

    开源的工作流调度系统在这些方面做得通常都相对简单,这也是很多公司二次开发改造的重点方向。

    资源和权限控制



    有人的地方就有江湖。任务多了,势必就需要进行资源和权限管控。

    最直接的问题就是,如果有很多任务都满足运行条件,资源有限的情况下,先跑哪个?任务优先级如何定义和管理?

    再退一步,你怎么知道哪些资源到了瓶颈?如果调度系统管理执行的任务类型很多,任务也可以在不同的机器或集群上运行,你如何判定哪些任务需要多少资源?哪些机器或集群资源不足?能否按照不同的条件区别管理,分类控制并发度或优先级?

    最后,谁能编辑,运行,管理一个任务?用户角色怎么定义?和周边系统,比如Hadoop/Hive系统的权限管理体系如何对接配合?

    这些方面的内容,多数的开源的工作流调度系统也做得并不完善,或者说很难做到通用,因为很多功能需要和周边系统深度配合才可能完成。

    系统运维能力

    系统的运维能力:包括是否有系统自身状态指标的监控,是否有业务操作日志,执行流水等便于分析排查问题,系统维护,升级,上下线,能否快速完成,系统是否具备灰度更新能力等等。

    总结

    工作流调度系统做为大数据开发平台的核心组件,牵扯的周边系统众多,自身的业务逻辑也很复杂,根据目标定位的不同,场景复杂度和侧重点的不同,市面上存在众多的开源方案。

    但也正因为它的重要性和业务环境的高度复杂性,多数有开发能力的公司,还是会二次开发或者自研一套甚至多套系统来支撑自身的业务需求,我司也不例外。关于我司Jarvis调度系统的架构实现,功能设定和产品方案,后续再另写一篇文章详细阐述。


    常按扫描下面的二维码,关注“大数据务虚杂谈”,务虚,我是认真的 ;)

    展开全文
  • 集群资源管理与任务调度系统综述

    千次阅读 2019-05-03 23:49:49
    0. 集群资源管理与任务调度系统出现的背景 (1)出现背景 信息技术快速发展,各行各业都慢慢于互联网进行深度融合,即所谓的“互联网+”。为了提供更好的服务以吸引更多的消费者进行更多维度的消费,各个互联网公司...
  • MCS多媒体调度系统介绍.pdfMCS多媒体调度系统介绍.pdfMCS多媒体调度系统介绍.pdfMCS多媒体调度系统介绍.pdfMCS多媒体调度系统介绍.pdf
  • 伴随着全球经济繁荣发展,预防和处置重大突发性紧急事件的应急救灾,安全防御反恐等公共安全系统设施建设,已经...应急指挥调度管理系统|城市公共安全应急指挥系统 BF-9300 BTX创建型警用(PDT)集群系统是基于IP网络...
  • 数据平台作业调度系统详解-实践篇

    万次阅读 多人点赞 2017-07-25 09:34:19
    上一篇文章,讨论了作业调度系统的分类,流派,架构实现方案和各种方案的优缺点以及适用场景,最后还简单总结了理想中,一个完备的工作流作业调度系统,应该具备哪些功能特性。但是,纸上得来终觉浅,绝知此事要躬行...
  • 研制了包括中央调度系统、卡车车位监测系统、智能化卡车工况监测系统、通讯系统的硬件系统和调度优化决策软件系统在内的露天矿卡车自动化实时调度系统,采用专家系统方法建立了调度决策模拟,使中央调度系统能及时...
  • 阿里云分布式调度系统-伏羲

    千次阅读 2019-05-04 18:19:38
    最近在做一个类似的东西,看...下文作者:陶阳宇,花名举水,阿里云高级技术专家,飞天分布式系统早期核心开发人员,开发和优化过伏羲系统中多个功能模块,参加了飞天5K、世界排序大赛等多个技术攻坚项目。在分布式...
  • agv车辆调度系统-技术篇

    千次阅读 2021-09-18 16:53:53
    交通管制:调度系统核心算法第一篇-交通管制 请看这篇文章 避碰算法:Agv、Rgv 车辆控制调度系统开发第二篇 请看这篇文章 解锁算法:蚁群算法+递归算法 非核心算法 选车:贪心算法+Manhattan Distance 移车:递归算法...
  • 车载融合通信调度系统介绍

    万次阅读 2021-01-14 10:16:29
    车载融合通信调度系统是由车载调度服务器(包含融合通信模块和视频接入模块)、对讲接入网关、语音网关、车载调度台软件、IP话机终端、视频会议终端、车载监控主机及配套的云台监控、音频矩阵、多信道接收机、高清...
  • 滴滴司机调度系统实践

    千次阅读 2020-07-16 23:04:41
    桔妹导读:如何解决供需不平衡问题呢?一个自然的想法就是调度空闲的在线司机到需求较多的区域。滴滴网约车团队近期发表在万维网大会WWW 2020 Research Track的Oral长文《...
  • slurm作业调度系统

    千次阅读 2020-04-20 21:51:59
    PBS作业调度系统于SLURM调度系统比较。 配置服务器运行环境 查看当前所载入的所有module,可以使用下面的命令: module list 想要查看服务器中所有可用的module,可以使用如下的命令。 module avail 执行完毕后,...
  • 导语:在前面我们讲过了阿里云分布式任务调度平台,今天我们从架构和技术实现上来为大家讲解腾讯云分布式任务调度系统TCT(Tencent CloudTask)如何实现任务调度的精准实时、稳定高效,以及任务的切分和编排。...
  • 调度系统的几个核心功能

    千次阅读 2021-02-21 09:46:40
    调度系统是什么 先从调度说起,调度就是为每件事情,合理的安排时间。具体得说就是在合理的时间开始,耗费合理的时间完成。举个例子: 11:00~12:00 在这期间把销售数据跑出来。 13:00~14:00 在这期间把拉新的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 684,490
精华内容 273,796
关键字:

调度系统