如何实施数据质量流程

数据仓库系统中的数据质量 (DQ) 变得越来越重要。 不断增加的监管要求，以及数据仓库解决方案日益复杂的问题，迫使公司加强（或启动）数据质量计划。

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

DQ 项目最难解决的问题之一是，乍一看，它为业务部门创造了大量工作，却没有提供任何额外的功能。 数据质量计划通常只有在以下情况下才有强有力的支持者：

• 存在严重影响业务的数据质量问题。
• 监管机构执行数据质量标准（例如，金融行业的 BCBS 239）。

DQ 的处理类似于软件开发中的测试——如果一个项目用完了时间和/或预算，这部分往往会首先减少。

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

术语定义

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

数据仓库 (DWH)

数据仓库（DWH）是一种非操作系统，主要用于决策支持。 它整合了操作系统的数据（全部或较小的子集），并为 DWH 系统的用户提供查询优化的数据。 数据仓库应该在企业内部提供“单一版本的事实”。 数据仓库通常由阶段/层组成：

操作数据大部分未更改地存储到暂存层中。 核心层包含合并和统一的数据。 下一个可选阶段是派生区域，提供派生数据（例如，客户的销售分数）和聚合。 数据集市层包含针对给定用户组优化的数据。 数据集市通常包含聚合和大量派生指标。 数据仓库用户通常只使用数据集市层。

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

数据质量

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

数据质量并不意味着数据必须完全或几乎没有错误——它取决于用户的要求。 “足够好”的方法是一个不错的选择。 如今，大公司有“数据（或信息）政府政策”，数据质量是其中的一部分。 数据政府政策应描述贵公司如何处理数据以及如何确保数据具有正确的质量以及不违反数据隐私规则。

数据质量是一个持续的话题。 必须实现 DQ 电路环路（见下一章）。 监管要求和合规性规则也会影响所需的数据质量，例如 TCPA（美国电话消费者保护法）或欧洲针对隐私问题的 GDPR，以及行业特定规则，例如欧盟保险业的 Solvency II，BCBS 239和其他用于银行业务，等等。

数据质量电路回路

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

这个循环中的步骤将在接下来的章节中描述。

数据质量角色

要实施成功的 DQ 计划，需要以下角色：

• 数据所有者。 数据所有者对数据质量负责，同时也对数据隐私保护负责。 数据所有者“拥有”一个数据域，控制访问，并负责确保数据质量并采取行动修复发现。 在较大的组织中，通常会找到多个数据所有者。 例如，数据域可以是营销数据、控制数据等。如果公司中存在多个数据所有者，则应该有一个人（数据所有者或其他人）负责整个数据质量流程。 数据所有者应具有强制执行数据质量和支持 DQ 流程的强大权限； 因此，数据所有者通常是高级利益相关者。 对业务领域的良好理解以及良好的沟通技巧很重要。
• 数据管家。 数据管家帮助在企业内实施数据质量，支持数据用户解决有关如何解释数据/数据模型、数据质量问题等问题。数据管家通常是数据所有者的员工，或者可以组织在数据质量能力中心或 DQ 团队。 数据管理员可以有 IT 或业务背景，但应该了解双方。 分析技能以及对他们支持的业务领域的良好理解，再加上强大的沟通技巧，是成功的数据管家的主要先决条件。
• 数据用户。 这些是处理数据的数据仓库用户。 数据用户通常使用数据集市层，并对数据的工作结果负责。 数据用户确保对他们需要的质量水平进行充分的数据质量检查。 数据用户需要深入了解他们的数据、业务领域以及解释数据所需的分析技能。 在每个业务部门的数据用户中找几个人负责数据质量问题是合理的。

为确保成功，重要的是在 DQ 项目的早期阶段明确定义并在组织内广泛接受这些角色。 为这些角色找到支持项目的有能力的数据专家同样重要。

定义规则

查找并实施有用的 DQ 检查/规则。 定义 DQ 规则需要对您的数据仓库及其使用有充分的了解。

如何找到 DQ 规则？

如前所述，数据用户（和数据所有者）负责数据使用，因此也负责所需的数据质量水平。 数据用户应该对他们的数据有很好的理解，以便他们可以为有用的数据质量规则提供最佳输入。

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

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

