大数据与AI：数仓团队用AI预测ETL任务当天是否会出问题（空值率飙升、数据量波动），需要把哪些历史日志特征喂给模型？

一、问题定义：什么叫“当天出问题”

做预测之前，最容易被跳过、也最致命的一步是标签定义。很多团队上来就拉日志、跑XGBoost，AUC刷到0.95，上线后却毫无价值——原因往往不是模型不行，而是“出问题”这三个字从来没被精确定义过。

在数仓语境下，“当天出问题”至少包含四类互不相同的故障形态，它们的特征分布差异极大，混在一起训练会让模型学到一个“四不像”的决策边界：

• 执行失败：任务状态为FAILED、超时被杀、资源申请失败。这类标签最干净，直接从调度系统（Airflow、DolphinScheduler、DataWorks等）的任务实例表取。
• 延迟产出：任务成功但完成时间晚于SLA承诺时间，导致下游报表无法按时刷新。标签需要结合SLA配置与完成时间戳计算。
• 数据质量异常：任务成功、按时完成，但产出数据的空值率、数据量、主键唯一性、枚举取值分布偏离历史基线。这类最隐蔽，也最需要“日志特征”支撑。
• 静默错误：数据质量规则没覆盖到、业务方事后才发现的口径错误。这类标签噪声最大，通常只能靠人工回填的故障工单获取。

笔者认为，工程上务实的做法是先做“执行失败+延迟产出”的联合标签，把数据质量异常作为第二阶段目标。原因很直接：前两类的标签来自系统日志、客观可追溯，样本量大、噪声低；数据质量异常的判定依赖规则阈值，而阈值本身是人为设定的，直接拿来当标签会把“规则没调好”误学成“任务会出问题”。

一个可操作的标签定义示例（模拟口径，供参考）：任务实例满足以下任一条件即标为正样本——① 状态为FAILED；② 完成时间晚于SLA时间超过15分钟；③ 产出分区行数为0。负样本为状态SUCCESS、按时完成且行数大于0的实例。标签时间粒度对齐到“调度日+任务ID”。

需要强调的是，预测目标的时间语义必须与决策时点对齐。如果模型在任务启动前就要给出预警（这是最有价值的场景），那么所有特征只能使用“任务启动之前”可获得的信息；如果允许在任务运行中途预警，则可以使用运行中的实时指标。这两种设定对应完全不同的特征集和评估方式，后文会反复回到这一点。

二、分析主线：把日志看成任务行为的时间序列

大多数“日志特征”教程的做法是：把日志表里的字段列一遍，数值型做统计、类别型做编码，然后全部丢进模型。这种做法在工程上能跑通，但很难解释“为什么这个特征有用”，也就无法在出问题时快速定位、无法在漂移时判断该保留哪些特征。

本文主张的分析主线是：一个ETL任务的一次执行，本质上是一段有固定阶段结构的行为轨迹。它依次经过“计划（被调度）—启动（申请资源）—运行（读写数据）—产出（写分区）—校验（质量规则）”。任何一次“出问题”，都是这五个阶段中某一阶段的行为偏离了该任务自身的历史常态。因此，特征工程的本质不是收集日志字段，而是为每个阶段构造“偏差度量”。

这条主线带来三个直接推论：

• 基线必须是“任务自身的历史”而非“全局平均”。一个每天跑3分钟的小任务，运行时长翻倍到6分钟可能毫无风险；一个跑4小时的大任务，多跑20分钟可能就撞上SLA。绝对阈值没有意义，相对偏差才有。
• 特征要区分“阶段内偏差”与“阶段间传导”。上游延迟（阶段间传导）和本任务运行变慢（阶段内偏差）是两类完全不同的信号，混在一个“总耗时”特征里会互相抵消。
• 时间窗设计比特征本身更重要。用“过去7天均值”还是“过去30天同星期几中位数”，对空值率这类强周期指标的偏差度量结果可能天差地别。

本文评述：这条“行为阶段偏差”主线并非凭空构造，它与软件工程中基于日志的异常检测研究思路一脉相承——把系统执行视为事件序列，用序列模式的偏离来判定异常。但数仓场景的特殊性在于：任务之间通过血缘强耦合，一个任务的“异常”可能是上游正常波动的合理传导。因此本文在阶段模型之上又叠加了“血缘传导”维度，这是与通用日志异常检测最大的不同。

三、六大类特征体系总览

沿着上述主线，我们把可喂给模型的历史日志特征归为六大类。下表给出总览，后续章节逐一展开计算口径与工程细节。

