离线作业300+，凌晨3点告警把我叫醒——任务调度怎么治理？

// 治理前的DAG依赖（过度依赖）
ods_ad_click -> dwd_ad_click -> dws_channel_roi -> ads_roi_report
                                     ^
              dim_content_tag --------+  <- 不必要的强依赖！
                                        内容标签跟ROI没关系
 
// 治理后的DAG依赖（解耦）
ods_ad_click -> dwd_ad_click -> dws_channel_roi -> ads_roi_report
 
dim_content_tag -> dws_content_analysis -> ads_content_report  (独立链路)

// 作业分级配置示例
 
// P0作业配置：
// priority: HIGH
// retry_count: 3
// retry_interval: 5min
// timeout: 60min（超时即告警）
// alert_channel: 电话 + 企微群 + 短信
// SLA_deadline: 08:00
 
// P1作业配置：
// priority: MEDIUM
// retry_count: 3
// timeout: 120min
// alert_channel: 企微群
// SLA_deadline: 10:00
 
// P2作业配置：
// priority: LOW
// retry_count: 3
// timeout: 180min
// alert_channel: 邮件
// SLA_deadline: 14:00

分级的关键价值：P0作业的资源优先级最高，调度引擎优先分配资源给P0。当集群资源紧张时，P2作业可以排队等待，但P0作业必须立即运行。这避免了'一个不重要的作业占用大量资源导致核心报表超时'的问题。

幂等设计：重跑不出错

幂等是调度治理的基本功——任何作业重跑N次结果必须一样。看起来简单，但很容易踩坑：

-- 幂等写法：INSERT OVERWRITE（重跑会覆盖，结果一样）
INSERT OVERWRITE TABLE dws_channel_roi_1d PARTITION(dt='${bizdate}')
SELECT channel, country_code, SUM(pay_amount) AS revenue
FROM dwd_user_payment_di WHERE dt='${bizdate}'
GROUP BY channel, country_code;
 
-- 非幂等写法：INSERT INTO（重跑会重复插入！）
INSERT INTO TABLE dws_channel_roi_1d PARTITION(dt='${bizdate}')
SELECT channel, country_code, SUM(pay_amount) AS revenue
FROM dwd_user_payment_di WHERE dt='${bizdate}'
GROUP BY channel, country_code;
-- 重跑一次：数据翻倍！重跑两次：数据翻三倍！
 
-- 如果必须用INSERT INTO，先DELETE再INSERT
-- 在Hive中用INSERT OVERWRITE + 分区来实现
-- 在Doris/Hologres中先DELETE WHERE dt=xxx再INSERT

面试高频追问

追问一：你们用什么调度工具？为什么选它？

我们在短剧出海公司用的是DataWorks（阿里云自带），在出海硬件品牌用的是Airflow。选择标准：如果全套阿里云技术栈（MaxCompute/Hologres），DataWorks是最省事的——跟阿里云服务原生集成，不需要自己搭建和运维。如果是开源技术栈（Spark/Hive on AWS），Airflow是社区最活跃的选择——Python写DAG灵活度高，但需要自己运维Airflow集群。DolphinScheduler也是好选择，国内社区活跃，适合中大型团队，但学习曲线比Airflow陡。

追问二：上游任务失败了，下游自动重跑时怎么保证数据正确？

靠幂等+依赖检查。上游成功重跑后，调度工具会检测到上游状态变成'成功'，自动触发下游运行。因为下游是INSERT OVERWRITE（幂等），不管运行几次结果都一样。但有一个陷阱：如果上游重跑后数据变了（比如修了一个bug，数据量从100万变成120万），下游必须也要重跑——不能只重跑上游不重跑下游，否则下游还是基于旧数据。我们的做法是：P0链路上游重跑后，自动级联重跑所有下游。

追问三：怎么处理跨天运行的长任务？

这在大数据量场景很常见——凌晨0点开始跑，2点还没跑完，第二天的调度已经开始了。我们的策略是：① 每个作业设超时时间（P0作业60分钟，超时即告警排查）；② 长任务拆分成多个子任务并行执行（比如按国家分区并行处理）；③ 调度层面设置互斥锁——同一个作业不允许两个实例同时运行，后一个实例必须等前一个完成后才开始。

实战踩坑

调度治理中最痛的一次经历：某天凌晨4点，P0的ROI报表因为依赖链路太长（5层深度，ODS→DWD→DWS→中间表→ADS→推送Hologres），其中一个中间层的Spark作业因为数据倾斜跑了3个小时还没完成。等全链路跑完已经上午11点了——业务方等了3个小时。

后来我们做了两个优化：① 缩短关键链路深度——把5层压缩到3层，去掉了不必要的中间表（直接在DWS里做了之前中间表的逻辑）；② 给每一层设置超时阈值——如果DWD在凌晨2点前没完成，跳过DWS的常规链路，直接用昨天DWS的数据+今天的增量做快速合并出ADS，保证8点前有数据（虽然可能不是最精确的）。

// 关键链路优化：降低DAG深度
 
// 治理前（5层，端到端3-4小时）
ODS -> DWD -> DWS -> tmp_roi_detail -> ADS -> Hologres推送
     30min  40min  60min(倾斜!)  20min  10min
 
// 治理后（3层，端到端1.5小时）
ODS -> DWD -> DWS(含原tmp逻辑) -> ADS+推送
     30min  50min              20min
 
// 降级方案（保底）
如果DWS在02:00前未完成：
-> 触发降级任务
-> 用昨天DWS + 今天增量ODS快速合并出ADS
-> 数据可能有1-2%误差，但保证08:00前有数据

总结

调度治理的三板斧：理清DAG依赖（解耦不必要的强依赖）、作业分级（P0/P1/P2差异化SLA）、幂等设计（INSERT OVERWRITE天然幂等）。面试时讲调度，不要只说'我们用Airflow/DataWorks'——要能说出你管理多少个作业、怎么分级、遇到过什么调度事故以及怎么优化的。调度治理不是技术难题，是工程管理能力的体现。

调度管好了，但数据质量出问题才是最致命的——下游报表全错了。下一篇聊数据质量监控体系怎么建，包括质量规则、告警机制和数据血缘。

你们有多少离线任务？凌晨被告警叫醒过吗？最长的任务跑多久？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长