什么是数据合约？入门指南与示例

语义数据合约

语义数据验证确保数据在逻辑上一致，并与业务逻辑保持一致。

语义验证必须被显式强制执行。

确实，不同于模式检查，语义数据合约依赖业务逻辑，必须在外部实现。

在很多用例中，语义看起来像模式校验合约的扩展。它通常取决于业务规则，并表现为我们的数据模型必须遵守的一组行级条件。

一个语义合约的示例如下：

• 指标偏离： 相对于移动平均或其他阈值的偏差。例如，昨日活跃用户数低于7日移动平均值的75%尚可接受，但跌至 0% 则不可接受。
• 业务逻辑： 交易监控告警标记与反欺诈评分。在此场景中，付款应为 0。
• 数据沿袭： 描述数据实体如何演化。例如，transaction_completed_at 不可能早于 created_at。
• 参照完整性： 实体关系很重要，也可用语义合约来描述。请看下面的 dbt 代码。它说明每个退款的 refund_id 都应映射回有效的 transaction.id。

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: id技术支持

由终端用户自行设定语义合约的告警级别，这通常通过自定义数据质量测试来实现。

各类业务逻辑规则常涉及数据完整性。非逻辑性数据情形可能源于数据库与服务器配置错误，或测试数据无意注入生产环境。数据完整性检查旨在依据这些业务规则验证数据，帮助识别不合理或不合逻辑的值。

数据库实体总是彼此相关。这称为实体关系，通常以实体关系图（ERD）展示。参照完整性不足会导致缺失或不完整的数据。数据合约必须应对这些潜在陷阱，以确保数据完整性与准确性。

例如，常见关系是 customers 与 orders 之间的一对多关系，即单个客户可能拥有多个 orders。在这种情形下，订单仅当其包含 customers 数据集中有效的 customer_id 时才被视为有效。

这种约束称为参照完整性约束，确保实体间关系被准确维护。

数据合约中的服务级别协议（SLA）

SLA 是可通过数据合约实现的额外数据质量检查层。

SLA 关注数据新鲜度。

由于数据模型会定期更新新数据，SLA 可能包含关于新数据预计可用的最晚时间或最大允许延迟的检查。例如，在 dbt 中，可通过新鲜度测试实现：

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1技术支持

假设我们要生成关于昨天事实的报告；为此，我们要确保数据已存在。确实，几天甚至更久都看不到新订单会很奇怪。

在下面的示例中，我们可以使用 dbt 的测试配置来检测数据集中意外的订单延迟。这样您就可以用特定的名称选择和引用该测试。

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"技术支持

通过定义自定义名称，您可以完全掌控测试在日志消息与元数据工件中的显示方式。

同样地，在实时数据管道中，通常期望数据不超过数小时之久。对于以分钟甚至秒级延迟处理数据的流式处理应用，SLA 至关重要。

在流式应用中，我们希望检查迟到事件的最大允许延迟，以及平均无故障时间（MTBF）与平均修复时间（MTTR）等指标。实现这一点需要细致地跟踪事件，并从应用监控与事件管理工具（如 PagerDuty、Datadog 和 Grafana）中提取相关数据。

数据治理合约

妥善处理可识别个人身份信息（PII）是数据转换过程不可或缺的一环。对许多公司而言，确保这些数据集至少符合 GDPR，并遵守 HIPAA 或 PCI DSS 等数据隐私法规，至关重要。

数据治理合约确保已建立充分的假名化或数据掩码策略。

请看下面的 dbt 代码。作为 tests 强制的合约要求 user_email 为 SHA256 哈希（已掩码）：

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matching技术支持

另一方面，我们可能希望对其他表强制执行模式匹配。例如，在下面的例子中，transaction_reference 字段必须符合 [“TRX-%”, “%-2023”] 模式：

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: any技术支持

当包含敏感数据的列、元数据（数据所有者等）以及获授权访问某数据产品的用户角色被纳入其中时，数据治理合约也会非常有用。

例如，我们可以使用 dbt 中的 meta 字段指明数据模型的所有者与模型开发生命周期阶段：

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: true技术支持

meta 字段允许您为资源设置元数据，随后会被编译进 dbt 生成的 manifest.json 文件，并可在自动生成的文档中查看。

我们可以使用诸如 dbt-checkpoint 等包在拉取请求期间进行扫描，以确保必填的 meta 字段已存在。若任何模型（来自 manifest 或 YAML 文件）缺少指定的 meta 键，钩子会失败。

模型的 meta 键必须存在于 YAML 文件或 manifest 中。