这张表的价值不在于“列全了”，而在于它把每一类特征锚定到了具体的行为阶段。当模型上线后某个特征重要性突然变化，团队可以顺着阶段定位到“是资源层变了”还是“上游血缘变了”，而不是对着特征名猜。

四、任务静态元数据与血缘特征

4.1 静态元数据：先验风险的结构化表达

静态元数据描述任务“是什么”，不随单次执行变化，但它是模型理解任务先验风险的基础。常见可用字段包括：任务类型（SQL/Python/Shell/存储过程）、所属业务域、负责人团队、调度周期（日/小时/周）、是否核心链路、依赖的上游任务数量、下游任务数量、SQL文本长度、是否包含多表JOIN、是否包含UDF。

这些字段大多需要编码。任务类型、业务域用目标编码或频次编码；上下游数量、SQL长度用分位数分桶或对数变换。需要提醒的是，负责人团队这类字段要谨慎使用——它可能隐含组织变动带来的分布漂移，且在合规审查中容易引发争议。更稳妥的做法是用“该团队历史任务失败率”这类聚合统计替代原始身份字段。

4.2 血缘特征：风险的传导结构

血缘特征刻画任务在图结构中的位置。可构造的指标包括：血缘深度（从源头表到该任务的最长路径）、扇入度（直接上游数）、扇出度（直接下游数）、是否处于关键路径（下游可达的核心报表数量）、上游表的更新频率稳定性。

笔者认为，扇入度和关键路径覆盖度是两个被严重低估的特征。扇入度高的任务，任何一个上游抖动都可能传导过来，其失败概率天然更高；关键路径覆盖度高的任务，一旦延迟影响面大，往往会被优先人工干预（重跑、加资源），这反过来会让它的“失败”标签变少——这是一种典型的干预偏差，建模时必须意识到。

工程提示：血缘图通常来自调度系统的依赖配置或数据地图的血缘解析。两者可能不一致（配置依赖≠真实数据依赖），建议以真实SQL解析出的表级血缘为准，配置依赖作为补充。血缘特征变化频率低，可按天离线计算后作为维表关联。

五、运行时长与资源画像特征

运行阶段是日志信息最密集的阶段。执行引擎（Spark、Hive、Flink等）会输出大量指标，但直接全量喂给模型既冗余又容易过拟合。建议按“偏差度量”原则收敛为少量高信息量特征。

5.1 耗时偏差类特征

最核心的一组特征。计算口径建议统一为“本次值相对历史基线的相对偏差”：

# 相对偏差特征计算示例（伪代码，示意口径）
baseline = median(duration[task_id, 过去30天, 同星期几])
dev_ratio = (duration_today - baseline) / (baseline + 1e-6)
# 同时保留绝对偏差与分位位置，避免基线接近0时比值爆炸
dev_abs   = duration_today - baseline
pct_rank  = percentile_rank(duration_today, history[task_id, 过去30天])

除了总耗时，还应拆出“排队等待时长”“资源申请时长”“实际计算时长”。三者偏差的语义完全不同：排队时长飙升通常指向集群资源紧张（全局性风险），计算时长飙升更多指向数据量膨胀或数据倾斜（任务局部风险）。

5.2 资源画像类特征

包括CPU使用率峰值、内存峰值与spill量、shuffle读写量、GC时间占比、并发task数、失败重试task数。这些指标在Spark UI或引擎日志中均可获取。建议对每个指标同时保留“当日值”和“相对近30天中位数的偏差”。

本文评述：资源类特征的一个常见陷阱是把“结果”当成“原因”。例如spill量巨大往往是因为内存不足，而内存不足可能正是任务失败的直接原因——这没问题；但如果任务已经失败，日志里的大量报错指标会被误当成预测特征，造成穿越。因此资源特征必须严格截取“任务启动到决策时点”之间的数据。

六、数据质量特征：空值率与数据量波动

这是用户问题中最关心的部分，也是最容易做错的部分。核心难点在于：空值率和数据量是“产出后”才知道的指标，如果预测目标是“任务启动前预警”，它们只能以“历史值”的形式出现，而不能用当天的值。

6.1 空值率特征的正确用法

空值率对预测的价值体现在两个层面。第一，历史空值率的稳定性本身就是风险信号：一个过去30天空值率方差极大的字段，说明上游数据源本身不稳定，该任务未来出质量问题的概率更高。第二，空值率的短期趋势变化：过去3天连续上升，即使还没超过阈值，也是强预警信号。

