3. 特征工程与质量维度：特征定义、质量维度与异常分类体系
聊到实时特征的质量监控，很多人第一反应就是「先写规则，再报警」。但我在几个项目里踩过坑之后发现——如果连特征的定义都没对齐，质量维度也没梳理清楚，后面所有的监控和自动处理都是空中楼阁。
这一节，我们就来把地基打牢。
3.1 特征定义：先搞清楚你在监控什么
我见过最头疼的情况是什么？团队里 A 同学说「用户活跃天数」是从登录日志算的，B 同学说「用户活跃天数」是从行为埋点算的。结果同一个特征，两个 pipeline 产出差了 30%。
所以，特征定义必须包含三个要素：
- 业务语义：这个特征到底代表什么？比如「近 7 天登录天数」vs「近 7 天有行为的天数」
- 计算逻辑：数据源、聚合窗口、计算方式。这部分最好用伪代码或 SQL 固化下来
- 产出约束：期望的取值类型、范围、分布形态
我个人习惯：每个特征上线前，先写一份「特征定义卡」，类似数据字典的升级版。里面除了上面三点，还会注明「首次产出时间」「更新频率」「上游依赖」。这样后面出问题时，排查路径清晰很多。
举个例子，一个简单的实时特征定义卡：
| 字段 | 内容 |
|---|---|
| 特征名称 | user_7d_login_cnt |
| 业务语义 | 用户近 7 天（含今天）的登录天数 |
| 计算逻辑 | 从 login_log 表按 user_id 聚合，窗口为当前时间往前 7 天，count(distinct login_date) |
| 产出约束 | 整型，范围 [0, 7]，99% 分位数 ≤ 7 |
| 更新频率 | 每分钟增量更新 |
3.2 质量维度：四个核心维度
特征定义清楚了，接下来就是怎么衡量它「好不好」。我一般把质量维度拆成四个：完整性、准确性、一致性、时效性。这四个维度基本覆盖了我在生产环境中遇到过的 95% 的问题。
3.2.1 完整性
说白了就是「有没有缺数据」。缺数据分两种：
- 行缺失：某些 key 没有产出特征值。比如某个用户本该有特征，但 pipeline 里丢了
- 字段缺失：特征值本身是 null 或空值
我在项目中遇到过最坑的一次——某个实时特征因为上游 kafka topic 挂了，整整 20 分钟没有新数据进来。监控报警只报了「延迟」，没报「缺失」。结果模型在线上的效果直接崩了。
避坑指南：完整性监控不能只看「有没有值」，还要看「该有的 key 有没有」。我后来加了一个「预期 key 数 vs 实际 key 数」的对比监控，才把这个问题堵住。
3.2.2 准确性
准确性衡量的是「特征值对不对」。但说实话，在实时场景下，你很难拿到 ground truth 去做比对。所以我的做法是：
- 值域校验：特征值是否在合理范围内。比如年龄特征突然出现 200，那肯定有问题
- 分布漂移检测：特征的整体分布是否发生显著变化。用 KS 检验或 PSI 都可以
- 业务规则校验：比如「登录天数」不可能大于「7」，如果出现 8，直接标记异常
3.2.3 一致性
一致性关注的是「同一个特征在不同地方算出来是不是一样的」。常见场景：
- 离线 vs 实时：离线跑出来的特征和实时 pipeline 产出的特征，统计值是否一致
- 多副本一致性：同一个特征有多个计算路径时，结果是否对齐
嗯，这里要注意——一致性不是要求完全相等。实时和离线因为窗口边界不同，有微小差异是正常的。关键是要设定一个可接受的偏差阈值。
3.2.4 时效性
时效性就是「特征产出够不够快」。实时特征如果延迟太高，那跟离线特征有什么区别？
我一般监控两个指标：
- 处理延迟：从事件发生到特征产出的时间差
- 产出新鲜度：特征值对应的事件时间 vs 当前时间的差距
我曾经遇到过一个 case：特征的处理延迟只有 2 秒，看起来很健康。但仔细一查，pipeline 在处理历史数据回填，产出的事件时间其实是 3 小时前的。所以只看处理延迟是不够的，一定要结合事件时间来看。
3.3 异常分类体系：把问题分门别类
质量维度是「衡量标准」，异常分类是「问题类型」。我习惯把实时特征异常分成三大类：
3.3.1 数据源异常
上游数据出了问题，特征自然跟着遭殃。比如：
- Kafka topic 无数据或数据量骤降
- 上游表 schema 变更（加字段、改类型）
- 数据源连接超时或认证失败
3.3.2 计算过程异常
pipeline 本身出了问题：
- Flink/Spark 作业反压或 OOM
- UDF 抛出异常导致整条链路中断
- 状态后端膨胀导致 checkpoint 失败
3.3.3 特征值异常
特征值本身不符合预期：
- 值域越界（年龄 200）
- 分布漂移（均值突然跳变）
- 缺失率飙升（null 比例从 1% 涨到 50%）
- 重复值异常（所有用户特征值都一样）
你想想看，这三类异常的处理方式完全不同。数据源异常要通知上游团队，计算过程异常要重启作业或扩容，特征值异常才需要触发自动修复逻辑。所以分类清楚，后面的自动处理才能对症下药。
3.4 知识体系总览
下面这张图把这一节的核心逻辑串起来了。从特征定义出发，到四个质量维度，再到异常分类，最后落到处理策略——这就是我们整个课程的基础框架。
3.5 小结
这一节我们做了三件事：
- 定义了特征——不只是名字，而是业务语义、计算逻辑、产出约束三位一体
- 拆解了四个质量维度——完整性、准确性、一致性、时效性，每个维度都有对应的监控思路
- 建立了异常分类体系——数据源、计算过程、特征值，三类异常对应不同的处理策略
说实话，这部分工作看起来不「炫酷」，但它是整个实时特征质量体系的基石。我见过太多团队一上来就写监控代码，结果特征定义没对齐，维度没想清楚，最后报警一堆但都不知道该怎么处理。
把这一节的内容消化掉，后面讲自动处理策略时，你就能很自然地知道「这个异常该归到哪一类，应该用什么策略来处理」。