实现Data Mesh——通过数据契约驱动数据产品

在本章中，我们将首先从实施的角度来看待数据网格，回答以下问题：它的主要组件是什么？然后，我们将与产品思维进行对比，探讨什么是数据产品，最后深入讨论数据契约。本章中的示例遵循我们用例的主题，即Climate Quantum Inc.

通过信任带来价值

根植于敏捷方法论，数据网格专注于为企业带来价值。我们知道，从工程和技术的角度来看，谈论价值似乎有些奇怪。毕竟，在数据工程中，"价值"是什么呢？

别担心------我们并不是要将一本以工程为导向的书变成一本商业书籍。但我们坚信，集体上我们需要将目标与数据网格保持一致，而其中一个目标就是信任。

在与同行工程师和科学家的多次交谈中，我们常常告诉他们，我们不够聪明，无法知道如何处理每一条数据，但我们知道如何提供他们需要（有时想要）的数据。我们的团队提供数据或访问和处理数据的工具。我们不假装了解客户的工作，尽管我们花时间了解他们，而每个人都应该这样做。信任是基础。哈佛商业评论（HBR）曾发表过一篇文章，探讨了如何将信任具体化。让我们看看这如何适用于数据世界。

首先，我们试图与客户建立诚实和积极的关系。你知道，这可能会很有挑战性，你也可能在自己的职业生涯中经历过。

可信的产品

当你想到一个好的产品时，最重要的考虑之一就是你对它的信任。也许你喜欢用你那台相当不错的尼康无反相机拍照。当你在远足时带着相机，你希望它在开机后能够立即使用，而不是有一个漫长的启动时间。当你按下快门时，你期望照片能够瞬间保存在你的CFexpress卡上，并在10秒内显示在你的iPhone上。

在这里，你通过照片是否保存在卡上以及分辨率、压缩、色彩平衡和其他属性是否符合你的预期来判断质量。从相机到手机传输照片所需的时间是服务级目标。当你的产品按预期工作并提供你所期望的质量时，你对它的信任自然会增强。

信任的第二个要素是展示我们在客户领域的专业知识。当然，我们可以假装是专家；然而，数据契约是捕捉他们需求的更具体的方法。数据契约将提供建立信任所需的专业知识水平（更多内容请参见"数据契约的导航"）。

一致性是HBR描述的信任的第三个要素。数据契约将通过数据质量结果和服务级指标（SLI）提供这种一致性。因此，我们的客户获得可以信任和基于此构建的数据。信任是你应该努力提供的价值。

我们是在将商业考虑引入一本技术书吗？从现在开始，你所做的一切将基于你将要建立的信任，而你将通过一系列契约来保证这种信任，如图5-1所示。

既然我们已经确立了信任作为主要价值的必要性，接下来我们来看看数据契约以及它们如何建立这种信任。

导航数据契约

如你在本章第一部分所学，数据契约的必要性是显而易见的：你需要一个工件来支持你希望在数据中建立的信任。让我们首先深入理论，了解你希望在契约中包含的信息，然后再看一些示例。

理论探讨

让我们从枯燥的部分开始：理论。契约建立了两个或多个方之间的正式关系。我们都签署过隐性或显性的契约：你为某人工作（或有客户），你很可能拥有一部手机，而且你大概也不住在桥下。正如你所想，数据契约是一个类似的协议，涉及到数据（显而易见）。数据契约是多个方之间的协议，具体来说，是数据生产者和数据消费者之间的协议。

让我们将数据契约与现实生活进行比较。数据生产者是大众汽车（Volkswagen，简称VW）。产品是一辆2013年款的VW Beetle 2.0L TDI，数据契约列出了汽车的规格。我们认为甲壳虫的造型吸引人，我们在某些时候相信柴油动力，并认为3117磅/1.4吨的2.0L发动机应该能提供一辆反应灵敏的汽车。这些特征都是契约的一部分。

在数据契约中，这些特征可以是模式。例如，数据集包含一个客户表，具有25列，其中一列是名字，其类型为VARCHAR，长度为32。

契约包括服务级协议（SLA）以及功能性和非功能性要求（NFR）。对于我们的VW Beetle，这些要求可能包括32 MPG/7.4 L/100 km的油耗或车库何时能提供取车服务。对于数据，这可能包括检测问题的时间，或者对于每日批处理，数据可用的时间。

