2024年Apache DolphinScheduler RoadMap：引领开源调度系统的未来

非常欢迎大家来到Apache DolphinScheduler社区！随着开源技术在全球范围内的快速发展，社区的贡献者 “同仁” 一直致力于构建一个强大而活跃的开源调度系统社区，为用户提供高效、可靠的任务调度和工作流管理解决方案。

file

在过去的一段时间里，我们取得了一些重要的成就，但我们的愿景远未实现。为了更好地满足用户需求和推动项目的发展，我们在2024 新春伊始，制定了以下Roadmap，将在未来的版本中实现一系列激动人心的功能和改进。

当前社区状态

2024 年 roadmap 有两个来源，部分是来自 2023 年发起但是没有开始实施，或者实施了部分的议题，另一部分是最新新增的议题。2024 年 roadmap 可以分成如下几个部分

云原生相关：我们希望增加 K8S executor 复用 K8S 提供的能力做弹性资源管理、监控和失败重试等

任务插件增强：我们收到了用户关于任务插件的诉求，将会进一步支持 streaming 类型的任务、trigger 类型插件等，除此之外，我们还希望统一在worker 和master 中运行的任务、以及为任务插件增加生命周期的接口。于此同时我们会持续关注动态任务组件的功能，希望以后可以对任务组件单独发版保证迭代频率

DataOps 相关：希望引入 data ops 相关功能，通过集成 git 供应商来实现 git ops，最终实现工作流 CICD

测试：我们会继续完善和增加项目单元测试覆盖率，并且逐步补充 API 部分的测试

其他优化：引入工作流事件触发功能；优化审计日志

云原生相关

我们希望引入 K8S executor 作为 dispatcher 将 dolphinscheduler 的任务分发到 K8S 中，K8S executor 的好处是我们可以有更高的资源利用率；沿用 K8S 的监控机制，实现 pod level 的监控；沿用 pod 容错做任务容错。

这个设计的核心是将executor 的抽象出来变成可配置的，用户可以选择 K8S 或者非 K8S 的 executor，如果选择 K8S executor ，dolphinscheduler 会将任务提交到 K8S API server ，每个任务启动一个 worker，运行一个 pod。这一点的好处是 worker 不是一个长期运行的资源，而是仅当有任务的时候才需要启动。当业务低谷的时候，我们有空运行的worker 来等待任务运行。

详情请看链接：https://github.com/apache/dolphinscheduler/issues/13316

file

任务插件增强

streaming 任务类型增强

2023年 dolphinscheduler 社区增加了 streaming 任务类型的支持，但是是使用shell 提交 flink 任务，一经推出收获了不少用户。当时实现的是一个简单版本，想看看用户反馈，开发者在开发过程，以及用户的使用中发现了部分可优化项。这部分优化项目我们希望能在 2024 年有部分进展，其中包括

使用 flink sdk 去创建和提交任务，目前的 shell 方式提交不能很好的监控和处理运行中的任务，使用 sdk 可以有更多功能的支持，详情请看链接： https://github.com/apache/dolphinscheduler/issues/11440
支持 flink sql
增加 flink 的指标
增加 checkpoints savepoint 管理，保证任务失败重试等异常情况能继续执行

详情请查看 https://github.com/apache/dolphinscheduler/issues/11352

动态任务组件 & 任务单独发版

这个任务是引入动态任务组件的概念，将任务组件的参数通过后端定义，然后在前端渲染，希望通过这样方法化简任务组件的开发流程，在参数的输入类型没有新增的情况下，可以不修改或者少修改前端代码而实现任务组件的新增和修改。

详情请看链接：https://github.com/apache/dolphinscheduler/issues/12526

同时这个任务也是我们将任务插件单独发版的前置任务，任务插件单独发版也是非常重要的功能，实现了这个功能后，我们可以加快任务插件的发版频率，保证用户使用的是功能丰富、最新的任务插件。例如我们有一个新的任务插件 A ，这个插件在昨天被 merge 到 dev 分支，那么我们今天就能安排这个插件的发版。又例如我们发现了已经发版的任务插件 B 有比较严重的 bug，在这个bug 被 fix 后，我们就能安排插件的bugfix 版本发版。

这个任务已经实现了已经简单的demo，详情请看链接： https://github.com/apache/dolphinscheduler/issues/12526

任务插件生命周期管理

为任务插件增加 close 方法从而更好的管理任务插件，特别是需要关闭资源的的任务组件，如数据库、云计算资源任务等。我们目前为任务插件定义了 init、handle、cancel 等方法，对于关闭资源的方法都是在任务中单独实现的，所以希望抽象一个 close 方法统一处理需要关闭资源的任务。

详情请看链接： https://github.com/apache/dolphinscheduler/issues/14877

统一 worker 和逻辑任务

dolphinscheduler 现在有两个类型的任务 spi，分别是 worker 任务和逻辑任务，这两种任务类型分别是运行在 worker 上的，以及运行在 master 上的。不同的 spi 导致两种任务有不同的生命周期管理，并且不利于后面动态任务组件的实现，所以需要将两种任务尽可能弄成统一spi。

详情请看链接： https://github.com/apache/dolphinscheduler/issues/14823

Git Ops

dolphinscheduler 在处理生产和开发环境的时候，只能通过json导入导出来实现，社区部分伙伴建议我们可以使用 gitops 方法论来实现开发到生产环境的部署。GitOps 是一种基于版本控制系统的持续交付和基础设施管理的方法。它的核心理念是将整个系统的状态和配置存储在版本控制库中，通过Git的特性实现对系统的自动化管理和持续交付。

gitops 支持

希望将工作流相关资源的校验、工作流部署到生产环境的功能集成到 dolphinscheduler 中，集成之后只需要在 dolphinscheduler 配置 git 供应商的 url 和鉴权信息，就能在远程仓库中有新的push 事件后，立马触发工作流的更新操作，从而保证生产中的工作流和远端 git 供应商的定义是一样的，实现客户的 cicd ，保证流程简单便捷

测试

测试对于开源软件至关重要，它不仅确保软件质量和稳定性，还提高了用户体验。通过全面的测试，可以及时发现和修复潜在的问题，增强软件的可靠性。测试也是保证新功能引入不破坏现有功能的关键，为开源项目的可持续发展提供了坚实的基础。dolphinscheduler 社区从 2023 年一直在努力提高测试覆盖度、并做了优化让贡献者更加方便的写测试，但是测试的增强是一个长期的工作，2024 年我们会坚持这部分内容

API 测试

在 api 层面的测试，确保我们核心的 api 接口能正常运行。当被 api 测试覆盖的接口，可以确保每次提交新代码时，API 接口逻辑和依赖关系都正确，不会破坏之前已有的功能。补充缺失的单元测试，确保接口与接口之间的连接性。dolphinscheduler 社区在 2023 年已经启动 api 测试的补充，目前部分核心接口已经覆盖，希望在 2024 年将尽可能多的 api 接口进行覆盖。

详情请看链接： https://github.com/apache/dolphinscheduler/issues/10411

UT 增强

单元测试对比 API 测试是粒度更加小的，他能保证部分代码块如预期般工作，在此之前我们升级到了 junit5，并且增加了worker 部分的测试覆盖率，与 api 测试一样的是，这是一个长期的工作，同时需要更多有激情的贡献者参与到该功能的建设中。

详情请看链接： https://github.com/apache/dolphinscheduler/issues/10573