📌 数据质量

一、课程引入：为什么数据质量是数仓的“生命线”📌

数据质量是数仓建设的基础基准，但此前课程仅做概念介绍，本讲聚焦实操落地——从“是什么”“为什么出问题”到“怎么解决”，完整覆盖数据质量保障全流程。

核心逻辑：数仓下游对接 BI、风控、产品、运营等角色，数据质量直接决定下游用户体验。若数据频繁出错，会导致业务方丧失信任，甚至替代数仓团队，因此“数据质量 = 数仓团队的生存底线”。

二、核心认知：数据质量是什么？为什么会出问题？

1. 数据质量的本质

核心是数据的准确性与可靠性，即数据能真实反映业务场景，满足下游分析、决策需求。数据质量问题并非仅指数仓自身 Bug，而是覆盖“数据源 - 数仓加工 - 下游使用”全链路的问题集合。

2. 数据质量问题的3大成因⚠️

上游数据源问题：空值、字段缺失等问题源于业务库（如 MySQL），非数仓代码 Bug，但业务方“只认结果不认过程”，最终由数仓背锅。例如：后端传参时某字段为空，数仓抽取后仍为空，业务方会判定为数仓问题。
人员能力差异：新老员工水平不一，新手易写 Bug，老员工可能因习惯问题忽视规范，导致问题频发。
代码不规范：多层嵌套子查询、字段命名混乱等问题，导致后续维护者扩展或修改时极易出错，引发任务挂掉或数据失真。

核心结论：数据质量无法“彻底根治”（人都会犯错），但可通过机制“源头预防、过程管控”，将问题遏制在萌芽阶段。

三、业务视角：数据质量差带来的6大痛点

业务方对数据质量的不满，本质是“数仓缺少标准化机制”，具体表现为：

数仓无规范，模型混乱：数仓前中期快速扩张，数据模型设计不合规——比如本应“一人一条数据”的表，混入多条重复数据；代码过几个月就看不懂，后续重构无从下手。
上线前缺少保障：代码写完直接交付业务方，未做数据校验——简单指标反复出 Bug（甚至 10 次以上），导致业务方质疑数仓能力。
缺少数据质量卡点：数据从 ODS→DWD→DWS 全链路无校验，若 ODS 层数据为空 / 异常，问题会一路传导至下游，最终导致报表、大屏无数据。
数据运维不及时：任务挂了未发现、数据产出延迟，导致下游 C 端产品（如用户端报表）、大屏无法正常展示，数仓团队背“核心锅”。
问题反馈无渠道：业务方不知道“找谁提 Bug、提了后谁负责、何时解决”，Bug 仅存于聊天记录，新人接手时无历史参考，问题反复出现。
上游问题难推动：数据源问题（如字段空值）反馈给后端后，对方推诿拖延；且部分问题隐藏较深（如仅发现 1 个用户字段空值，实际有大量用户存在同类问题），数仓被迫“背锅”。

四、核心方案：数据质量保障的5大实操手段✅

解决数据质量问题的核心是“建立标准化机制”，覆盖“上线前 - 上线中 - 上线后”全流程，具体分为 5 个模块：

1. 基础：制定上线与变更规范

规范是“强制约束”（靠人自觉不可靠），核心覆盖“模型设计 - 代码开发 - 上线审核”全流程：

上线规范：模型设计→评审→写代码→试运行→数据比对→配置监控→线上初始化，缺一步不可上线；通过平台强控，不合格则拦截。
变更规范：变更前必须明确“业务背景 + 影响范围”——模型变更需同步下游，指标变更需确认是否有下游使用（有使用则不可直接改）。

关键补充：规范无法管控“业务理解”，但可通过“需求确认机制”降低偏差——接需求时必须问清“为什么做（业务背景）、做什么（口径）”，且要拿到“最终版口径”再开发，避免反复修改。若业务方需求模糊，可请 Leader 介入协调。

2. 核心：代码审核机制（强管控）

业务理解靠个人能力，代码质量则可通过“强审核”保障，实操流程：

提交前置条件：代码必须在测试环境跑通，具备“试运行记录”才能提交审核。
审核核心维度：代码整洁度、分区条件是否完整、distinct/where 过滤是否合理、driver 与 execute 比例是否正常、字段命名规范性。
工单审批机制：设置一级 / 二级审批人，强制走工单流程；审核不通过则打回，直至修改合格。

示例：晋升员工信息表提交审核时，若发现字段数量不匹配（应 18 个字段实际仅 2 个），审批人直接打回，要求修正后重新提交。

3. 上线前保障：数据探查+数据比对

核心目标：验证“数据模型内容是否符合预期”，避免带着问题上线，分为两步：

（1）数据探查：摸清数据“底细”

针对新做的数据模型或新增字段，探查核心指标：总记录数、去重后记录数、空值 / 空串占比、最大值 / 最小值、字段长度分布。

实操方式：有平台用平台（如网易数据质量平台的“形态探查”），无平台则写 SQL 实现（如用 max()/min() 查极值，where is null 查空值）。

示例：部门表以“部门 ID”为主键，探查后发现总记录数 = 去重记录数 =9，空值占比 0，说明主键唯一、数据完整。

（2）数据比对：验证“修改无副作用”

针对“新增字段 / 修改逻辑”的场景，比对新旧表数据，确保“原有字段不受影响”：

比对对象：线上表（旧表）与线下测试表（新表）。
比对核心：以主键关联，比对原有字段数据是否一致；新增字段数据是否符合业务逻辑。
工具选择：有平台用平台（如网易平台的全量 / 抽样比对），无平台则用 DolphinScheduler，或写 SQL 做两表 join 比对。

