数据质量建设

Posted 2023-01-06 爱是与世界平行

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据质量建设相关的知识，希望对你有一定的参考价值。

数据仓库之数据质量建设

数仓建设真正的难点不在于数仓设计，而在于后续业务发展起来，业务线变的庞大之后的数据治理，而数据治理的范围非常广，包含数据本⾝的管理、数据安全、数据质量、数据成本等。在这么多治理内容中，大家想下最重要的治理是什么？当然是数据质量治理，因为数据质量是数据分析结论有效性和准确性的基础，也是这一切的前提。所以如何保障数据质量，确保数据可用性是数据仓库建设中不容忽视的环节。

数据质量涉及的范围也很广，贯穿数仓的整个生命周期，从数据产生->数据接入->数据存储->数据处理->数据输出->数据展示，每个阶段都需要质量治理。

在系统建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免事后的清洗工作。

1. 为什么要进行数据质量评估

很多刚入门的数据人，拿到数据后会立刻开始对数据进行各种探查、统计分析等，企图能立即发现数据背后隐藏的信息和知识。然而忙活了一阵才颓然发现，并不能提炼出太多有价值的信息，白白浪费了大量的时间和精力。比如和数据打交道的过程中，可能会出现以下的场景：

场景一：作为数据分析人员，要统计一下近 7 天用户的购买情况，结果从数仓中统计完发现，很多数据发生了重复记录，甚至有些数据统计单位不统一。

场景二：业务看报表，发现某一天的成交 gmv 暴跌，经过排查发现，是当天的数据缺失。

造成这一情况的一个重要因素就是忽视了对数据质量的客观评估，没有制定合理的衡量标准，导致没有发现数据已出现问题。所以，进行科学、客观的数据质量衡量标准是非常必要且十分重要的。

2. 数据质量衡量标准

如何评估数据质量的好坏，业界有不同的标准，我总结了以下六个维度进行评估，包括完整性、规范性、一致性、准确性、唯一性、及时性。

数据完整性

完整性指的是数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。

数据规范性

规范性指的是描述数据遵循预定的语法规则的程度，是否符合其定义，比如数据的类型、格式、取值范围等。

数据一致性

一致性是指数据是否遵循了统一的规范，数据集合是否保持了统一的格式。数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑，一致性并不意味着数值上的绝对相同，而是数据收集、处理的方法和标准的一致。常见的一致性指标有：ID 重合度、属性一致、取值一致、采集方法一致、转化步骤一致。

数据准确性

准确性是指数据记录的信息是否存在异常或错误。和一致性不一样，存在准确性问题的数据不仅仅只是规则上的不一致，更为常见的数据准确性错误就如乱码，其次异常的大或者小的数据也是不符合条件的数据。常见的准确性指标有：缺失值占比、错误值占比、异常值占比、抽样偏差、数据噪声。

数据唯一性

唯一性指的是数据库的数据不存在重复的情形。比如真实成交 1 万条，但数据表有 3000 条重复了，成了 1.3 万条成交记录，这种数据不符合数据唯一性。

数据及时性

及时性是指数据从产生到可以查看的时间间隔，也叫数据的延时时长。比如一份数据是统计离线今日的，结果都是第二天甚至第三天才能统计完，这种数据不符合数据及时性。

还有一些其他的衡量标准，在此简单列出：

维度	衡量标准
参照完整性	数据项是否在父表中有定义
依赖一致性	数据项取值是否满足与其他数据项之间的依赖关系
正确性	数据内容和定义是否一致
精确性	数据精度是否达到业务规则要求的位数
技术有效性	数据项是否按已定义的格式标准组织
业务有效性	数据项是否符合已定义的
可信度	根据客户调查或客户主动提供获得
可用性	数据可用的时间和数据需要被访问时间的比例
可访问性	数据是否便于自动化读取

3. 数据质量管理流程

本节流程如下图所示：

1. 数据资产等级

1) 等级定义

根据当数据质量不满足完整性、规范性、一致性、准确性、唯一性、及时性时，对业务的影响程度大小来划分数据的资产等级。

