提高数据质量：与 Lyft 探索数据合同

看起来这是我的数据质量系列的第二部分！

在上一篇文章中，我探讨了 Airbnb 通过激励措施提高数据质量的策略。他们实施单一评分和明确的评分标准，以在数据生产者和消费者之间建立共识，培养真正的主人翁意识。

现在，Lyft 采取了一种独特的方法，不是以不同的方式尝试同一件事，而是专注于数据质量的不同方面。而且，Lyft 的战略与 Airbnb 的努力相辅相成。虽然我认为 Airbnb 的 DQ 分数（或任何类似分数）是巩固提高数据质量的各种尝试的有效手段，但 Lyft 正在从不同的角度应对这一挑战。

Airbnb 的 DQ 评分是提供数据质量具体可视化的宝贵工具。从本质上讲，任何提高数据质量的举措都应该对这一分数产生明显的影响。另一方面，Lyft 提出了一项可能的举措，通过根据特定质量标准测试和验证数据来主动提高质量。

从根本上来说，这是数据质量生命周期中的不同点。引入一种提高质量的机制需要首先对其进行衡量的能力。

因此，尽管Airbnb的重点在于衡量和观察数据质量，依靠生产者的兴趣来提高这种质量并“看起来不错”，但 Lyft 却采取了不同的方法。 Lyft 强调主动测试和验证数据质量，为生产者和消费者提供有效提高和控制质量的手段。

总的来说，这些方法提供了一个全面的策略来解决和提高整个生命周期中的数据质量。

出于这个原因，我特别有兴趣仔细研究 Lyft 的方法。

另一个让我感兴趣的因素是测试，更具体地说，是契约测试，随着微服务架构的出现，它已经在基础软件工程中使用了很多年。然而，数据契约是数据工程领域较新的事物，被视为构建高质量数据管道的顶峰或最终步骤之一。这就是为什么我想更详细地研究 Lyft 的方法并探索一些潜在的相似之处。

如前所述，Airbnb 和 Lyft 采取的方法是互补的，旨在实现相同的目标：提高数据质量。

Airbnb开发了 DQ 评分，重点衡量和增强数据质量的 4 个不同方面：

DQ Score 的指导原则包括全覆盖、自动化、可操作性、多维性、可演化性。它具有准确性、可靠性、管理性和可用性等维度。

Lyft 的 Verity 是一个旨在提高5 个维度的数据质量的平台

将数据质量定义为衡量数据如何按预期使用的指标，涵盖语义正确性、一致性、完整性、唯一性、格式良好和及时性等方面。

很容易将 Lyft Verity 改进的 5 个数据质量方面与 Airbnb 的 DQ 分数衡量的 4 个数据质量维度进行比较。例如，及时性等方面肯定会影响 DQ 分数的可靠性，而准确性将取决于数据的语义正确性、完整性和唯一性。另一方面，可用性得分受到数据与其他因素的一致性的影响。

Lyft 的 Verity 专注于定义与语义正确性、一致性、完整性、唯一性、格式良好和及时性相关的检查。它遵循测试优先和验证的方法，而 Airbnb 的统一 DQ 评分强调通过各个维度评估数据质量。

如果我们想将 DQ 分数合并到最后一个模式中，它将位于警报/调试步骤的一侧。

Airbnb 的 DQ 评分使用不同的信号来评估准确性、可靠性、管理性和可用性方面的数据质量。

我们还有一组输入信号可以更直接地衡量质量（Midas 认证、数据验证、错误、SLA、自动 DQ 检查等），而其他信号则更像是质量的代理（例如，有效的所有权、良好的治理卫生、使用铺好的路径工具）。

如前所述，Airbnb 的 DQ 评分与 Verity 之间可能存在重叠。 Airbnb 专注于将数据质量向右推，强调测量和评分，而 Lyft 的 Verity 采取主动方法，将检查定义配置、测试和验证流程向左移动，强调主动改进数据质量。

现在，我的主要兴趣在于左侧，检查定义配置、测试和验证方面。

Lyft 如何将数据质量测试集成到其流程中？

我们首先检查一下执行路径。

