数据人最常听到，最扎心、刺耳的一句话，莫过于“你数据准不准?”。一次数据异常的“锅”，可能就抵过了过去数据支撑积累的所有业务价值感知。数据质量问题，是每个数据应用类的数据产品都需要时刻关注并解决的问题。
下面的场景，你是否曾经经历过?
1.9点钟刚开始上班，用户群里已经炸了锅，营销数据报表、经验概况……今天的数据怎么还没出来啊，晨会着急看数呢
2.CDP平台新客大礼包营销场景，为什么出现了是实为老客但系统判定成新客，多发的成本，损失谁来承担啊?
3.昨天DAU同比下降了80%，你们确认下数据对不对，是不是数据不全啊?
4.大数据安全法9月1日正式实行了，你们数据产品中怎么出现了用户身份信息，你违法了啊!
5.业务发现流量统计有个异常的峰值，被业务diss，你们数据产品自己不看数据吗，没有一点业务常识和数据sense吗?
……
BI数据分析、数据化运营等数据价值应用类的数据产品，数据质量的问题将导致错误的业务决策，或者带来用户体验问题、直接的经济损失。因此，作为数据干饭人，要对数据产品的数据质量负责，早诊断、早发现、早解决，防患于未然，否则，蚁穴溃堤就为时已晚。
一、数据质量问题的类型
国际数据管理协会(DAMA)定义了数据质量维度，结合实际的业务场景，总结数据质量7个核心的维度：准确性、及时性、完整性、合理性、一致性、唯一性、安全性。
1.准确性
准确性是指，一个数据值与设定为准确的值之间的一致程度，或与可接受程度之间的差异。在数据质量评价维度里面是第一位的，数据都不准，数据产品可视化效果再炫酷、交互体验再丝滑，也都无济于事。而且准确性是业务对数据团队信任度的重要前提。当数据产品呈现的数据多次不准确后，一旦数据出现波动，业务第一反应往往是数据是不是不准，而不是先看是不是有业务动作产生的数据结果。
数据产品应对策略：
定义数据评价标准，例如按照业务增长趋势或模型预测，定义指标合理的波动范围，当波动超出阈值后，及时预警通知数据人员，提前发现解决。
2.及时性
数据从采集加工到输出应用，需要经过很长的数据仓库ETL计算、数据同步的过程，任务运行耗时、运行质量、任务的依赖关系，都会影响数据最终产出的时间。一般离线数据分析(T 1，指今天分析的是昨天的完整数据)在次日凌晨12：00开始执行任务，当数据量大、计算耗时长、依赖任务多的任务，可能数据要在第二天下午，或者T 2才能输出。业务上班需要看数据，数据还没跑完，就影响业务正常的使用数据了。数据及时性主要受大数据集群服务的稳定性、存储和计算资源的影响，集群资源紧张，任务抢资源时，可能会导致原来9点前完成的任务，到下午还没完成。
数据产品应对策略：
设定核心数据涉及任务的最晚就位时间监控，但这种监控多数是通知，因为一般资源层面的问题很难修复，以知晓为主。而数据产品需要制定对应的兜底方案，例如，监控数据任务的状态，只有任务状态为成功时，才展示最新日期的数据，否则仍然展示前一天的数据，并且加上对应的交互提醒。“昨日数据计算中，请先查看其他日期数据“
3.完整性
主要包括实体缺失、属性缺失、记录缺失和字段值缺失四个方面。举个例子，App用户会基于设备ID 用户账号生成一个唯一uuid，在某次iOS发版后，数据报表统计分析发现iOS的DAU出现陡降，按照操作系统和app版本发现是新版本id生成服务异常，很多用户uuid为空，测试环节没有覆盖到，大量的数据统计才能发现这个问题。于是，后来针对埋点数据的核心字段，都进行了完整性监控，从数据底层更早发现问题，而不是业务报表输出。
4.合理性
主要包括格式、类型、值域和业务规则是否合理有效。由于业务端并不会把所有用户的交互输入操作进行规则验证，对于一些异常操作，会导致数据出现异常的情况。曾经遇到过外卖BD为了完成业绩获取奖金，自己跟商家合作下大金额订单，一笔外卖十几万元。这种可能就属于不正常的数据，通过数据合理范围的设定，可以及时抓出这些问题，由运营人员或者廉政部门进行审核。
5.一致性
指系统之间的数据差异和相互矛盾的一致性，业务指标统一定义，数据逻辑加工结果。数据团队不生产数据，只是数据的搬运工，数据从业务系统同步数据仓库，可能会由于系统、工具异常，导致数仓数据和业务端数据不一致的情况。对于数据产品端，主要是指同一指标或标签，数据处理逻辑不一致，数据对不上。数据加工层，需要对数仓贴源层与业务数据源数据量、核心字段一致性监控。
6.唯一性
主要是指数据主键的唯一，经常遇到数据主键重复，导致数据统计异常的情况。
7.安全性
2021年9月1日数据安全法正式实行，对于用户身份证、手机号等敏感数据是严谨明文传输和展示的，数据加工处理要在加密状态进行，数据产品端展示明文敏感信息会带来法律风险。
二、数据质量问题产生的原因
导致数据质量的问题多种多样，一般可以分为业务端、技术端、基础设施几个方面：
业务端：业务变动，例如新上活动页面埋点缺失，业务源系统变更(源系统数据库表结构变更、源系统环境变更)、业务端数据输入不规范等;
技术端：数据开发流程不规范、数据质量监控不健全，例如数据开发任务中各种任务的流程、参数、配置等出错，数据验证不充分
基础设施：存储计算集群资源不足，导致数据处理任务失败、延迟，从而导致数据输出结果异常。
三、数据产品如何掌控好自己的生命线
除了数据开发者需要关注自己的数据质量外，数据产品也需要对数据产品涉及到的数据源、任务进行过程监控，及时发现数据质量问题。同时，在产品端提供异常提醒，避免数据问题带来的错误决策或错误数据的营销使用。
首先，基于数据血缘或线下的数据链路维护，找到数据产品用到的数据的加工链路。针对核心服务，保证数据质量监控规则的全面覆盖。当数据加工环节出现异常时，第一时间知晓，跟进开发修复数据，并在业务端做好信息同步。
其次，在数据产品实现时，对数据指标依赖的加工任务状态进行判断，一是任务成功状态，二是及时性，当任务失败或延迟时，产品页面上，进行兜底方案处理，例如友好的文案提示，或利用IM邮件等通知用户。
此外，数据产品要和数据血缘建立联动关系，当业务怀疑数据异常时，可以直接从前端页面中，一键找到数据指标的加工链路，快速排查问题。
最后，数据团队还需要和业务建立信息互通机制，例如参与业务周会，了解产品、运营等业务动作，业务变动时，可以第一时间评估对数据的影响。
四、数据产品的延申：数据质量监控产品
为了实现数据产品对数据质量问题的早发现、早解决、早通知，最常用到的一个工具类数据产品就是数据质量监控了。即通过数据表、字段的规则配置，例如对表数据量、数据重复、字段波动、字段值等监控规则。在数据源层发现质量问题。
五、小结
数据质量问题是数据开发人员与数据产品需要共同关注的问题，两个角色是“一根绳上的蚂蚱“。但实际上，往往会出现断层的情况，即数据开发人员对数据输出端：数据产品的关注度不够，认为只要自己把数据ETL做好，加一些监控就够了。而数据产品，则以为只需要关注产品功能和交互，数据出来问题，那是数据开发的责任，不关注数据质量。数据产品是数据价值的体现形式之一，应该从产品出发，关注数据质量保障流程，共同提升业务对数据团队的信任度。这样，再有业务问”数据准不准“时，就可以更加有底气地反问，“你们业务有调整吗?”。