毁灭性：数据一旦出错，会引起巨大的资产损失，面临重大收益受损等。标记为 L1
全局性：数据用于集团业务、企业级效果评估和重要决策任务等。标记为 L2
局部性：数据用于某个业务线的日常运营、分析报告等，如果出现问题会给该业务线造成一定的影响或影响其工作效率。标记为 L3
一般性：数据用于日常数据分析，出现问题的带来的影响很小。标记为 L4
未知性质：无法追溯数据的应用场景。标记为 Lx

重要程度：L1>L2>L3>L4>Lx。如果一份数据出现在多个应用场景中，则根据其最重要程度进行标记。

2) 等级划分

定义数据资产等级后，我们可以从数据流程链路开始进行数据资产等级标记，完成数据资产等级确认，给不同的数据定义不同的重要程度。

1. 分析数据链路：

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

2. 标记数据资产等级：

在所有数据链路上，整理出消费各个表的应用业务。通过给这些应用业务划分数据资产等级，结合数据的上下游依赖关系，将整个链路打上某一类资产等级标签。

举例：

假设公司有统一的订单服务中心。应用层的应用业务是按照业务线，商品类型和地域统计公司的订单数量和订单金额，命名为order_num_amount。

假设该应用会影响到整个企业的重要业务决策，我们可以把应用定级为 L2，从而整个数据链路上的表的数据等级，都可以标记为L2-order_num_amount，一直标记到源数据业务系统，如下图所示：

2. 数据加工过程卡点校验

1) 在线系统数据校验

在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。

基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，我们可以通过工具+人员管理并行的方式来尽可能的解决以上问题：既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。

1. 业务上线发布平台：

监控业务上线发布平台上的重大业务变更，通过订阅这个发布过程，及时将变更内容通知到数据部门。

由于业务系统复杂多变，若日常发布变更频繁，那么每次都通知数据部门，会造成不必要的资源浪费。这时，我们可以使用之前已经完成标记的数据资产等级标签，针对涉及高等级数据应用的数据资产，整理出哪些类型的业务变更会影响数据的加工或者影响数据统计口径的调整，则这些情况都必须及时通知到数据部门。

如果公司没有自己的业务发布平台，那么就需要与业务部门约定好，针对高等级的数据资产的业务变更，需要以邮件或者其他书面的说明及时反馈到数据部门。

2. 操作人员管理：

工具只是辅助监管的一种手段，而使用工具的人员才是核心。数据资产等级的上下游打通过程需要通知给在线业务系统开发人员，使其知道哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用，提高在线开发人员的数据风险意识。

可以通过培训的方式，把数据质量管理的诉求，数据质量管理的整个数据加工过程，以及数据产品的应用方式及应用场景告知在线开发人员，使其了解数据的重要性、价值及风险。确保在线开发人员在完成业务目标的同时，也要考虑数据的目标，保持业务端和数据段一致。

2) 离线系统数据校验

数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加过程中的质量，是离线数据仓库保障数据质量的一个重要环节。

数据加工上线流程如下图所示：

在这些环节中，我们可以采用以下方式来保障数据质量：

代码提交核查：

开发相关的规则引擎，辅助代码提交校验。规则分类大致为：

代码规范类规则：如表命名规范、字段命名规范、生命周期设置、表注释等；
代码质量类规则：如分母为 0 提醒、NUll 值参与计算提醒等；
代码性能类规则：如大表提醒、重复计算监测、大小表 join 操作提醒等。

代码发布核查：

加强测试环节，测试环境测试后再发布到生成环境，且生成环境测试通过后才算发布成功。

任务变更或重跑数据：

在进行数据更新操作前，需要通知下游数据变更原因、变更逻辑、变更时间等信息。下游没有异议后，再按照约定时间执行变更发布操作。

3. 数据处理风险监控

风险点监控主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制，主要包括在线数据和离线数据运行风险点监控。

1) 数据质量监控

在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。

