企业官网建设流程全解析

一、引言

早期的数据处理任务常由 Linux Cron 驱动，这种方式对少量、相互独立的脚本足够有效。在大数据平台中，任务调度远不只是“每天凌晨执行一段 SQL”。一条数据链路可能包含数据采集、清洗、聚合、质量检查、指标计算和结果分发，任务之间存在复杂依赖，还要处理补数、重试、超时、节点宕机和资源隔离。

因此，调度系统逐渐从“定时器”演化为“工作流状态机”，它不仅触发任务，还要保存任务状态、判断依赖、分配执行节点、处理事件和恢复异常。

DolphinScheduler 聚焦的正是这类数据工程问题：用 DAG 管理复杂依赖，用可视化界面降低编排门槛，再通过多 Master、多 Worker 和故障转移机制提升调度控制面的可用性。

二、核心定位与概念

Apache DolphinScheduler 是一个面向数据编排场景的分布式、可扩展、可视化工作流调度平台。它使用 DAG 表达任务依赖，由 Master 负责工作流编排和状态推进，由 Worker 执行具体任务，并通过注册中心、元数据库和插件体系构建集群协调及扩展能力。它定位为解决大数据任务依赖复杂、ETL 关系难维护、任务健康状态难监控等问题的平台。

理解 DolphinScheduler，可以先掌握六个概念。

静态定义和运行实例必须分开理解。例如，一条“每日销售指标”工作流只有一个定义，但每天运行一次便会产生一个新的工作流实例；工作流内的每个任务也会生成对应任务实例。

DAG 则负责描述任务间的偏序关系：

DAG 只规定依赖，不强制所有任务串行。如果三个清洗任务互不依赖，调度器可以并行分发，从而缩短工作流总耗时。

三、总体架构

DolphinScheduler 采用控制面与执行面分离的思路。Master 负责“决定运行什么”，Worker 负责“执行具体任务”。

+------------------------- 访问与管理层 --------------------------+ | | | Browser / Open API / Python SDK | | | | | v | | +------------------+ +------------------+ | | | API Server |<-------->| UI | | | +------------------+ +------------------+ | | | | +-----------------|------------------------------------------------+ | v +------------------------- 调度控制层 ------------------------------+ | | | +----------------+ +----------------+ | | | MasterServer 1 | | MasterServer 2 | ... | | | DAG 解析 | | 状态推进 | | | | 任务分发 | | 故障转移 | | | +--------+-------+ +-------+--------+ | | | | | | +-----------+-----------+ | | | | | +-------v--------+ | | | Registry Center| | | | ZK/JDBC/Etcd | | | +----------------+ | | | | +----------------+ | | | Metadata DB | | | | 定义/实例/命令 | | | +----------------+ | +---------------------------|---------------------------------------+ | v +------------------------- 任务执行层 ------------------------------+ | | | +----------------+ +----------------+ +----------------+ | | | WorkerServer 1 | | WorkerServer 2 | | WorkerServer N | | | | Shell / SQL | | Spark / Flink | | DataX / Python | | | +----------------+ +----------------+ +----------------+ | | | +---------------------------|---------------------------------------+ | v HDFS / Hive / Spark / Flink 数据库 / 对象存储 / 外部 API +----------------+ | AlertServer | | 邮件/脚本/插件 | +----------------+

1.MasterServer

MasterServer 是工作流调度的大脑，主要负责：

• 扫描待执行命令；
• 创建或恢复工作流实例；
• 解析 DAG；
• 判断当前哪些任务满足运行条件；
• 创建并持久化任务实例；
• 选择 Worker 并分发任务；
• 接收任务状态事件；
• 推进后继节点；
• 处理超时、重试和故障转移。

Master 内部值得关注的组件包括：

DolphinScheduler 的核心并不是简单地遍历 DAG，而是以事件和持久化状态驱动整个工作流生命周期。

2.WorkerServer

WorkerServer 是任务执行节点。它接收 Master 下发的任务，将任务放入线程池，然后由对应任务插件执行。

Worker 内部的关键职责包括：

• WorkerManagerThread ：消费任务队列并提交线程池；
• TaskExecuteThread ：调用相应任务插件；
• RetryReportTaskStatusThread ：向 Master 上报状态，未收到 ACK 时继续重报。 状态 ACK 重报值得特别注意。分布式系统中，任务已经执行完成，不代表 Master 一定收到完成消息。Worker 在未收到确认时继续上报，可以降低网络抖动导致任务状态丢失的概率。

3.注册中心

注册中心承担以下职责：

• Master、Worker 服务注册；
• 节点存活状态维护；
• 节点变化事件通知；
• 分布式锁；
• 故障转移协调。

DolphinScheduler 支持多种注册中心，有 ZooKeeper、JDBC Registry 和 Etcd 三种实现。

4.元数据库