在某些情况下，问题可能会成为完全的交易破坏者：重复记录过多、必填字段中的NULL值过多，或释放到大气中的氮氧化物（NOx）排放量过高（比如几年前的VW丑闻）。这些约束可能来自生产者/卖方或监管机构------这为联邦计算治理打开了大门，但我们在本章不讨论这个。

堆砌有用信息

那么，你在数据契约中应包含什么呢？我们认为，几乎任何能够阐明数据的生产和使用预期的信息都可以包含在数据契约中。在开源数据契约标准中，社区将这些信息分为以下八个类别：

1. 基础和人口统计

   • 本节包含关于契约的一般信息，如名称、领域、版本等。

2. 数据集和模式

   • 本节描述数据集和数据契约的模式。这是数据质量的支持，详细内容将在下一节中说明。数据契约专注于单个数据集，包含多个表（显然还有列）。

3. 数据质量

   • 本类别描述数据质量规则和参数。这些与数据集和模式部分定义的模式紧密相连。

4. 定价

   • 本节涵盖对客户使用此数据产品时的定价。目前的定价是实验性的。

5. 利益相关者

   • 这一重要部分列出了利益相关者及其与该数据契约的关系历史。

6. 角色

   • 本节列出了消费者根据所需的访问类型可能需要的角色。

7. 服务级协议

   • 本节描述SLA。

8. 自定义属性

   • 本节使用键值对列表覆盖数据契约中的自定义和其他属性。这一部分提供灵活性，而无需每当有人需要额外属性时就创建一个新的模板版本。

数据契约本身使用YAML文件。选择YAML是显而易见的，因为它对机器和人都很容易读取。YAML文件可以很好地存放在GitHub存储库中，源代码控制提供了出色的可追溯性。

BITOL，一个Linux基金会项目

数据契约有许多种类；在本书中，我们将积极跟随开放数据契约标准（ODCS），这是LF AI & Data支持的Bitol项目的一部分，属于Linux基金会。

ODCS是一个开放标准，因此优于封闭标准，因为它能够促进跨多种平台的互操作性和兼容性，通过广泛的协作促进创新。开放标准具有成本效益，减少对专有解决方案的依赖，从而降低总体开支。此外，开放标准通过允许集体审查增强安全性和透明度，确保更高的安全标准和更快的问题解决速度。它们提供更大的持久性和可持续性，因为它们是由社区驱动的，不依赖于单一实体，从而避免了与封闭标准相关的过时或供应商锁定的风险。总体而言，开放标准创造了一个更具活力、竞争力和包容性的技术生态系统。

让我们看看数据契约如何与数据产品和数据网格相关联。这将帮助你理解如何最佳利用它们。

一切都与适当的版本控制有关

数据可以作为产品出售（或消费）。就像我们的VW Beetle，它可以有功能性要求（四个轮子、一个方向盘等）、非功能性要求（行驶时释放的NOx数量）和服务级协议（交付日期、故障时的替换车等）。

然而，当我们看到所选甲壳虫的NOx问题时，我们可能会决定切换到一种非柴油版本，比如2014年的2.5L五缸发动机。这仍然是同一产品，但版本不同（2014年与2013年）；它是原始产品的一个变体（汽油与柴油）。

数据产品也是如此。我们可以添加或删除一些信息，通过版本来处理这些变化。我们还可以共享产品的不同变体，如原始、策划、汇总等。

总而言之，一个数据产品可以有多个数据契约：每个数据集和版本至少一个数据契约，我们将在下一节中研究。这给了我们所需的灵活性。

保持简单和语义化

更改遵循语义版本控制，以确保数据工程师在版本数据契约时的一致性。语义版本控制依赖于补丁、次要和主要更改。我们将在"以稍好方式进行文档化"中查看几个示例。

数据网格将DPO视为任何数据产品的利益相关者。当他们转到新角色时，我们将新的DPO添加到契约中，保持人类的传承。这将导致补丁版本：我的数据契约可以从1.0.1变更为1.0.2。补丁是提供向后兼容的错误修复。它也可以是像数据契约中添加新利益相关者这样的信息更改。

