马朋勃腾讯大数据高级工程师编辑整理｜业界首个数据智能知识地图发布
[浮云]活动推荐：五华诞直播
[礼品]直播亮点：公布业海门个数据智能知识地图
[美国赞]观看模式：重磅！业界首个数据智能知识地图公布
导读：现在和你们分享一下腾讯统一大数据调度平台-US，主要包括以下四大部份内容：
分享嘉宾｜马朋勃腾讯大数据初级安装工程师
编辑整理｜曹红姣平安产险寿险
监制社区｜
01
系统简介
统一调度平台是腾讯自研的一款分布式离线任务调度平台，主要负责腾讯离线剖析任务的定时调度。主要起到承上启下的作用，承上即指开放插口对接数据应用平台及一些重点业务，启下即指驱动各个估算、存储资源根据任务的依赖关系有条不紊的运行。
典型场景：
该场景主要包括：数据搜集、数据剖析估算、数据入库3块内容。数据搜集，支持将用户侧生成的文本数据、关系型数据、消息型数据等搜集完成后，通过出库任务出库至大数据平台，即生成ODS层的数据。用户可以通过统一调度平台提供的估算引擎，例如Hive、Spark等，定义统一调度的估算任务对数据进行加工，加工后的数据即为DWD或DWS层数据。接着经过一系列挖掘后生成用户想要的有价值的数据，比如生成一张报表或游戏日活统计数据。最终通过统一调度平台的入库任务将数据推送至用户侧供其使用。现在支持关系型数据的推送或则文件系统,读取统一调度平台提供的插口进行数据的拉取。
总体而言，大数据平台犹如是一个很大的数据加工厂，原材料是用户生成的原始数据，成品就是加工提取后有价值的数据。而统一调度平台在车间中承当一个管家的角色，协调各个组件有条不紊的运行。整个加工过程数据存在上下游依赖关系，数据依赖就直接反映出任务的依赖，基于任务的依赖关系就生成了一张复杂的DAG图，而统一调度平台依照调度周期驱动DAG图周而复始的运行。
--
02
系统设计
1.第一代调度构架挑战
第一代调度构架设计之初能满足当初的业务需求，但随着任务体量不断下降，由于构架设计及技术选型的成因，已很难满足业务即时性的要求。主要表现为：
其二，调度核心模块扩充比较困难，单个节点承载的任务量已达到系统的极限，一
旦任务堆积或许还会导致后续任务的延时；
其一，数据库负载已达到难题；
其一，没有一个健全的资源管控，由于底层资源有限，而资源消耗型的业务或许会占用大量的资源，造成时序性要求很高的任务延时；
其一，任务优先级关系管理不当，造成大量的关键任务推迟，从而导致报表延后；
其一，系统存在大数据量处理效率不高的问题，例如任务的例子化或任务的下发等。
如下针对任务例子化及任务调度进行重点说明。针对第一代调度构架存在的问题，有两个方案可以解决此问题：其三，自研新一代调度平台；其一，辅以开源调度方案。
2.开源调度方案
业界关注得更多是调度平台的通用性，常常数据规模比较小，即未考虑海量的数据规模。诸如：针对当任务量达到百万规模时功耗已达到难题。另外的维护费用十分高，由于的文件定义是通过文件做定义，当有成百上万工作流时，就需维护成百上万的文件。另外，基于腾讯较高业务复杂度，数据体量大，集群跨地域等背景，还要设计一款支持纵向扩充，且能满足腾讯集群规模和大体量任务量的任务调度平台。
3.新一代调度系统构架
新一代调度系统重点考虑扩充性、高可用、高吞吐、灵活性4个指标。该系统构架引进了解决调度层的单点问题；依据业务的不同，设计不同的调度核心负责不同的业务，不同调度核心支持彼此的迁移，假如任务下降即可通过扩容调度核心进行解决。对于数据库负载的问题，通过将数据库由MySQL更换为Tbase（腾讯自研的分布式数据库），使得通过Hbase做了一个数据的冷热分离；为解决资源管控不够健全的问题任务平台，依据资源设计了基于资源的公正调度算法，限制资源消耗型业务的任务并发，防止占领关键任务的资源导致报表延时。甚至对调度内核进行了彻底的重画，提高了整体功耗。
如上，为新一代调度构架系统。用户通过前台和第三方平台调统一调度平台插口层，通过网段限流、鉴权和审计以后，API将任务定义或则工作流定义讲到储存层，于是调度核心从储存层领到对应的任务，接着调度核心再从控制层拉取对应的剖析片任务，于是调度核心进行对应的任务例子化，例如：天任务一天生成一个例子、小时任务每小时生成一个例子）、依赖判定、并发控制和任务下发；第二代调度系统对比第一代调度系统做了什么优化，详细优化举措又是怎样？如下主要从例子化和任务下发两点来进行探讨。
4.例子化
（1）例子化功耗难题及解决方案选型
由上图可知，任务例子生成作为调度核心的第一步动作，假如它发生了推迟，后续依赖判定及任务下发就会推迟，因而造成结果数据延后。第一代调度系统的任务例子化存在任务例子化功耗低下的问题，致使分钟级任务调度支持度低，任务推迟严重等问题。
与此同时，任务例子化存在的挑战包括：
通过剖析发觉，引起如上痛点的主要成因包括：
基于上述问题，我们思考了业界常用的解决方案：
①存储可伸缩
考虑到业务的入侵性和扩充性，最终选择了分布式方案，即选用Tbase做储存。Tbase是基于PG自研的一款分布式数据库，由专业的维保人员去维护。
②应用可伸缩
基于腾讯体量和费用的考虑，应用可伸缩这块在水平伸缩和平行伸缩都有落地实现。接下去我们以例子化为例，看下详细的优化举措。
（2）例子化——解决方案
就储存可伸缩做的详细优化包括以下3点：
①为解决MySQL单点功耗的问题，将MySQL切换为分布式Tbase，支持数据库的水平扩充；
②为解决查询效率的问题，对数据做了冷热分离，冷数据选用Hbase做储存；
③为解决水平扩充，引进了，即每位调度核心在启动以后从去获取对应的任务分片，任务调度核心只负责对应分片的任务。
应用平行伸缩方案即是针对任务例子生成进行优化，生成例子的过程优化包括对例子进行Hash分桶。Hash算法可以自定义，使得每位桶可以自己定义桶的大小和缓冲时间，当桶满了或则达到它的缓冲时间以后，对这个桶做一个mini-batch之后做批量递交，由于是有多个桶，就将之前的串口一次写入就转化为mini-batch的并行写入，因而例子化功耗得到急剧增强。
5.任务下发
（1）任务下发——问题剖析
任务下发主要存在报表延时和服务压力大两个问题。详细表现为：①偶发性重点报表达到分钟级左右的延时；②服务压力大。
任务下烫面临的挑战包括：①任务量大，达到千万级的任务下发；②用户对数据成效性要求较高；底层任务依赖较繁琐，还要依赖估算、存储、权限系统及用户侧的OLAP等；③底层资源有限；④任务依赖纷扰，在有限的时间及资源内驱动纷扰的组件运行上千万的任务。
剖析报表延的案例发觉导致报表延时的成因包括：①未考虑链路依赖的优先级；例如：低优先级的父任务造成高优先级的子任务不能及时运行；②低优先级的任务长时间得不到运行造成淹死的状况；③用户对于小周期任务延时格外敏感；诸如：由于调度时将月/天/小时任务一起执行，引发用户对小周期任务的推迟格外敏感；④任务的依赖链路太长，造成下游任务不能及时运行，因而造成报表延时。
剖析服务压力大的案例发觉主要成因是没有对服务器做并发控制，大量的任务或许会拖垮服务器。诸如：某个入库任务，将估算以后的数据入库到MySQL，这时大量的任务同时对多个表执行入库任务，这时或许会把用户侧的MySQL服务烧死，这时还要限制服务的并发。
而上一代调度算法选用优先级调度算法，逐步来说，优先级选用的是静态优先级。如右图所示，A任务的优先级低，B任务的优先级高，而且A任务下游有两个高优先级的任务，而B任务的下游没有高优先级任务，根据上一代调度算法，B要优于A运行，而实际理想的状况是，A要优于B运行。
上一代调度算法支持任务并发控制，不支持服务并发。诸如如右图所示：在上一代调度算法中，X下发两个正在运行的例子后，于是Y还可以下发两个任务去运行。理想的状况是，还要等到X的所有任务执行结束以后，于是Y能够下发。
因此，最终得出的推论是问题出现在任务调度算法上。
（2）任务下发——方案选择
由上可知，任务下发的调度算法主要从两个方向进行优化：①动态优先级，优先级考虑任务动态执行过程；②动态并发控制，按照资源实时动态做并发控制。
参考操作系统的任务调度方案：①FCFS（FirstComeFirst），该方案特点是公正，并且该方案对短作业不友好；②SJF（ShortJobFirst），该方案特点是全局等候时间最短，劣势是对长作业不友好；基于第①和第②方案都不能满足统一调度需求，只好做到局部最优。参考前两个方案设计了基于资源的公正调度算法即第③个方案。③RFS（Fair），综合考虑动态优先级（基于任务执行过程动态估算优先级）和资源的并发控制（执行过程动态执行动态并发）。
为实现第③个方案，带给了两个问题，怎么动态估算优先级？哪些是资源，怎么做资源的并发控制？
a.任务下发——动态优先级
实现任务下发动态优先级的估算原则包括：①任务的迫切性，任务越接近，它的优先级越高；②任务的关键性，即任务所对应的业务越关键则任务越关键，优先级越高；③任务的经常性，即任务越经常优先级越高，即分钟任务的优先级>天任务的优先级>周任务的优先级>月任务的优先级；④周期的快捷性，短作业任务优先级>长作业任务优先级；⑤依赖的传递性，越是上游的任务优先级越高，由于下游的任务都依赖上游的任务。
基于上述原则，整理出任务优先级要素：
b.任务下发——动态资源控制
面临的主要挑战是，底层服务类别十分多，方案很难统一。诸如任务下发到一个（执行机，即包括地理机和容器）上，那还要做资源并发控制，不能下发很多的任务把资源拖垮；同理，针对Yarn的资源队列，例如递交任务到Yarn起来，递交很多任务那都会导致任务阻塞，这时还要控制Yarn资源队列（Queue）的并发；包括Hive集群、HDFS集群或则用户侧的MySQL服务（）等，都须要做资源并发控制。另外，随着服务的资源消耗，还要动态估算任务的资源状况，它的实时性要求比较高。这块的解决方案是选用领域模型对服务进行一个高度具象，即一切皆是资源（参考Linux操作系统一切皆是文件的思想），具象一个资源插口，包括已用配额、最小配额和最大配额，按照服务资源量化为配额，即资源配额。于此同时，按照执行历史任务评估任务占用配额。
（3）任务下发解决方案——资源公正调度
确定任务动态优先级和动态资源控制，我们看下基于资源的公正调度算法详细实现；资源公正调度的核心思想是怎样从百万级任务中获取满足资源并发控制的最高动态优先级任务。
最高动态优先级任务分为如下5个方法：
①分片读取：调度内核读取对应分片的待执行任务；
②分桶：待执行任务Hash分桶；
③桶内排序：每位桶根据优先级进行桶内排序；
④桶内并发控制：桶内根据动态优先级从高到低递归，判定资源并发控制，直至有一个任务满足并发控制；
⑤桶外排序：对每位桶满足并发控制的高优先级任务排序获取优先级最高任务。
--
03
营运状况
1.例子化落地疗效
①性能提高：功耗增强30倍；百万任务例子化功耗增强了10倍+
②支持分钟级调度：满足业务分钟级调度需求
2.基于资源公正调度——落地疗效
①用户重点报表均按量输出，满足用户分钟需求
②业务侧未出现因任务并发大导致的宕机现象
3.营运状况——内网
①核心指标：千万级日调度任务、万级用户规模、上千的集群规模、支持80+任务类别
②每天调度任务数：千万级，任务数年下降50%
③服务部委/业务：IEG、PCG、CSIG、WXG、CDG等
4.赋能公有云
研制数据开发平台，现在已开放使用，它是一款一站式的数据协作开发平台，包括数据剖析、工作流协同编排、数据资产管理、数据整治等全链路的数据加工能力，帮助数据安装工程师高效完善企业级的数据中台。
--
04
项目未来规划
短期规划：持续系统抛光任务平台，极至增强功耗及用户感受；推进系统自维保，提高问题确诊剖析能力；
常年规划：构建一站式数据开发平台。
--
05
问答环节
Q1：调度的周期拉取是线程机制还是方式，系统语言是选用哪种语言撰写？
A1：选用Java语言撰写。主要是支持两种方式，线程机制主要针对大批量长周期的，对实时性不太敏感的任务调度选用线程机制，对于短周期分钟级别实时性要求高的任务调度选用触发（读取系统显存的线程，对系统显存消耗大）的方式。
Q2：海量任务数据储存是怎样解决的？
A2：百万任务一天会生成千万级别的例子，储存做了冷热分离，把近期一天且状态处在待运行的任务或则依赖判定之前的任务全部存在Tbase（腾讯自研的分布式数据库）中。将早已运行成功的或则永久中止（重试这些次已失败）的任务储存在Hbase中。
Q3：调度平台如何实现手动扩容的？
A3：腾讯调度平台引进了，的节点是支持热备的，每位调度核心从去拉取对应任务的分片，不同调度分片的任务分片假如宕机是可以水平迁移的。当扩容一个节点过来时，只需从去拉取对应的分片，于是才会从一个节点获取部份任务分配到新节点起来。
Q4：任务的后边输出数据（二补码文件）是怎样解决的？
A4：针对各类组件，如Hive后边输出数据会储存在后边临时表，任务执行完成后会把临时数据表drop掉；另外，Spark这些会有一个临时的HDFS目录，用户把数据讲到临时的HDFS目录，操作完成后会把临时目录进行清除；另外在估算过程中，为保证数据一致性，对Hive等组件也做了一些扩建，执行完成后，会把数据会做一次性的move操作。
Q5：版本更新时怎么解决已运行但未执行完成的作业任务调度问题？
A5：1、调度核心假如重启，假如这时作业状态已完成都会去递交状态，这时会不停重试递交状态，重试的步长也会不断放大，当调度上去后，才会把状态递交上来。2、如果DB故障，写DB失败后会将数据写入硬盘，待DB恢复以后，会从硬盘调用数据之后再次写入DB；3、不同的调度核心可以进行水平迁移，当任务A的调度核心停止后，会把任务迁移到其它的调度核心，只要有一定量的调度核心是存活，才能保证任务的正常调度。
评论列表 (0)