0x00概述随着大数据时代的到来，数据应用也越来越蓬勃，越来越多的应用和服务建立在数据基础上，数据的重要性不言而喻。而且，数据质量是数据分析和数据挖掘结论有效性和准确性的基础，也是这一切的数据驱动决策的前提！如何保障数据质量和确保数据可用性是所有数据人员不可忽视的重要一环。
数据质量主要从完整性、准确性、一致性和及时性四个方面进行评估。 结合业务流程和数据处理流程对这四个方面进行详细的分析和说明。
由于数据最终是为商业价值服务的，本文不仅仅是对理论的阐释，而是以数据质量监控这一数据的应用为出发点，分享居士对数据质量的思考。 在本文中，您将获得以下知识点：
数据质量的中心关注点
从数据计算链上理解，每个阶段都会出现哪些数据质量问题
从理解业务逻辑出发，监控数据质量带来的帮助
实现数据质量监控系统时应关注的几点
数据质量监控面临的几个难点及解决办法
0x01的四个关注点本节简要介绍了需要关注数据质量的四个方面：完整性、准确性、一致性和及时性。 这四个关注点出现在我们数据处理过程的各个阶段。
另一方面，完整性是指数据的记录和信息是否完整，是否有遗漏。 数据丢失主要包括记录丢失和记录中的字段信息丢失，两者的统计结果都不准确，因此完整性是数据质量的最基础保障。
简而言之，进行监视需要考虑两个方面：数据数量是否减少，以及是否缺少某些字段的值。 完整性监视常见于日志级别监视，通常在数据访问时进行数据完整性检查。
二、准确性是指数据中记录的信息和数据是否准确，有无异常或错误的信息。
直观上就是看数据是否准确。 一般准确性的监视多集中在业务结果数据的监视上，如日常活动、收入等数据是否正常等。
三.一致性是指同一指标在不同地点的结果是否一致。
在数据不匹配的情况下，当数据系统往往达到一定的复杂度时，往往会在多个位置计算相同的指标，不同的计算口径和开发者容易产生相同的指标不同的结果。
四、及时性确保数据完整性、准确性和一致性后，可以保障数据及时生产，体现数据价值。
即时性很容易理解，主要是数据计算速度是否足够快，这体现在数据质量监测中监测结果的数据在指定时间点之前计算是否完成。
0x02数据处理各阶段的数据质量数据质量监控之所以困难，是因为在数据的各阶段会产生数据质量问题。 因此，本节以典型的数据处理链为例，共享各阶段容易发生什么样的数据质量问题。
如下图所示，为了举例说明，试着描绘了简单的数据处理流程。 在实际情况下，会比这种情况复杂得多。 将数据处理分为数据访问、中间数据清洗、结果数据计算三个阶段。
如上图所示，作为数据访问的一部分，最容易发生的是数据完整性问题，这里要特别注意的是数据量是否急剧增加或急剧下降。
急剧增加意味着大量数据可能重复报告，或者异常数据可能进入，急剧下降意味着数据可能丢失。
另一方面，它还检查不同字段中的值是否丢失，如地址和设备字段中是否出现大量空值。
数据清洗在这里，我把数据清洗的范围限定在数据仓库的中间表清洗。 这一部分一般也是我们数据仓库建设的中心部分。 业务发展到一定程度后，数据中间层的建设势在必行。
在这个阶段，最容易发生的是数据完整性和数据准确性问题。 数据中间层保障数据是出于统一出口，让数据一起对，一起错。 但是，由于很难保证数据的正确性，所以在数据清洗阶段需要尽量保证数据的正确性。
数据结果数据主要强调对外提供数据的过程，一般是从中间表计算或直接获取的可展示数据。 这里是业务和上司最容易感知的地方，所以这个环节主要关注数据的准确性和及时性。
总体而言，数据的完整性、准确性、一致性和及时性需要在数据处理的各个阶段加以关注，但首先可以解决核心问题。
0x03业务流程各个阶段的数据质量谈完数据处理后，继续谈业务流程。 因为数据的最终价值是对业务的贡献，所以数据的质量最好也能从解决业务问题出发。 因此，本节说明从典型的商业场景中应该如何处理数据的质量。
首先，居士认为进行监控需要考虑用户，但我们的数据质量监控平台的一个重要作用是，上司、产品和运营等用户希望对我们的数据放心。 那么，他们的关注点是什么？ 居士，我认为是业务指标！
那么，这个业务指标可以从两个角度来考虑。
各个指标的数值异常。 例如，数据是否达到了某个阈值？ 有激增和俯冲吗？
整个业务链的数据有没有异常？ 例如，从曝光到注册的转换有没有异常？
下图是APP的用户行为漏斗分析，实际上是从获取用户到转换的简
单链路。那么针对该链路，我们数据质量监控要做的事，除了告诉使用ggdcs一个节点的值有问题，也需要告诉他们整个链条哪里出了问题，哪里的转化低了。
0x04 如何实现数据质量监控前面分享了数据质量关注的点，以及从技术和业务角度会如何关注数据质量，本节将简单地分享一下如何实现数据质量监控。这里将分两个角度：宏观的设计思路和技术实现思路。
一、设计思路数据质量监控的设计要分为四个模块：数据、规则、告警和反馈。
数据：主要是需要被数据质量监控到的数据，数据可能存放在不同的存储引擎中，比如Hive、PG、ES等。
规则：是指如何设计发现异常的规则，一般而言主要是数值的异常和环比等异常监控方式。也会有一些通过算法来发掘异常数据的方法。
告警：告警是指出发告警的动作，这里可以通过微信消息、电话、短信或者是微信小程序的方式来触发告警内容。
反馈：这里需要特别注意，反馈是指对告警内容的反馈，比如说收到的告警的内容，那么负责人要来回应这个告警消息是否是真的异常，是否需要忽略该异常，是否已经处理了该异常。有了反馈的机制，整个数据质量监控才容易形成闭环。更能体现业务价值。
二、技术方案
关于技术方案，这里不多描述细节，因为不同的公司和团队情况对实现方案的考虑是不同的，简单做的话，可以写一些定时脚本即可，复杂的话可以做成一个分布式的系统。这里也可以参考居士17年写的一部分内容No.22 漫谈数据质量监控。
本篇只简单说明几个技术实现中需要关注的点：
最开始可以先关注核心要监控的内容，比如说准确性，那么就对核心的一些指标做监控即可，不用开始就做很大的系统。
监控平台尽量不要做太复杂的规则逻辑，尽量只对结果数据进行监控。比如要监控日志量是否波动过大，那么把该计算流程前置，先计算好结果表，最后监控平台只监控结果表是否异常即可。
多数据源，多数据源的监控有两种方式可以处理：针对每个数据源定制实现一部分计算逻辑，也可以通过额外的任务将多数据源中的数据结果通过任务写入一个数据源中，再该数据源进行监控，这样可以减少数据监控平台的开发逻辑。具体的优缺点可以自行衡量。
实时数据的监控，实时和离线数据监控的主要区别在于扫描周期的不同，因此在设计的时候可以先以离线数据为主，但是尽量预留好实时监控的设计。
在设计之初，尽量预留好算法监控的设计，这是一个很大的加分项，具体的结合方式也可以和第二点建议接近，比如算法异常数据放到一张结果表中，再在上面配置简单的告警规则即可。
0x05 一些困难在做数据质量监控的时候难免会遇到一些困难点，亦或是被老板挑战的地方，下面列举几个问题和解决的思路，供大家参考：
问题一：假设你的结果表要经过多层的中间表计算，你怎么保证每个环节都是正确的，且最终结果是正确的？
思路：从两个点考虑：
每一层代码有 Code Review，保证代码逻辑正常。
单独一条计算流，对关键指标从原始数据直接计算结果，和日常的结果表做对比，发现不同则告警。这种方式也可以理解为是结果数据和源数据的对账。
问题二：告警信息太多了，太容易被忽略怎么办？
思路：主要是思路是提高告警的准确率，避免无用的告警，有三个思路：
多使用机器学习算法的方式来发现异常点，比如：异常森林。
加入反馈机制，如果业务负责人认为该告警是正常的，就打上正常的tag，后续告警规则根据反馈进行优化。
加入屏蔽功能，屏蔽不感兴趣的告警。
0x06 补充草稿发出来后，收到了一些反馈，但是要将这些反馈都融入到文章中需要很多的时间，因此先将内容在展现出来，供大家参考。
一、水大人思路很清晰，展示在这里给大家做参考
二、魔幻的金毛数据准确性 是建立在合理的业务口径下，从口径角度去统一才会获得准确的结果。
而不是仅仅认为从某个面去看这个数据是准确的就要做统一，不应从数据去逆推口径。
0xFF 总结和本系列其它文章相似，本文更侧重的是做数据质量过程的思考，这个思考主要体现的地方是，怎么去定义问题和解决问题，而不是直接给出解决的方案。
比如说从数据流程的各个环节来梳理需要做数据质量的点，以及业务方核心会关注的点，这些才是能决定你的数据质量监控平台能否获得认可的关键因素。当这些东西都理清之后，技术实现只是把你的想法具像化的工具，这并非是不重视技术，而是更看重如何让技术的价值最大化。
最后，欢迎大家多多交流。
更多数据仓库的内容：
闲聊数据库和数据仓库的区别
数据对业务价值帮助的一些思考
数据仓库实践之业务数据矩阵的设计
漫谈数据仓库和范式
一种通用的数据仓库分层方法