我们可能会在客户数据产品的策划客户数据集中为潜在客户表添加一个年龄列。该数据集的版本因这一变化而升至次要版本，从1.0.2变更为1.1.0。次要更改保持向后兼容；它允许现有的下游应用、解决方案和查询正常工作。

随着时间的推移，我们意识到潜在客户和客户表应合并。这是一个重大变化，会破坏大部分消费者代码。这种演变是将更新的契约提升到版本2.0.0的理由。重大更改是指不提供向后兼容的更改。这种更改会导致现有的下游应用、解决方案或查询中断。

并非所有的更改在强度上都是相同的。表5-1列出了表、API和数据契约的更改示例，并描述了更改的严重性：是补丁、次要更改还是重大更改。这些列表并不详尽。

表5-1. 数据产品中更改的严重性

工件	补丁	次要	重大
表	添加新列	对现有列进行逻辑更改	更改列的数据类型 更改列的名称 删除列
API	一个不属于次要或重大更改的错误修复	在有效负载中添加新字段 在HTTP请求中添加可选参数	将必需参数更改为可选参数 更改请求或响应数据的格式 更改资源的数据类型（例如，将字符串更改为整数） 删除一个或多个资源、删除或更改特定资源的属性或方法，或对API功能的任何其他更改 为客户端HTTP请求添加一个新的必需字段
数据契约	更新元数据 更改描述字段 更改利益相关者	修订数据质量规则 添加一个新的键，前提是它是可选的或具有默认值	更改键的数据类型 更改键的名称 删除一个键

跟踪更改及其在版本控制中的后果可能听起来并不简单，但这将使数据生产者和消费者能够以自己的节奏演变，增加他们之间的信任，并增强我们系统的稳健性。

为了更方便地管理这些契约，数据网格需要工具。例如，PayPal团队开发了一种比较服务，用于分析两个契约并建议版本号。

可能还需要一种哲学上的转变，因为严格的契约并不意味着它的消费应该是毫不妥协的。TCP协议的创始人之一Jon Postel曾说："在你做的事情上要保守，在接受别人的事情上要宽容。"这已经成为计算机科学中的稳健性原则，通常被称为Postel法则。

走过一个例子：补充部落知识

在GitHub存储库中，你会找到几个数据契约的示例，团队也将继续添加更多。现在，让我们看看一个复杂的商业问题，我们可以通过数据契约来解决：部落知识。部落知识是指一群人知道某些事情，而对于不属于该群体的人来说，这些信息相对较难获取。这是一种口头传统。部落知识本身并没有错，但它难以扩展，抵制组织变革，并且在监管环境中会产生问题。你不应该去除它，而是学习如何与之共存并加以补充。以下是增强它的两种方法：

1. 记录，记录，再记录。
2. 创建人类传承。

以稍好方式进行文档化

工程师通常不介意记录。他们常常记录不足或记录过多，但某种形式的文档通常是存在的。问题在于记录变化。数据契约提供了解决方案，以正确的水平记录并同步变化。例如，你可以利用描述和其他信息字段，如示例5-1所示。注意：此数据契约格式目前专注于表和结构化数据；扩展工作正在进行中。

示例5-1. ODCS v3中的基本表描述

schema:
  - object: tbl
    logicalType: object
    physicalType: table
    description: 提供核心支付指标
    dataGranularityDescription: 在列txn_ref_dt和pmt_txn_id上进行聚合
    properties:
      - name: txn_ref_dt
        businessName: 交易参考日期
        logicalType: date
        physicalType: date
        description: 交易的参考日期。请在报告和聚合中使用此日期，而不是txn_mystical_dt，因为它稍显神秘。
        examples:
          - 2022-10-03
          - 2025-01-28

这只是一个简单的示例，尽管有时找到正确的字段并不像看起来那么简单！

有时，字段是计算的结果或与之相关的业务规则。数据契约允许你通过权威定义来具体化这些约束。示例5-2显示了字段rcvr_cntry_code既有业务定义又有参考实现。

示例5-2. 使用权威定义

schema:
  - table: tbl
    properties:
      - name: rcvr_cntry_code
        description: 收件国代码
        logicalType: string
        physicalType: varchar(2)
        authoritativeDefinitions:
          - url: https://collibra.com/asset/748f-71a5-4ab1-bda4-8c25
            type: businessDefinition
          - url: https://github.com/myorg/myrepo
            type: referenceImplementation

