关于任务调度:亿级异构任务调度框架设计与实践
背景阿里云日志服务作为云原生可观测与剖析平台。提供了一站式的数据采集、加工、查问剖析、可视化、告警、生产与投递等性能。全面晋升用户的研发、运维、经营、平安场景的数字化能力。 日志服务平台作为可观测性平台提供了数据导入、数据加工、汇集加工、告警、智能巡检、导出等性能，这些性能在日志服务被称为工作，并且具备大规模的利用，接下来次要介绍下这些工作的调度框架的设计与实际。 本次介绍次要分为四个局部： 任务调度背景可观测性平台的亿级任务调度框架设计任务调度框架在日志服务的大规模利用瞻望任务调度背景通用调度调度 在计算机外面是一个十分常见的技术，从单机到分布式再到大数据系统，调度的身影无处不在。这里尝试总结出调度的一些独特特色。 操作系统：从单机操作系统Linux来看，内核通过工夫片的形式来管制过程在处理器上的执行工夫，过程的优先级与工夫片挂钩，简略来说，过程的在单CPU或者某个CPU的执行由调度器来把握；K8s被称为分布式时代的操作系统，在Pod创立后，K8s的管制面调度器通过对节点进行打分排序，最终选出适宜的Node来运行Pod。大数据分析系统：从最早的MapReduce应用偏心调度器反对作业的优先级和抢占，到SQL计算引擎Presto通过Coordinator的调度器将执行打算中的任务分配到适宜的worker上来执行，Spark通过DAGScheduler拆分成Stage，TaskScheduler将Stage对应的TaskSet最终调度到适宜的Worker上来执行。任务调度框架：在数据处理中常见的ETL解决工作、定时工作，这些工作具备多模的特点：定时执行、继续运行、一次性执行等。在工作执行过程中须要思考工作的编排和状态一致性问题。 这里简略的对调度做一个形象，如上图所示，调度负责将不同的Task调配到不同的Resource上执行，Task能够是过程、Pod、子工作；Resource为具体执行Task工作的资源，能够是处理器、线程池、节点、机器。通过这个形象，能够看出调度在零碎中的地位。 调度的覆盖面很广，本文次要集中在任务调度框架的设计与实际，这里先通过一些例子来看下任务调度的一些特点，以下次要讲工作分为定时类的工作和依赖类的工作两种来开展。 任务调度定时类工作 定时执行能够了解为每个工作之间有工夫先后顺序，并且要在特定的工夫点执行，比方每隔1小时对日志进行监控，00点的监控工作须要首先执行，01点的监控工作须要在01点准时执行；同样，相似的定时场景，还有仪表盘订阅、定时计算等。 依赖类工作 除了定时执行，还有另外一种编排模式，比方程序依赖，各个工作之间有先后执行的依赖，也叫Pipeline形式，还有一种比拟常见的编排模式，拓扑依赖，也称为DAG，比方Task2/Task3须要等到Task1执行实现才能够执行，Task5须要等到Task3/Task4执行完才能够执行。 任务调度特点任务调度在执行的过程中须要尽可能平衡的将工作分派到适合的机器或者执行器下来执行，比方要依据执行器的以后负载状况，要依据工作本身的特色进行分派执行；在执行器执行的过程中也可能会解体，退出，这时候须要将工作迁徙到其余的执行器中。整个调度过程须要思考到调度策略、FailOver、工作迁徙等。接下来来看下任务调度的一个简略利用。 任务调度利用：一条日志的历险 上图中原始日志为一条Nginx拜访日志，其中包含IP、工夫、Method、URL、UserAgent等信息，这样一些原始日志并不利于咱们进行剖析，比方咱们想统计拜访最高的Top 10 URL，通过命令解决是这样的： cat nginx_access.log |awk '{print $7}'| sort|uniq -c| sort -rn| head -10 | more 抛开命令的复杂性和原始日志的数据量不谈，即便需要略微变动，命令就须要大量的改变，十分不利于保护，对日志进行剖析的正确形式必然是应用分布式日志平台进行日志剖析，原始日志蕴含着大量“信息”，然而这些信息的提取是须要一系列的流程。 首先是数据采集、须要通过Agent对散布在各个机器上的数据进行集中采集到日志平台，日志采集上来后须要进行荡涤，比方对于Nginx拜访日志应用正则提取，将工夫、Method、URL等重要信息提取进去作为字段进行存储并进行索引构建，通过索引，咱们能够应用类SQL的剖析语法对日志进行剖析、例如查看拜访的Top 10 URL，用SQL来表白就会十分简洁清晰： select url, count(1) as cnt from log group by url order by cnt desc limit 10 业务零碎只有在服务，日志就会一直产生，能够通过对流式的日志进行巡检，来达到零碎异样的检测目标，当异样产生时，咱们能够通过告警告诉到零碎运维人员。 通用流程提取从这样一个日志剖析零碎能够提取出一些通用的流程，这些通用的流程能够概括为数据摄入、数据处理、数据监测、数据导出。 除了日志，零碎还有Trace数据、Metric数据，它们是可观测性零碎的三大支柱。这个流程也实用于可观测性服务平台，接下来来看下一个典型的可观测服务平台的流程形成。 典型可观测服务平台数据流程 数据摄入：在可观测服务平台首先须要扩大数据起源，数据源可能包含各类日志、音讯队列Kafka、存储OSS、云监控数据等，也能够包含各类数据库数据，通过丰盛数据源的摄入，能够对系统有全方位的观测。数据处理：在数据摄入到平台后，须要对数据进行荡涤、加工，这个过程咱们把他统称数据处理，数据加工能够了解为数据的各种变换和富华等，汇集加工反对对数据进行定时rolling up操作，比方每天计算过来一天汇总数据，提供信息密度更高的数据。数据监测：可观测性数据自身反馈了零碎的运行状态，零碎通过对每个组件裸露特定的指标来裸露组件的衰弱水平，能够通过智能巡检算法对异样的指标进行监控，比方QPS或者Latency的陡增或陡降，当出现异常时能够通过告警告诉给相干运维人员，在指标的根底上能够做出各种运维或者经营的大盘，在每天定时发送大盘到群里也是一种场景的需要。数据导出：可观测性数据的价值往往随着工夫产生衰减，那么对于长时间的日志类数据出于留档的目标能够进行导出到其余平台。从以上四个过程咱们能够形象出各类工作，别离负责摄入、解决、检测等，比方数据加工是一种常驻工作，须要继续对数据流进行解决，仪表盘订阅是一种定时工作，须要定时收回仪表盘到邮件或者工作群中。接下来将要介绍对各类工作的调度框架。 可观测性平台的亿级任务调度框架设计可观测平台工作特点依据上面对可观测平台工作的介绍，能够总结一个典型的可观测平台的工作的特点： 业务简单，工作类型多：数据摄入，仅数据摄入单个流程波及数据源可能有几十上百个之多。用户量大，工作数数量多：因为是云上业务，每个客户都有大量的工作创立需要。SLA要求高：服务可用性要求高，后盾服务是降级、迁徙不能影响用户已有工作的运行。多租户：云上业务客户互相间接不能有影响。可观测平台任务调度设计指标 依据平台工作的特点，对于其调度框架，咱们须要达到上图中的指标 反对异构工作：告警、仪表盘订阅、数据加工、汇集加工每种工作的特点不一样，比方告警是定时类工作、数据加工是常驻类工作，仪表盘订阅预览是一次性工作。海量任务调度：对于单个告警工作，如果每分钟执行一次，一天就会有1440次调度，这个数量乘以用户数再乘以工作数，将是海量的任务调度；咱们须要达到的指标是工作数的减少不会对打爆机器的性能，特地是要做到程度扩缩容，工作数或者调度次数减少只须要线性减少机器即可。高可用：作为云上业务，须要达到后盾服务降级或者重启、甚至宕机对用户工作运行无影响的目标，在用户层面和后盾服务层面都须要具备工作运行的监控能力。简略高效的运维：对于后盾服务须要提供可视化的运维大盘，能够直观的展现服务的问题；同时也要对服务进行告警配置，在服务降级、公布过程中能够尽量无人值守。多租户：云上环境是人造有多租户场景，各个租户之间资源要做到严格隔离，相互之间不能有资源依赖、性能依赖。可扩展性：面对客户的新增需要，将来须要反对更多的工作类型，比方曾经有了MySQL、SqlServer的导入工作，在将来须要更多其余的数据库导入，这种状况下，咱们须要做到不批改任务调度框架，只须要批改插件即可实现。API化：除了以上的需要，咱们还须要做到工作的API化管控，对于云上用户，很多海内客户是应用API、Terraform来对云上资源做管控，所以要做到工作治理的API化。可观测平台任务调度框架总体概览基于上述的调度设计指标，咱们设计了可观测性任务调度框架，如上图所示，上面从下到上来介绍。 存储层：次要包含工作的元数据存储和工作运行时的状态和快照存储。工作的元数据次要包含工作类型，工作配置、任务调度信息，都存储在了关系型数据库；工作的运行状态、快照存储在了分布式文件系统中。服务层：提供了任务调度的外围性能，次要包含任务调度和工作执行两局部，别离对应后面讲的工作编排和工作执行模块。任务调度次要针对三种工作类型进行调度，包含常驻工作、定时工作、按需工作。工作执行反对多种执行引擎，包含presto、restful接口、K8s引擎和外部自研的ETL 2.0零碎。业务层：业务层包含用户间接在控制台能够应用到的性能，包含告警监控、数据加工、重建索引、仪表盘订阅、汇集加工、各类数据源导入、智能巡检工作、和日志投递等。接入层：接入层应用Nginx和CGI对外提供服务，具备高可用，地区化部署等个性。API/SDK/Terraform/控制台：在用户侧，能够应用控制台对各类工作进行治理，对于不同的工作提供了定制化的界面和监控，同时也能够应用API、SDK、Terraform对工作进行增删改查。工作可视化：在控制台咱们提供了工作执行的可视化和工作监控的可视化，通过控制台用户能够看出看到工作的执行状态、执行历史等，还能够开启内置告警对工作进行监控。任务调度框架设计要点接下来从几方面对任务调度框的设计要点进行介绍，次要包含以下几方面来介绍： 异构任务模型形象调度服务框架大规模工作反对服务高可用设计稳定性建设任务模型形象 接下来看下任务模型的形象： 对于告警监控、仪表盘订阅、汇集加工等须要定时执行的工作，形象为定时工作，反对定时和Cron表达式设置。对于数据加工、索引重建、数据导入等须要继续运行的工作，形象为常驻工作，这类工作往往只须要运行一次，能够有也能够没有完结状态。对于数据加工的预览、仪表盘订阅的预览等性能，是在用户点击时才会须要创立一个工作来执行，执行实现即可退出，不须要保留工作状态，这类工作形象为DryRun类型，或者按需工作。调度服务框架 服务根底框架应用了Master-Worker架构，Master负责工作的分派和Worker的管控，Master将数据抽象为若干Partitions，而后将这些Partitions分派给不同的Worker，实现了对工作的分而治之，在Worker执行的过程中Master还也能够依据Worker的负载进行Partitions的动静迁徙，同时在Worker重启降级过程中，Master也会对Partition进行移出和移入； 工作的调度次要在Worker层来实现，每个Worker负责拉取对应Partitions的工作，而后通过JobLoader对工作进行加载，留神：这里只会加载以后Worker对应Partitions的工作列表，而后Scheduler对工作进行调度的编排，这里会波及常驻工作、定时工作、按需工作的调度，Scheduler将编排好的工作发送到JobExecutor进行执行，JobExecutor在执行的过程中须要实时对工作的状态进行长久化保留到RedoLog中,在下次Worker降级重新启动的过程中，须要从RedoLog中加载工作的状态，从而保障工作状态的准确性。 ...