IDE大数据离线任务调度系统就是设计目标2.1用户交互的产品功能
1.背景
在数据库房的构建过程中，核心技术是抽取、转换、装载（ETL），它为数据库房提供及时、高质而精确的数据。因为ETL包括诸多的处理任务，且此类任务之间有一定的约束关系，怎么高效的调度和管理这种任务是数据库房ETL推行中特别重要的工作，只是增加数据库房开发效率和资源运用率的关键。
在大数据平台，随着业务发展，每次承载着成千上万的ETL任务调度，这种任务的型态各类各样。如何样让大量的ETL任务精确的完成调度而不出现问题，并且在任务调度执行中出现错误的状况下，任务才能完成自我恢复并且执行错误信令与完整的日志查询。IDE大数据离线任务调度系统就是在这些背景下衍生的一款分布式调度系统。
在探讨IDE平台之前，首先讨论一下作业调度系统和资源调度系统的差别，由于常常有老师把这三者混为一谈。资源调度系统的典型代表例如：Yarn／Mesos／Omega／Borg，也有阿里的伏羲，腾讯的盖娅（Gaia），百度的诺曼底()等等。我们现在的内容主要述说的是作业调度系统。不过，IDE不仅完成了大数据的任务各式复杂调度外，还包含了任务开发、依赖组织、状态维护、任务监控、任务整治、服务监控、动态扩缩容等众多内容。
2.设计目标
2.1用户交互的产品功能
从用户交互的产品功能上看，主要包括以下几点：
具体的用户产品功能如图1所示：
(图1：用户产品功能清单)
2.2后台调度功能
从后台调度系统自身逻辑看，主要包括以下几点：
具体的调度模块功能如图2所示：
(图2：调度模块的功能清单)
2.3任务执行器功能
从任务执行器方面看，主要包括以下几点：
具体的任务执行器功能如图3所示：
(图3：任务执行器功能清单)
2.4任务维保功能
从任务维保视角看，主要包括以下几点：
平台维保能力如图4所示：
(图4：平台维保能力)
2.5平台对外功能
从平台对外的能力输出方面，主要包括以下几点：
平台的对外服务能力如图5所示：
(图5：平台对外服务能力)
3.平台价值
现在国美八大产业聚首并发，数据爆发下降，借助大数据平台打通各产业数据，服务智慧零售。在整个智慧零售中和大数据开发战略中，ETL是BI（商业智能）的基础，数据调度是ETL的心灵。
使用该平台才能对企业中批量运行作业进行集中管理，并通过强悍的调度引擎功能实现作业的逻辑运行，并提供直观具体的监控方式，辅助维保工作。平台为系统的开发与维保提供以下价值：
解放人力，增加工作效率。
通过使用平台对大数据作业进行手动化管理和监视。当系统出现异常的状况时，以电邮、短信等多种形式通告相应的管理员进行人工参与，大大降低了现有管理员的工作压力，增强了IT系统的管理效率。
灵活的配置及信令体系。
运用平台提供的灵活配置功能和加强的信令处理模式，大大避开了由于故障处理不及时而带给的损失。
强悍的权限管理。
将各类运行操作权限合理的分配给作业及操作人员，进行权限限定的批量作业设置、运行和监视，使核心权限得到有效保护。
全面的作业运行情况剖析。
通过手动采集作业运行情况、时间，剖析故障分布、作业运行时长等业务运行指标，整体掌握系统运行健康度。
4.平台建设
IDE平台致力为用户提供从数据源申请、任务争创、任务调度编排、任务维保、任务信令、运行剖析等一站式大数据开发平台，帮助企业迅速完全数据中台搭建。
IDE大数据开发平台在构架上分为任务管理平台、任务调度、任务执行、任务监控、和API服务五部份。平台选用了先进的技术构架，具备很强的跨平台性。布署简便，维护简略，容易使用。支持分步式的多机集群，能承载大规模数据的高负荷运行，具备良好的稳定性。平台选用了单层构架，结构清晰，具备良好的扩充性、稳定性和容错性。
平台整体构架如图6所示。
(图6：平台构架设计)
接下去，我们重点解读部份设计实现细节和相关实践经验。
4.1用户功能实现说明
用户交互的产品功能，重视图形化可视化，易操作易维护。
让用户才能尽或许的自助服务，同时减少操作代价，提高错事的或许性。支持当天任务计划和执行历史的查询，支持周期作业信息的检索，包括作业概况，历史运行流水，运行日志，变更记录，依赖关系、任务运行明细查询等。这部份功能的目的，是为了让系统格外透明，让业务愈发可控，让清查和剖析问题愈发容易。尽或许的让一切作业任务信息和变更记录都有源可查，做到任务操作都可以追踪和追溯。
(图7：任务开发主页面)
(图8：任务流设计画笔)
(图9：任务节点依赖关系编排)
(图10：任务可视化配置页面)
(图11：任务维保管理页面)
(图12：任务流画笔上的维保操作)
(图13：任务信令类别)
(图14：任务信令配置页面)
(图15：任务执行依赖剖析)
4.2调度周期设计说明
准实时调度，支持周期性任务（分钟、小时、天、周、月），作业计划的变更。
何谓准时实调度，首先指的是平台会根据各个上线的任务流的调度时间生成调度执行计划，当触发时间到了，平台会根据调度执行计划准确的生成任务流例子和任务例子。并且在任务执行上，并不保证准实时的分配机器执行。实际上平台以整体资源使用状况为最高原则，并根据一定的限流策略控制任务的执行，例如：任务优先级、任务组并发度、平台任务并发数、任务特定执行时间等诱因。在保证平台资源容许的状况下，尽量按量执行任务。为了保障任务的实时性，应当保障任务资源的可用性和计划可控性。
作业计划的变更容许用户调整自己上线的任务流执行计划。例如天任务调整为小时任务，调度开始时间从1点开始调整为2点开始。假如对上线早已生成任务例子的任务流进行调整，应当下线后再调整，此刻会提示用户杀害当前的任务，于是完成计划调整。假如上线的任务流还未到触发时间，没有生成任务例子，用户可以及时修正，并对任务执行无影响。
图16是平台的任务流速率支持的类别。
(图16：任务流调度速率类别)
4.3调度策略设计说明
灵活的调度策略，触发模式还要支持：时间触发，依赖触发或则混和触发，支持多种依赖关系等。
首先，在一些复杂的业务场景里，存在跨流任务依赖调度，不同的任务流的速率和时间周期不一致，例如天依赖小时、周依赖隆安。
再者，针对不同优先级的任务，在资源运用高峰和任务执行高峰时段，可以适当调整中低优先级的任务的执行时间窗口，防止低优先级的任务和高优先级的任务进行资源占据，错峰执行，减少资源运用率和均衡性。
在解决跨流依赖方面，平台现在仅支持大速率依赖小速率，例如：天依赖小时、周依赖天、月依赖天，以及同频依赖，例如：小时依赖小时、天依赖天、周依赖周、月依赖月。平台在设计之初限制了一个任务只好属于一个任务流，不容许任务跨流存在，怎么解决跨流依赖的问题呢？我们建议用户对任务争创任务风波，可以理解成任务的一个执行副本。这个丑闻是容许跨流存在的。假如一个任务流还要依赖另外一个任务流的的某个任务，只要依赖这个任务的丑闻即可，通过风波我们将任务流进行串联上去。如图17所示。
(图17：任务风波依赖)
在解决跨系统之间的依赖问题，我们提供了FTP风波，即在FTP服务器上构建标志文件，一个丑闻对应一个标志文件地址，当FTP服务器上的标志文件生成的时侯，我们觉得业务系统早已完成作业，还要触发平台任务执行。
由于FTP风波存在实时性和稳定性的问题，即调度服务是不停的线程各个FTP风波服务器，当FTP服务器负荷较重，常常会连结超时，造成扫描文件标志推迟，从而引发下游任务推迟，我们对用户系统了API丑闻，即业务系统作业完成后可以读取平台的API插口，触发下游任务执行，解决了时效性和稳定性的问题。
(图18：风波列表)
4.4调度流控设计说明
做很多住户隔离，执行器资源隔离、内建流控，负载均衡和作业优先级等制度。
大多数的工作流调度系统，多住户的隔离比较简略，业务上房客之间完全独立，住户之间的业务很难互相关联。同一住户的工作流方面也不能相互依赖和关联。更多的考虑是地理资源层面的隔离，这个，多半通过独立集群或则虚拟化的方案来解决，同一住户内部，做得好的或许再考虑一下业务队列管理。
我司的业务环境则不适宜采取类似的方案，首先从业务的视角来说，不同的业务组（也称住户），但是管理的作业会有不同，并且常常不同住户之间的作业，互相依赖关系复杂，犬齿交错，变化也经常，基本不或许在地理集群或机器的层面进行隔离，业务组之间的人员流动，业务变更也比较经常。
再者在同一住户业务内部，不同优先级的任务，不同类别的任务，不同应拿来源的任务，包括周期任务，一次性任务，失败重试任务，历史重刷任务等各类状况，还有不同的资源和流控管控需求。
现在本平台在开发实践中，主要从以下几方面进行限流控制：
4.5系统高可用设计说明
系统高可用，组件模块化，核心组件无状态化。
从系统构架的视角出发，模块化的设计有促使功能隔离，增加组件耦合度和单个组件的复杂度，提高系统的可拓展性，一定程度上有促使增强系统稳定性，但带给的问题是开发调试会格外困难，从这个视角来说又不促使稳定性的改进。因此各个功能模块拆不拆，如何拆常常是须要考量考虑的。
平台选用常见的主从式构架，根据功能模块界定清晰，职责单一而不紧耦合，防止繁琐复杂的业务耦合设计。节点负责作业计划的管理和任务的调度分配，节点负责详细任务的执行。用户通过Web控制后台管理作业，而Web控制后台与服务器之间的交互透过Rest服务来执行，Rest服务也可以给Web控制后台以外的其它系统提供服务（适于支持外部系统和调度系统的对接）。平台布署构架图如图19所示。
（图19：布署构架图）
调度不仅引进的负责时间调度外，核心的就是任务例子在执行过程中的状态变化以及变化后触发的操作逻辑。任务例子状态的变化切换现在仿造yarn的状态机实现原理，再次进行了扩建封装。这块的核心组件受限研制时间和技术问题没有做到无状态。
这儿所说的无状态化，更多的指出的是各个调度组件运行时状态的持久化，在组件崩溃重启后任务平台，所有的运行时状态都应当才能通过外部持久化的数据中迅速的恢复重建。
为了保证状态的一致统一，平台的所有作业和任务的信息变更，无论是用户发起的作业配置更改，还是执行器反馈的作业状态变更，就会递交给节点同步写入到数据库。
在HA方面，根据准实时的设计目标，平台并没有准备做到秒级别的崩溃恢复速率，系统崩溃时，只要能在分钟级别范围内，重建系统状态，就基本能满足系统的设计目标需求。
因此虽然高可用性设计的重点，关键在于重建的过程中，系统的状态能够精确的恢复。例如，主节点崩溃或维护其间，发生状态变更的任务在主节点恢复之后，能够正确更新状态等等。而双机热备份无缝切换，现在来看实现难度较大（很多步骤还要考虑原子操作任务平台，数据同步和防止竞争冲突），实际需求也不强烈，通过监控，手动重启和双机冷备的形式来加速系统重建速率，基本也就足够了。
另外，为了减少系统局部维护／升级其间的系统可用性，平台支持节点的动态上下线，可以对节点进行滚动维护，当节点下线时，节点和ZK节点也会缓存任务的状态变更信息，等到节点再次上线后再度汇报结果。因此一定程度上也能提高和应对系统不可用的时间。
4.6任务失败策略
支持任务失败转移、执行机器资源发觉和健康度评估。
作业失败的成因这些，有上游表数据不对、脚本配置错误等主要成因，还有一些临时性的病因，例如网路成因、外部DB负载成因，或许重试了就好了。因此，为了减少维保代价，我们还要可以支持相关重试策略的配置。其实，格外理想的状况是系统可以智能的依据失败的成因手动采取不同的策略。
(图20：任务失败重试配置)
(图21：任务失败重试运行记录)
4.7任务运行剖析设计说明
任务运行自助剖析，对任务进行确诊剖析，以便用户发觉和调整问题。
针对失败的任务提供任务运行日志，便于查看出错问题，辨识常见的错误机制，明晰的告诉用户错误类别，假如或许，告知解决方案。
(图22：任务执行日志)
针对成功的任务提供确诊信息，例如某个任务跑得慢，是由于GC，还是数据量变化，是由于集群资源不够，还是自身业务在某个环节被限流？各类状况下，用户该怎么规避解决，能够手动给出建议？之外，是否还能定期手动确诊，及时告诫用户，迫使用户自主优化？防止问题积压到影响业务正常运行的时侯才被关注。
现在我们自研了“华佗”平台，可以针对在上执行的hive、mr、spark任务进行运行确诊，对于出现GC、数据倾斜、资源消耗等方面作出综合的确诊。
(图23：任务运行确诊)
(图24：任务运行确诊详情)
5.状况和未来
整体来说，本文后面所描述的设计目标，平台基本上都早已实现了。经过3年的开发和持续改进过程，当前调度系统日常大约日均承载约20万个周期调度作业，接入企业集团绝大部份的离线估算相关的开发任务。平台现在趋向稳定，因为系统自身成因引起的大规模系统故障早已十分少见。
然而，因为前期平台过于追求满足用户的离线作业需求，未考虑任务配置的合理智、优先级和业务的关联性以及任务之间的血亲关系等，在后期任务量迅速上升的状况下，常常出现资源竞争激烈、任务小文件碎片化严重、任务变更影响和追踪定位链路过长等等问题。另外在极端环境下，尤其是在高负载大流量状况下，遇见系统软件，显存，DB或网路异常问题时，能够较差的进行容错处理，还是还要经历更多的复杂场景来加以磨练的。
未来，我们将从以下几个方面进行优化增强。
用户层面
调度层面
任务剖析整治层面
6.后续
我司的大数据离线任务开发调度平台从设计、开发到上线营运经历了这些问题，尤其是在第二次版本改建升级过程中，不仅自身考察外，还参考和借鉴了一些其他产品的设计观念。平台的部份设计内容和思想参考了香菇街刘旭辉的《大数据平台调度系统构架理论和实践》的相关内容，在此非常谢谢刘旭辉的理论文章，同时也谢谢参与平台设计开发的每一位男子伴的付出。这次内容主要从理论层面述说国美大数据离线平台的设计和实践，后续将对平台内部的详细功能的具体设计、关键代码实现做一次分享，敬请盼望。
作者简介
桑强，国美易购IT总部大数据平台研制中心离线估算工具研制部总监。10年硬件行业从业背景，13年开始接触大数据，有着5年多的大数据应用和平台开发经验。目前负责国美大数据基础工具平台的研制工作，主要包括离线估算工具、实时估算工具、数据资产与品质平台的构架、研发和项目管理等工作。在对接大数据底层和大数据业务线之间，怎样做好平台工具化，减少用户使用难度，支撑大数据应用的实践和研制上有着丰富的研制经验。
假如你喜欢这篇文章，或希望见到更多类似优质报导，记得给我留言和点赞哦！
