📚 课程目录第4章特征缺失率监控

4. 特征缺失率监控：缺失率的定义与计算方式，滑动窗口统计，阈值设定策略，告警触发机制

缺失率监控，说白了就是盯着特征里「空值」的比例。我见过不少团队，上线前拍脑袋设个阈值，结果线上天天误报，最后运维直接把告警关了。嗯，这章咱们就把这事聊透。

4.1 缺失率的定义与计算方式

先给个标准定义：缺失率 = 空值样本数 / 总样本数 × 100%。但这里有个坑——「空值」到底指什么？

我个人习惯把空值分成三类：

显式空值：数据库里的 NULL、NaN、None
隐式空值：空字符串 ""、空格、占位符如 -999、Unknown
业务空值：比如用户年龄填了 0，或者收入填了 1 元——明显不合理

我曾经踩过的坑：只统计 NULL 就以为万事大吉。结果某个上游系统把缺失值统一写成了 "N/A"，缺失率从 2% 直接飙到 35%，而我这边毫无察觉。所以计算缺失率时，一定要把隐式空值也纳入统计。

计算方式其实很简单，但要注意窗口范围。看个例子：

-- 单批次缺失率计算（SQL 示例）
SELECT
  feature_name,
  COUNT(*) AS total_rows,
  SUM(CASE WHEN value IS NULL OR value = '' OR value = 'N/A' THEN 1 ELSE 0 END) AS missing_count,
  ROUND(SUM(CASE WHEN value IS NULL OR value = '' OR value = 'N/A' THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS missing_rate
FROM feature_log
WHERE dt = '2024-01-15'
GROUP BY feature_name;

4.2 滑动窗口统计

单批次统计有个问题：你今天看缺失率 5%，明天看 8%，到底是趋势恶化还是正常波动？你想想看，如果只看单点，你根本分不清。

所以要用滑动窗口。我一般用两种窗口：

窗口类型	窗口大小	适用场景
短窗口	最近 7 天	快速发现突发异常，比如上游表字段被删
长窗口	最近 30 天	观察长期趋势，比如数据源质量缓慢恶化

滑动窗口的计算逻辑：

def sliding_window_missing_rate(df, feature, window_days=7):
    """
    滑动窗口缺失率计算
    df: 包含 dt 和 feature 列的数据框
    """
    df = df.sort_values('dt')
    df['rolling_missing_rate'] = (
        df[feature].isnull()
        .rolling(window=window_days, min_periods=1)
        .mean() * 100
    )
    return df

我的经验：短窗口用 7 天，长窗口用 30 天，这两个值基本够用。如果数据更新频率是小时级，窗口可以缩到 24 小时和 7 天。别搞太复杂，够用就行。

4.3 阈值设定策略

阈值怎么设？我见过三种主流策略：

固定阈值法：拍脑袋定个 5%、10%。简单粗暴，但容易误报。
统计阈值法：用历史数据的均值 ± 3σ 作为动态阈值。
分位数法：取历史数据的 P95 或 P99 作为阈值。

我个人最推荐统计阈值法。为什么？因为不同特征的缺失率基线差异很大。用户性别缺失率可能常年 0.5%，而用户收入缺失率可能稳定在 20%。你用一个固定阈值，要么漏报要么误报。

看个动态阈值的实现：

def dynamic_threshold(history_rates, window=30, sigma=3):
    """
    基于滑动窗口的动态阈值
    history_rates: 历史缺失率序列
    """
    rolling_mean = history_rates.rolling(window).mean()
    rolling_std = history_rates.rolling(window).std()
    upper_threshold = rolling_mean + sigma * rolling_std
    lower_threshold = rolling_mean - sigma * rolling_std
    return upper_threshold, lower_threshold

阈值设定清单：

每个特征独立设定阈值，不要共用
阈值要随窗口滑动自动更新
设置上下双阈值：过高要告警，过低也可能有问题（比如数据被硬编码填充）
冷启动阶段先用固定阈值，积累 30 天数据后切到动态阈值

4.4 告警触发机制

阈值设好了，怎么告警？这里有个关键点：不要单点触发就告警。我见过最蠢的告警策略——缺失率超过阈值就发钉钉，结果一天告警 200 次，运维直接把机器人踢出群了。

合理的告警机制应该分层：

告警级别	触发条件	通知方式	响应要求
P0 紧急	连续 3 个窗口超过阈值上限	电话 + 钉钉	30 分钟内响应
P1 严重	单窗口超过阈值上限	钉钉	2 小时内响应
P2 警告	单窗口超过阈值上限的 80%	邮件	24 小时内确认
P3 通知	缺失率趋势持续上升（连续 5 个窗口递增）	日报	无需立即响应

告警触发逻辑的伪代码：

def alert_trigger(current_rate, upper_threshold, history):
    # 连续 3 个窗口超阈值 → P0
    if all(r > upper_threshold for r in history[-3:]):
        return 'P0'
    # 单窗口超阈值 → P1
    elif current_rate > upper_threshold:
        return 'P1'
    # 接近阈值 → P2
    elif current_rate > upper_threshold * 0.8:
        return 'P2'
    # 趋势上升 → P3
    elif is_monotonic_increasing(history[-5:]):
        return 'P3'
    else:
        return None

注意：告警一定要带上下文。别只发一句「缺失率过高」，要附带：当前值、阈值、历史趋势、可能原因。我习惯在告警消息里加一个「最近 7 天缺失率趋势图」的链接，这样收到告警的人能立刻判断严重程度。

4.5 整体流程框架

把上面这些串起来，就是缺失率监控的完整链路。我画了张图，你看一眼就明白了：

你看，整个链路其实不复杂。数据进来 → 算缺失率 → 滑窗统计 → 阈值判定 → 决定是否告警。但每个环节都有细节，尤其是阈值和告警策略，直接决定了这个监控系统能不能真正用起来。

我的建议：刚开始搭建时，先跑一周的「静默模式」——只计算不告警。把历史数据跑一遍，看看各个特征的缺失率分布，再根据实际分布设定阈值。这样上线后误报率会低很多。

嗯，缺失率监控这块就这些。记住一句话：监控不是为了告警，而是为了让你在问题变严重之前发现它。阈值设得再漂亮，如果没人响应，那就是一堆数字而已。