现在，我们需要定义我们想要执行的政策：文档的完成百分比、与权威定义链接的字段的百分比等等。再也不需要记录不足或记录过多，也不再存在数据模型和文档不同步的问题。数据契约提供了一个丰富的单一真实来源。

创建人类传承

数据传承适用于跟踪数据的旅程。现在，让我们了解什么是人类传承（而不是数据传承），它如何共享知识和跟踪历史。随着故事的发展，我们将其翻译成数据契约中使用的代码。假设一个场景，科林（Colin）几年前以DPO的身份加入Climate Quantum Inc.（示例5-3）。

示例5-3. 简单的团队成员

team:
  - username: colin
    role: dpo
    dateIn: 2014-08-02

由于科林的直率、直接和火爆的性格，他很快去探索其他领域，并被卡琳（Karin）取代（示例5-4）。

示例5-4. 团队演变

team:
  - username: colin
    role: dpo
    dateIn: 2014-08-02
    dateOut: 2014-10-01
    replacedByUsername: karin
  - username: karin
    role: dpo
    dateIn: 2014-10-01

卡琳的风格更合适，她得到了晋升。她雇佣了马克斯（Max）来接替她的DPO职位（示例5-5）。

示例5-5. 添加马克斯并替换卡琳

team:
  - username: colin
    role: dpo
    dateIn: 2014-08-02
    dateOut: 2014-10-01
    replacedByUsername: karin
  - username: karin
    role: dpo
    dateIn: 2014-10-01
    dateOut: 2019-03-14
    replacedByUsername: max
  - username: max
    role: dpo
    dateIn: 2019-03-14

发生了一些伟大的事情，马克斯进入了他的休假。尽管他在回来的时候仍然会是DPO，但他在缺席期间让奥尔（Ole）代为监视（示例5-6）。

示例5-6. 最终，奥尔加入团队

team:
  - username: colin
    role: dpo
    dateIn: 2014-08-02
    dateOut: 2014-10-01
    replacedByUsername: karin
  - username: karin
    role: dpo
    dateIn: 2014-10-01
    dateOut: 2019-03-14
    replacedByUsername: max
  - username: max
    role: dpo
    dateIn: 2019-03-14
    comment: 因休假而轻微中断，预计2021年4月底回归
    dateOut: 2021-04-01
    replacedByUsername: ole
  - username: ole
    role: dpo
    dateIn: 2021-04-01

这时，奥尔遇到了麻烦，需要紧急请假。由于我们曾多次遭遇墨菲定律，这正是我们需要DPO提供关键信息的时候。尽管马克斯和奥尔都不在，但得益于契约中描述的人类传承，我们可以快乐地联系到卡琳，她总是乐于助人。

这个例子说明了一个虚构的情况，但我们非常确定你在职业生涯中经历过类似的事情。

什么是数据质量服务（QoS），以及为什么它至关重要？

规范我们描述数据质量和服务水平的方式是数据契约成功的关键。在这一部分中，我们将介绍数据QoS的概念，数据QoS是数据质量与服务水平协议（SLA）结合的结果。我们将首先解释这个概念，然后详细描述构成数据QoS的要素，首先关注数据质量，然后关注服务水平指标（SLI）。最后，我们将解释我们如何对它们进行分组。

注意： 服务质量（QoS）是网络工程中一个成熟的概念。QoS是对服务整体性能的测量，例如电话、计算机网络或云计算服务，特别是网络用户所感受到的性能。在网络中，几个标准被考虑用于定量测量QoS，例如数据包丢失、比特率、吞吐量、传输延迟、可用性等。本章将QoS应用于数据工程。

随着业务的成熟，你观察数据的需求不断增长，你会意识到想要测量的属性数量将带来更多的复杂性而不是简单性。这就是为什么在2021年，Jean-Georges提出将数据质量和服务水平结合到一个表格中的想法，灵感来自于Mendeleev（以及其他许多人）在物理学中对原子元素进行分类的工作。你可以在图5-2中看到结果。数据QoS表代表了用于测量数据质量和服务水平的最基本要素。

