数据仓库系统中的数据质量变得越来越重要. 越来越多的监管要求，但也日益复杂的数据仓库解决方案，迫使公司加强(或启动)数据质量(DQ)计划.

本文主要关注“传统”数据仓库, 但数据质量在数据湖等更“现代”的概念中也是一个问题. 本文将展示在实现数据质量策略时需要考虑的一些要点，以及需要避免的一些常见陷阱. 本文没有介绍如何选择正确的技术/工具来构建DQ框架.

DQ项目中最具阻碍性的问题之一是，乍一看, 它为业务单位创建了大量的工作，而没有提供任何额外的功能. 数据质量倡议通常只有在以下情况下才有强有力的支持者:

存在严重影响业务的数据质量问题.
监管机构执行数据质量标准(例如.g., BCBS 239 在金融行业).

DQ的处理类似于软件开发中的测试——如果一个项目耗尽了时间和/或预算, 这部分倾向于首先减少.

当然，这并不是全部的真相. 良好的数据质量系统有助于及早发现错误, 从而加快了向用户交付“足够好”质量数据的过程.

术语定义

在讨论这个主题之前，对所使用的术语有一个共同的理解是很重要的.

数据仓库(DWH)

A 数据仓库非操作系统是否主要用于决策支持. 它整合操作系统(所有操作系统或较小的子集)的数据，并为DWH系统的用户提供查询优化的数据. 数据仓库应该在企业内提供“事实的单一版本”. 数据仓库通常由阶段/层组成:

操作数据基本不变地存储在 分段层. 的芯层包含整合和统一的数据. 下一个可选阶段是a 推导区域，提供派生数据(例如，销售的客户评分)和聚合. 的 数据集市层 包含针对给定用户组优化的数据. 数据集市通常包含聚合和大量派生指标. 数据仓库用户通常只使用数据集市层.

在每个阶段之间，某种数据转换发生. 通常, 数据仓库定期加载操作数据的增量提取，并包含保存历史数据的算法.

数据质量

数据质量通常被定义为产品满足用户需求的程度. 不同的用户可能对产品有不同的需求，因此数据质量的实现取决于用户的观点, 确定这些需求是很重要的.

数据质量并不意味着数据必须完全或几乎没有错误——它取决于用户的需求. “足够好”的方法是一个很好的选择. 现在, 大公司有“数据(或信息)政府政策”,数据质量是其中的一部分. A 数据政府政策 应该描述一下你的公司是如何处理数据的，以及它是如何确保数据具有正确的质量的 数据隐私规则 没有被侵犯.

数据质量是一个持续的话题. 必须实现DQ电路环路(参见下一章). 法规要求和遵从性规则也会影响所需的数据质量，例如 TCPA (美国电话消费者保护法)或 GDPR 在欧洲的隐私问题，但也有行业特定的规则，如偿付能力II 欧盟的保险，BCBS 239和其他银行，等等.

数据质量电路

与所有质量主题一样，DQ是一项持续的活动，旨在保持令人满意的质量. 作为DQ项目的结果，a 电路回路 类似于下面的一个必须实现:

这个循环中的步骤将在下一章中描述.

数据质量角色

下一个, 我们将看到如何提高数据仓库环境中的数据质量，以及如何实现一个成功的DQ计划. 为此，需要以下角色:

数据所有者. 数据所有者不仅要对数据质量负责，还要对数据隐私保护负责. 数据所有者“拥有”一个数据域, 控制访问, 并负责确保数据质量，并采取行动解决问题. 在较大的组织中，通常会找到几个数据所有者. 例如，数据域可以是营销数据、控制数据等. 如果公司中存在多个数据所有者, 应该有一个人(数据所有者或其他人)负责整个数据质量过程. A data owner should have a strong authority to enforce data quality and support the DQ process; therefore, 数据所有者通常是高级利益相关者. 对业务领域的良好理解以及良好的沟通技巧非常重要.
数据管理员. 数据管理员帮助实现企业内的数据质量, 就如何解释数据/数据模型的问题向数据用户提供支持, 数据质量问题, 等. 数据管理员通常是数据所有者的员工，或者可以组织在数据质量能力中心或DQ团队中. 数据管理员可以有IT或业务背景，但应该了解这两方面. 分析技能以及对所支持的业务领域的良好理解, 结合较强的沟通能力, 成功的数据管理员的主要先决条件是什么.
数据用户. 这些是处理数据的数据仓库用户. 数据用户通常使用数据集市层，并对数据的工作结果负责. 数据用户确保有足够的数据质量检查，以满足他们所需的质量水平. 数据用户需要对他们的数据有深刻的理解, 业务领域, 以及解释数据所需的分析技能. 在每个业务单元的数据用户中找几个人负责数据质量问题是合理的.