处理错误

数据仓库中可能会出现哪些已知错误？

• 数据仓库中的错误转换逻辑
  • 您的 IT 环境越复杂，转换逻辑就越复杂。 这些是最常见的 DQ 问题，此类错误的影响可能是“丢失”数据、重复、不正确的值等。
• 负载过程不稳定或负载处理不当
  • 数据仓库的负载可能是一个复杂的过程，其中可能包括作业编排定义中的错误（作业开始得太早或太晚、作业未执行等）。 由于手动干预（例如，某些作业被跳过，某些作业以错误的截止日期或昨天的数据文件启动）导致的错误经常发生在加载过程由于某些中断而超出频带时发生。
• 数据源的错误数据传输
  • 数据传输通常作为源系统的一项任务来实现。 作业流程中的异常或中断可能会导致交付空的或不完整的数据。
• 错误的操作数据
  • 操作系统中的数据包含迄今为止无法识别的错误。 听起来可能很奇怪，但数据仓库项目中的陈词滥调是，在数据包含在 DWH 中之前，通常看不到操作数据的质量。
• 对数据的误解
  • 数据是正确的，但用户不知道如何正确解释。 这是一个非常常见的“错误”，严格来说不是数据质量问题，而是与数据治理有关，是数据管理员的任务。

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

数据质量维度

DQ 维度是识别和集群 DQ 检查的常用方法。 有许多定义，并且维度的数量变化很大：您可能会发现 16 个，甚至更多的维度。 从实践的角度来看，从几个维度开始并在您的用户中找到对它们的一般理解会不会令人困惑。

• 完整性：所需的所有数据是否可用且可访问？ 是否所有需要的资源都可用并已加载？ 阶段之间是否丢失了数据？
• 一致性：是否存在错误/冲突/不一致的数据？ 例如，处于“已终止”状态的合同的终止日期必须包含早于或等于合同开始日期的有效日期。
• 唯一性：是否有重复？
• 完整性：所有数据是否正确链接？ 例如，是否有订单链接到不存在的客户 ID（典型的参照完整性问题）？
• 及时性：数据是最新的吗？ 例如，在一个每天更新的数据仓库中，我希望昨天的数据今天可用。

数据仓库加载过程生成的数据也很有帮助。

• 丢弃数据的表。 您的数据仓库可能具有跳过/延迟由于技术问题（例如，格式转换、缺少强制值等）而无法加载的数据的过程。
• 记录信息。 明显的问题可能会写入日志表或日志文件。
• 交货单。 一些系统对操作系统提供的数据使用“交货单”（例如，记录数量、不同键的数量、值的总和）。 这些可用于数据仓库和操作系统之间的协调检查（见下文）。

请记住，每项数据质量检查都必须由至少一名数据用户进行分析（请参阅“分析”一章），以防发现错误，为此您需要有人负责并随时负责执行每项检查。

在复杂的数据仓库中，您最终可能会拥有许多（有时是数千个）DQ 规则。 执行数据质量规则的过程应该足够健壮和足够快来处理这个问题。

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

• 定义为强制的列包含 NULL 值。
• 主键字段值在表中是唯一的。
• 启用了关系完整性检查的表中没有现有的外键。

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

家政服务非常重要。 不同数据用户单位定义的规则可能重叠，应合并。 您的组织越复杂，需要的内务管理就越多。 数据所有者应该将规则整合过程作为一种“数据质量规则的数据质量”来实施。 此外，如果不再使用数据或其定义已更改，则数据质量检查可能会变得无用。

数据质量规则的类别

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

• 数据质量检查。 “正常”情况，检查一个数据仓库层中的数据（参见图 1），无论是在一个表中还是在一组表中。
• 和解。 检查数据是否在数据仓库层之间正确传输的规则（参见图 1）。 这些规则主要用于检查“完整性”的 DQ 维度。 对账可以使用单行或汇总方法。 检查单行更加精细，但您必须在比较层之间重现转换步骤（数据过滤、字段值更改、非规范化、连接等）。 您跳过的层数越多，必须实现的转换逻辑就越复杂。 因此，最好在每个层与其前任层之间进行协调，而不是将暂存层与数据集市层进行比较。 如果必须在协调规则中实现转换，请使用规范，而不是数据仓库代码！ 对于汇总调节，找到有意义的字段（例如，汇总、不同值的计数等）。
• 监测。 数据仓库通常包含历史数据，并加载了操作数据的增量提取。 数据仓库和运营数据之间存在差距逐渐扩大的危险。 构建汇总的数据时间序列有助于识别此类问题（例如，将上个月的数据与当月的数据进行比较）。 对数据有充分了解的数据用户可以为监控规则提供有用的度量和阈值。

