Hi，你好呀，见字如面，我是唐晨，日更大数据领域知识和个人观点，关注 Data + AI 领域的小伙伴，可以点击关注公众号。目前，我正在体系化更新数据资源管理/数据治理/数据中台系列文章。
数据成为越来越多企业应用或服务的建设基石，而数据质量是数据价值发挥的前提。比如数据的准确性和及时性会影响企业的运营效率；而数据错误或不完整则会导致和客户沟通不顺畅，影响客户满意度。
此外，企业内部的数据分散在多处，且类型和来源均在不断丰富及增长，使得情况进一步恶化，企业面临着越来越严重的数据质量问题。因此，保障数据质量已经是各个企业数字化转型成功的必要条件。
| 01 常见的数据质量问题
日常工作中，你有没有遇到以下几种情况：
- 业务系统数据库表结构发生变更，导致数据开发任务异常；
- 物理资源不足，开发任务出现排队积压，核心数据严重延迟。
相信对于数据开发而言，以上都是家常便饭，也是每天工作不得不面临的挑战和困难。而更多的数据消费人员，不管是运营、产品、分析师还是管理层，大家也逐渐意识到数据质量问题，已经严重影响到了他们的日常工作。去年的双十一大促活动期间，张一涵（化名）是某头部坚果商家的供应链部门运营，她的核心职责就是制定商品的采购计划。早上 8:30，她匆忙赶到办公室坐下，准备开启一天的紧张工作，像往常一样，打开公司的供应链决策辅助系统（数据产品），立马傻眼了。系统显示部分商品的库存数据显示为 0，这明显是不符合常识的，她快速判断可能是数据出了问题。于是，将问题反馈给了数据部门，希望他们能尽快解决，否则她就没法开展工作了。而部门中，和她岗位职责一样的人员有 30 多个，如果时间拖得太久，势必会对公司的业务运营造成影响。接到投诉反馈后，负责库存域的数据开发立马着手排查， 经过 1 个小时的紧张排查后，确认自己负责的商品库存指标产出表没有问题，而是上游依赖的表数据有问题。于是，基于血缘关系逐层向上排查，又过了 2 个多小时，最终，锁定在 DWD 层的某张表 A。这张表的产出任务在前一天有一次线上变更，任务代码存在漏洞，对部分商品入库数据格式解析异常，但是没有将异常抛出，导致产出数据表 数据异常，进而影响了所有下游表。从接收投诉开始，到最终定位问题源头表，已经花费了一上午的时间，供应链运营部门成员也焦急地等待了一上午。与此同时，数据开发也开始争分夺秒的修复数据任务，修复完成后重新提交上线，并重跑了所有的下游表产出任务。由于任务之间有相互依赖，也就是串行结构，必须等上一个任务完成后，才会执行下一个任务。于是，全部数据修复花了 3 个多小时，最终，经过业务部门确认数据没有问题，时间已经将近 7 个小时。业务部门已经炸锅了，毕竟他们要靠数据来开展工作，你说这种事情多搞两次，年底部门绩效能好吗？现在，业务部门对数据部门的要求不仅仅是要快速提供数据，更要保质保量地提供。- 作为数据的生产方，理应比业务方更早发现数据异常，但是，却是在业务方投诉过来了才意识到数据出了问题。
- 整个排查过程耗时近 3 个小时，定位问题效率太低。
- 上游数据故障污染了下游，未能及时阻断，导致影响面大、修复成本高。上游的数据已经出现了问题，没有任何措施，让错误的数据继续往下游流动，有的时候错误的数据造成的危害，远比没有数据可用更大。
数据加工处理过程由于链路长、业务逻辑复杂、依赖工具组件多等因素，天然决定了，它一定会出现问题，就像实体工业制造业一样，都会出一些生产事故。
| 03 如何改进和保障数据质量
事故不可避免，但是，我们要努力做到减少事故的出现，即使出现了事故也尽早发现、尽快修复。重点就是：早发现、早修复，核心一个字：早。出现问题第一时间感知到，快速定位问题，并着手修复。- 完成表数据加工处理后，就对数据质量做校验，确保数据的准确性、完整性和一致性，这是目前业内主流的，且被验证过的方法。
- 针对业务要求比较高的校验规则，可设置强制阻断任务，防止错误数据蔓延，造成更广、更大的数据影响。
常见的质量规则如下：
规则
| 说明
|
| - SQL 配置逻辑：SELECT CASE WHEN COUNT(*) > 0 THEN '数据不完整' ELSE '数据完整' END AS 完整性检查结果 FROM 表名 WHERE 列1 IS NULL OR 列2 IS NULL OR ...;
|
| - 检查数值字段是否在预期范围内，或者文本字段是否符合特定格式。
- SQL 配置逻辑：SELECT CASE WHEN 年龄 < 0 OR 年龄 > 120 THEN '年龄无效' ELSE '年龄有效' END AS 准确性检查结果 FROM 表名;
|
| - SQL 配置逻辑：SELECT CASE WHEN 表1.字段 = 表2.字段 THEN '一致' ELSE '不一致' END AS 一致性检查结果 FROM 表1 INNER JOIN 表2 ON 表1.关联字段 = 表2.关联字段;
|
| - SQL 配置逻辑：SELECT CASE WHEN COUNT(*) = COUNT(DISTINCT 列名) THEN '唯一' ELSE '不唯一' END AS 唯一性检查结果 FROM 表名;
|
| - 确保数据的及时更新，避免使用过时或过期数据进行分析。
- SQL 配置逻辑：SELECT CASE WHEN 最后更新时间 > NOW() - INTERVAL 1 DAY THEN '及时更新' ELSE '未及时更新' END AS 及时性检查结果 FROM 表名;
|
以上规则在配置的时候，可以组合运用，也就是同一个表可以设置多个规则校验，而任何一个校验都可以设置强弱规则（一旦校验不通过，强规则则会阻断任务；弱规则则只会发出提醒，不会阻断任务）。
一般涉及到交易相关的或者核心财务报表类的，都会设置成强规则校验，而一些分析应用类的，则可以酌情设置成弱规则。“企业的表有成千万张，历史债务很多，难道每个表都要配置对应的校验规则吗？”质量校验涉及到数据计算，而且有时候可能比数据表的产出任务逻辑还要复杂，成本更高。因此，并不是全部数据表都要配置校验规则的（也就是无需追求 100%覆盖）。数据质量管理是以数据清洁为目标，以业务需求为驱动，最终从使用者的角度定义完成情况，能够满足业务需要的数据即为“好数据”。通常只需要对核心的一些报表进行配置。通常指那些影响面广、使用者职级比较高、下游落地场景比较重要的数据。很多时候，数据开发人员就私自确定了质量校验规则，完全没有业务部门参与，这就是典型的“既当运动员又当裁判”。
为了衡量自身的工作成果，就定义了质量规则覆盖率的指标（一般会是 90%以上），这样做既浪费了资源又未能确保核心数据的质量。
因此，数据质量规则的设计应当让相关业务人员参与，确保可以满足业务的使用场景。| 小结
数据质量管理是一项持续、例行的工作，企业数据质量管理水平直接影响数据应用的效果和数字化转型的成效。
很多企业粗暴的将数据质量管理的职责，按在数据开发工程师头上，这是非常不合理的，结果就是空有一堆校验规则，但是是脱离业务需求的，数据依然面临着严重的质量问题。
（正文完）
今天的分享就到这里，希望对你能有多帮助和启发。
我是唐晨，日更大数据+AI 领域知识和个人观点，关注 Data + AI 领域的小伙伴，可以点击关注公众号。
看看都是哪些角色在订阅唐晨说数，点击下方选项查看:
有任何问题想咨询我本人，可添加微信。
现在文字真的越来越少用户有耐心阅读完了，后期是需要经营视频号了，欢迎关注，到 500 了启动直播，线上聊一聊。![]()