表示

为了表示这些要素，准确地在两个轴上识别每个要素是很重要的：

• 时间（或周期）
• 组别

每个要素都附加了额外的属性，如图5-3所示。

时期

时期标识时间敏感的要素，或者是要素在其组中的顺序。其中一些是非常明显的，例如，"生命周期结束"显然是在"通用可用性"之后，如图5-4所示。

某些元素的分类时期更为微妙：当数据进入新的数据存储时，你会先检查准确性，然后检查一致性，而只有在拥有大量数据时才能检查唯一性。这些元素没有时间上的联系，但它们是按顺序发生的，如图5-5所示。

组别

第二个要确定的分类是元素的分组。元素之间是否存在逻辑关系，使其有意义？

这就是Jean-Georges提出的分类：

• 静态数据（R）
• 动态数据（M）
• 性能（P）
• 产品生命周期（L）
• 数据行为（B），包括保留、刷新频率、可用时间和延迟
• 与时间相关的（T）指标

这为什么重要？

对构成数据QoS的元素进行分类和定义有很多好处：

我们可以达成一致的定义

开发信息技术基础设施库（ITIL）的第一步是建立项目利益相关者之间的共同词汇。尽管ITIL可能并不适用于所有情况，但这第一步至关重要。数据QoS提供了一个演进的框架，拥有一致的术语和定义。

与数据合同的兼容性

当我们关注数据合同时，请记住它们需要建立在标准化的期望之上。这在数据保留期限上显而易见，因为你可能不会看到持续时间、安全保管或其他内容。然而，延迟和新鲜度常常被混淆；我们这里以延迟为例。

建立基础

数据QoS并不是一成不变的。它支持演变和创新，同时提供坚实的基础。

为什么数据质量还不够

在数据领域，行业对信任的标准往往仅限于数据质量。Jean-Georges对此感受颇深。在2017年，Spark Summit上，他提出了CACTAR（Consistency、Accuracy、Completeness、Timeliness、Accessibility和Reliability）作为六个数据质量维度的缩写，并在一篇Medium文章中进行传达。尽管没有官方标准，EDM Council有几个不同的标准，并增加了第七个维度。因此，他决定与EDM Council的列表保持一致。数据质量的七个维度如图5-6所示。

准确性 (Ac)

准确性指数据的精确程度，可以通过将数据与原始文档和可信来源进行比较，或者根据业务规则进行确认来评估数据的真实性。数据的真实性与其权威来源进行比较，以确定数据是否提供但不正确。一些例子包括：

• 一个客户24岁，但系统将其识别为42岁。
• 供应商地址有效，但并不是他们的地址。
• 小数数量四舍五入。

有趣的事实：许多准确性问题源于数据输入。如果你的团队中有数据录入人员，奖励他们的准确性，而不仅仅是速度！

完整性 (Cp)

数据必须用一个值填充（即，不为空，不可空）。完整性检查数据集中是否存在所有必要的数据属性。一些例子包括：

• 当业务规则或法律要求时，缺少发票号码。
• 一条记录缺少某些属性。
• 信用卡号码中缺少到期月份。

有趣的事实：主键始终是一个必填字段。

一致性 (Cs)

数据在数据存储之间应保持一致的内容。一致性确保一个组中的数据值、格式和定义与另一个组中的相匹配。一些例子包括：

• 数字格式在转储中转换为字符。
• 在同一数据源中，一些记录的数据格式无效。
• 不同数据存储中的收入计算方式不同。
• 当字符串从网站转到仓库系统时，从最大长度255缩短到32。

有趣的事实：Jean-Georges于1971年10月5日出生于法国，但他的星座是天秤座（十月）。在字符串中表达时，日期格式通过本地化过滤器转换。因此，出生于10月5日使得在欧洲的日期表示为05/10/1971，而在美国则为10/05/1971。

覆盖率 (Cv)

所有记录都包含在数据存储或数据源中。覆盖率与数据集中的数据存在但缺失的范围和可用性有关。一些例子包括：

• 每个客户必须存储在客户数据库中。
• 复制的数据库缺少源中的行或列。

时效性 (Tm)

数据必须代表当前条件；数据在需要时可用且可使用。时效性衡量数据反映当前市场或业务条件的程度，以及在需要时的可用性。一些例子包括：