如何量化数据质量问题

一旦您定义了要检查的内容，您就必须指定如何量化已识别的问题。 诸如“五个数据行违反了 ID 为 15 的 DQ 规则”之类的信息对数据质量没有多大意义。

缺少以下部分：

• 如何量化/计算检测到的错误。 您可以计算“行数”，但也可以使用货币规模（例如，曝光）。 请记住，货币价值可能有不同的符号，因此您必须研究如何有意义地总结它们。 您可以考虑对数据质量规则同时使用量化单位（行数和汇总）。
• 人口。 数据质量规则检查的单元数是多少？ “五分之五的数据行”与“五百万分之五”的质量不同。 应该使用与误差相同的量化来测量总体。 通常将数据质量规则的结果显示为百分比。 总体不得与表中的行数相同。 如果 DQ 规则仅检查数据的子集（例如，仅在合同表中终止合同），则应应用相同的过滤器来衡量总体。
• 结果的定义。 即使数据质量检查发现问题，也不一定总是会导致错误。 对于数据质量，使用阈值对结果进行评级的交通灯系统（红、黄、绿）非常有用。 例如绿色：0-2%，黄色：2-5%，红色：5%以上。 请记住，如果数据用户单元共享相同的规则，它们对于给定规则的阈值可能会大不相同。 营销业务部门可能不介意丢失几笔订单，而会计部门甚至可能介意几美分。 应该可以根据百分比或绝对数字定义阈值。
• 收集样本错误行。 如果数据质量规则提供检测到的错误的样本，这会有所帮助——通常，（业务！）键和检查的数据值足以帮助检查错误。 限制数据质量规则的写入错误行数是个好主意。
• 有时，您可能会在数据中发现无法修复但通过有用的数据质量检查发现的“已知错误”。 对于这些情况，建议使用白名单（数据质量检查应跳过的记录键）。

其他元数据

元数据对于路由“分析”和监控数据质量控制循环的各个阶段非常重要。

• 检查项目。 它有助于将检查的表和字段分配给数据质量规则。 如果您有一个增强的元数据系统，这可能有助于自动为该规则分配数据用户和数据所有者。 出于监管原因（例如 BCBS 239），还需要证明 DQ 如何检查数据。 但是，通过数据沿袭 (*) 将规则自动分配给数据用户/数据所有者可能是一把双刃剑（见下文）。
• 数据用户。 每个 DQ 规则必须至少分配一个数据用户/数据用户单元，以在“分析”阶段检查结果，并确定发现是否以及如何影响他们对数据的工作。
• 数据所有者。 每个 DQ 规则都必须分配一个数据所有者。

(*) 数据沿袭显示两点之间的数据流。 通过数据沿袭，您可以找到影响仓库内给定目标字段的所有数据元素。

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

测量数据质量

衡量数据质量意味着执行可用的数据质量规则，这些规则应该由数据仓库的加载过程触发自动完成。 正如我们之前所见，可能存在大量数据质量规则，因此检查将非常耗时。

在一个完美的世界中，只有当所有数据都没有错误时才会加载数据仓库。 在现实世界中，这种情况很少发生（实际上，几乎从未如此）。 根据数据仓库的整体加载策略，数据质量过程应该或不应该（后者更有可能）支配加载过程。 将数据质量流程（作业网络）并行并链接到“常规”数据仓库加载流程是一个很好的设计。

如果有定义的服务级别协议，请确保不要通过数据质量检查来阻止数据仓库负载。 数据质量过程中的错误/异常不应该停止常规加载过程。 数据质量过程中的意外错误应报告并显示在“分析”阶段（见下一章）。

