调度系统在大数据平台中扮演着中枢神经的角色。整个中台的数据产出、业务元数据流转、作业执行、数仓管理乃至资产统计等关键链路，都与调度系统深度耦合，是平台不可或缺的核心子系统。
有数大数据平台的调度系统，是基于开源 Azkaban 进行了深度二次开发而来。我们针对企业级生产环境的需求，重点增强了以下核心功能：
跨Flow依赖： 打破了Azkaban原生的Flow隔离，实现了任务之间的复杂依赖关系。
高可用（HA）： 确保了调度组件自身的高可用性，消除了单点故障风险。
日历调度： 增加了更灵活、更精细化的日历调度能力，以满足复杂的业务周期。
目前，该系统在网易内部已稳定支撑每日十万量级的离线任务，并展现出了极高的扩展性，是平台稳定运行的坚实保障。
1.任务
指离线开发上的任务，是调度设置的基本单位，也是一次执行的基本单位，任务可分为线上模式和开发模式。开发模式的任务用于日常调试，线上模式的任务用于离线调度。任务提交上线，就会生成线上模式的版本，2个模式下的任务内容，包括节点和代码、调度设置、报警设置，互相独立
任务由一系列的节点组成，这些节点连接在一起，构成一个有向无环图（DAG）。
·节点
在任务内，支持拖入多种节点，节点是更小的处理单元，目前平台支持丰富的节点类型，不同节点可实现不同的数据处理功能。比如各数据源节点（MySQL、Oracle、Doris、StarRocks等十余种），可以实现直接操作数据库的功能。还有包括Spark节点、Python、Shell、轮询节点、选择节点、嵌套流、触发器节点等等。
2.调度
·定时调度
任务内通过多种节点构建数据处理过程后，如果需要希望任务能周期性执行，则可以通过设置调度信息，实现任务定时调度的结果。在配置上，目前支持常规调度（设置起止时间、时间间隔、调度日历）、Corntab和Quartz Cron等3种类型调度。
其中调度日历指，可以实现任务在特定日期才执行的效果。而Corntab和Quartz Cron两种方式，可以实现更加灵活的任务调度。
·任务依赖
数据的加工梳理，有上下游之分，比如产出了一份明细数据，接着基于该明细数据进行汇总数据加工。该加工任务为了保障数据产出的正确，就需要配置上游任务，依赖上明细数据的产出任务。进而使得上游任务完成后，下游才允许调度。
3.任务执行
·实例
任务的每一次执行，都是通过生成一个具体的实例来完成。实例可以通过定时调度触发、手动执行触发，也可以通过补数据触发、重跑触发。实例会按照任务内的节点DAG流程运行，直至完成（失败或终止）。
调度任务产生实例的关系图
调度系统在平台内作为中枢神经，是一个相对比较抽象的存在，但是实际在平台的非常多功能上，都会有它在背后默默支持。
在任务运维中心子产品中，有一个“周期实例运维”菜单，调度系统每时每刻都在计算和执行实例，对于定时调度的任务，会通过该页面呈现出来。
除了定时生成的实例外，平台上还有一系列手动触发的实例。
1.线上模式实例操作触发
针对线上任务，我们做了一些补充的运维手段，方便用户对业务数据进行重刷、补充、恢复等操作。主要为重跑和补数据两个。
重跑
任务运维中心上针对失败、异常实例的运维手段，为的是在数据异常、任务失败等场景下，可以重新运行异常实例，重新产出数据。重跑是基于已有实例操作的，会继承已有实例的各种配置。
·单实例重跑
·批量重跑
补数据
有些场景下，用户需要生成当前业务的历史批次数据（比如新建的任务，需要产出上个月的业务数据），或者历史数据有误，重新调整了任务代码，此时，可以使用补数据功能。这可以让用户针对单个或一批任务的某一历史时间段，进行业务数据的重跑、恢复。
·单任务补数据
·批量补数据
补数据任务上的实例如果失败后，也支持重跑。
2.任务的试运行
针对用户在开发、测试过程中的运行需求，我们提供了各种试运行的功能，此时也需要调度系统完成实例的生成和执行。
离线开发
离线开发，任务页面，针对开发模式的任务，可以执行立即运行，满足数据开发人员即时调试数据的目的。
数据质量中心
质量监控任务，支持试跑快速探查数据质量的结果。
形态探查任务运行，支持快速探查一张表的主键、字段枚举值和分布、字段的最大最小值、样例数据等。尤其是针对新接入的源头数据，可以一键快速完成数据形态探查。
数据比对任务运行，支持两份数据的逐行、逐字段的比对。尤其是针对业务系统重构的新老表、核心表更改时的线上和测试表的比对，让数据的差异一览无余。
数据传输试跑
离线同步任务运行，支持即时触发数据传输任务，更便捷完成数据集成
数据导入任务导入本地数据，支持本地数据快速变成线上表的数据。
安全中心任务试跑
数据识别任务执行“立即识别”，可通过任务扫描，快速完成海量元数据中的词根、数据元等的拾取，助力数据标准落地。
除了前面提到的调度系统对EasyData的个子产品的执行支撑外，本身系统也做了一些改进和优化，以便更好支撑海量任务的调度执行。
我们实例的运行资源消耗具有显著的波动性，这导致在业务高峰期，执行机的CPU和内存资源偶尔出现过载，或是底层计算资源被打满，影响整体稳定性。
为解决此问题，我们引入了一套动态的实例并发控制机制。其核心实现分为以下几个关键点：
1.执行器增加资源感知
每个执行器增加了资源感知模块，该模块负责实时统计当前节点的CPU、内存使用率。同时，我们增加了一个可配置的“实例运行上限值”为安全阈值。
2.调度器实现负载决策
服务会周期性地同步所有执行器的实时负载数据，调度器在其资源水位低于预设阈值时，才向其分派新任务。
通过这套基于实时负载反馈的闭环调度，我们确保了任务下发的安全性，有效避免了资源过载，从根本上解决了节点资源被打满的问题。
我们的任务执行模型最初是通过创建独立的任务进程来实现的。这种模式的优劣非常分明：
1.优势（隔离性）
服务进程与任务进程物理隔离，任何单一任务的异常或崩溃都不会影响主服务的稳定性。
2.缺点（高开销）
进程的创建、销毁和上下文切换会消耗大量的系统资源
我们发现，平台上有大量的任务（如数据湖SQL执行）本身较为简单，但在机器资源有限时，上述“重”模式严重限制了并发能力。
针对这一痛点，我们增加了SQL任务的轻量化执行模式。在该模式下，任务不再创建独立进程，而是直接在服务主进程中通过线程来执行。这一优化极大降低了资源消耗，显著提升了简单任务的并发上限，最终实现了整个平台的轻量化部署。
目前，我们的服务平台在经历初期的功能迭代与性能调优后，已进入高可用、高稳定的运行阶段。平台已实现长时间无故障运行，每日可稳定支撑10万+量级的任务调度，为业务的连续性提供了坚实保障。
在稳定运行的同时，我们也识别到在极端负载下（如数据库性能波动时）存在的潜在性能瓶颈。针对此问题，我们后续的核心规划是从根本上优化数据库的存取结构。我们将着力分离大字段的读写操作，消除其对核心数据库性能的冲击与依赖，实现整体服务性能的进一步跃升，彻底解决极端情况下的性能隐患。
展望未来，我们将保持技术前瞻性，从两大方向持续发力：
1.技术驱动
积极跟进并吸收业界优秀的开源项目经验，迭代优化我们的技术栈与架构。
2.生态拓展
计划接入更多元化的数据源，丰富平台功能。
我们将致力于持续完善平台服务质量，不断提升系统韧性与扩展性，为业务创造更大价值。