数据合约的实现模式

在流式数据管道中（按行），可以在数据摄取前或之后——即在源端（源数据模型层）执行合约验证。

当我们“原样”摄取数据时，验证过程就像一次转换步骤，强制执行合约规则并过滤无效数据，例如写入到专门的数据库视图或表，以便进一步调查。

当数据直接摄入原始数据湖后，也可以事后应用验证检查。

实时数据合约验证的主要优势在于，它能在数据到达最终目的地（数据湖或数据仓库）之前过滤掉无效记录。这种方法在事件驱动或实时数据处理中十分常见，例如变更数据捕获（CDC）事件。在这种验证中，随着数据流经管道，会对合约的某些方面进行校验。

数据合约工具

数据社区正逐步认识到数据合约的潜在益处——这是一个不断演进的数据工程领域。该领域已有众多工具问世，部分仍处于早期阶段。dbt 可被视为数据合约的通用框架。

在源端（源数据模型层）也可使用 Google 的 Dataform 实现类似合约，即当数据已成功摄入数据仓库时。我们希望为此使用简单的行级条件。

请看下面的示例。它为我们的表应用了特定的行级条件：

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …技术支持

下面是另一个数据合约实现的示例，可通过 Soda.io（一个小众的数据质量框架）实现：

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0技术支持

通过调整告警设置，您可以将检查配置为发出警告而非使验证失败。Soda 扫描会运行协议中指定的检查，检查 YAML 文件或在程序调用中内联的检查，并为每项检查返回结果：通过、失败或错误。

根据我的经验，许多公司引入数据合约的方式仍较为零散，这取决于数据管道设计模式（批处理或实时）、数据序列化选择以及用于存储和处理的系统等因素。

数据合约的实施取决于业务需求与业务逻辑。

Great Expectations 是一个 Python 库，可用于实现语义层级的数据合约。可以使用 pip 安装：pip install great_expectations。

运行 great_expectations init 后，我们即可进行数据验证：

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:技术支持

请看下面的代码片段。它说明了如何为 price 列创建数据检查定义：

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},技术支持

数据合约最佳实践

并不存在放之四海皆准的答案。根据我的经验，成功实施数据合约高度依赖业务需求。要让数据合约有效发挥作用，请遵循以下关键最佳实践：

• 可扩展性： 建议加入可扩展机制（例如 on_schema_change: append）与版本管理，使您能在不破坏现有管道集成的情况下修改合约条款。 以面向未来变更与可扩展性的思路设计数据合约。 这种方法能确保合约适应不断演变的需求与增长。
• 清晰规则： 建议在数据合约中使用直白、简洁的语言，避免误解与曲解。合约应以所有相关方（无论技术背景如何）都能访问并理解的方式撰写与命名。
• 协作： 协作努力能确保对需求形成全面、均衡的理解，兼顾多种视角与需要。在创建数据合约时，应邀请多元干系人参与，包括数据生产者、数据工程师、数据科学家，以及来自业务、IT、法务与合规部门的代表。
• 元数据： 建议为数据合约提供完善的文档与元数据。完善的文档有助于合约的顺利应用与维护。应包含详细说明、字段定义、验证规则及其他相关信息，以支持清晰理解与高效实施。
• 定期评审： 持续评审有助于长期保持合约的相关性与有效性。为监控和更新数据合约制定结构化方法。定期评审可确保合约保持最新，符合不断演进的业务需求，并遵守新出台或变化的法规。

结论

近期，数据所有权正在向分布式转变，领域团队对其数据产品负责。这一变化促使组织通过数据合约重新定义数据质量预期并将其形式化。

语义数据验证确保数据逻辑一致并符合业务逻辑。它们有助于检查数据管道中的各类异常，例如数值、沿袭与参照完整性。不足的参照完整性会导致数据缺失或不完整，因此同样重要。

数据治理合约也可在 CI/CD 管道中实施，并在标注包含敏感数据的列、元数据（数据所有者等）以及获授权访问数据产品的用户角色时发挥重要作用。

模型的元数据以及开发者定义的其他必填元字段，有助于监控模型的资源使用与性能。

数据合约中的服务级别协议（SLA）明确了与数据新鲜度、完整性与故障恢复相关的具体承诺。

数据合约是现代数据建模技术的要素，有助于确保数据平台稳健可扩展并减少错误。解决数据质量问题可能代价高昂。对于企业级公司而言，通过利用支持数据合约验证的现有数据质量工具，最大化数据投资回报率（ROI）变得愈发重要。