简单聊聊数据质量

|0x00 数据质量该怎么理解

大多数数据的从业者，对“数据质量”并没有很深的理解，倒是在面试中经常被问起这个问题。之所以对于“数据质量”理解不深刻，也是因为没有亲身经历“资产损失”，没有站在台前，直面“用户”或者“客户”的不信任。

数据质量其实是产品口碑的一部分，是“用户”或者“客户”信任产品的基石。

如果一定要给数据质量下一个定义，我倾向于用三个“不”来总结，即“不丢失”、“不错误”、“不延迟”。如果引申到日常的架构中，就是代码逻辑正确、技术框架稳定可靠、按时保质交付数据。

看起来定义简单，实则落地很有挑战。

|0x01 数据质量问题分析

数据质量的挑战在哪里？简单总结，有如下几个方面：

• 数据任务“裸奔”，没有工具来保障；
• 研发标准缺失，大家随意开发；
• 数据问题没有主动发现的意识，往往是被动的通知；
• 日常开发涉及团队众多，数据链路很长；
• 技术变动影响较大，上游各种技术更新都会影响数据质量；
• 由于工作交接导致的业务不熟悉。

从上面的Case可以看出，数据质量的问题，大致可以归为两个方面的问题：流程不健全、机制未执行。

问一下自己，日常开发过程中，有没有完善的研发机制呢？如果有的话，是不是严格落实了呢？很多时候，我们为了赶业务的进度，有意无意的放弃了一些繁琐的环节，等到发生问题的时候，回头来看，发现大多数的问题，都是因为这些省去的缓解导致的。

可以说，只要严格落实规范和机制，绝大多数的数据质量问题都可以迎刃而解。

|0x02 数据质量保障机制

数据质量如何才能够落实呢？还是要从流程和机制入手。

1. 建立数据质量的意识：由于数据工作大多数是在开发的幕后，不直接参与第一线的工作，因此对于风险管控的意识是不足的。将数据质量问题，纳入考核的KPI，通过“硬”手段来建立风险意识，非常有必要；除此之外，每个故障的事后复盘、日常质量意识的宣传，都很有必要；
2. 定义数据质量标准：既然数据质量要纳入KPI，那么就一定要有对应的标准。后端开发的同学往往有P级事故的评价标准，那么数据也有必要根据产出时间、CodeReview、上线流程、日常运维等几个方面，来建立自己的考核标准；同时，日常开发中，对于数据需求的逻辑如何明确、模型设计如何规范化、代码是否有CR机制等方面的流程，一定要有明确的定义；
3. 善于使用管理工具：如果单单依靠人的力量来检查数据的质量问题，那么会加重日常工作的负担，因此如何通过工具来简化维护流程，也非常的重要；例如每个核心表，是否可以自动配置检查任务，从主键唯一、行数为空、指标波动等方面，来检查核心任务的准确性呢？再例如有没有最基础的报警工具，以及值班表，每个夜里都能够指定固定的同学，来保障任务的运转顺畅呢？
4. 规范数据发布流程：简单而言，每次发布上线前，要有上下游影响的评估、重大变动要有通知机制、如果上线出了问题要有回滚方法、24小时都要有人员值班；这些流程可以根据公司情况的不同，自定决定，但不能没有。

|0xFF 数据质量的自动保障

大多时候，讲流程、机制容易，但落地很难。当今天大数据技术持续快速发展的时候，只讲方法、策略，已经难以满足业务发展的诉求了，更多的时候，是期望有工具化、产品化、自动化的质量保障方法，来简化人的工作量。

可以说，“工具化、产品化、自动化”，依然是当下热门的创新点。

数据质量的保障是一项长期工作，但这并不意味着现在就可以放弃质量管控，当有一天业务慢下来了，需要你拾起这件事情的时候，过去挖的坑，今天都要一一的埋上，这才是最痛苦的。