元数据库保存工作流调度的持久化状态，包括：

• 用户、租户和项目；
• 工作流定义及版本；
• 调度配置；
• 调度命令；
• 工作流实例；
• 任务实例；
• 执行状态和参数。

Master 会扫描数据库中的t_ds_command 表来获取待处理命令。数据库因此不只是配置存储，也是调度链路中的关键组件。数据库连接池、索引、事务延迟和可用性都会影响控制面的稳定性。

四、一次工作流如何运行

DolphinScheduler 的典型执行过程如下：

用户发布并触发工作流 | v 生成调度命令，写入元数据库 | v MasterSchedulerService 扫描 t_ds_command | v 创建或恢复 Workflow Instance | v 解析 DAG，查找当前可运行节点 | v 创建并持久化 Task Instance | v 按 Worker Group 与负载策略选择 Worker | v Worker 调用任务插件执行 | v Worker 上报 RUNNING / SUCCESS / FAILURE | v Master 更新状态并检查后继依赖 | +----+----+ | | 依赖满足 仍需等待 | | v +------> 等待后续事件 调度后继任务 | v 所有节点进入终态 | v 计算工作流最终状态并触发告警

这里有三个工程细节。

第一，Master 会先持久化任务实例，再进行任务分发。这使系统能够在故障恢复时识别哪些任务已经创建、哪些任务已经提交、哪些任务仍在运行。

第二，Master 推进的是状态机，而不只是调用脚本。一次状态变化可能触发后继节点、重试、失败策略、告警或工作流结束。

第三，任务执行结果必须具备幂等语义。调度系统可以重新提交任务，却无法自动判断重复执行一条INSERT 、文件上传或外部接口调用是否会产生业务副作用。

五、Worker 负载分配

Worker 选择策略包括：

• RANDOM ：随机选择；
• ROUND_ROBIN ：轮询；
• FIXED_WEIGHTED_ROUND_ROBIN ：固定权重平滑轮询；
• DYNAMIC_WEIGHTED_ROUND_ROBIN ：动态权重平滑轮询。

动态权重策略会综合 CPU 使用率、内存使用率和任务线程池使用率，默认权重分别为 30%、30% 和 40%，三项配置之和必须为 100。负载越低的 Worker，越容易被选中。

调度器看到的“线程池较空”不一定意味着业务执行引擎也有资源。例如 Worker 只负责提交 Spark 作业，而 Spark 集群已经过载，此时 Worker 指标无法完整反映下游计算资源。因此，Worker 分配策略还应配合 Yarn、Kubernetes 或 Spark 队列容量管理。

六、容错机制

1.Master 故障转移

多个 Master 会向注册中心注册。某个 Master 失联后，存活 Master 获取故障转移锁，接管相关工作流实例，然后根据数据库中的持久化状态重新分析 DAG。

恢复过程大致如下：

Master A 宕机 | v 注册中心检测节点消失 | v Master B 获取故障转移锁 | v 查询 A 负责的工作流实例 | +--> RUNNING 任务：继续监控 | +--> 已创建但未入队任务：重新提交 | +--> 已完成任务：保留状态 | v 重新计算 DAG，继续推进

分布式锁用于避免多个 Master 同时恢复同一个实例，节点与注册中心连接超时可能由网络抖动导致；相关服务会选择停止自身，防止节点在失去协调能力后继续运行。

2.Worker 故障转移

Worker 失联后，Master 找出该 Worker 上的任务实例，将任务置于故障转移状态，并重新提交。

这并不等于业务层面的“恰好执行一次”。例如：

INSERT INTO result_table SELECT * FROM source_table;

如果任务在写入成功后、状态上报前发生故障，调度器可能重跑任务。业务应通过分区覆盖、事务、幂等键或先写临时表再交换分区等方式控制重复执行风险。

3.三种重跑行为

DolphinScheduler 区分三种容易混淆的行为：

任务重试适合瞬时错误，例如网络超时。失败恢复适合修复数据或环境后继续执行。全量重跑则适合前序结果也需要重新生成的场景。

七、功能特性与优势

• 可视化 DAG：DolphinScheduler 支持通过 Web UI 拖拽任务节点并连接依赖边。相比纯代码式工作流，可视化方式更便于数据开发、运维和业务技术人员共同查看依赖关系。
• 任务插件：DolphinScheduler 通过插件封装具体任务类型，常见类型包括shell/sql/spark/flink/datax/http/子工作流等。
• 工作流运维：DolphinScheduler具备定时、暂停、恢复、停止、全局及局部参数等工作流控制能力，并强调可视化 DAG、模块化、高可靠和扩展性。
• 补数能力：DolphinScheduler提供补数能力，用于重新计算过去某个时间区间的数据。串行补数对下游压力小，适合任务间存在跨日依赖的场景；并行补数速度更快，但可能瞬间占满数据库、计算队列或外部接口限额。

