100个标签，业务方说不准——标签质量怎么监控？

-- 标签覆盖率自动监控SQL
-- 每天标签任务完成后运行
 
INSERT OVERWRITE TABLE dqc_tag_coverage PARTITION (dt='${bizdate}')
SELECT
  'gender' AS tag_name,
  COUNT(*) AS total_users,
  COUNT(gender) AS covered_users,                           -- 非NULL数
  ROUND(COUNT(gender) * 100.0 / COUNT(*), 2) AS coverage_pct,
  CASE WHEN COUNT(gender) * 1.0 / COUNT(*) < 0.90
       THEN 'CRITICAL'                                      -- <90%严重告警
       WHEN COUNT(gender) * 1.0 / COUNT(*) < 0.95
       THEN 'WARNING'                                       -- <95%警告
       ELSE 'OK'
  END AS alert_level
FROM ads_user_profile
WHERE dt = '${bizdate}'
 
UNION ALL
 
SELECT
  'value_level' AS tag_name,
  COUNT(*) AS total_users,
  COUNT(value_level) AS covered_users,
  ROUND(COUNT(value_level) * 100.0 / COUNT(*), 2) AS coverage_pct,
  CASE WHEN COUNT(value_level) * 1.0 / COUNT(*) < 0.90
       THEN 'CRITICAL'
       WHEN COUNT(value_level) * 1.0 / COUNT(*) < 0.95
       THEN 'WARNING'
       ELSE 'OK'
  END AS alert_level
FROM ads_user_profile
WHERE dt = '${bizdate}';

-- 标签值波动检测：和前7天均值对比
WITH today_stats AS (
  SELECT tag_name, coverage_pct
  FROM dqc_tag_coverage WHERE dt = '${bizdate}'
),
history_avg AS (
  SELECT tag_name, AVG(coverage_pct) AS avg_coverage
  FROM dqc_tag_coverage
  WHERE dt BETWEEN DATE_SUB('${bizdate}', 7) AND DATE_SUB('${bizdate}', 1)
  GROUP BY tag_name
)
SELECT
  t.tag_name,
  t.coverage_pct AS today_pct,
  h.avg_coverage AS avg_7d_pct,
  t.coverage_pct - h.avg_coverage AS delta,
  CASE WHEN ABS(t.coverage_pct - h.avg_coverage) > 5
       THEN 'ANOMALY'   -- 偏差超过5个百分点就告警
       ELSE 'NORMAL'
  END AS status
FROM today_stats t
JOIN history_avg h ON t.tag_name = h.tag_name;

为什么用5个百分点作为阈值？这是我在实际运营中调出来的经验值。太小（1%）会有太多误报，太大（10%）会漏报。5%刚好能捕捉到异常又不会频繁打扰。不同标签可以设不同阈值——核心标签（value_level）设3%，非核心标签（兴趣偏好）设8%。

一致性校验——Hive和Redis的数据对得上吗？

标签数据从Hive同步到Redis后，最怕的就是两边数据不一致。我建了一个每天自动跑的校验Job：

# Hive vs Redis 一致性校验脚本
import random
from pyspark.sql import SparkSession
import redis
 
spark = SparkSession.builder.getOrCreate()
r = redis.Redis(host='redis-host', port=6379)
 
# 随机抽1000个用户
sample = spark.sql("""
  SELECT user_id, value_level, gender
  FROM ads_user_profile WHERE dt = '${bizdate}'
  ORDER BY RAND() LIMIT 1000
""").collect()
 
mismatch = 0
for row in sample:
    redis_val = r.hget(f'user:profile:{row.user_id}', 'value_level')
    if redis_val and redis_val.decode() != row.value_level:
        mismatch += 1
 
mismatch_rate = mismatch / len(sample) * 100
print(f'Mismatch rate: {mismatch_rate:.2f}%')
if mismatch_rate > 1:  # 不一致率>1%就告警
    send_alert(f'Redis标签不一致率 {mismatch_rate}%，请检查同步任务')

面试高频追问

追问一：标签准确率怎么验证？又不能人工逐条检查

准确率的验证方法是抽样。每月随机抽500-1000个用户，把标签值和原始数据做交叉验证。比如验证「用户价值等级」：随机抽500个标记为「高价值」的用户，回溯他们近一年的订单数据，看是否满足「消费>=200且购买>=3次」的条件。如果480个符合，准确率就是96%。这个过程可以半自动化——SQL算出原始值，和标签值对比，只有不一致的才需要人工排查。

追问二：标签出了质量问题，怎么快速定位原因？

我总结了一个排查三步法：第一步看覆盖率——覆盖率突然下降通常是上游数据缺失（ODS没到或者埋点停了）；第二步看分布——标签值的分布和历史比有没有大变化（比如高价值用户突然从10%变成30%，可能是口径变了或者JOIN出了问题）；第三步看数据血缘——从标签表往上追溯，逐层检查DWS、DWD、ODS的数据量和质量。80%的问题在第一步就能定位。

追问三：质量监控的告警发给谁？怎么避免告警疲劳？

告警分级处理。CRITICAL级别（覆盖率<90%或核心标签异常）直接发到值班群+电话通知标签Owner；WARNING级别（覆盖率90-95%或非核心标签波动）只发企业微信消息给Owner；INFO级别（轻微波动）只记录日志，不发通知。我们上线第一个月告警泛滥，每天几十条，后来通过调阈值+分级，稳定在每天2-3条有效告警。

实战踩坑

前面提到的gender标签事故，详细说一下。我在某出海硬件品牌发现gender标签覆盖率只有65%，原因是数据来源是用户注册时的填写，但很多用户跳过了性别填写。缺失的35%在标签加工时被COALESCE填了默认值F。

这个默认值的设定完全是之前的开发拍脑袋填的，没有任何业务依据。结果运营用这个标签做性别定向推送时，35%的用户收到了错误的性别推荐。

-- 修复前：拍脑袋填默认值（错误做法）
SELECT user_id,
  COALESCE(gender, 'F') AS gender  -- 缺失的直接填F，大问题！
FROM ods_user_register;
 
-- 修复后：缺失就是unknown，不要瞎填
SELECT user_id,
  COALESCE(gender, 'unknown') AS gender  -- 诚实标记为unknown
FROM ods_user_register;
 
-- 同时在标签元数据里标注覆盖率只有65%
-- 让业务方知道这个标签有35%是unknown，使用时需要注意

教训：缺失的标签值不要填默认值（除非有明确的业务规则）。宁可标记为unknown，也不要用错误的值误导业务决策。同时在标签元数据中标注覆盖率，让使用者知道这个标签的局限性。

总结

标签质量监控四维度：覆盖率（自动化SQL检查）、准确率（月度抽样验证）、一致性（Hive-Redis对账）、及时性（SLA监控）。加上波动检测和分级告警，形成完整的质量保障体系。面试时能讲出质量事故的排查和解决过程，比说「我们做了监控」更有深度。

下一篇聊一个数据分析和建模相关的话题：用户分群怎么做？NTILE打分和K-Means聚类，面试怎么答？

你们标签的覆盖率一般在多少？有没有遇到过质量事故？评论区聊聊～

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