高级平台工程师的最佳数据质量框架

这就是为什么任何认为数据对其业务运作非常重要的组织--无论是内部消费者还是外部消费者--都需要实行数据质量管理和实施数据质量框架的原因。听起来就像这样：开发可重复的、理想情况下是自动的流程和模式，以确保进入系统并向下游传输的数据符合您和消费者的期望。

各位资深数据工程师都知道，了解这些期望是成功的一半。另一半时间主要用于将这些预期转化为跟踪和警报，以帮助您在复杂的摄取流程中发现并解决问题。

在本指南中，我们将分享一些策略，以确保数据质量管理不是简单地叠加在现有硬编码流程之上，而是内置于每个 DAG 中。要做好管理，就需要在低质量数据进入转换层之前及早发现异常。

让我们从定义开始。数据质量框架是一种工具，组织可利用它来定义相关的数据质量属性，并为数据质量管理流程提供指导，以持续确保数据质量满足消费者的期望（服务水平协议）。

这句话很复杂，让我们来解读一下：

1. 您需要一个流程：除非你有无限的工程师时间，否则流程应包括在数据管道的每个阶段进行可重复的、理想情况下是自动的单元测试（如果你想主动发现问题，尤其是在摄取阶段），以及处理数据问题的工作流程。
2. 您必须持续确保：数据质量的下降与数据速度成正比，也就是所谓的数据漂移。我们许多人现在处理的这种高速数据需要经常检查。
3. 您必须满足消费者的期望，而不是自己的期望：数据质量从根本上说是一个业务流程。您的数据 SLA 或 "服务协议 "是与消费者签订的，如果数据科学家无法运行他们的模型，如果客户收到不准确的运输交付预估，或者如果您的地区副总裁因为仪表板无法加载而不得不空手参加董事会，那么工程方面的一切都无关紧要。

要实现上述承诺，有很多事情要做，而其中的每一个要素都充满了依赖性。例如，如果你要问自己如何构建这样一个系统，你会提出以下问题：

1. 如何了解消费者对数据质量的期望？
2. 如何将这些期望转化为可量化的数据质量衡量标准？
3. 您将如何对每条管道的质量实施自动测量？
4. 如何确定数据质量各维度的阈值？
5. 当数据违反这些阈值时，如何提醒您的团队？
6. 收到警报时，您的团队会怎么做？
7. 他们将如何判断警报的有效性和紧迫性？
8. 如果存在问题，他们将如何确定近因？
9. 他们将如何找出根本原因？
10. 他们将如何让消费者了解他们的期望？
11. 他们将如何从根本上解决问题？
12. 他们将如何验证已经解决了根本原因？
13. 他们如何记录所发生的事情以积累知识？

看似长长的、编号可能不吉利的清单？不要害怕。你可以委托他人。

问题 1 最适合你所在小组的业务分析员。这就需要他们与业务部门沟通，将用户故事、既定偏好、隐含偏好、请求和事件后记分解成一份数据"需求”清单。这些都是消费者对数据的定性期望，这是一种双向对话，因为他们可能无法用语言准确描述他们想要什么。（除非你的数据消费者是你的数据科学家，这样才能真正加快速度。）

问题 2 需要您和您的数据科学家共同回答（尤其是当他们也是消费者时）。鉴于每个管道的数据特征，您可以实际测量哪些属性，从而将定性期望清单进一步分解为定量测量清单？

根据您所遵循的数据质量模型，有四个或五个质量维度需要关注。在 IBM Databand，我们更喜欢具有四个特征的模式：

• 健身
  • 准确性 - 数据反映现实
  • 完整性 - 质量/时间
• 沿袭
  • 来源 - 提供商是否实现了您的期望？
  • 起源 – 它从哪里来？
• 管制
  • 数据控制
  • 数据隐私
  • 条例
  • 安全性
• 稳定性
  • 一致性
  • 可靠性
  • 及时性
  • 偏见

有了这些指标，数据工程师就可以解决第 3-13 个问题，并开始构建数据质量管理策略。在讨论如何做到这一点之前，我们应该问一问，为什么要做这些努力？

几年前，一家大型零售商的 Microsoft Dynamics CRM 系统进行了一次无关紧要的配置更改，这意味着网上显示的每件物品的库存数量不再反映实际情况。计数器干脆停止了更新。