• 文件交付太晚，或者源表未完全更新以用于业务流程或操作。
• 信用评级变更未在发布当天更新。
• 地址未更新以供实际邮寄使用。

有趣的事实：每年有4500万美国人更改地址。

唯一性 (Uq)

数据可以重复多少次？这支持没有记录或属性被多次记录的理念。唯一性意味着每条记录和属性都应该是独一无二的，目标是达到单一、唯一的数据条目。（是的，人们可以梦想，对吧？）一些例子包括：

• 同一个客户、产品或合作伙伴的两个实例具有不同的标识符或拼写。
• 在同一数据库中，股份被表示为股权和债务。

有趣的事实：数据复制本身并不坏；非自愿的数据复制才是问题所在！

我们可以达成共识，这七个维度非常全面。作为一个行业，现在可能是时候说：足够好了。当然，这完全毁掉了Jean-Georges的CACTAR缩写（及其伟大的背景故事）。

但这仍然不够。数据质量没有回答关于生命周期结束、保留期限以及损坏时修复所需时间的问题。接下来，让我们看一下服务水平。

服务水平补充质量

数据质量描述了数据的状态，而服务水平则为可用性、数据状态等方面的期望提供了宝贵的信息。

图5-7是可以应用于你的数据及其交付的服务级别指标（SLI）列表。你需要为你的生产系统设定一些目标（服务级别目标，或称为SLO），并与用户及其期望达成一致（设定服务级别协议，或称为SLA）。

可用性（Availability, Av）

可用性简单来说就是回答这个问题：我的数据库是否可访问？数据源可能由于各种原因变得不可访问，例如服务器问题或网络中断。基本要求是，当你使用 JDBC 的 connect() 方法时，数据库能够做出肯定的响应。

吞吐量（Throughput, Th）

吞吐量是指数据被评估的速度。它可以通过单位时间内的字节或记录来测量。

错误率（Error Rate, Er）

你的数据在多长时间内会出现多少次错误？你对这些错误的容忍度是多少？

一般可用性（General Availability, Ga）

在软件和产品管理中，一般可用性意味着产品已准备好供公众使用，功能齐全、稳定并得到支持。在这里，一般可用性适用于数据何时可供消费。如果你的消费者需要，它可以是与特定版本（如 alpha、beta、v1.0.0、v1.2.0 等）相关联的日期。你也可以想象 alpha 或 beta 阶段作为特定的 SLA，或使用版本号或状态来区分生产和开发版本。

支持结束（End of Support, Es）

支持结束是指你的产品将不再获得支持的日期。对于数据来说，这意味着在此日期之后数据可能仍然可用，但如果你作为消费者遇到问题，将不会提供修复。这也意味着你将期望一个替代版本。

有趣的事实：Windows 10 将支持到 2025 年 10 月 14 日。

生命周期结束（End of Life）

生命周期结束（End of Life, El）是指你的产品将不再可用的日期。没有支持，没有访问。什么都没有。 对于数据来说，这意味着连接将失败或文件将不可用。这也可能意味着与外部数据提供者的合同已结束。

有趣的事实：Google Plus 于 2019 年 4 月关闭。在此日期之后，你无法访问 Google 的社交网络的任何内容。

保留期（Retention, Re）

我们保存记录和文档的时间是多久？这里没有什么特别的------与大多数 SLA 一样，这可能根据用例和法律法规约束而有所不同。

更新频率（Frequency of Update, Fy）

你的数据多久更新一次？每天？每周？每月？与此频率相关的一个指标是可用时间，这适用于日常批量更新。

延迟（Latency, Ly）

延迟测量的是数据生成与可供消费之间的时间。

发现问题的时间（Time to Detect an Issue, Td）

你能多快检测到问题？有时，问题可能意味着故障，比如你在寒冷的早晨车子无法启动；有时则可能意味着缓慢，比如你的数据在几个月内错误地向证券交易委员会提供了数据。你能保证多快检测到问题？你可能会看到这个 SLA 被称为"故障检测时间"。

有趣的事实：松鼠（或其他类似生物）咬坏了我妻子车子的油管。我们通过油表快速下降的情况发现了问题，即使只开了几公里。你想冒险开车去修车吗？

