考察点
数据质量题考的是你有没有被脏数据半夜叫醒过。面试官想听到一套能运转的机制：监控哪些维度、规则配在哪、发现问题后怎么拦住下游，而不是「我们用了 Griffin」这种工具罗列。追问会落在规则阈值怎么定、误报怎么处理、怎么跟调度系统联动。
参考答案
监控什么：四个维度
完整性——数据全不全。最常用的规则：分区行数是否为零或断档、行数同比/环比波动（比如昨日分区行数比 7 天均值低 30% 触发告警）、主键唯一性（重复行数 = 0）、关键字段非空率（user_id 空值率 < 0.1%）。
及时性——数据到没到。任务产出时间是否超过 SLA（比如 DWS 核心表 7:00 前必须就绪）、实时链路消费 lag 是否超限、数据源是否断流（Kafka topic 十分钟无新消息）。
准确性——数据对不对。业务规则校验：金额不能为负、状态字段必须落在枚举值集合内、比例类指标在 0 到 1 之间；跨表对账：DWD 支付明细求和与业务库日终对账差值 < 0.5%；分布检查：某维度取值分布突变（某天 Android 占比从 60% 掉到 20%，多半是埋点出了问题）。
一致性——口径齐不齐。同一指标在不同下游表的数值是否一致，主外键关联的匹配率（事实表的商品 ID 在维表里的匹配率应 > 99%）。
怎么落地：卡点和分级是灵魂
DQC 不是跑一堆校验 SQL 发发邮件就完事，核心是跟调度系统联动：任务产出后、下游任务启动前，先跑 DQC 规则，结果决定放不放行。这就是卡点。
规则必须分级，不然要么拦不住事、要么天天半夜熔断：
- 强规则（阻断）：行数为零、主键重复、核心表超时未产出。触发后熔断——挂起下游依赖任务、电话/值班群告警，避免脏数据流向下游几十张表，把一小时能修的问题变成三天的回刷。
- 弱规则（告警不阻断）：行数波动 30%、空值率微超。发告警通知负责人，下游照常跑，人来判断要不要追。
宁可一开始规则少而准，也不要一上来配几百条规则天天报警，两周后所有人把告警群屏蔽，DQC 就死了。先覆盖核心链路（钱、订单相关）的强规则，再逐步铺开。
阈值怎么定
固定阈值适合业务规则（金额 >= 0），但行数这类随业务周期波动的量，要用基线告警：按历史 7/30 天数据算均值和标准差，波动超过 n 倍标准差才告警，同时支持排除大促等已知异常日。静态阈值配出来的结果是：周末天天误报，大促天天熔断。
工程实现要点
规则配置存元数据库，与表资产绑定，表负责人变更时规则跟着走；每条规则记录触发历史，方便算误报率并定期优化；校验本身要轻——行数、波动类规则走 count 和聚合，别把对账 SQL 写成全表 join 把集群打垮。工具上自研规则引擎（本质是定时跑校验 SQL + 调度钩子）最灵活，开源可选 Apache Griffin、Great Expectations，选型看和现有调度（DolphinScheduler、Airflow）的集成成本。
可能的追问
- DQC 拦住了，下游等着出报表怎么办？ 熔断要有降级预案：值班人确认问题后可手动跳过单条规则放行（留审计记录），同时给下游提供「数据异常」标识，让看板显示异常而不是显示错数据。
- 对账差异 0.3%，是质量问题还是口径问题？ 先查口径——时区、退款是否剔除、支付状态枚举是否对齐，八成差异是口径不一致而非真脏数据，这也是为什么对账前要先拉业务方确认对账口径文档。
- 实时链路的 DQC 和离线有什么不同？ 实时没法等分区齐全再校验，改为滑动窗口内做断流检测、lag 监控、抽样校验（按比例抽消息检查格式和字段合法性），以及端到端对账（流式结果按小时与离线口径对账）。