目前，Lyft 的 Verity 主要致力于确保其 Hive 数据仓库中存储的数据的质量。不过，未来计划扩展其功能以支持其他数据源。

请注意，虽然他们将 Hive 称为数据工作室，但实际上他们将其用作混合数据存储解决方案，作为结构化、处理和清理数据（银层）的数据仓库运行，同时还充当原始事件的数据湖数据（青铜层）。

Hive 中的数据质量差导致实验指标受到污染、机器学习功能不准确以及执行仪表板存在缺陷。

Verity 的检查可以集成到 Airflow DAG 中，以确保仅处理高质量的原始数据并将其作为派生数据存储在 Hive 中。

数据生产者和消费者可以定义他们的数据质量检查，并在数据生成时或内部消费之前验证数据空气流动或者弗莱特。

……

VerityAirflowOperator 可以以阻塞方式使用，在检查失败时停止 DAG，从而防止不良数据到达生产环境。这利用了“ 阶段检查交换” 模式：我们在分阶段模式中创建数据，使用阻塞运算符验证数据，如果通过质量检查，则将其提升到生产环境。

还可以手动或自动安排检查来验证原始数据和派生数据。

Verity 计划检查与任何数据编排引擎隔离，因此即使 Airflow 或 Flyte 完全关闭，它们仍然可以运行。这解决了由于气流任务从未运行而导致检查不发出警报的常见问题。

因此，本质上有 3 种主要方法来触发检查：作为 Airflow DAG 的一部分、手动或通过 Verity 平台/UI 安排。

我不认为当前的检查可以集成到实时流管道（例如 Flink + Kafka）中以在数据进入 Hive（或更早）时对其进行验证。

实施这种类型的实时检查将能够及时检测差异，从而降低存储和处理成本并提高整体数据质量。

嗯，为了彻底，Verity 检查是通过 API 服务器进行管理的，该服务器可用于通过某些 API 以编程方式触发检查。

Verity API 服务器— 该服务处理与运行检查以及保存和检索其结果有关的所有外部 API。 API 服务器不执行任何检查，而是将消息写入我们的检查队列，该队列利用简单队列服务（SQS）。

因此，也许您可以以更实时的方式触发这些作业，例如从流作业中触发，甚至长期通过与 Hive 变更数据捕获 (CDC) 集成来触发这些作业。

然而，当在 Airflow 之外执行时，这些作业将无法阻止数据处理作业；相反，它们会生成推送到检查队列的异步警报。一些消费者希望在检查失败时延迟数据处理，而另一些消费者则宁愿继续处理并收到警报。

现在，让我们看看这些数据质量测试。

下面是一个检查rider_events.session_id是否不为 null 的示例。这是通过查询和条件组件的组合来完成的。

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity 主要专注于定义和执行数据质量检查，而不是定义完整的数据模式。

模式验证并不是一个新概念。在基于事件的系统中定义事件数据模式有多种方法，例如 JSON Schema、Protocol Buffers、Avro 或 Parquet 等存储格式。最佳选择取决于您的技术堆栈、用途和具体要求。

虽然数据模式对于定义数据对象或表行的整体结构很有价值，但它们无法捕获特定于消费者的更复杂的验证检查，例如数据分布、业务规则、SLA 和阈值。

数据契约不仅仅局限于模式验证，模式验证的重点是识别语法错误。我个人发现 JSON Schema 在这里提供了一个更合适和可读的选项，有效地将这些结构和语法验证功能与序列化或存储问题分开。

然而，为了解决语义错误并提高数据准确性，拥有定义数据检查的有效方法可以定义数据契约的另一个方面。

这就是 Verity DSL 发挥作用的地方。

除了语义验证之外，数据契约还提供了另一个值得关注的重要方面。

从语法的角度来看，无论涉及消费者还是生产者，验证检查都保持一致。验证规则集不依赖于任何特定的消费者或生产者，并且可以一次性定义为单个模式。

然而，Verity 数据契约 DSL 提供了更细的粒度，定义了小的独立规则，这特别适合这种情况：数据的语义和用法根据特定的消费者而变化。此外，并非所有消费者都需要利用对象的所有属性。他们的期望不同。这并不意味着它们是矛盾的（这肯定是一个问题），而是互补且不同的。