通知时间（Time to Notify, Tn）

一旦你发现了问题，你需要多少时间来通知用户？当然，这是假设你知道你的用户是谁。

修复时间（Time to Repair, Tr）

一旦问题被检测到，你需要多长时间来修复？这是运行骨干级光纤网络的网络运营商常用的一个指标。

当然，随着时间的推移，还有许多其他的 SLA 会出现。协议遵循指标；协议可以包括罚款。你会发现服务的描述可能变得非常复杂。

在下一部分中，让我们将数据 QoS 应用到数据合同中，结合 Climate Quantum Inc. 的背景。

将数据 QoS 应用于数据合同

在本节中，我们将查看三个如何将数据 QoS（数据质量与服务水平的结合）应用于数据合同的示例。为了演示这些维度在数据合同中的使用，我们将使用纽约市空气质量数据集，该数据集可以由 Climate Quantum Inc. 使用。表 5-2 列出了该数据集的前 10 条记录，数据集的元数据如表 5-3 所示。

表 5-2. 纽约市空气质量数据集的前 10 条记录

Unique ID	Indicator ID	Name	Measure	Measure info	Geo type name	Geo join ID	Geo place name	Time period	Start_Date	Data value	Message
216498	386	Ozone (O3)	Mean	ppb	CD	313	Coney Island (CD13)	Summer 2013	6/1/13	34.64
216499	386	Ozone (O3)	Mean	ppb	CD	313	Coney Island (CD13)	Summer 2014	6/1/14	33.22
219969	386	Ozone (O3)	Mean	ppb	Borough	1	Bronx	Summer 2013	6/1/13	31.25
219970	386	Ozone (O3)	Mean	ppb	Borough	1	Bronx	Summer 2014	6/1/14	31.15
164876	383	Sulfur Dioxide (SO2)	Mean	ppb	CD	211	Morris Park and Bronxdale (CD11)	Winter 2008-09	12/1/08	5.89
164877	383	Sulfur Dioxide (SO2)	Mean	ppb	CD	212	Williamsbridge and Baychester (CD12)	Winter 2008-09	12/1/08	5.75
219971	386	Ozone (O3)	Mean	ppb	Borough	2	Brooklyn	Summer 2009	6/1/09	26.27
219972	386	Ozone (O3)	Mean	ppb	Borough	2	Brooklyn	Summer 2010	6/1/10	33.83
164878	383	Sulfur Dioxide (SO2)	Mean	ppb	CD	301	Greenpoint and Williamsburg (CD1)	Winter 2008-09	12/1/08	4.33
164879	383	Sulfur Dioxide (SO2)	Mean	ppb	CD	302	Fort Greene and Brooklyn Heights (CD2)	Winter 2008-09	12/1/08	4.41

表 5-3. 纽约市空气质量数据集的元数据

列名	描述	类型
UniqueID	唯一记录标识符	普通文本
IndicatorID	跨时间和空间测量值的标识符	数字
Name	指标名称	普通文本
Measure	指标的测量方式	普通文本
MeasureInfo	关于测量的信息（如单位）	普通文本
GeoTypeName	地理类型；UHF 代表联合医院基金社区。比如，全市、区和社区区是不同的地理类型。	普通文本
GeoJoinID	用于将地理区域连接到地图地理文件以制作主题图的邻域地理区域标识符	普通文本
GeoPlaceName	邻域名称	普通文本
TimePeriod	数据适用的时间描述；例如，这可以是某一年、一段年份或一个季节。	普通文本
StartDate	TimePeriod 开始的日期值，总是一个日期值；这对于绘制时间序列可能很有用。	日期和时间
DataValue	此指标、测量、地点和时间的实际数据值	数字
Message	适用于数据值的备注；例如，如果估计基于小数字，我们将在这里详细说明。	普通文本

检查测量的一致性

让我们确保测量相关信息符合我们的预期。作为提醒，这里有一些一致性示例：

• 客户标识符应该是八个字符长，但它不是。
• 客户地址类型必须在规定的地址类型列表中（家庭、办公室）。
• 地址填写了文本，但不是识别地址。
• 存在无效的 ISO 货币代码。
• 温度包含字母。