比如交易系统配置的一些监控规则，如订单拍下时间、订单完结时间、订单支付金额、订单状态流转等都配置了校验规则。订单拍下时间肯定不会大于当天时间，也不会小于业务上线时间，一旦出现异常的订单创建时间，就会立刻报警，同时报警给到多人。通过这种机制，可以及时发现并解决问题。

随着业务负责程度的提升，会导致规则繁多、规则配置的运行成本增大，这时可以按照我们之前的数据资产等级有针对性的进行监控。

离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。对数据调度平台上所有数据处理调度进行监控。

我们以阿里的 DataWorks 数据调度工具为例，DataWorks 是基于 MaxCompute 计算引擎的一站式开发工场，帮助企业快速完成数据集成、开发、治理、质量、安全等全套数据研发工作。

DataWorks 中的 DQC 通过配置数据质量校验规则，实现离线数据处理中的数据质量监控报警机制。

下图是 DQC 的工作流程图：

DQC 数据监控规则有强规则和弱规则：

强规则：一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）。
弱规则：只报警但不阻断任务的执行。

DQC 提供常用的规则模板，包括表行数较 N 天前波动率、表空间大小较 N 天前波动率、字段最大/最小/平均值相比 N 天前波动率、字段空值/唯一个数等。

DQC 检查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能，因此还是依赖数据产等级来确定规则的配置情况。比如 L1、L2 类数据监控率要达到 90% 以上，规则类型需要三种及以上，而不重要的数据资产则不强制要求。

2) 数据及时性监控

在确保数据准确性的前提下，需要进一步让数据能够及时地提供服务，否则数据的价值将大幅度降低，甚至没有价值，所以确保数据及时性也是保障数据质量重中之重的一环。

任务优先级：

对于DataWorks平台的调度任务，可以通过智能监控工具进行优先级设置。DataWorks的调度是一个树形结构，当配置了叶子节点的优先级，这个优先级会传递到所有的上游节点，而叶子节点通常就是服务业务的消费节点。

因此，在优先级的设置上，要先确定业务的资产等级，等级越高的业务对应的消费节点优先级越高，优先调度并占用计算资源，确保高等级业务的准时产出。

总之，就是按照数据资产等级优先执行高等级数据资产的调度任务，优先保障高等级业务的数据需求。

任务报警：

任务报警和优先级类似，通过DataWorks的智能监控工具进行配置，只需要配置叶子节点即可向上游传递报警配置。任务执行过程中，可能出错或延迟，为了保障最重要数据（即资产等级高的数据）产出，需要立即处理出错并介入处理延迟。

DataWorks智能监控：

DataWorks进行离线任务调度时，提供智能监控工具，对调度任务进行监控告警。根据监控规则和任务运行情况，智能监控决策是否报警、何时报警、如何报警以及给谁报警。智能监控会自动选择最合理的报警时间、报警方式以及报警对象。

4. 通知管理

要想真正解决数据质量问题，就要明确业务需求并从需求开始控制数据质量，并建立数据质量管理机制。从业务出发做问题定义，由工具自动、及时发现问题，明确问题责任人，通过邮件、短信等方式进行通知，保证问题及时通知到责任人。跟踪问题整改进度，保证数据质量问题全过程的管理。

5 如何保障数仓数据质量？

5.1 有赞数据链路

5.1.1 数据链路介绍

首先介绍有赞的数据总体架构图：

自顶向下可以大致划分为应用服务层、数据网关层、应用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查询提供了基础能力。

以上对整体架构做了初步的介绍，对于质量把控来说，最核心的两个部分是：数据仓库以及数据应用部分。因为这两部分属于数据链路中的核心环节，相对于其他层级而言，日常改动也更为频繁，出现问题的风险也比较大。

5.2 数据层测试

5.2.1 整体概览

首先，针对数据层的质量保障，可以分成三个方面：数据及时性、完整性、准确性。

5.2.2 数据及时性

数据及时性，顾名思义就是测试数据需要按时产出。及时性重点关注的三个要素是：定时调度时间、优先级以及数据deadline。其中任务的优先级决定了它获取数据计算资源的多少，影响了任务执行时长。数据deadline则是数据最晚产出时间的统一标准，需要严格遵守。