注意：若数据量极大（如 1 亿行），可抽样验证（如选 5 个部门），保证 80% 准确性即可；剩余 20% 可交给 BI 同学辅助验证，平衡效率与质量。

4. 过程管控：DQC数据质量监控卡点

DQC（Data Quality Control）是“数据全链路的防火墙”，本质是“自动执行的校验 SQL”，核心作用是拦截异常数据，避免问题传导。

（1）DQC核心规则（基础4条+业务扩展）

规则类型	具体内容	作用
基础规则（必配）	1. 表行数不为空；2. 表行数波动在合理范围（如 0-30%）；3. 主键唯一；4. 主键不为空（无 Null/ 空串）	保障数据“存在且完整”
业务规则（按需配）	1. 特定字段非空（如订单金额）；2. 数值合规（如贷款日期 < 今天）；3. 枚举值正常（如性别仅“男 / 女”）；4. JSON 字段内 Key 非空	保障数据“符合业务逻辑”
复杂规则	自定义 SQL 实现（如带 where 条件的数值校验）	应对特殊业务场景

（2）强弱规则与告警机制

强规则：规则不通过则任务直接挂掉，下游任务停止运行（如主键为空）——拦截核心问题。
弱规则：规则不通过仍继续运行，但触发告警（如某字段空值占比 0.1%）——提示非核心问题。
告警方式：任务异常后，通过短信、电话、飞书 / 钉钉通知值班人，避免问题过夜。

（3）无平台的替代方案

没有商业平台时，可用两种方式实现 DQC：1. 用 DolphinScheduler 的内置节点（空值检查、表行数校验等）；2. 写 Python 脚本，任务执行后自动调用 SQL 校验，异常则触发告警。

5. 交付保障：数据产出的基线与SLA

核心解决“数据延迟交付”问题，通过“基线管理 +SLA 约定”确保下游按时拿到数据：

（1）SLA：与业务方的“契约”

明确约定数据产出时间（如每天 10 点前），签字画押——若未按时交付，数仓团队承担责任；提前同步交付风险，避免被动背锅。

（2）基线管理：保障核心任务优先运行

基线定义：将核心任务（如 C 端用户数据、核心报表数据）纳入基线，设置优先级（L1-L4，L4 最高），优先级越高的任务优先抢占资源。
值班机制：组建值班组，配置预警时间（如约定 10 点交付，9 点半预警），告警间隔 30 分钟 / 次，确保夜间问题及时响应。
应急方案：针对全量数据，提前准备“回溯任务”——若 T-1 数据异常，可将 T-2 数据灌到 T-1，临时保障下游使用（仅适用于全量场景）。

关键实践：给 C 端用户用的数据设为 L4 优先级，内部报表设为 L1；基线值班必须有“值班手册”，明确问题排查步骤（先查 DQC→再查日志→最后联系上游），避免值班人半夜慌乱出错。

6. 闭环管理：数据问题上报平台

解决“Bug 无记录、追溯无依据”问题，核心是“建立问题全生命周期管理机制”：

简易方案：无平台时，用飞书共享文档 /Excel 记录——包含问题 ID、名称、负责人、处理步骤、分类（数据源问题 / 代码问题等）。
专业方案：用缺陷管理平台（如 Jira）或数仓专属上报平台，实现“问题提交 - 分配 - 处理 - 关闭”全流程线上化，便于新人查阅历史问题。

五、落地推展：如何推动上下游协同？

数据质量不是数仓团队的“独角戏”，需联动下游共同参与：

初期（无平台）：建沟通群，用共享文档记录问题，鼓励业务方直接反馈 Bug，形成“问题共查”氛围。
中期（有平台）：向业务方同步数仓的保障措施（如 DQC、基线），让下游感知“数据质量在提升”；主动同步 Bug 处理进度，增强信任。
长期：推动下游参与数据质量治理（如共同定义业务规则），将数据质量纳入团队共同 KPI，避免数仓“单打独斗”。

六、进阶思考：从“质量保障”到“质量治理”

配置 DQC、基线等是“基础操作”，进阶方向是“治理优化”，解决“保障体系自身的问题”：

DQC 治理：优化过敏感规则（如 2% 波动就告警），减少无效告警对值班人的干扰；合并重复规则，提升校验效率。
基线治理：调整不合理的优先级（避免全设 L4 导致资源争抢）；优化预警时间，减少夜间无效告警。
工具化探索：开发自动化校验工具——输入 ODS 表和目标指标，自动比对 DWS 层数据与 ODS 层聚合结果，实现“一键验证”，减少人工写 SQL 的成本。

七、课程答疑精选

Q：一个项目下表很多，是否要拆分？ A：看数据源和内容——同一系统源、内容一致的表，可通过 union 合并为一张 DWD 表；多系统源、内容差异大的表，按类型加 type 字段区分，不拆分。
Q：表行数为空，一定是数据源问题吗？ A：不一定。可能是数仓任务未配依赖（如主表 2 点 20 产出，任务 2 点 17 就跑了），或代码逻辑错误（如 where 条件写死导致无数据）。
Q：C 端数据和内部数据的优先级怎么分？ A：C 端用户数据（如用户端报表）设为 L4 最高优先级，保障资源；内部报表设为 L1，错峰占用资源。

八、总结：数据质量的核心逻辑

数据质量的本质是“以业务为中心的标准化体系”——通过“规范约束人、工具管控流程、协同联动上下游”，将“被动背锅”转化为“主动保障”，最终实现数仓的“可靠交付”，这也是数仓团队的核心价值所在。