可构造的特征包括：近7天/30天空值率均值与标准差、近3天空值率斜率（线性拟合系数）、空值率相对同星期几基线的偏差、空值率突破历史P95的次数。注意要对字段级空值率做聚合（如取最大值、均值、超标字段数），否则字段一多特征维度会爆炸。

6.2 数据量波动特征

数据量波动比空值率更直观，也更容易受业务周期影响。建议构造：当日行数相对近30天同星期几中位数的比值、行数环比变化率、行数为0的历史频次、分区大小（字节）变化率。对于小时级任务，还应加入“当日累计行数 vs 历史同期累计”的对比。

本文评述：很多团队把“当天空值率”直接当特征去预测“当天是否出问题”，这在任务启动前预警的场景下是典型的标签泄漏——因为当天空值率只有在任务跑完之后才有值，而那时问题已经发生了。正确做法是用历史空值率刻画“这个任务有多脆弱”，用上游任务的当日空值率刻画“风险是否正在传导”，两者结合才是可用的信号。

七、调度依赖与上游传染特征

数仓任务很少孤立失败。上游延迟、上游失败、依赖等待超时是极强的前置信号。这类特征的关键在于“在决策时点已可获得”。

• 上游完成延迟：直接上游任务当日实际完成时间与计划完成时间的差值，取最大值与均值。
• 上游失败数：直接上游中状态为FAILED的数量，以及近3天上游失败次数。
• 依赖等待时长：本任务从“依赖满足”到“实际启动”的等待时间，反映调度队列压力。
• 上游数据量偏差：上游产出表当日行数相对基线的比值，用于捕捉“上游少产导致下游空跑”的传导链。
• 血缘传染分数：把上游任务的当日风险分（可由同一模型对上游任务打分得到）按血缘距离加权聚合，形成“上游风险传染”特征。这是本文较推荐的一个组合特征。

笔者认为，血缘传染分数是这类特征中最有工程价值的一个。它把“单任务预测”升级为“图上预测”，让模型能够利用任务间的相关性。实现上可以采用两阶段：先对每个任务独立打分，再把上游分数作为下游任务的特征输入。注意要按血缘拓扑排序计算，避免循环依赖导致的计算死锁。

八、历史故障与修复行为特征

历史故障特征是“任务可靠性”的直接刻画，通常信息量很高。可构造：近7天/30天失败次数、失败率、平均修复时长（从失败到重跑成功的间隔）、重跑次数、人工干预次数（如手动改参数、手动补数据）、最近一次失败距今天数。

需要警惕的是“故障聚集”带来的标签相关性：一个任务连续三天失败，这三天的样本高度相关，如果随机切分训练/测试集，会造成评估虚高。正确做法是按时间切分（如前28天训练、后7天测试），或按任务分组切分，确保同一任务的不同时间样本不跨集合。

关于重跑特征的一个细节：重跑次数既是“风险信号”（说明任务不稳定），也可能是“干预结果”（说明团队在积极修复）。建模时应明确它代表哪一层语义，必要时拆成“自动重跑次数”和“人工重跑次数”两个特征。

九、时间日历与业务上下文特征

时间特征看似简单，但在数仓场景中极其重要。数据量、空值率、任务耗时都有强烈的周期性：月初月末结算、周一补数据、大促期间流量暴涨。建议构造：星期几、是否月初/月末、是否节假日、是否大促日、距最近大促天数、当日调度批次序号。

这些特征的作用不是直接预测失败，而是帮助模型正确解读其他特征的偏差。例如同样是数据量翻倍，在大促日是正常的，在普通工作日则是异常。把日历特征与数据量偏差做交叉（如“数据量比值 × 是否大促”），能显著提升模型的判别力。

十、标签构造与样本切分

标签构造直接决定模型上限。前文已给出联合标签的思路，这里补充三个工程细节。

10.1 正负样本比例与采样

ETL任务失败率通常在1%~5%量级（不同团队差异大，需以实际数据为准），属于典型类别不平衡。建议保留原始分布训练，通过调整决策阈值和代价敏感学习来优化，而不是简单过采样——过采样容易让模型对少数类过拟合，线上误报率飙升。若必须采样，优先用欠采样负样本并配合概率校准。

10.2 时间切分与滚动验证

严禁随机切分。推荐“滚动时间窗验证”：用第1~4周训练、第5周验证，再滚动到第2~5周训练、第6周验证，依次类推。这样评估结果更接近线上真实表现，也能观察模型随时间的稳定性。

10.3 冷启动任务的处理