这三要素中，属于“普世规则”且在质量保障阶段需要重点关注的是：数据deadline。那么我们基于数据deadline，针对及时性的保障策略就可分为两种：

监控离线数据任务是否执行结束。这种方式依赖于有赞作业开发平台的监控告警，若数据任务在deadline时间点未执行完成，则会有邮件、企微、电话等告警形式，通知到相应人员。

检查全表条数或者检查分区条数。这种方式依赖接口自动化平台，通过调用dubbo接口，判断接口返回的数据指标是否为0，监控数据是否产出。

其次我们可以关注失败、重试次数，当任务执行过程中出现多次失败、重试的异常情况，可以抛出告警让相关人员感知。这部分的告警是对deadline告警的补充，目前在有赞作业开发平台上也有功能集成。

5.2.3 数据完整性

数据完整性，顾名思义看数据是不是全，重点评估两点：数据不多、数据不少。

数据不多：一般是检查全表数据、重要枚举值，看数据有没有多余、重复或者数据主键是否唯一。
数据不少：一般是检查全表数据、重要字段（比如主键字段、枚举值、日期等），看字段的数值是否为空、为null等。

可见数据完整性和业务本身关联度没有那么密切，更多的是数仓表的通用内容校验。所以从一些基础维度，我们可以将测试重点拆成表级别、字段级别两个方向。

表级别完整性：

全表维度，通过查看全表的总行数/表大小，若出现表总行数/总大小不变或下降，说明表数据可能出现了问题。
分区维度，通过查看当日分区表的数据行数/大小，若和之前分区相比差异太大（偏大或偏小），说明表数据可能出现了问题。

目前有赞元数据管理平台已集成相关数据视图：

字段级别完整性：

唯一性判断：保证主键或某些字段的唯一性，防止数据重复导致和其他表join之后数据翻倍，导致最终统计数据偏大。

比如判断ods层订单表中的订单号是否唯一，编写sql：

select 
count(order_no)
,count(distinct order_no) 
from ods.xx_order

若两者相等，则说明order_no值是表内唯一的；否则说明order_no表内不唯一，表数据存在问题。

非空判断：保证重要字段非空，防止空数据造成和表join之后数据丢失，导致最终统计数据偏少。

比如判断ods层订单表中的订单号是否出现null，编写sql：

select 
count(*) 
from ods.xx_order 
where order_no is null

若结果等于0，则说明order_no不存在null；若结果大于0，则说明order_no存在null值，表数据存在问题。

枚举类型判断：保证枚举字段值都在预期范围之内，防止业务脏数据，导致最终统计结果出现遗漏/多余的数据类型。

比如判断ods层订单表中的shop_type字段中所有枚举值是否符合预期，编写sql：

select shop_type from ods.xx_order group by shop_type

分析查询结果是否满足预期，确保不会出现遗漏/多余的枚举类型。

数据有效性判断：判断数据格式是否满足预期，防止字段的数据格式不正确导致数据统计的错误以及缺失。常见的有日期格式yyyymmdd。

一旦出现数据完整性问题，对数据质量的影响很大。所以完整性策略更适用于ods层，因为我们更期望从源头发现并解决数据不合理问题，及时止损，避免脏数据进入下游之后，数据污染扩大。

另外，我们看到完整性校验内容逻辑简单，且比较固定，稍微进行简单的抽象就能将其模板化。那么作为测试，我们更倾向于将数据完整性校验做成工具。目前有赞“数据形态工具”已经落地，下面给出我的一些思路：

针对所有表来说，普世性的规则，比如表主键的唯一性。
针对不同类型比如数值、String、枚举、日期格式类型，列举出常见的数据判断规则。
给每项规则进行等级划分，比如表的主键不唯一，记为critical。String类型字段的空值比例大于70%，记为warning。
根据表数据是否满足上述这些规则，最终落地一份可视化报告，测试人员可根据报告内容评估数据质量。

5.2.4 数据准确性