为了确保成功，明确和广泛地定义这些角色是很重要的接受在DQ项目的早期阶段. 找到它同样重要称职的数据专家对于这些支持项目的角色.

定义数据仓库中的DQ规则

数据质量/数据仓库的关系非常紧密，因为定义前者的规则需要对后者有很好的理解.

如何找到DQ规则?

如前所述， 数据用户 (和数据所有者)负责数据的使用，因此也负责所需的数据质量水平. 数据用户应该对他们的数据有很好的理解，这样他们才能为有用的数据质量规则提供最好的输入.

他们也是分析数据质量规则结果的人, 因此，让他们定义自己的规则总是一个好主意. 这进一步提高了对分配给数据用户单位的DQ规则结果的检查和评级的接受度(参见“分析”一章)。.

这种方法的缺点是数据用户通常只知道数据集市层, 而不是数据仓库的早期层. 如果数据在“较低”阶段被损坏, 仅检查数据仓库的“顶层”层是检测不到这一点的.

解决错误

数据仓库中可能会发生哪些已知错误?

数据仓库中的转换逻辑错误
- 您的IT环境越复杂，转换逻辑也就越复杂. 这些是最常见的DQ问题, 而这种错误的影响可能是“丢失”数据, 重复的, 不正确的价值观, 等.
负载过程不稳定或负载处理错误
- 数据仓库的负载可能是一个复杂的过程，其中可能包括作业编排定义中的错误(作业开始得太早或太晚), 未执行的任务, 等.). 由于人工干预造成的错误(例如.g., 有些作业被跳过, 一些作业在错误的截止日期开始或昨天的数据文件开始)经常发生在加载过程由于某些中断而超出带时.
数据源数据传输错误
- 数据传输通常作为源系统的任务来实现. 作业流中的异常或中断可能导致传递空数据或不完整数据.
操作数据错误
- 操作系统中的数据包含到目前为止尚未识别的错误. 这听起来可能很奇怪, 但是，在数据仓库项目中，直到数据包含在DWH中，才能看到操作数据的质量，这是老生常谈.
数据误读
- 数据是正确的，但用户不知道如何正确地解释它. 这是一个非常常见的“错误”，严格来说不是数据质量问题，而是与数据治理有关的问题，是数据管理员的任务.

这些问题通常是由于人们缺乏适当的知识和技能来定义, 实现, 运行, 并使用数据仓库解决方案.

数据质量维度

DQ维度 是一种常见的方法来识别和聚类DQ检查. 有很多定义, 维度的数量变化很大:你可能会发现16个, 或者更多维度. 从实际的角度来看, 从几个维度开始，并在用户中找到对它们的一般理解，这样不会让人感到困惑.

完整性: 是否所有所需的数据都可用并可访问? 是否所有需要的源都可用并已加载? 阶段之间数据丢失了吗?
一致性: 是否有错误/冲突/不一致的数据? 例如, 处于“已终止”状态的合同的终止日期必须包含高于或等于合同开始日期的有效日期.
独特性: 有重复的吗?
完整性: 是否所有数据都正确链接? 例如, 是否存在链接到不存在的客户id的订单(一个典型的引用完整性问题)?
及时性: 数据是当前的吗?? 例如，在有每日更新的数据仓库中，我希望昨天的数据今天可用.

数据仓库生成的数据 装载过程 也能有所帮助吗.

