亿级异构任务调度框架设计与实践

背景

阿里云日志服务作为云原生可观测与分析平台。提供了一站式的数据采集、加工、查询分析、可视化、告警、消费与投递等功能。全面提升用户的研发、运维、运营、安全场景的数字化能力。

日志服务平台作为可观测性平台提供了数据导入、数据加工、聚集加工、告警、智能巡检、导出等功能，这些功能在日志服务被称为任务，并且具有大规模的应用，接下来主要介绍下这些任务的调度框架的设计与实践。

本次介绍主要分为四个部分：

• 任务调度背景

• 可观测性平台的亿级任务调度框架设计

• 任务调度框架在日志服务的大规模应用

• 展望

任务调度背景

通用调度

调度在计算机里面是一个非常常见的技术，从单机到分布式再到大数据系统，调度的身影无处不在。这里尝试总结出调度的一些共同特征。

• 操作系统：从单机操作系统 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