因此，允许所有消费者建立独特的规则，通过协作组合，可以提供对数据质量语义意义的全面理解是非常重要的。

正是这种协作方面特别引起了我的共鸣。请耐心等待，这可能看起来有点夸张，但从我的角度来看，这是值得一提的。 :)

数据交换使不同的团队（生产者和消费者）能够有效协作。就像传统软件开发中的 API 一样，建立对这些数据交换的共同理解至关重要。在微服务架构中，出现了一种称为消费者驱动契约 (CDC) 的协作测试方法，消费者定义生产者提供的 API 的预期行为。生产者有责任在发布新版本之前验证这些合同。

我认为数据合约具有类似的协作精神。尽管数据验证是在真实数据上执行的，而不是在发布时执行的，并且不会阻止发布，但它是基于合作并鼓励数据生产者和消费者之间的团队合作。我坚信这种协作方法是提高数据质量的关键，应该进一步融入到流程中。

嗯，我非常喜欢进行类比……

实际上请注意，Lyft 真实章程中也提到了这种协作方面。

VerityUI 通过 Verity 主页提供简化的数据发现体验。我们对检查定义元数据的全文搜索使用户可以查看当前正在执行的所有检查及其检查结果。这具有有用的聚合，例如所属团队、表名称和标签。

我并不完全清楚如何通过 Verity 平台 UI 在消费者和生产者之间共享数据合同问题，但我绝对认识到通过仪表板进行协作的重要性：

• 数据产品接口的生产者可以自信地确保他们不会无意中造成他们没有预料到的下游损坏。

• 界面的使用者可以放心，他们对界面的依赖不会也不会受到损害。

虽然 Verity 是定义数据质量检查的出色工具，但不幸的是它不是开源的。

幸运的是，还有另一个名为 Soda Core 的开源数据质量框架提供了类似的功能。

Soda Core 是一个免费的开源命令行工具和 Python 库，使数据工程师能够测试数据质量。它利用用户定义的输入生成 SQL 查询，对数据源中的数据集运行检查以查找无效、丢失或意外的数据。当检查失败时，它们会显示您在检查中定义为“不良”的数据。

在扫描数据集期间，Soda Core 会评估预定义的检查，以识别无效、丢失或意外的数据。

下面是使用 Soda.core 语法对先前定义的 Verity DSL 测试进行的等效检查。

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core 是确保数据质量的强大工具。它可以帮助您在数据问题给您的业务带来问题之前尽早发现并修复它们。

值得注意的是，Soda Core 还可以通过与 Spark DataFrames 无缝集成来促进流数据的数据质量检查。

虽然Verity对Hive的数据质量检查适用于静态数据集，但对流数据的检查需要更加轻量级和高效。

数据通常会以小批量事件的形式进行处理，延迟非常低，这使得它们适合实时检查和异常检测等特定用例。

最后，让我们提一下还有其他可用的数据验证工具，例如 DeeQu、Great Expectations……

在我们结束时，我希望您能够更清楚地了解可以采取哪些步骤来提高数据质量。

我们已经看到了两种不同的数据质量改进方法，每种方法都有自己的优势和方法。其中一个重点是提高可见性和可观察性，激励数据生产者提高质量标准。另一个优先考虑通过测试和验证优先的方法来提高质量标准。两者是互补的。

Verity 不仅仅是一种用于定义数据检查的领域特定语言 (DSL)；它是一个集中式平台，使数据从业者能够有效协作。该平台帮助生产者和消费者协调数据质量期望，包括格式、结构和准确性。

Verity 的数据合同管理功能可以（是？）通过与更广泛的功能（例如元数据管理和发现）集成来进一步增强，以满足更复杂的数据质量需求。

与 Airbnb 的 DQ 评分类似，Lyft 的 Verity 促进了数据生产者和消费者之间的协作反馈循环。通过激励和授权每个团队掌控数据质量，Verity 营造了一个数据质量不断提高的支持性环境。

觉得这篇文章有用吗？关注我领英,哈克农， 和中等的！请👏这篇文章分享吧！