DolphinScheduler的主要优势：

• 面向数据工程的开箱体验：DolphinScheduler 把 SQL、Shell、Spark、Flink、数据集成、依赖检查和子工作流放在统一平台中。对于传统大数据平台，它通常比从通用任务队列或 Cron 自建依赖系统更省成本。
• 可视化与平台治理结合：可视化 DAG 不只降低创建门槛，也便于故障定位。运维人员可以直接观察失败节点、上下游影响和任务日志，而不必先阅读一套代码仓库。
• 分布式控制面：多 Master 和多 Worker 支持横向扩展。Master 负责调度计算，Worker 负责执行，两类服务可以按不同压力分别扩容。
• 恢复手段较完整：任务重试、失败节点恢复、全流程重跑和服务故障转移分别覆盖不同故障层级。对于依赖链较长的数据工作流，这比“失败后全部重跑”更节省计算资源。
• 插件边界清晰：任务、告警和注册中心均具有插件化扩展路径。团队可以把公司内部计算平台或数据工具封装为任务插件，而不用改写整个调度内核。

DolphinScheduler的局限与使用边界：

• 元数据库压力不可忽略：调度命令、工作流实例和任务实例都保存在数据库中。当任务数量很大时，数据库写入和状态更新可能成为瓶颈。（慢 SQL/表和索引膨胀/历史实例清理/连接池使用率/大字段查询等）
• 调度容错不等于任务幂等：Worker 故障转移、网络超时和状态重报都可能形成不确定的执行边界。任务设计应默认接受“可能重试”，并通过业务主键、分区覆盖、事务或去重机制控制副作用。
• Worker 环境治理有成本：如果通过物理机 Worker 运行 Shell、Spark、Flink、Python 等任务，各节点必须保持客户端、配置文件、JAR、Python 包和环境变量一致。环境漂移会导致“同一个任务在某些 Worker 成功、在另一些 Worker 失败”。
• 可视化编排也会产生治理问题：在 UI 中直接修改工作流很方便，但如果没有发布规范，容易出现环境定义不同、修改缺少代码审查、变更来源不可追踪、批量迁移困难等问题。

八、适用场景

DolphinScheduler 较适合以下场景：

• 企业数据中台和离线数仓；
• Spark、Flink、Hive、SQL 混合任务；
• 数据采集、清洗、质量检查和指标计算；
• 需要按业务日期补数的数据链路；
• 数据开发与运维人员共同管理工作流；
• 需要多租户、Worker Group 和资源权限的平台；
• 希望通过 UI 降低 DAG 维护门槛的团队。

以下场景需要谨慎评估：

• 所有任务都已容器化，并以 Kubernetes CRD 和 GitOps 为主要治理方式；
• 团队坚持工作流必须由代码定义并通过单元测试及代码审查；
• 只有少量独立 Cron 任务，没有复杂依赖和补数需求；
• 大量任务要求强事务或严格的 exactly-once 语义；
• 主要需求是实时流式事件处理，而不是批处理工作流编排。

九、部署使用

DolphinScheduler 提供多种部署方式：

基本部署过程如下：

准备 JDK、数据库、注册中心 | v 下载并解压 DolphinScheduler | v 安装所需插件依赖和 JDBC Driver | v 配置数据库、注册中心、时区和任务运行环境 | v 初始化元数据库 | v 启动 API / Master / Worker / Alert | v 创建租户、用户、项目和工作流 | v 发布并运行工作流

各服务启动成功后，默认 UI 地址为：http://localhost:12345/dolphinscheduler/ui 。

DolphinScheduler最小使用路径可以归纳为：

创建 Tenant | 创建并授权 User | 创建 Project | 创建 Workflow | 拖入 Shell / SQL 等任务 | 连接上下游依赖 | 配置重试、超时和 Worker Group | 保存并上线 | 手动运行或配置 Schedule | 查看 Workflow Instance | 进入 Task Instance 查看日志

User 和 Tenant 不是同一个概念：

• User 用于登录、调用 API 和执行管理操作；
• Tenant 表示任务实际执行时使用的租户身份；
• 在传统 Linux Worker 上，Tenant 通常需要映射到操作系统用户。

十、同类平台对比

调度平台选型建议：

所有任务是否已经容器化，并以 Kubernetes 为统一底座？ | +-- 是 --> 是否强调 CRD、GitOps、Pod 级资源控制？ | | | +-- 是 --> 优先评估 Argo Workflows | +-- 否 --> 团队是否希望主要使用 Python 代码定义 DAG？ | +-- 是 --> 优先评估 Airflow | +-- 否 --> 是否需要可视化编排、补数和多角色协作？ | +-- 是 --> 优先评估 DolphinScheduler | +-- 否 --> 是否维护传统 Hadoop 存量系统？ | +-- Oozie / Azkaban