在数据合同中，示例 5-7 展示了如何添加一致性数据质量规则。在这种情况下，测量标识符要求最小值为 100,000；如果不是，则该错误被视为对运营的业务影响。

示例 5-7. 纽约市空气质量的数据合同

schema:
  - name: Air_Quality
    description: Air quality of the city of New York
    dataGranularityDescription: Raw records
    properties:
      - name: UniqueID
        primary: true
        description: Unique identifier
        logicalType: number
        physicalType: int
        quality:
          - rule: rangeCheck
            description: This column should not contain values under 100000
            dimension: conformity
            severity: error
            businessImpact: operational
            mustBeGreaterThanOrEqualTo: 100000

完整性

数据要求必须填充值：你不希望有 NULL 值。以下是一些示例：

• 缺少客户标识符、电话或更多信息。
• 不允许 NULL 值（必填字段）。
• 根据业务规则必须填充的字段。
• 缺少属性的记录。

示例 5-8 显示了如何在数据合同中表示完整性：UniqueID 是一个必填字段。如果此规则无效，则视为对运营的业务影响的错误。

示例 5-8. 添加更多数据质量规则

schema:
  - name: Air_Quality
    description: Air quality of the city of New York
    properties:
      - name: UniqueID
        primary: true
        description: Unique identifier
        logicalType: number
        physicalType: int
        quality:
          - rule: nullCheck
            engine: ClimateQuantumDataQualityPackage
            description: This column should not contain null values
            dimension: completeness
            severity: error
            businessImpact: operational
            mustBeLessThan: 1
            unit: percent

准确性

准确性确保提供的数据是正确的。以下是一些示例：

• 一位客户 12 岁，但系统将其识别为 32 岁。
• 一个供应商地址有效，但它不是实际供应商的地址。

在数据合同中，你可以指定空气质量的值应在 0 到 500 之间。如示例 5-9 所示，它是相同的应用（rangeCheck）用于有效性维度。相同的工具可以用于多个数据质量维度。

示例 5-9. 向空气质量数据添加准确性规则

schema:
  - name: Air_Quality
    description: Air quality of the city of New York
    dataGranularityDescription: Raw records
    properties:
      - name: DataValue
        description: Measured value
        logicalType: number
        physicalType: 'float(3,2)'
        quality:
          - rule: rangeCheck
            engine: bitol
            description: 'This column should contain positive values under 500'
            dimension: accuracy
            severity: error
            businessImpact: operational
            mustBeGreaterThanOrEqualTo: 0
            mustBeLessThan: 500

启动服务水平

服务水平通常适用于整个数据产品。你不会有一个保留六个月的表和另一个保留三年的表。

在数据合同中描述服务水平需要灵活性，因为可以随着时间的推移创建更多的 SLI。示例 5-10 显示了服务水平的定义，假设支持结束日期是 2030 年 1 月 1 日，保留期是 100 年，数据集于 2014 年 10 月 23 日发布，延迟显然未定义。

示例 5-10. 为附加信息添加服务水平

slaDefaultElement: StartDate
slaProperties:
  - property: endOfSupport
    value: 2030-01-01T04:00:00.000Z
  - property: retention
    value: 100
    unit: 'y'
  - property: generalAvailability
    value: 2014-10-23T04:00:00.000Z
  - property: latency
    value: -1
    unit: As needed

如你所见，SLI 是属性，留有扩展的空间。

你可以在 GitHub 上看到许多其他合同示例，包括摘录和完整的示例。

总结

在这一章中，你了解到信任在数据中是基础。它通过三种特性实现：积极的关系、展示专业知识和保持一致性。

数据合同是实现这种信任并构建可靠数据产品的关键。它们也可以在数据产品范围之外使用，例如用于文档数据管道。

数据合同应遵循诸如 Bitol 项目的 ODCS 标准。

与非数据网格方法相比，创建和维护数据合同是一项额外的工作，但它们简化了数据工程团队的许多负担，例如文档和数据质量的实现。数据合同可以帮助文档化，并补充部落知识。

数据 QoS 将 EDM 理事会认可的七个数据质量维度与广泛的服务水平清单相结合。它们可以通过时间线进行分组和组织，就像周期表一样。数据 QoS 是一个可扩展的框架，定义了在实施数据合同时可以使用的值。