人们继续购买，但数量保持不变。当数据工程团队接到警报时，事情已经变得很糟糕了。

大多数商品都可以在网上购买，也可以到店取货。很多人选择店内取货。订单得到了处理，但并不存在的物品却被售出。于是，消费者来到商店，零售商们争先恐后地寻找替代品，或承诺折扣，或以某种方式安抚他们。开始排队。商店里的游客不得不等待购买，而且很多人都在愤愤不平地玩手机，这让他们很反感。由于从发现问题到修复管道需要几天时间，所以又过了几天，事情才得到解决。

考虑到品牌声誉的损失，这次失误造成了数千万的损失，而这种损失本不应该发生。

这一切都说明，数据问题是复杂的。它们可能很难被发现和解决，并在不经意间滋生。我们很容易陷入这样一种模式，即假定一切正常，只是因为你还能得出一些洞察分析，即使你正在积累越来越多的地下数据债务。

此外，数据质量问题的最真实迹象也往往是滞后指标。例如，消费者告诉您或者像上一个零售客户关系管理的例子一样，成千上万的零售经理和地区副总裁告诉你。真糟糕。这意味着数据已经在系统中存在了一段时间，修复需要几天时间才能见效。谈不上满足消费者的期望。

这就是航运初创公司 Shipper 所遇到的情况，也是他们投入巨资防止这种情况发生的原因。他们的数据工程团队为一个应用程序提供尽可能接近实时的数据，帮助电子商务供应商将库存运送到装运港。他们不仅要担心消费者的期望，还要担心消费者的消费者。而当他们的系统有时过期两天时，就会造成期望落空的连锁反应。因此，他们在数据质量管理和工具方面投入了大量资金，这些工具可以通过自动检查向他们发出预警警报。

数据质量管理是一种使数据质量检查自动化和普遍化的方法，这样你就能以等量和反量的力量对抗数据集和管道上的熵。

让我们回到之前的例子和问题清单。您的分析师会与业务部门沟通以收集需求，您的数据科学家会向您提供一份量化的消费者期望清单。然后如何继续前进并建立系统？

制定数据质量框架。你的框架首先应该承认，系统是一个循环，你所了解到的一切有关消费者期望的信息都会影响系统，而消费者的期望是不断变化的。

让我们逐一探讨这些阶段：

1. 定性： 业务分析师将消费者的需求分解为一系列要求
2. 量化： 数据科学家将需求分解为可量化的数据质量衡量标准，而这些衡量标准目前还只是理论上的。
3. 计划： 数据工程师将数据质量的量化指标转化为他们可以在数据管道可观察性平台中运行的检查。这样的平台至关重要—Airflow 和 Spark 等流程和管道调度系统可以检测出管道本身的问题，但无法检测出数据内部的问题，而这正是出现问题最多的地方。工程师需要了解系统中哪些可以跟踪，哪些不可以跟踪。
4. 实施： 数据工程师实施跟踪并进行测试。举个非常简单的例子，如果数据需要全部存在，并且不缺少任何字段或列，则可以围绕数据完整性参数设置警报。像 Databand 这样的可观察性平台可以实现这一点，并允许您设置异常检测，这样您就无需手动设置每个值。
5. 管理： 数据工程师会根据历史管道数据对这些警报进行回溯测试，以验证它们是否真的会按预期运行。如果属实，他们就会将其与事故管理计划一起投入生产，规定警报触发时由谁负责，以及收到警报时他们会怎么做。
6. 验证：数据工程师和数据科学家确认，数据管理框架已在预期指标方面显著提高了性能。商业分析师向消费者证实，情况确实如此。

你如何处理你的框架？你把它付诸实践。

正如我们在许多示例中探讨的那样，数据质量问题最糟糕的指标就是滞后指标--比如，消费者告诉你有东西坏了。在数据工程领域，我们所做的很多事情都是在建立管道的同时建立信任。

通过投资数据质量管理框架，帮助团队自动识别问题，您将创建值得信赖的数据。这样你的工作就轻松多了。

深入了解 IBM Databand 如何通过检测意外列变化和空记录来提供更好的数据质量监控，从而帮助您满足数据 SLA。如果您准备深入了解，请立即预约演示。