面试官问'你们怎么保证数据质量'——数据治理不是空话，要讲具体方案

// 治理前的混乱状况
 
// 同一个'用户点击商品'行为，不同团队的埋点：
// iOS团队：product_click
// Android团队：click_product
// Web团队：ProductClick
// 另一个iOS开发：product_tap
 
// 结果：
// 1000+个事件，很多是重复的
// 数据开发每次要写一堆CASE WHEN来合并
// 报表数字经常对不上，因为漏了某个事件名

-- 埋点治理的关键SQL：将旧事件映射到新标准事件
INSERT INTO dwd_event_standardized
SELECT
  CASE
    WHEN event_name IN ('product_click','click_product',
                        'ProductClick','product_tap')
    THEN 'product_click'  -- 统一为标准事件名
    WHEN event_name IN ('add_cart','addToCart','cart_add')
    THEN 'cart_add'
    ELSE event_name
  END AS standard_event_name,
  user_id, device_id, event_time, platform,
  event_params  -- 保留原始参数
FROM ods_raw_events
WHERE dt = '${bizdate}';
 
-- 效果：1000+事件精简到100+标准化事件
-- 数据质量问题减少60%

数据校验方案：三级监控体系

光做埋点治理还不够，还需要建立持续的数据质量监控。我在某出海硬件品牌搭建了一套三级监控：

监控级别	检查什么	检查时机	告警方式
L1 基础校验	表是否存在、分区是否有数据、记录数是否为0	每个ETL作业完成后自动检查	作业失败直接告警，阻断下游
L2 统计校验	记录数波动>30%、NULL率>5%、核心字段为空	每天凌晨ETL全部完成后跑批量检查	发送告警到钉钉群，数据开发排查
L3 业务校验	核心指标与历史趋势对比、跨报表指标一致性	每天早上报表产出后	发送日报给数据负责人+业务方

-- L2统计校验示例：检查核心表的数据质量
 
-- 检查1：记录数波动
SELECT
  table_name,
  today_count,
  yesterday_count,
  ROUND((today_count - yesterday_count) * 100.0
    / NULLIF(yesterday_count, 0), 2) AS change_pct
FROM (
  SELECT 'dwd_device_activation' AS table_name,
    (SELECT COUNT(*) FROM dwd_device_activation
     WHERE dt = '${today}') AS today_count,
    (SELECT COUNT(*) FROM dwd_device_activation
     WHERE dt = '${yesterday}') AS yesterday_count
) t
WHERE ABS(change_pct) > 30;  -- 波动超过30%告警
 
-- 检查2：NULL率
SELECT COUNT(*) AS null_count,
  COUNT(*) * 100.0 / (SELECT COUNT(*) FROM dwd_device_activation
    WHERE dt = '${today}') AS null_pct
FROM dwd_device_activation
WHERE dt = '${today}' AND device_id IS NULL;

数据口径不一致怎么解决

这是面试最常追问的细节。'同一个指标在不同报表中数字不一样'是数据团队最头疼的问题。我遇到过渠道经理拿着两张报表来质问我：'为什么这张报表的日活是100万，那张是95万？'

排查后发现，两张报表的'日活'定义不同：一张是'当日有任何事件的用户数'，另一张是'当日有登录事件的用户数'。定义不同当然数字不同，但报表上都叫'日活'，业务方看不出区别。

// 解决口径不一致的三步法
 
// 第1步：建立指标字典
// 每个指标必须有唯一定义：名称、计算公式、数据来源、口径说明
// 例：日活用户数 = COUNT(DISTINCT user_id)
//     WHERE event_type = 'login' AND dt = '${bizdate}'
 
// 第2步：指标统一在DWS层计算
// 所有报表从同一个DWS表取数据，不允许各自从DWD层算
// DWS表就是'金标准'——指标只算一次，下游只引用
 
// 第3步：报表Review制度
// 新报表上线前，数据开发要Review指标口径
// 确认所有指标都从DWS层取，不能自己写SQL重新算

面试高频追问

追问一：你怎么推动业务方配合埋点治理？

这是考你的软技能。技术好但推不动业务配合也白搭。我的做法是：先拿一个典型案例说服产品经理——'这张报表上周的日活数字差了5%，就是因为有两个重复的埋点没合并'。用业务方能理解的影响来推动，而不是讲技术术语。然后我写了一份简单的埋点规范文档，附带了一个注册模板，让客户端开发每次加埋点只需要填表格，不增加太多工作量。推动治理最关键的是：让对方觉得'这对我有好处'和'配合的成本很低'。

追问二：数据质量告警太多怎么办？告警疲劳怎么解决？

这是非常实际的问题。一开始我们的告警确实太多，很多是误报，团队开始忽略告警。我做了两个调整：第一，给告警分级——L1（阻断下游）、L2（需要排查）、L3（观察即可），只有L1告警会直接打电话，L2走钉钉消息，L3汇总成日报。第二，定期Review告警规则，把连续一个月没有触发过的规则停掉，把频繁误报的规则调整阈值。调整后有效告警占比从30%提升到85%。

追问三：你怎么衡量数据治理的效果？

量化治理效果是很多人忽略的。我用三个指标衡量：第一，数据质量问题数——治理前每周约15个数据问题工单，治理后降到3个；第二，报表开发效率——治理前做一个新报表平均3天（大部分时间在理解和清洗数据），治理后平均1天；第三，数据口径投诉数——治理前每月约5次业务方投诉数字对不上，治理后基本为0。有这些数字，面试官会觉得你的治理是真正产生了价值的。

实战踩坑

我在某知名出海硬件品牌踩过一个数据质量的大坑。有一次月度复购率报表突然从25%降到了8%，业务方直接炸了。

排查后发现是上游埋点SDK升级时，order_id字段从整数改成了字符串。我们DWD层的清洗脚本在做去重时，用的是整数比较，字符串类型的order_id被当成了不同的记录，导致订单数被严重膨胀，复购率计算分母变大了。

-- 踩坑：字段类型变更导致去重失败
 
-- 原来的去重逻辑（order_id是INT时正确）
SELECT DISTINCT order_id, user_id, amount
FROM ods_orders WHERE dt = '${bizdate}';
-- 结果：10000条订单
 
-- SDK升级后order_id变成STRING
-- '123' 和 123 被当成不同记录
-- 结果：18000条'订单'（很多重复）
 
-- 修复：统一类型后再去重
SELECT DISTINCT
  CAST(order_id AS BIGINT) AS order_id,
  user_id, amount
FROM ods_orders WHERE dt = '${bizdate}';
 
-- 防范措施：在DWD层加Schema检查
-- 上游字段类型变更时自动告警

教训：数据质量问题往往来自上游的'小变更'——字段改名、类型变更、枚举值新增。必须建立上游变更的感知机制，在DWD层加Schema校验，字段类型不对直接告警而不是静默处理。

总结

讲数据质量按四个维度组织：完整性、准确性、一致性、及时性。准备一个有数字的治理案例（如埋点治理、口径统一）。讲清楚你建了什么监控体系（三级告警）、解决了什么具体问题（口径不一致、埋点混乱）。面试时能同时讲技术方案和管理流程，展示'数据治理是技术+管理综合问题'的认知，会比只讲技术的人高一个档次。

下一篇聊一个实战性很强的面试题：面试官问'你做过数据迁移吗？怎么保证不丢数据'——迁移项目该怎么讲？

你们团队的数据质量怎么样？踩过什么数据质量的坑？评论区聊聊～

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