别让大数据任务“互相等着死” ——聊聊任务依赖与 DAG 设计的江湖规矩

兄弟姐妹们，今天咱来聊一个在大数据平台里最容易把人搞破防的问题：任务依赖与 DAG 设计。

我见过太多人刚接触大数据调度系统的时候，张口闭口就一个想法：

“我这 20 个任务，随便排吧，反正跑起来就行。”

然后现实啪啪打脸——
任务死锁、每日延迟、数据不一致、补数像剥洋葱一样一层层回溯，甚至一个表延迟 8 小时，让上游中游下游同时骂娘。

那问题出在哪？
不在 SQL，不在 Spark，不在存储。很多时候死在任务依赖管理。

一、DAG 到底解决啥问题？别装了，说人话！

所谓 DAG（Directed Acyclic Graph）——有向无环图。
说人话就是：

• “我先跑谁，再跑谁”
• “谁依赖谁”
• “不能绕一圈最终依赖自己”

它解决的是核心大问题：

1. 数据要有顺序
2. 任务不能死循环
3. 能可视化可追踪可补数
4. 任务延迟可定位

你要是想象大数据任务是一排排多米诺骨牌，
DAG 的意义就在于：

谁先倒，谁后倒，不能倒回头。

二、为什么“依赖管理”是大数据的生死线？

举个真实案例：

你有个数据仓库：

• A 表：用户基础数据
• B 表：订单信息
• C 表：订单聚合日报
• D 表：数据分析结果报表

如果 B 依赖 A，C 依赖 B，D 依赖 C。
结果有人把 D 表给调到凌晨 2 点跑，还让 B 在 2 点半才完成。

于是 D 表利用的是前一天的老数据——
然后 BI 报表展示数据穿越回过去。
业务线狂骂：

“昨天数据怎么变回前天的？！”

这就是依赖顺序坏了，系统还能跑，但跑错了。

所以真实的坑是：

• 错数据比不产出还致命
• 延迟会传染整个链路
• 补数越补越乱
• 任务之间互相等死

我见过最恶心的情况：
400 条任务彼此依赖，竟然绕成了环，大家互相等，最终凌晨 3 点没有一条任务触发。

那叫一个壮观。

三、DAG 设计的三条“江湖规矩”

规矩 1：数据分层必须天然支持 DAG

最怕有人上来就一个肥 SQL，从 ODS 拉到 DW，再 join 维表，再算指标，然后存三份结果，最后写入 Kylin 立方。

兄弟，这叫自我毁灭。

数据层次应该是什么？

ODS → DWD → DWS → ADS

每层做一件事：

• ODS 保留原始宽表
• DWD 清洗、规范、建模
• DWS 主题聚合
• ADS 面向业务呈现

每层都是 DAG 的 Checkpoint，这样依赖天然分离。

规矩 2：一个任务干一件事，多任务组合复杂逻辑

新手会干这种事情：

“我要对账、聚合、指标计算一起算。”

导致任务过重、依赖不可拆、补数牵一发而动全身。

正确方式：

• 一个任务只产一份数据
• 多任务组合实现业务逻辑
• 依赖清晰、可重跑、可复用

简单粗暴一句话：

计算拆开写，成果少量存。

规矩 3：依赖必须显式写出来，不能靠猜

依赖不写清楚会怎样？

• 下游永远比上游早跑
• Spark 跑个寂寞
• 计算结果全是旧数据

Airflow / DolphinScheduler / Azkaban / Oozie
都支持显式依赖：

# Airflow 示例
from airflow import DAG
from airflow.operators.dummy_operator import DummyOperator

with DAG('demo_dag') as dag:
    task_A = DummyOperator(task_id='A')
    task_B = DummyOperator(task_id='B')
    task_C = DummyOperator(task_id='C')

    task_A >> task_B >> task_C  # DAG: A -> B -> C

这就是 DAG 的灵魂：
明确告诉系统，顺序必须这样走。

四、再聊依赖管理中的“坑点”

坑 1：任务时间窗口对不上

有的人任务每天跑 2 点，有的人 4 点，还相互依赖。

这叫：时间对不上，永远跑不对

一个成熟平台必须：

• 上游完成时间可估
• 下游根据上游快照等候
• 用 event 触发更可靠

坑 2：依赖过深，让补数成为灾难

我见过数据补数补出 PTSD 的同事。
原因是链路太深：

A → B → C → D → E → F → G → H…

补 A 需要等全部链路反应，补出来还要

• 校验数据
• 回填
• 重跑报表

正确方式：

• 聚合层少
• 缓存层全
• 每层独立可重建

说白了：

可补性是 DAG 的终极价值。

坑 3：血缘关系不清晰

一个表被三十个下游依赖，
结构改动还不通知。

这一刀砍下去，下游全挂。
血缘图必须明确：

• 谁用我
• 我依赖谁
• 改动影响到谁

五、一个干净利落的 DAG 设计示例

我们用 Spark 模拟一个分层计算逻辑：

# DWD: 清洗日志
df_dwd = spark.sql("""
    SELECT user_id, event_time, action
    FROM ods_event_log
    WHERE event_time >= date_sub(current_date(), 1)
""")
df_dwd.createOrReplaceTempView("dwd_event")

# DWS: 聚合
df_dws = spark.sql("""
    SELECT user_id, COUNT(*) as action_cnt
    FROM dwd_event
    GROUP BY user_id
""")
df_dws.createOrReplaceTempView("dws_user_action")

# ADS: 产出报表
df_ads = spark.sql("""
    SELECT u.user_id, a.action_cnt, u.level
    FROM dws_user_action a
    JOIN dwd_user_info u
    ON a.user_id = u.user_id
""")

每一层都是 DAG 的节点。

六、那我们到底要怎么做？五条落地建议

1. 依赖要写死，不靠时间猜
2. 数据分层天然保护 DAG 结构
3. 多任务组合，小任务原子化
4. 每层都可以补数
5. 血缘清晰、依赖透明

一句核心：

DAG 不仅是技术，更是工程治理。

七、最后说点感受：

做大数据的这几年，我越来越感觉到：

• 技术不是决定成败的关键
• 硬件算力也不是最大瓶颈
• 运营过程才最折磨人