新上线任务没有历史，所有“近N天”特征都是空值。建议为这类样本单独设一个“冷启动”标记，并用任务静态元数据+血缘特征做兜底预测；同时在前两周降低告警阈值敏感度，避免大量误报消耗团队信任。

十一、特征穿越与数据泄漏防控

这是本文最想强调的工程红线。特征穿越（leakage）在ETL预测中极其常见，且往往隐蔽。典型场景包括：

• 用当天产出指标预测当天失败：任务都失败了，哪来的当天产出？这类特征在训练集里只对负样本有值，模型会学成“有值=不出问题”的荒谬规则。
• 用“修复后”的日志：重跑成功后，日志里会留下重跑记录，若特征窗口包含了重跑时段，等于提前知道了结果。
• 用全局统计量做编码：目标编码若在全量数据上计算再切分，测试集信息会渗入训练集。必须在训练折内计算。
• 用未来日期的日历特征：看似无害，但如果“距大促天数”用了未来事件，且大促与故障强相关，同样构成穿越。

防控手段建议三条：一是为每个特征标注“可用时点”，在特征注册表中强制记录，任何晚于决策时点的特征禁止入模；二是构造“时间机器”回放测试，用历史某天的数据快照重跑特征计算，验证输出与当时线上一致；三是做特征重要性审计，若某个特征重要性异常高且语义可疑，优先怀疑穿越。

一个实用的自检问题：假设我现在站在任务启动前的那一刻，这个特征的值我能拿到吗？拿不到，就不能用。这个问题能挡掉八成以上的穿越。

十二、建模路径与评估口径

特征准备好之后，模型选型反而不是难点。表格数据上，梯度提升树（XGBoost、LightGBM、CatBoost）通常是强基线，工程成熟、可解释性好。若任务间血缘关系复杂，可考虑图神经网络引入结构信息，但落地成本高，建议先用“血缘传染分数”特征在树模型上逼近效果。

评估口径上，AUC适合看整体排序能力，但在极不平衡场景下容易虚高。更应关注：Precision@K（每天预警前K个任务，命中多少真实故障）、召回率@固定误报预算（在每天最多误报N次的前提下能召回多少故障）、以及预警提前量（平均提前多少分钟给出预警）。这三个指标才对应运维团队的真实诉求。

十三、线上运维：漂移、冷启动与告警闭环

模型上线只是开始。数仓环境变化快——集群扩容、调度策略调整、业务口径变更、上游系统迁移——都会让特征分布漂移。建议做三件事：

• 特征分布监控：对每个特征计算PSI或KS，超过阈值触发告警，定期回看是否需要对特征做重标准化或下线。
• 模型性能监控：由于标签有延迟（故障要等发生才知道），可用“代理指标”如预警命中率、人工反馈率做实时监控，真实标签回填后做周级复盘。
• 告警闭环：每条预警都要有处置记录（是否人工介入、是否真的故障、误报原因），这些记录反过来成为下一轮训练的标签补充和特征改进依据。

关于冷启动，除了前文提到的兜底策略，还建议建立“任务上线观察期”机制：新任务前14天只记录不告警，积累足够样本后再纳入正式预测。这能显著降低早期误报对团队信任的消耗。

十四、前沿预判与结语

从研究趋势看，基于日志的异常检测正从“规则+统计”走向“序列建模+图建模”。大语言模型在日志解析、根因摘要上的应用也在快速推进——它擅长把非结构化报错文本转成结构化事件，弥补传统特征工程对文本日志利用不足的短板。但笔者认为，短期内LLM不会替代特征工程，而是作为“日志结构化器”嵌入特征流水线：把报错堆栈、异常关键字、任务注释转成类别特征，再喂给树模型。这样既利用了语义信息，又保留了可解释性和稳定性。

另一个值得关注的方向是“因果特征”的引入。当前特征大多是相关性度量，若能识别“上游延迟→本任务超时”的因果路径，预警的可解释性和干预建议质量会大幅提升。这在工程上可以通过血缘图上的干预实验（如人为延迟上游观察下游）逐步积累。

回到最初的问题：该把哪些历史日志特征喂给模型？答案不是一张无限长的字段清单，而是围绕“计划—启动—运行—产出—校验”五个阶段，为每个阶段构造相对任务自身历史基线的偏差度量，再用血缘把任务间的风险传导串起来。特征不在多，在于每个特征都能回答“它刻画了哪个阶段的哪种偏差”。把这条主线守住，模型的效果和可维护性都会有保障。

十五、参考文献与声明