数据质量落地

9次阅读

共计 3409 个字符，预计需要花费 9 分钟才能阅读完成。

数据质量是数据分析结论有效性和准确性的基础，也是一切的前提。如何保障数据质量。

完整性

完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。

准确性

准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。比如一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息等，这些必然都是有问题的。如果确保记录的准确性，也是保障数据质量必不可少的一个原则。

一致性

一致性一般体现在跨度很大的数据仓库体系中，比如阿里巴巴数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性。例如用户 ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致。所以，在建设阿里巴巴数据仓库时，才有了公共层的加工，以确保数据的一致性。

及时性

在确保数据的完整性，准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。一般决策支持分析师都希望当天能够看到前一天的数据，而不是等三五天才能看到某一个数据分析结果；否则久已经失去了数据及时性的价值，分析工作变得毫无意义。现在对时间要求更高了，越来越多的应用都希望数据时小时级别或者实时级别的。

数据仓库建设过程中，经过不断的实践，总结出一套数据质量方法，在满足以上四个原则基础上，为数据做基础保障。

主要包括如下几个方面：

消费场景知晓部分主要通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题。

根据应用的影响程度，确定资产等级。资产等级划分：

毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关分险
全局性质：数据直接或间接用于集团级业务和效果的评估
局部性质：数据直接或间接用与内部一般数据产品或运营产品报告
一般性质：数据主要用于日常数据分析，带来影响极小
未知性质：不能明确说明数据的应用场景，则标注未知

前面已经给出了数据资产等级的定义，但是对于庞大的数据量，如何给每一份数据都打上一个等级标签呢？

首先要明白数据的流转过程：

数据是从业务系统中产生的，经过同步工具进入到数据仓库系统中，在数据仓库中进行一般意义上的清洗，加工，整合，算法，模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现出来的。

所以数据资产的落地方式则依赖于 元数据应用链路方式，主要分为三步：

通过不同的数据应用确定资产等级
根据元数据确定数据应用表的上下游血缘关系
将消费链路上表打上资产标签

数据生产加工各个环节卡点校验部分主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。其中在线系统指 OLTP 系统，离线系统指 OLAP 系统。

在线系统卡点校验

在线系统业务复杂多变，总时在不断的变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，总结出两个行之有效的方法：

工具和人员双管齐下，既要在工具上自动捕捉每一次业务的变化，同时也要求业务人员在意识上自动进行业务变更通知。

数据库表的变化感知。无论是随着业务发展而做的数据库扩容还是表的 DDL 变化，都需要主动通知到离线开发人员。

离线系统卡点校验：

数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗，加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加工过程中的质量，是离线数据残酷保障数据质量的一个重要环节。主要实现方法分为以下几个方面：

代码提交卡点校验：将每一次提交上线的代码进行扫描，将风险点提示出来

任务发布上线卡点校验：发布上线测试主要包括 Code Review 和回归测试，对于资产等级较高的任务变更发布，则采用强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布

Dry Run：不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误，真实环境的运行测试，则使用真实数据进行测试。

数据重刷前变更通知：一般将变更原因，变更逻辑，变更测试和变更时间通过类似通知中心平台通知下游，下游对此没有异议后，在按照约定时间执行发布变更。

风险点监控部分主要是针对数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括 在线数据和离线数据 的风险点监控两个方面。

在线数据的风险点监控主要是针对在线系统日常运行产出的数据进行业务规则的校验，以保证数据质量。利用实时平台进行监控。

针对数据库表的记录进行规则校验。在每一个业务系统中，当完成业务过程进行数据落库时，实时平台同时订阅一份相同的数据进行逻辑验证，当校验不通过的时候，以报警的形式披露给订阅人。完成数据的校验，这也是数据的准确性把的第一道关。

离线数据的风险点监控主要是针对离线系统日常运行产出的数据进行数据质量监控和时效性监控。利用离线平台进行监控。

主要包括数据准确性和数据产出及时性的监控:

1. 数据准确性
采用 DCQ 检查，DQC 查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，旦检查点太多自然就会影响整体的性能，因此还是依赖数据产等级来确定规则的配置情况。比如高等级 A1,A2 类数据监控率就要到达 90% 以上，规则类型也需要三种以上。
2. 数据及时性
为确保前一天的数据完整，天任务是从零点开始运行的，由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，则需要进行一系列的报警和优先级设置，使得重要的任务优先且正确产出，所以就要根据任务划分优先级，并制定对应的任务告警。优先级则根据资产等级来进行划分，任务告警主要包括出错告警，完成告警，未完成告警，周期性告警，超时告警以及自定义告警。

上文提到的保障数据仓库数据质量的各种方案，如何评价这些方案的优劣，则需要一套度量指标。

1. 数据质量起夜率

前文在介绍数据及时性时已经提到，数据产品或者管理层决策日报一般都要求在上午 9:00 之前提供，数据仓库的作业任务都是在凌晨运行的一旦数据出现问题就需要开发人员起夜进行处理。因此，每个月的起夜次数将是衡量数据质量建设完善度的一个关键指标。如果频繁起夜，则说明数据质量的建设不够完善。

2. 数据质量事件

针对每一个数据质量问题，都记录一个数据质量事件。数据质量事件，首先用来跟进数据质量问题的处理过程；其次，用来归纳分析数据质量原因；第三，跟进数据质量原因来查缺不漏，既要找到数据出现问题，也要针对类似问题给出后续预防方案。因此，数据质量事件既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指针。

3. 数据质量故障体系

对于严重的数据质量事件，将升级为故障。故障是指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险。比如财报计算错误等，都将带来恶劣影响。所以此类数据质量问题，已经不仅仅是一个事件，而是升级为故障。所以数据质量故障对于开发人员和部门来讲，都是一个重要的考核点，因此也是数据质量最严的一个指标。

故障定义

首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误即自动生成故障单，形成故障。

故障等级

故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按 pl 到 p4 定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果。

故障处理

故障发生后，需要快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中会尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响。

故障 Review

对于故障会进行 Review，即分析故障的原因、处理过程的复盘、形成后续解决的 Action，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会到具体的责任人。注意，对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生。