数据准确性，顾名思义数据要“准确”。“准确”这个概念比较抽象，因为我们很难通过一个强逻辑性的判断，来说明数据有多准，大部分都存在于感性的认知中。所以准确性测试也是在数据质量保障过程中思维相对发散的一个方向。

经过总结，我们可以从字段自身检查、数据横向对比、纵向对比、code review等方面，去把控数据的准确性，这些测试点和业务的关联也比较密切。

5.2.4.1 自身检查

数据自身检查，是指在不和其他数据比较的前提下，用自身数据来检查准确的情况，属于最基本的一种检查。常见的自身检查包括：检查数值类指标大于0、比值类指标介于0-1范围。这类基础规则，同数据完整性，也可以结合“数据形态工具”辅助测试。

举个例子，比如针对订单表，支付金额必然是大于等于0，不会出现负数的情况，编写sql：

select 
count(pay_price) 
from 
dw.dws_xx_order 
where par = 20211025 and pay_price<0

若结果为0，说明支付金额都是大于0，满足预期；否则若count结果大于0，说明数据存在问题。

5.2.4.2 表内横向数据对比

表内横向对比可以理解为同一张表内，业务上相关联的两个或多个字段，他们存在一定的逻辑性关系，那么就可以用来做数据对比。

比如针对订单表，根据实际业务分析易得：针对任何一家店铺的任意一款商品，都满足订单数 >=下单人数，编写sql：

select 
kdt_id
,goods_id
,count(order_no)
,count(distinct buyer_id) 
from dw.dws_xx_order
where par = '20211025'
group by kdt_id,goods_id
having count(order_no)<count(distinct buyer_id)

若查询结果不存在记录，则说明不存在订单数<下单人数，反向说明订单数>=下单人数，则符合预期；否则若查询结果的记录大于0，则不符合预期。

5.2.4.3 表间横向数据对比

表间横向对比可以理解为两张表或多张表之间，其中具有业务关联或者业务含义一致的字段，可以用来做数据对比：

同类型表之间对比：针对hive里的支付表A和支付表B，里面都有支付金额字段，那么同样维度下的表A.支付金额 = 表B.支付金额。
多套存储之间对比：比如有赞数据报表中心针对支付表，应用层存储分别用到了mysql和kylin，用作主备切换，那么相同维度下的kylin-表A.支付金额 = mysql-表B.支付金额。
多个系统之间对比：跨系统之间，比如有赞的数据报表中心和crm系统，两个系统都有客户指标数据，那么相同维度下的数据报表中心-表A.客户指标 = crm-表B.客户指标。

我们深度剖析数据横向对比的底层逻辑，本质就是两张表的不同字段，进行逻辑运算符的比较，也比较容易抽象成工具。目前有赞“数据比对工具”已经落地，下面给出我的一些思路：

输入两张表，分别设置两表的主键。
输入两张表中需要对比的字段，且设置对比的运算符，比如>、=、<。
根据设置的规则，最终数据对比通过、不通过的记录，落地一份可视化报告，测试人员可根据报告内容评估数据质量。

5.2.4.4 纵向数据对比

纵向对比就是上下游的数据比较，目的是确保重要字段在上下游的加工过程中没有出现问题。

比如数仓dw层存在订单的明细表，数据产品dm层存在订单数的聚合表，那么二者在相同维度下的数据统计结果，应该保持一致。

5.2.4.5 code review

首先，在进行code review之前的需求评审阶段，我们先要明确数据统计的详细口径是什么，下面举两个实际的需求例子。

需求1：（错误示例）统计时间内店铺内所有用户的支付金额。问题所在：需求描述太过于简洁，没有阐述清楚数据统计的时间维度以及过滤条件，导致统计口径不清晰，要求产品明确口径。
需求2：（正确示例）有赞全网商家域店铺维度的离线支付金额。支持自然日、自然周、自然月。统计时间内，所有付款订单金额之和（剔除抽奖拼团、剔除礼品卡、剔除分销供货订单）。

明确需求之后，下面详细介绍code review的一些常见关注点：

1）关联关系 & 过滤条件