请记住，数据质量规则可能会因为意外错误而崩溃（可能是规则本身被错误地实现，或者底层数据结构随着时间的推移而改变）。 如果您的数据质量系统提供了一种机制来停用此类规则，这将有所帮助，尤其是在您的公司每年发布的版本很少的情况下。

DQ 流程应尽早执行并报告——理想情况下，应在加载检查的数据后立即执行。 这有助于在数据仓库加载期间尽早发现错误（一些复杂的仓库系统加载持续数天）。

分析

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

您的数据质量项目应明确定义反应方式。 数据用户应该有义务对带有发现的规则（至少是带有红灯的规则）发表评论，解释正在采取哪些措施来处理发现。 需要通知数据拥有人，并应与数据使用者一起决定。

可以执行以下操作：

• 严重问题：必须解决问题并重复数据加载。
• 问题是可以接受的：尝试为将来的数据加载修复它并在数据仓库或报告中处理问题。
• 有缺陷的 DQ 规则：修复有问题的 DQ 规则。

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

为了能够及时做出反应，DQ 系统必须将发现的“他们的”规则告知数据用户。 使用数据质量仪表板（可能会发送出现问题的消息）是一个好主意。 用户越早了解调查结果越好。

数据质量仪表板应包含：

• 分配给给定角色的所有规则
• 规则的结果（交通灯、度量和示例行）能够按结果和数据域过滤规则
• 数据用户必须为调查结果输入的强制性评论
• 可选择“否决”结果的功能（例如，如果数据质量规则报告由于有缺陷的实现而导致的错误）。 如果多个业务单位分配了相同的数据质量规则，则“否决”仅对数据用户的业务单位有效（而非整个公司）。
• 显示未执行或异常的规则

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

数据所有者有责任确保每个发现都得到评论，并且所有数据用户的数据质量状态（原始或否决）至少为黄色。

为了快速概览，这将有助于为数据用户/数据所有者构建一种简单的 KPI（关键绩效指标）。 如果每个规则都被赋予相同的权重，那么为所有相关规则的结果创建一个整体交通灯是非常容易的。

就个人而言，我认为计算给定数据域的数据质量的总体值相当复杂，而且往往是阴谋论，但是您至少可以显示按数据域的结果分组的总体规则的数量（例如，“100 条 DQ 规则90% 的绿色、5% 的黄色和 5% 的红色结果”）。

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

改进流程

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

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

• 保持最新。 数据仓库中的变化需要被数据质量系统捕捉到。
• 提高。 针对数据质量规则尚未涵盖的错误实施新规则。
• 精简。 禁用不再需要的数据质量规则。 合并重叠的规则。

监控数据质量流程

监控整个数据质量过程有助于随着时间的推移对其进行改进。

值得关注的是：

• 数据质量规则对数据的覆盖范围
• 随着时间的推移，活动规则中数据质量发现的百分比
• 活动数据质量规则的数量（密切关注——我已经看到数据用户通过简单地禁用越来越多的数据质量规则来解决他们的发现。）
• 数据加载中对所有发现进行评级和修复所需的时间

结论

以下许多要点在任何类型的项目中都很重要。

预计阻力。 正如我们所看到的，如果没有紧急的质量问题，数据质量通常被视为额外的负担，而不提供新的功能。 请记住，它可能会给数据用户带来额外的工作量。 在许多情况下，合规性和监管要求可以帮助您说服用户将其视为不可避免的要求。

寻找赞助商。 如上所述，DQ 不是一个快速销售的项目，因此需要一个强大的赞助商/利益相关者——管理层越高越好。

寻找盟友。 与赞助商一样，任何分享强大数据质量理念的人都会很有帮助。 DQ 电路循环是一个持续的过程，需要人们保持电路循环的活力。

从小处着手。 如果到目前为止还没有 DQ 策略，请寻找需要更好数据质量的业务部门。 建立一个原型，向他们展示更好的数据的好处。 如果您的任务是改进甚至替换给定的数据质量策略，请查看组织中运行良好/被接受的事物，并保留它们。

不要忽视整个画面。 尽管从小处着手，但请记住，某些要点，尤其是角色，是成功 DQ 战略的先决条件。

一旦实施，就不要松手。 数据质量过程需要成为数据仓库使用的一部分。 随着时间的推移，对数据质量的关注往往会变得有点迷失，这取决于您来维护它。