DolphinScheduler 实战：从第一个 DAG 到生产级调度的 6 个关键动作-育师

DolphinScheduler 实战：从第一个 DAG 到生产级调度的 6 个关键动作

【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler

凌晨一点，你被电话叫醒：昨天的增量数据还没跑完，早上九点的经营看板交不出去。你登机器翻日志，发现上游同步脚本卡了 40 分钟，而你根本不知道它卡在哪一步。这类"链路一长就失控"的问题，靠人肉盯着和 crontab 堆脚本是解决不了的，你需要的是一套分布式工作流调度系统——DolphinScheduler 就是干这个的：把任务编排成 DAG，声明依赖和周期，剩下的交给 Master/Worker 集群去执行和容错。

下面不从头讲理论，直接按一条链路的生命周期走：先把第一个 DAG 跑起来，再接一条完整的数据管道，然后让模型流水线上线，最后聊聊上了生产之后那些容易翻车的细节。

1. 把第一个 DAG 跑起来：任务编排的搭积木逻辑

为什么"声明依赖"比"写死顺序"重要

新手最常见的做法是写一个大脚本：step1.sh && step2.sh && step3.sh，或者干脆在代码里 sleep 等上游。这种写法的代价很具体：第二步依赖的第一步没跑完就空跑；某一步失败，整条链静默结束，没有任何人知道；想只重跑第三步，得把前两步的幂等性都保证好。

DAG（有向无环图）的思路是把"顺序"从代码里拿出来，变成声明：你只说"B 依赖 A"，执行计划由调度器算。这样带来三个直接好处——能并行的节点自动并行、失败节点可以单独重跑、链路图在界面上随时可看。

搭积木的递进过程

第一个工作流从最简单的两个节点开始：一个 SHELL 任务拉数据，一个 SQL 任务落仓，连一条线。跑通之后，再往上面"搭积木"：

这里的关键动作有三个，每一个都对应一个"不这么做的代价"：

任务先定义，再连线。DolphinScheduler 里任务定义（Task Definition）和工作流定义是分开的，同一个任务可以被多个工作流复用。代价对照：如果每次都把任务写死在某个工作流里，改一处逻辑要翻 N 个流程。
依赖关系显式声明。B 和 C 都依赖 A，但互不依赖——调度器会自动并行执行它们。不声明的代价是链路实际耗时等于各任务之和，凌晨的任务拖到早上。
失败策略留在任务级别配置：失败重试次数、重试间隔、超时告警都是节点属性，不是全局一刀切。同步类任务值得重试，幂等性差的写入任务重试前要先确认前置条件。

界面左侧是任务类型清单，右侧画布拖出来连成图。连完点"运行"，你在工作流实例页能看到每个节点的状态流转，哪个节点红了一眼就找到。

周期触发：从手动到定时

DAG 跑通后，给它挂一个定时触发（通常是 cron 表达式），这才是"调度"而不是"手动执行"。建议第一个定时流程就配一个"失败告警"，哪怕先指向自己的邮箱——没有告警的定时任务是定时埋雷。

依赖关系一旦声明清楚，这条链路的耗时、失败点、重跑入口就都变成了可见、可操作的东西，接下来可以开始往上面接真实的数据管道了。

2. 数据从 A 到 B 的完整链路：ETL 管道的编排思路

一条链路的主轴

拿最常见的场景说话：业务库 MySQL 每天凌晨把订单增量同步到 Hive，清洗聚合后写入报表库。这条链路上的每个环节，选什么工具是"手段"层面的决策，编排才决定链路是否可靠：

三个环节的分工：DataX 管搬运，它是这条链上最快的通道，按分片键并发抽取；Spark/SQL 管重计算，大表关联、聚合这类脏活丢给集群；Python 管零活，去重规则、字段映射这类三五分钟写清楚的逻辑，不必为一个 UDF 起一个 Spark 作业。

DataX 通道数怎么调不翻车

DataX 任务里真正影响成败的参数就三个，其余都是装饰：

splitPk：抽取分片键。不配它，reader 退化成单线程全表扫，同步时间直接翻几倍；配了但选错列（比如没有索引的字符串列），数据库侧压力会失控。
channel：并发通道数。经验值从 3~5 起步，翻倍观察源库 CPU 和同步耗时的变化，取耗时收益递减的拐点。无脑拉满的代价是源库慢查询，第二天业务方比你还先发现问题。
batchSize：攒批写入大小。批太小写入放大，批太大内存吃紧，1000 左右通常是安全区。

"setting": { "speed": { "channel": 5 }, "errorLimit": { "record": 0 } }

errorLimit值得单独说：同步类任务建议置 0，一条脏数据都不该静默通过，宁可失败重跑。

上图是 DataX 节点的关键配置区：失败重试次数、重试间隔、任务优先级、Worker 分组都在这一个面板里。把"同步任务失败重试 3 次、间隔 5 分钟"配在这里，比在脚本里写while循环可靠得多——重试发生在调度层，日志、状态、告警都是完整的。

让链路"断得明白、接得回来"

ETL 管道最容易翻车的地方不是某个环节写错，而是环节之间状态丢失。两个动作能兜住：抽取后落一个水位（分区或时间戳标记），清洗后做行数/金额合计校验（DolphinScheduler 的 DATA_QUALITY 节点或一个 SQL 任务都能做）。校验失败就断链、告警，而不是把脏数据灌到报表库。