包含丢弃数据的表. 您的数据仓库可能有一些流程可以跳过/延迟由于技术问题而无法加载的数据.g.，格式转换，缺少强制值等.).
日志信息. 可以将明显的问题写入日志表或日志文件中.
交货单. 有些系统使用“交货单”来获取业务系统(如.g.(记录数，不同键数，值的总和). 它们可用于数据仓库和操作系统之间的核对检查(见下文).

请记住，在发现错误的情况下，每个数据质量检查必须由至少一个数据用户进行分析(参见“分析”章节), 为此，你需要一个负责任的人来监督每一次检查的实施.

在复杂的数据仓库中，最终可能会有许多(有时是数千个)DQ规则. 执行数据质量规则的过程应该足够健壮和快速以处理此问题.

不要检查由技术实现保证的事实. 例如，如果数据存储在关系DBMS中，则不需要检查是否:

定义为mandatory的列包含NULL值.
主键字段值在一个表中是唯一的.
启用关系完整性检查的表中不存在现有的外键.

也就是说, 请始终记住，数据仓库是不断变化的，字段和表的数据定义可能会随时间而变化.

家务管理很重要. 不同数据用户单位定义的规则可能重叠，应该加以合并. 您的组织越复杂，需要的内务管理就越多. 数据所有者应该将规则整合过程作为一种“数据质量规则的数据质量”来实现.”也, 如果数据不再使用，或者数据的定义发生了变化，那么数据质量检查可能变得毫无用处.

数据质量规则的类别

数据质量规则可以根据测试的类型进行分类.

数据质量检查. “正常”的情况, 检查一个数据仓库层(参见图1)中的数据，可以是一个表或一组表.
和解. 检查数据是否在数据仓库层之间正确传输的规则(参见图1). 这些规则主要用于检查“完整性”的DQ维度.“对账可以使用单行或汇总的方法. 检查单行要细得多, 但是您必须重现转换步骤(数据过滤), 字段值的变化, 反规范化, 连接, 等.). 您跳过的层越多，必须实现的转换逻辑就越复杂. 因此, 在每一层与其前身之间进行协调是一个不错的选择，而不是将登台层与数据集市层进行比较. 如果转换必须在协调规则中实现, 使用规范, 不是数据仓库代码! 对于总结的和解，找到有意义的字段(例如.g.、汇总、不同值的计数等.).
监控. 数据仓库通常包含历史数据，并加载操作数据的增量提取. 数据仓库和操作数据之间的差距可能会逐渐扩大. 构建汇总的时间序列数据有助于识别诸如此类的问题.g.(上月数据与当月数据对比). 充分了解其数据的数据用户可以为监测规则提供有用的度量和阈值.

如何量化数据质量问题

一旦您定义了要检查的内容，您就必须指定如何量化已确定的问题. 诸如“5行数据违反ID为15的DQ规则”之类的信息对于数据质量来说意义不大.

缺少以下部分:

如何量化/计算检测到的错误. 您可以计算“行数”，但也可以使用货币规模(例如，暴露)。. 记住，货币价值可能有不同的标志, 所以你必须研究如何有意义地总结它们. 您可以考虑在数据质量规则中同时使用量化单位(行数和汇总).
人口. 数据质量规则检查的单元数是多少? “5行数据中有5行”和“500万行数据中有5行”的质量不同.“总体应该使用与误差相同的量化方法来测量. 通常将数据质量规则的结果显示为百分比. 填充不能与表中的行数相同. 如果DQ规则只检查数据的一个子集(例如.g., 仅合同表中已终止的合同), 应该使用相同的过滤器来测量总体.
结果的定义. 即使数据质量检查发现了问题，也不一定会导致错误. 数据质量, 交通灯系统(红色, 黄色的, 绿色)使用阈值对发现进行评级是非常有用的. 例如，绿色:0-2%，黄色:2-5%，红色:5%以上. 请记住，如果数据用户单位共享相同的规则, 对于给定的规则，它们可能有非常不同的阈值. 营销业务单位可能不会介意失去一些订单, 而会计单位可能只在乎几分钱. 应该可以根据百分比或绝对数字确定阈值.
收集示例错误行. 如果数据质量规则提供了检测到的错误的示例，则会有所帮助!)键和已检查的数据值足以帮助检查错误. 对于数据质量规则来说，限制写入错误行的数量是个好主意.
有时, 您可能会在数据中发现“已知错误”，这些错误不会被修复，但可以通过有用的数据质量检查发现. 对于这些情况，使用 白名单 (数据质量检查应该跳过的记录的键).

其他元数据

元数据 “分析”和监控数据质量控制循环的各个阶段是否重要.

检查项目. 它有助于将已检查的表和字段分配给数据质量规则. 如果您有一个增强的元数据系统, 这可能有助于自动将数据用户和数据所有者分配给此规则. 出于监管原因(如BCBS 239), 还需要证明DQ是如何检查数据的. 然而, 通过数据沿袭(*)自动为数据用户/数据所有者分配规则可能是一把双刃剑(见下文).
数据用户. 每条DQ规则必须至少指派一个数据用户/数据用户单位在