📚 课程目录第3章数据质量核心概念与定义

数据质量技术专家高阶面试宝典 - 第3节

第3章数据质量核心概念与定义

面试官考察数据质量概念时，表面问定义，实际看你对「质量维度的权衡」和「工程化落地」的认知深度。常见的六大维度：完整性、准确性、一致性、及时性、唯一性、有效性。核心不在于背诵名词，而在于结合实际场景解释冲突时的优先级判断。

  思维要点：回答时先给出维度定义 → 关联业务影响 → 举例说明维度间冲突 → 给出工程化解决方案（如DQC规则+监控）。

---

面试问题	请解释数据完整性（Integrity）的含义，以及在数据仓库中如何保证完整性？
考察点	是否理解实体完整性、参照完整性、域完整性三个层面；能否联系实际业务场景说明。
回答框架	① 先分三个层面定义（实体/参照/域）→ ② 举例说明（如订单表主键唯一、用户ID外键约束、金额字段取值范围）→ ③ 工程实现（DDL约束+DQC定时检测+告警）
示例回答	完整性包括实体完整性（主键唯一非空）、参照完整性（外键关联有效）和域完整性（字段值符合业务规则）。在数仓中，我们通过建模设计约束（如DIM表主键）、ETL脚本中插入前校验，以及每日DQC任务扫描异常记录来保障。
可能追问	如何处理因上游数据变更导致的主键冲突？
避坑提醒	⚠️ 别只背概念，要给出工程化手段；切忌说“完整性就是不能有空值”。

面试问题	数据准确性和数据一致性有什么本质区别？在实时数仓场景下如何保证两者？
考察点	区分概念边界，理解准确性是单系统内部，一致性是跨系统/跨表；考察实时场景下的处理经验。
回答框架	① 对比定义（准确性=值与真实值匹配；一致性=同一实体在不同数据源中匹配）→ ② 举例（用户年龄字段：准确性校验年龄范围，一致性校验CRM与数仓是否相同）→ ③ 实时场景：准确性通过字段规则校验，一致性通过流式对账+窗口聚合检测。
示例回答	准确性关注单值是否正确，比如金额字段不能为负数；一致性关注多源数据是否对齐，比如订单金额在交易库和数仓中必须相同。实时场景下，我们采用Flink CEP校验准确异常，同时用Kafka消息比对实现秒级一致性检测。
可能追问	如果发现一致性偏差，你如何定位是哪个环节引入的错误？
避坑提醒	⚠️ 避免混淆概念，用具体字段举例最有力；实时场景没有标准答案，重点展示思路。

面试问题	数据及时性（Timeliness）指标如何定义？如果业务要求T+1数据在早上8点前产出，但上游日志延迟，怎么处理？
考察点	及时性SLA定义与监控；应对上游延迟的降级策略与权衡思维。
回答框架	① 及时性常用指标：产出时间/数据新鲜度/延迟分布分位数 ② 延迟处理：先梳理依赖链路→设置超时阈值→补偿重跑机制→降级使用前几天的基线数据 ③ 主动预防：与上游约定SLA+兜底预案
示例回答	及时性定义为数据产出时间与业务期望时间的差值。对于上游日志延迟，我会先设置延迟容忍阈值（如30分钟），超过则触发告警并启动空跑补偿；同时下游使用历史同周期数据做降级，优先保证报表可用性，延迟数据到齐后增量刷新。
可能追问	如果业务要求强一致性（缺数据宁可不出），你的降级方案会怎么调整？
避坑提醒	⚠️ 不要只说“延迟了就重跑”，要体现分层降级思维；强一致性场景下要说明阻塞或回退机制。

---

项目名称	基于Flink+Delta Lake的实时支付数据质量监控平台
业务背景	公司核心支付链路从T+1转向实时风控与对账，要求30秒内数据准确率≥99.9%，一致性偏差≤0.01%。
规模指标	日均处理1.2亿笔交易；监控字段超过200个；数据源包括MySQL binlog、Kafka日志、Redis缓存状态。
技术栈	Flink 1.15 / Delta Lake / Spark DQC / Prometheus+AlertManager / 自研字段血缘追踪引擎
核心难点	① 千万级QPS下准确性校验不能影响主链路 ② 跨系统一致性检测需容忍毫秒级时间窗口差异 ③ 及时性SLA与数据完整性冲突（延迟重试 vs 缺页降级）
面试高频追问	Q: 如何处理数据重复消费导致的一致性异常？ Q: 准确性校验规则如何实现热更新？ Q: 如果Flink作业发生反压，质量监控如何保持低延迟？
可迁移回答话术	“在质量工程中，我坚持‘分层监控+可配置告警’原则：实时层做轻量字段规则校验并写入Delta表，离线层用Spark DQC做全量对账；遇到维度冲突时优先保证准确性，通过延迟补偿保证一致性，最终以业务可接受的降级预案兜底。”