Apache DolphinScheduler 在大数据环境中的应用与调优

“

下午好，我叫李进勇，是政采云数据平台架构师，在政采云主要负责大数据底层架构和数据工程化方面，同时也是 Dolphinscheduler的PMC成员。今天我将重点分享关于Apache Dolphinscheduler 2.0.9版本中一些优秀的功能。选择这个主题的原因是因为在2.0.X版本的演进中，我们致力于打造一个稳定且功能强大的工作流编排调度平台，使得工作流编排和批处理调度变得更加稳定可靠，因此将此主题命名为“聚焦调度”。

”

文｜李进勇

编辑整理｜ 曾辉

讲师介绍

李进勇

Apache DolphinScheduler PMC

本文主要涉及三大主题：首先，探讨常见的工作流配置模式，其次，介绍DS 2.0.X版本的重要功能特性，最后，分享生产环境下的调优实践。

01

工作流配置模式

在Apache DolphinScheduler中，工作流配置模式以其多样性和灵活性而受到开发者喜爱。

虽然这些配置模式可能已经为大家所熟知，但本文仍会对其进行简单介绍。

主要的配置模式包括单一DAG模式、子工作流串联模式、按数据仓库层级调度工作流依赖模式以及按数据仓库层级调度任务跑批模式。

这些模式在政采云等平台上得到了广泛应用，因此我们发现并修复了其中许多隐藏的问题，也向开源社区进行了反馈。

单一DAG模式是一种常见的配置模式，它能使任务在一个DAG中按照特定的配置进行运行。

尽管此模式较为简单并易于理解，但当任务数量庞大时，维护的困难性就会显现出来。在DS的2.0版本及之后，DAG的更新变成了一个大型事务操作，这对数据库压力较大。

按数据仓库层级调度工作流依赖模式则相对复杂。

它与数据仓库规范相对应，例如按照常见的数据仓库分层如ODS层、DW层、DWS层和ADS层，通过串联这些层级的子工作流来进行调度。

在整体批处理过程中，这种模式可能导致计算集群的空闲度较高。

按数据仓库层级调度任务跑批模式则更具灵活性，它按照依赖节点进行任务调度，而非按子工作流配置。

这种模式可以按照数据仓库分层及数据域来设置工作流，因此某一非关键任务的阻塞不会影响其他任务。

这些配置模式都有各自的特点和适用场景。对于不同的模式，我们也会遇到一些问题和挑战。

例如，在工作流调度时，多个工作节点的分配不均衡可能会导致计算资源的浪费。

此外，当某个非关键任务卡住或失败时，如何处理依赖关系也是一个需要解决的问题。在处理大量YARN日志时，任务停止也可能成为一个问题。

在2.0版本的演进过程中，我们发现了这些问题并做出了相应的解决方案。

02

2.0.X 版本功能特性

接下来，让我们深入探讨DS 2.0.X版本的几个重要功能特性。这些功能包括master召回机制、依赖全任务的强制成功更改、工作流停止的事件通知以及处理极端情况下的问题。

在工作流调度过程中，可能出现任务分配不均衡的情况，这会导致计算资源的浪费。

为解决这一问题，我们引入了master召回机制，通过重新分配任务来解决任务分配不均衡的问题。

另一重要的功能特性是依赖全任务的强制成功更改。

在之前的版本中，我们遇到过某个任务需要人工介入的情况，然而其所在的工作流成功，导致下游依赖的任务得以执行，而上游所需的任务却未执行。

为解决这一问题，我们对工作流的依赖检测方式进行了改进，将其从依赖工作流更改为依赖任务。

工作流停止的事件通知功能也得到了重要的改进。在此前的反馈中，有人提到任务停止时任务状态未得到更改的问题。

我们对任务停止相关代码进行了重构，并加入了新的处理流程，以解决任务停止时的状态更新问题。

最后，我们还修复了DS 2.0.X版本中出现的其他一些问题，比如工作流执行完成子工作流后出现的问题、任务发送失败后无法重新提交的问题以及工作流任务失败时重试时间无效等问题。

针对这些问题，我们进行了有效的修复和改进，提高了系统的稳定性和可靠性。

03

生产环境下的调优

第三部分将分享一些生产环境中的调优经验，包括调度历史的管理、版本清理、调优理念和集群配置。此外，还会提供一些参数和情况的讨论。

在生产环境中，由于工作流定义、任务关系和任务定义的版本历史保存，长期保留这些数据会导致日志表越来越大，进而影响批处理的性能。

因此，建议定期清理版本，例如在政采云中保留最近的20个版本。同样，每天的批处理运行会使工作流实例和任务实例表不断增长，建议进行清理。

具体的清理方法包括删除过时的工作流定义版本，可以使用"DELETE"接口删除无用版本。另外，可以调用"DELETE"接口删除过时的工作流实例，从而清理调度历史。

这部分的代码已经整理并上传至GitHub，大家可以根据需要直接使用。

在进行调优时，我们的目标是以最小的资源完成所需任务。调优的一个关键点是确保集群和DS集群的配比合理，以避免DS成为离线批处理的瓶颈。

例如，如果一个集群最多可以并行处理80个任务，而DS只有两个worker，每个worker并行处理30个任务，那么DS就成为瓶颈。

为了解决这个问题，我们可以增加DS的worker数量，从而减少任务的排队。

同时，并行度参数的设置也非常重要，例如根据机器的规模和任务类型合理地设置并行度参数。我们需要分析各个集群在高峰时段的负载情况，找到适合自己的参数值。通过监控集群整体的批处理负载以及各个worker节点的资源使用情况，可以进行参数的优化调整。

举例来说，对于8个16GB内存的机器，如果任务并行数在20-30左右，任务在本地执行，则参数设置合理。而如果任务在远端执行，可以适当调大并行度参数。同样地，CPU保护和内存预留参数也需要根据机器的配置进行设置，以保证机器的稳定性和性能。

在机器调优完成后，批处理的性能得到了提升，同时也减少了异常情况下的解决和调度工作。经过这些调整及改造，最近半年来，我们再也没有遇到调度引发的集群问题。

在参与开源社区时，我们可以了解到重大版本的变更，并找到适合自己业务情况的版本。对于调度系统，并不是一味追求最新版本，稳定才是最重要的。参与开源社区，在遇到问题时，社区中有很多专家可以帮助定位和解决，这也可以提升个人的技术视野。

总的来说，通过有效的管理和调优，DolphinScheduler在生产环境中可以更高效地运行，更好地服务于大数据处理和分析任务。

希望本文的分享对大家在实际应用和优化DolphinScheduler时有所帮助。

参与贡献

随着国内开源的迅猛崛起，Apache DolphinScheduler 社区迎来蓬勃发展，为了做更好用、易用的调度，真诚欢迎热爱开源的伙伴加入到开源社区中来，为中国开源崛起献上一份自己的力量，让本土开源走向全球。

参与 DolphinScheduler 社区有非常多的参与贡献的方式，包括：

贡献第一个PR(文档、代码) 我们也希望是简单的，第一个PR用于熟悉提交的流程和社区协作以及感受社区的友好度。

社区汇总了以下适合新手的问题列表：https://github.com/apache/dolphinscheduler/issues/5689

非新手问题列表：https://github.com/apache/dolphinscheduler/issues?q=is%3Aopen+is%3Aissue+label%3A%22volunteer+wanted%22

如何参与贡献链接：https://dolphinscheduler.apache.org/zh-cn/community/development/contribute.html