链路通了之后你会发现一个规律：数据管道稳定下来后，下一个"从实验到生产"的诉求，往往来自算法团队——他们手里也有同样的问题，只是主角换成了模型。

3. 让模型从 notebook 走到线上：MLOps 流水线设计

为什么 notebook 实验必须被流水线化

算法同学在 notebook 里跑出一个 AUC 0.91 的模型，然后它消失了：没人记得用了哪份数据、哪个特征版本、什么超参。三个月后想复现，只能重跑。MLOps 要解决的就是让"训练"变成和 ETL 一样有版本、有追溯、可重放的一条流水线。

流水线的四个状态

每个状态对应一个任务节点，衔接靠声明式依赖，不靠人喊。

实验追踪：让每次训练都有档案

DolphinScheduler 的 MLflow 任务插件把"训练"变成一种可编排的任务类型：指定实验名、算法、数据路径，训练结束后 run 自动上报到 MLflow 服务端。追踪的三个要素别省：

experiment 按模型/业务线划分，run 按日期或版本划分，命名规则定死——命名混乱的追踪库比没有追踪还难用；
参数、指标、产物（模型文件）三样都要记录，只记 AUC 不记超参，等于只记了结果没记原因；
tracking URI 配置在任务里，指向团队共用的 MLflow server，而不是每个人本地 5000 端口。

上图是一次实验下的 runs 列表：参数（algorithm）和指标（accuracy、f1-score）逐条可查、可对比。评估节点做的事也很简单——读最近一次 run 的指标，不达标就把工作流导向"超参调优"分支，达标才放行到模型注册。这一步用一个条件节点就能表达，省掉的人工是：再也不用有人盯着训练完手动判断。

可重复、可追溯的底线

部署节点里，通常的做法是：从模型注册表拉指定版本，构建镜像或写制品库，再触发下游的发布流程。关键纪律是线上跑的永远是注册表里的某个版本号，而不是"最新的那个"。做到这一点之后，回滚就从"凭记忆找回旧代码"降级为"改一个版本号重跑流水线"。

模型这条线跑稳之后，真正的考验才开始：前面所有链路，从单机 demo 挪到多机集群上，会暴露一批 demo 里根本看不到的问题。

4. 上了生产别裸奔：高可用、监控与容灾

坑 1：单 Master 跑着跑着就成单点

现象：Master 机器宕机，所有定时任务集体停摆，半小时后没人发现。对策：Master、Worker 都部署多副本，服务注册和故障转移走注册中心（ZooKeeper 或 etcd）。Master 之间通过分布式锁协调，挂掉一个，命令由存活节点接管；Worker 挂掉，其上运行的任务由容错机制重新调度。

不这么做的代价按小时计：一个单点故障吞掉整个凌晨批次，白天补数+对账的人力远超你为多部署两台机器花的成本。

坑 2：队列堆了多少任务，没人知道

现象：Worker 线程池打满，几百个任务在"排队中"泡着，业务方问"跑完没了"，你答不上来。对策：两类指标进监控——Worker 的线程池使用率和 CPU/内存（内置 Monitor 页面就有），调度侧的等待队列长度。线程池使用率持续 80% 以上且队列在涨，就是扩容信号，别等任务超时了才动手。

告警规则宁可先粗后细：先接"队列积压"和"任务失败率"两条，跑两周再补细粒度的，上来就配 30 条规则的团队最后都会调成静默。

坑 3：Kubernetes 部署的三个容易忘的配置

容器化部署走 Helm 的话，values 里有三个点最容易"默认值进生产"：

外部数据库：默认嵌入式/本地库撑不过第一次发版，指向集群里的 MySQL 或 PostgreSQL；
外部注册中心：ZooKeeper 三节点起，Master/Worker 全靠它做服务发现和故障转移；
副本数与资源 requests/limits：Master 建议 3 副本起步（要奇数，锁协调才有仲裁），Worker 按任务并发压测后定，requests 至少给到实际用量的一半，避免节点紧张时被驱逐。

坑 4：数据只进不出，库越跑越胖

现象：半年后元数据库几十 GB，查询越来越慢。对策：例行任务里放一个归档/清理节点，历史实例和日志按保留期（常见 30~90 天）清理，冷数据导出到对象存储；数据库侧对实例表的状态+时间列补索引。备份脚本每周全量+每日增量，恢复演练每半年一次——没恢复过的备份约等于没有。

调度侧稳了，剩下就是"这套东西适不适合你的场景"的问题——不同团队踩的坑不一样，最后给一份可以直接照抄的清单。

5. 选型与避坑清单

选型建议，按场景对号入座：

任务是批处理、跑在 Hadoop/YARN 或 K8s 上、团队已有 Hive/Spark 资产——DolphinScheduler 的适配度很高，任务类型基本覆盖；
任务形态是大量短平快脚本、且团队已有 Airflow 使用习惯——对比一下两者再定，迁移成本是真实成本；
有跨团队依赖（等别组的工作流跑完才能开工）——确认你要的"跨工作流依赖"能力在你的使用方式下成立，通常的做法是配合 DEPENDENT 类任务或上游产出标记；
环境是纯 K8s——直接用 Helm 方案，别在容器里再塞一层裸进程管理；
数据量小、链路不超过 5 个节点——先别上集群，单机模式把编排习惯养出来再说。

常见反模式，见过就会躲：