我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:香港跑狗图 > 调度策略 >

苏宁 1111 :苏宁大数据离线任务开发调度平台实践

归档日期:04-23       文本归类:调度策略      文章编辑:爱尚语录

  在数据仓库的建立过程中,核心技术是抽取、转换、装载(ETL),它为数据仓库提供及时、高质而准确的数据。由于 ETL 包括众多的处理任务,且这些任务之间有一定的约束关系,如何高效的调度和管理这些任务是数据仓库 ETL 实施中非常重要的工作,也是提高数据仓库开发效率和资源利用率的关键。

  在大数据平台,随着业务发展,每天承载着成千上万的 ETL 任务调度,这些任务的形态各种各样。怎么样让大量的 ETL 任务准确的完成调度而不出现问题,甚至在任务调度执行中出现错误的情况下,任务能够完成自我恢复甚至执行错误告警与完整的日志查询。IDE 大数据离线任务调度系统就是在这种背景下衍生的一款分布式调度系统。

  在阐述 IDE 平台之前,首先讨论一下作业调度系统和资源调度系统的区别,因为往往有同学把这两者混为一谈。资源调度系统的典型代表比如:Yarn/Mesos/Omega/Borg,还有阿里的伏羲,腾讯的盖娅(Gaia),百度的诺曼底 (Normandy) 等等。我们今天的内容主要讲述的是作业调度系统。不过,IDE 除了完成了大数据的任务各种复杂调度外,还包含了任务开发、依赖组织、状态维护、任务监控、任务治理、服务监控、动态扩缩容等诸多内容。

  对拥有权限的作业/任务进行管理,包括设计调度周期和时间、添加、修改、删除任务节点、组织依赖关系、查询等

  对任务运行状态进行查看、监控,进行杀死、重跑、补数据、查看运行日志、查看操作记录等运维操作

  支持任务失败报警,超时报警,到达指定时间未执行报警等异常情况的报警监控

  支持动态按应用/业务/优先级等维度调整作业执行的并发度调度时间和数据时间的分离

  支持历史任务独立重刷或按照依赖关系重刷后续整条作业链路允许设置作业生命周期,可以临时禁止或启用一个周期作业

  提供任务链路依赖分析,便于分析任务的上下游影响,调度执行延迟的溯源分析

  提供任务的导入导出、复制等功能,便于用户在多个运行环境和数据中心快速开发任务,提高开发效率

  提供任务的发布管控和权限管控的配置功能,规范任务开发流程,降低生产风险

  目前苏宁八大产业齐聚并发,数据爆发增长,依托大数据平台打通各产业数据,服务智慧零售。在整个智慧零售中和大数据开发战略中,ETL 是 BI(商业智能)的基础,数据调度是 ETL 的灵魂。

  使用该平台能够对企业中批量运行作业进行集中管理,并通过强大的调度引擎功能实现作业的逻辑运行,并提供直观详细的监控手段,辅助运维工作。平台为系统的开发与运维提供以下价值:

  IDE 平台旨在为用户提供从数据源申请、任务创建、任务调度编排、任务运维、任务告警、运行分析等一站式大数据开发平台,帮助企业快速完全数据中台搭建。

  IDE 大数据开发平台在架构上分为任务管理平台、任务调度、任务执行、任务监控、和 API 服务五部分。平台采用了先进的 JavaEE 技术架构,具有很强的跨平台性。部署简便,维护简单,容易使用。支持分步式的多机集群,能承载大规模数据的高负荷运行,具有良好的稳定性。平台采用了多层架构,结构清晰,具有良好的扩展性、稳定性和容错性。

  让用户能够尽可能的自助服务,同时降低操作代价,减少犯错的可能性。支持当日任务计划和执行历史的查询,支持周期作业信息的检索,包括作业概况,历史运行流水,运行日志,变更记录,依赖关系、任务运行明细查询等。这部分功能的目的,是为了让系统更加透明,让业务更加可控,让排查和分析问题更加容易。尽可能的让一切作业任务信息和变更记录都有源可查,做到任务操作都可以追踪和溯源。

  任务流的开发提供画布操作,任务节点拖拽方便,编排简单,如图 8 和图 9 所示。

  任务运行状态进行查看、监控,进行杀死、重跑、补数据、查看运行日志、查看操作记录等运维操作。如图 11 和图 12 所示

  提供丰富的告警,便于及时跟踪任务执行状态,降低事故率。如图 13 和 14 所示

  提供任务链路依赖分析,便于分析任务的上下游影响,调度执行延迟的溯源分析。

  所谓准时实调度,首先指的是平台会按照各个上线的任务流的调度时间生成调度执行计划,当触发时间到了,平台会按照调度执行计划精确的生成任务流实例和任务实例。但是在任务执行上,并不保证准实时的分配机器执行。实际上平台以整体资源使用情况为最高原则,并按照一定的限流策略控制任务的执行,比如:任务优先级、任务组并发度、平台任务并发数、任务特定执行时间等因素。在保证平台资源允许的情况下,尽量按时执行任务。为了保障任务的实时性,必须保障任务资源的可用性和计划可控性。

  作业计划的变更允许用户调整自己上线的任务流执行计划。比如天任务调整为小时任务,调度开始时间从 1 点开始调整为 2 点开始。如果对上线已经生成任务实例的任务流进行调整,必须下线后再调整,此时会提示用户杀死当前的任务,然后完成计划调整。如果上线的任务流还未到触发时间,没有生成任务实例,用户可以及时修正,并对任务执行无影响。

  灵活的调度策略,触发方式需要支持:时间触发,依赖触发或者混合触发,支持多种依赖关系等

  首先,在一些复杂的业务场景里,存在跨流任务依赖调度,不同的任务流的频率和时间周期不一致,比如天依赖小时、周依赖天等

  其次,针对不同优先级的任务,在资源利用高峰和任务执行高峰时段,可以适当调整中低优先级的任务的执行时间窗口,避免低优先级的任务和高优先级的任务进行资源抢占,错峰执行,提高资源利用率和均衡性。

  在解决跨流依赖方面,平台目前仅支持 大频率依赖小频率,比如:天依赖小时、周依赖天、月依赖天,以及同频依赖,比如:小时依赖小时、天依赖天、周依赖周、月依赖月。平台在设计之初限制了一个任务只能属于一个任务流,不允许任务跨流存在,如何解决跨流依赖的问题呢?我们建议用户对任务创建任务事件,可以理解成任务的一个执行副本。这个事件是允许跨流存在的。如果一个任务流需要依赖另外一个任务流的的某个任务,只要依赖这个任务的事件即可,通过事件我们将任务流进行串联起来。如图 17 所示。

  在解决跨系统之间的依赖问题,我们提供了 FTP 事件,即在 FTP 服务器上建立标识文件,一个事件对应一个标识文件地址,当 FTP 服务器上的标识文件生成的时候,我们认为业务系统已经完成作业,需要触发平台任务执行。

  因为 FTP 事件存在实时性和稳定性的问题,即调度服务是不停的轮询各个 FTP 事件服务器,当 FTP 服务器负荷较重,往往会连接超时,导致扫描文件标识延迟,进而导致下游任务延迟,我们对用户系统了 API 事件,即业务系统作业完成后可以调用平台的 API 接口,触发下游任务执行,解决了时效性和稳定性的问题。

  大多数的工作流调度系统,多租户的隔离比较简单,业务上租户之间完全独立,租户之间的业务很难相互关联。同一租户的工作流方面也不能互相依赖和关联。更多的考虑是物理资源层面的隔离,这个,多半通过独立集群或者虚拟化的方案来解决,同一租户内部,做得好的可能再考虑一下业务队列管理。

  我司的业务环境则不适合采取类似的方案,首先从业务的角度来说,不同的业务组(亦即租户),虽然管理的作业会有不同,但是往往不同租户之间的作业,相互依赖关系复杂,犬牙交错,变化也频繁,基本不可能在物理集群或机器的层面进行隔离,业务组之间的人员流动,业务变更也比较频繁。

  其次在同一租户业务内部,不同优先级的任务,不同类型的任务,不同应用来源的任务,包括周期任务,一次性任务,失败重试任务,历史重刷任务等各种情况,也有不同的资源和流控管控需求。

  任务优先级,任务分为高中低三个优先级,分别对应底层 yarn 的资源调度不同的权重,高优先级的优先分配执行机器和计算资源

  系统调用和用户补数据操作分开,平台绝大部分的任务执行都是依赖自身的调度周期执行,无需用户干涉,优先保证这部分的任务的执行资源;在某些业务场景下,需要对历史数据进行弥补,通过指定运行的数据时间强制任务执行,这类任务往往不是很紧急,可以将优先级降低

  失败重试和用户重跑优先级高于系统调用的优先级。当任务出现异常需要进行重跑或者重试,需要人工进行干预的情况下,一般属于紧急情况,需要优先保证这部分的任务的计算资源

  对于同一任务流内同一层级内部的多个任务,可以设置任务组,通过设置任务组的并发度来限制任务的并行个数,降低对业务系统的访问压力。这个往往在对分库数据库或者同一数据库进行多任务访问操作的时候,减轻业务数据库的访问压力,可以限制任务的并行执行个数

  按照任务类型进行限流。平台支持的任务类型很多,当底层对应的计算或者存储资源压力过大,可以限制某些类型的任务的并发个数,降低底层的计算压力。这个限流可以做到平台全局层面,也可以做到系统账号层面。

  可以为某些类型任务或者某个系统账号下的任务指定固定的机器资源执行,这样可以降低大资源消耗任务对其他任务的资源抢占,保障特殊任务的资源需求,也可以进行部分账号的任务的灰度发布,降低生产事故率

  Worker 节点的被动负载反馈(负载高的情况拒绝接收任务)和主节点的主动负载均衡(轮询和 Worker 节点并发数控制等策略)。在分配任务和领取任务方面都进行了任务队列深度控制,防止过度分配和过度领取而导致分配不均而引起的任务堆积

  从系统架构的角度出发,模块化的设计有利于功能隔离,降低组件耦合度和单个组件的复杂度,提升系统的可拓展性,一定程度上有利于提升系统稳定性,但带来的问题是开发调试会更加困难,从这个角度来说又不利于稳定性的改进。所以各个功能模块拆不拆,怎么拆往往是需要权衡考虑的。

  平台采用常见的主从式架构,按照功能模块划分清晰,职责单一而不紧耦合,避免繁重复杂的业务耦合设计。Master 节点负责作业计划的管理和任务的调度分配,worker 节点负责具体任务的执行。用户通过 Web 控制后台管理作业,而 Web 控制后台与 Master 服务器之间的交互透过 Rest 服务来执行,Rest 服务也可以给 Web 控制后台以外的其它系统提供服务(用于支持外部系统和调度系统的对接)。平台部署架构图如图 19 所示。

  Master 调度除了引入 Quartz 的负责时间调度外,核心的就是任务实例在执行过程中的状态变化以及变化后触发的操作逻辑。任务实例状态的变化切换目前仿照 yarn 的状态机实现原理,重新进行了改造封装。这块的核心组件受限研发时间和技术问题没有做到无状态。

  这里所说的无状态化,更多的强调的是各个调度组件运行时状态的持久化,在组件崩溃重启后,所有的运行时状态都应该能够通过外部持久化的数据中快速的恢复重建。

  为了保证状态的一致统一,平台的所有作业和任务的信息变更,无论是用户发起的作业配置修改,还是执行器反馈的作业状态变更,都会提交给 Master 节点同步写入到数据库。

  在 HA 方面,按照准实时的设计目标,平台并没有打算做到秒级别的崩溃恢复速度,系统崩溃时,只要能在分钟级别范围内,重建系统状态,就基本能满足系统的设计目标需求。

  所以其实高可用性设计的重点,关键在于重建的过程中,系统的状态能否准确的恢复。比如,主节点崩溃或维护期间,发生状态变更的任务在主节点恢复以后,能否正确更新状态等等。而双机热备份无缝切换,目前来看实现难度较大(太多流程需要考虑原子操作,数据同步和避免竞争冲突),实际需求也不强烈,通过监控,自动重启和双机冷备的方式来加快系统重建速度,基本也就足够了。

  另外,为了提高系统局部维护/升级期间的系统可用性,平台支持 Worker 节点的动态上下线,可以对 worker 节点进行滚动维护,当 Master 节点下线时,Worker 节点和 ZK 节点也会缓存任务的状态变更信息,等到 Master 节点重新上线后再次汇报结果。所以一定程度上也能减少和规避系统不可用的时间。

  作业失败的原因很多,有上游表数据不对、脚本配置错误等主要原因,也有一些临时性的原因,比如网络原因、外部 DB 负载原因,可能重试了就好了。所以,为了降低运维代价,我们需要可以支持相关重试策略的配置。当然,更加理想的情况是系统可以智能的根据失败的原因自动采取不同的策略。

  针对失败的任务提供任务运行日志,方便查看出错问题,识别常见的错误模式,明确的告诉用户错误类型,如果可能,告知解决方案。

  针对成功的任务提供诊断信息,比如某个任务跑得慢,是因为 GC,还是数据量变化,是因为集群资源不够,还是自身业务在某个环节被限流?各种情况下,用户该如何应对解决,能否自动给出建议?此外,是否能够定期自动诊断,及时提醒用户,敦促用户自主优化?避免问题积压到影响业务正常运行的时候才被关注。

  目前我们自研了“华佗”平台,可以针对在 hadoop 上执行的 hive、mr、spark 任务进行运行诊断,对于出现 GC、数据倾斜、资源消耗等方面做出综合的诊断。

  整体来说,本文前面所描述的设计目标,平台基本上都已经实现了。经过 3 年的开发和持续改进过程,当前调度系统日常大概日均承载约 20 万个周期调度作业,接入集团绝大部分的离线计算相关的开发任务。平台目前趋于稳定,由于系统自身原因造成的大规模系统故障已经非常罕见。

  但是,由于前期平台过分追求满足用户的离线作业需求,未考虑任务配置的合理性、优先级和业务的关联性以及任务之间的血缘关系等,在后期任务量快速上升的情况下,经常出现资源竞争激烈、任务小文件碎片化严重、任务变更影响和追踪定位链路过长等等问题。另外在极端环境下,尤其是在高负载大流量情况下,遇到系统硬件,内存,DB 或网络异常问题时,能否较好的进行容错处理,还是需要经历更多的复杂场景来加以磨练的。

  在保证现有平台功能稳定的基础上,进一步丰富平台的任务类型、任务参数、任务样例、帮助手册等,提高平台的易用性

  提供任务分析报表,可视化分析跟踪任务的总体运行情况、调度资源、计算资源、健康度,更好的按不同维度(个人/系统/全局等)汇总展示给用户,方便用户随时掌控和调整自身业务

  能够定期自动诊断,及时提醒用户,敦促用户自主优化。避免问题积压到影响业务正常运行的时候才被关注。

  灵活的调度策略,触发方式需要支持:时间触发,依赖触发或者混合触发,支持多种依赖关系等

  支持用户权限管理,能和各种周边系统和底层存储计算框架既有的权限体系灵活对接

  我司的大数据离线任务开发调度平台从设计、开发到上线运营经历了很多问题,尤其是在第二次版本改造升级过程中,除了自身调研外,还参考和借鉴了一些其他产品的设计理念。平台的部分设计内容和思想参考了 蘑菇街 刘旭辉的《大数据平台调度系统架构理论和实践》的相关内容,在此特别感谢刘旭辉的理论文章,同时也感谢参与平台设计开发的每一位小伙伴的付出。

  此次内容主要从理论层面讲述苏宁大数据离线平台的设计和实践,后续将对平台内部的具体功能的详细设计、关键代码实现做一次分享,敬请期待。

  桑强,苏宁易购 IT 总部大数据平台研发中心离线 年软件行业从业背景,13 年开始接触大数据,有着 5 年多的大数据应用和平台开发经验。现在负责苏宁大数据基础工具平台的研发工作,主要包括离线计算工具、实时计算工具、数据资产与质量平台的架构、研发和项目管理等工作。在对接大数据底层和大数据业务线之间,如何做好平台工具化,降低用户使用难度,支撑大数据应用的实践和研发上有着丰富的研发经验。

本文链接:http://mikephotos.net/diaoducelue/127.html