Apache DolphinScheduler 在腾讯音乐的应用实践

在选型过程中，我们考虑了以下几个产品的性能和功能：

Airflow

Oozie

Taier

Azkaban

DolphinScheduler

Airflow 和 Oozie 都需要编码工作，如编写 Python 代码或 XML 配置。

近年来，Azkaban 社区活跃度较低，并存在一些问题。

Taier 是一个新的项目，但稳定性较弱，并且在验证过程中发现了一些业务问题。

最终，我们选择了 Apache DolphinScheduler，因为它具有较为活跃的社区、丰富的功能扩展性和文档支持。

我们选择 Apache DolphinScheduler 之后进行了二次开发，主要集中在以下几个方面。

首先是业务版本管理，原有的版本管理无法满足我们的业务需求。

在发布之前，我们可以将工作流或任务提交到具有业务含义的业务版本上，并建立与底层的工作流和任务定义表的映射关系。在运行过程中，我们将业务版本转换为物理版本，并进行执行和展示。

这样，我们在提交时可以选择具有业务含义的版本。

我们发现原有的导出导入功能在开发、测试和生产环境中的发布过程中存在问题。做了适配之后，将测试环境中的资源ID转换为名称，并在导出的工作流 JSON 中进行导出。

在新环境中进行导入时，再将这些名称适配为新环境的资源ID。

这样，导入后的工作流可以直接使用，避免了跨环境发布后资源无法找到。

在项目开发和测试过程中，通常需要在不同的数据源和工具之间切换，差异化环境给开发带来了一定负担。为了解决这个问题，我们将数据探索功能集成到 Apache DolphinScheduler 中。

开发人员可以直接在平台上选择数据源类型和对应的数据源信息，并进行 SQL 编辑和测试运行。执行完毕后，结果会进行展示。

未来，我们还计划将 SQL 直接生成作业的功能加入平台。

我们对开源版本进行了定制化改造。除了常见的任务依赖，我们加入了三种特定的依赖类型。首先是内部依赖，针对平台内部的跨项目指定工作流任务是否完成。

其次，我们支持检查 Airflow 任务的运行情况，将 Airflow 的数据源注册到平台，并检查同一周期内的任务是否完成。

最后，我们支持数据依赖，可以通过编写 SQL 检查业务系统数据的状态是否满足运行条件。

为了满足业务需求，我们将任务的创建从工作流中拆分出来，任务可以脱离工作流单独创建，修改后，任务可以单独创建和编辑，开发人员确认无误后，将其关联到工作流中。

这时因为任务还未加入工作流，无法独立运行，这时会自动创建一个虚拟工作流来运行任务，并在前端展示时做了筛选，避免虚拟工作流实例显示在界面上。

此外，程序会定期清理虚拟工作流实例，避免对性能造成影响。

通过 Apache DolphinScheduler 平台，可以查看工作流和任务实例运行过程的基础监控；

但针对一些特殊场景时监控不到的，如平台挂掉时未及时调起的高优先级任务或执行时间超长的任务。

我们开发了一些小工具，对 DS 和 Airflow 进行监控，包括应调度未调度、应完成未完成和失败实时告警等监控场景的补充。

在开发过程中任务遇到异常时，我们通常需要查看任务运行日志、结合  DolphinScheduler 的日志和其他工具（如 Yarn 和 Starrocks）的日志来排查问题。

然而，这个过程需要查看大量的日志，并且需要逐个任务进行定位和排查，效率较低。

为了解决这个问题，我们建立了一个规则库，用于记录运行错误的任务日志，并将其分类保存在任务异常表中。通过程序对这些日志按照规则进行分类，为每个任务添加异常原因和分类标记。基于这些数据，我们可以提供相应的异常分析报告、平台运营看板、异常定位等。

此外，针对工作流和任务的多人编辑问题，我们引入了锁机制，确保同一时间只有一个人可以编辑或提交。

另外，我们改进了资源上传编辑的流程，避免了对多个任务逐一修改资源的繁琐操作。

我们将数据源的密码放置在密码服务中，而非本地存储，以确保数据源密码的安全性。

此外，我们还进行了其他数据源扩展和元数据采集的工作。

通过元数据采集的 SDK，我们可以创建数据采集作业并指定要采集的数据源和范围，并配置定时周期进行采集。

我们还进行了一些 bug 修复，例如修复了 SQL 文件中逗号分号分割的 SQL 的支持等。