数据仓库系统中的数据质量变得越来越重要. 越来越多的监管要求，但也日益复杂的 数据仓库解决方案，迫使公司加强(或启动)数据质量(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规则必须至少指派一个数据用户/数据用户单位在"分析"阶段检查结果，并决定一项发现是否以及如何影响其数据工作.
• 数据所有者. 每个DQ规则必须分配一个数据所有者.

(*)数据沿袭显示两点之间的数据流. 有数据沿袭, 您可以在仓库中找到影响给定目标字段的所有数据元素.

使用数据沿袭将用户分配给规则可能会有问题. 如前所述, 业务用户通常只知道数据集市层(和操作系统)。, 但不包括数据仓库的较低级别. 通过数据沿袭映射，数据用户将被分配他们不熟悉的规则. 对于较低级别，可能需要IT人员评估数据质量发现. 在很多情况下, 手动映射或混合方法(仅在数据集市中通过数据沿袭进行映射)可以提供帮助.

测量数据质量

度量数据质量意味着执行可用的数据质量规则，这是应该执行的 自动，由数据仓库的加载进程触发. 就像我们之前看到的, 可能有大量的数据质量规则, 所以检查会很耗时.

在理想情况下，只有在所有数据都没有错误的情况下才会加载数据仓库. 在现实世界中，这种情况很少发生(实际上，几乎从来没有发生过)。. 取决于整体加载策略, 您的数据仓库数据质量流程应该或不应该(后者的可能性更大)控制加载流程. 让数据质量流程(作业网络)并行并链接到“常规”数据仓库加载流程是一种很好的设计.

如果有定义好的服务水平协议, 确保不要用数据质量检查阻碍数据仓库的加载. 数据质量过程中的错误/异常不应停止常规加载过程. 应该报告数据质量过程中的意外错误，并在“分析”阶段显示出来(参见下一章)。.

请记住，数据质量规则可能会因为意外错误而崩溃(可能规则本身实现错误), 或者底层数据结构随时间变化). 如果您的数据质量系统提供了一种机制，将会有所帮助 禁用 这些规则，特别是如果您的公司每年发布的版本很少.

DQ过程应该如此 尽早执行并报告-理想情况下，在加载被检查的数据之后. 这有助于在数据仓库加载期间尽早检测错误(一些复杂的仓库系统加载持续数天)。.

分析

在这种情况下，“分析”意味着对数据质量发现做出反应. 这是分配给数据用户和数据所有者的任务.

您的数据质量项目应该清楚地定义反应方式. 资料使用者有义务对有发现的规则(至少是有红灯的规则)发表评论。, 解释正在采取什么措施来处理这一发现. 资料拥有人须获通知，并应与资料使用者一起作出决定.

可以执行以下操作:

• 严重的问题: 必须修复这个问题，并重复加载数据.
• 问题是可以接受的: 尝试为将来的数据加载修复该问题，并在数据仓库或报告中处理该问题.
• 缺陷DQ规则: 修复有问题的DQ规则.

在一个完美的世界里，每个数据质量问题都会得到解决. 然而，缺乏资源和/或时间往往导致变通.

能够及时做出反应, DQ系统必须通过调查结果告知数据用户“他们的”规则. 使用数据质量仪表板(可能会发送出现问题的消息)是一个好主意. 越早告知用户调查结果越好.

的 数据质量仪表板 应包含:

• 分配给给定角色的所有规则
• 规则的结果(交通灯), 措施, 以及示例行)，具有按结果和数据域过滤规则的能力
• 数据用户必须为调查结果输入的强制性注释
• 一个可选择“否决”结果的特性(如果数据质量规则报告了由于有缺陷的实现而导致的错误), 例如). 如果多个业务单元分配了相同的数据质量规则, “否决”只适用于资料使用者的业务单位(而非整个公司).
• 显示未执行或放弃的规则

仪表板还应该显示最近数据仓库加载过程的当前状态, 为用户提供数据仓库加载过程的360度视图.

数据所有者有责任确保对每个发现都进行了评论，并且所有数据用户的数据质量状态(原始或被否决)至少为黄色.

快速浏览一下, 它将有助于为数据用户/数据所有者构建一种简单的kpi(关键绩效指标). 如果每个规则被赋予相同的权重，那么为所有相关规则的结果设置一个整体交通灯是非常容易的.

就我个人而言, 我认为计算给定数据领域的数据质量的总体价值是相当复杂的，而且往往是模棱两可的, 但是，您至少可以显示按结果分组的数据域的总体规则数量.g.“100条DQ规则，90%为绿色，5%为黄色，5%为红色”).

数据所有者的任务是确保调查结果得到修正并提高数据质量.

改善流程

由于数据仓库流程经常发生变化，数据质量机制也需要维护.

数据所有者应始终注意以下几点:

• 保持更新. 数据仓库中的更改需要在数据质量系统中捕获.
• 增强. 为数据质量规则尚未涵盖的错误实现新的规则.
• 简化. 禁用不再需要的数据质量规则. 合并重叠的规则.

监控数据质量流程

随着时间的推移，监控整个数据质量过程有助于改进它.

值得关注的有:

• 数据质量规则对数据的覆盖范围
• 随着时间的推移，活动规则中数据质量发现的百分比
• 活跃数据质量规则的数量(请关注它)——我曾看到数据用户通过简单地禁用越来越多的数据质量规则来解决他们的发现.)
• 在数据负载内对所有发现进行评级和固定所需的时间

最终数据仓库数据质量过程提示

以下几点在任何类型的项目中都很重要.

预测阻力. 正如我们所见, 如果没有紧急的质量问题, 数据质量通常被视为没有提供新功能的额外负担. 请记住，它可能会为数据用户创建额外的工作负载. 在很多情况下, 遵从性和法规需求可以帮助您说服用户将其视为不可避免的需求.

找一个担保人. 如上所述, DQ不是一种快速销售的商品, 因此，需要一个强有力的赞助者/利益相关者——管理层越高, 更好的.

找到同盟. 与赞助者一样，任何分享高数据质量理念的人都将是最有帮助的. DQ电路回路是一个持续的过程，需要人们保持电路回路的活力.

从小事做起. 如果到目前为止还没有DQ策略，请寻找需要更好数据质量的业务单元. 构建一个原型，向他们展示更好的数据带来的好处. 如果您的任务是改进甚至替换给定的数据质量策略, 看看在组织中运作良好/被接受的事情, 并保留它们.

不要忽略了整体情况. 虽然开始很小, 请记住一些要点, 尤其是角色, 成功的DQ策略的先决条件是什么.

一旦实施，就不要放弃. 数据质量过程需要成为数据仓库使用的一部分. 随着时间的推移，对数据质量的关注往往会有点迷失，而维护数据质量则取决于您.