一文搞懂什么是数据合约

数据合约是分布式数据解决方案中保障数据质量和可扩展性的核心。它规定了数据库实体间数据交换的格式、模式和协议，通过消除数据歧义与未文档化的假设，为数据流通建立标准化规则。

本文带大家深入解析数据合约的核心概念，并提供基础与进阶技术，助力其高效落地。

一、数据合约的本质

数据合约定义了两个模型间数据交换的精确参数，确保数据格式与模式的一致性，是数据生产者（修改数据状态的流程）与消费者（数据接收方）之间的正式协议。

其核心逻辑类似商业合同，旨在明确数据产品（如表、视图、数据模型等）供需双方的责任，避免数据管道下游中断，保障数据转换的稳定性与可靠性。

核心组件

• 模式（Schema）：定义列名、数据类型、是否必填，以及格式、长度、值域等约束。
• 语义层：包含业务指标、计算逻辑与规则限制。
• 服务级别协议（SLA）：规定数据新鲜度、延迟容忍等服务标准。
• 数据治理：确保数据合规性、隐私保护与访问控制。

核心价值

• 自动化质量校验：在数据输出创建或更新时自动执行质量检查。
• 支持分布式扩展：尤其适用于数据网格（Data Mesh）等分布式架构。
• 优化开发生命周期：通过合约验证工具提升开发效率。
• 促进跨团队协作：建立生产者与消费者之间的反馈机制。

二、基于dbt的数据合约实践

基础示例：模式验证

在dbt中，通过YAML文件定义模型合约。以下示例中，​​dim_orders​​模型强制校验列类型：

models:  
-name:dim_orders
    config:
      materialized:table
      contract:
        enforced:true# 启用合约校验  
    columns:
      -name:order_id
        data_type:int
        constraints:
          -type:not_null
      -name:order_type
        data_type:string

若模型查询结果与合约冲突（如​​order_id​​返回字符串而非整数），dbt将抛出类型不匹配错误：

编译错误：模型dim_orders的合约校验失败  
列名: order_id | 定义类型: TEXT | 合约类型: INT | 不匹配原因: 数据类型错误

进阶实践：复杂约束

dbt支持表级与列级约束，如主键、外键、自定义检查：

models:  
-name:orders
    config:
      contract:
        enforced:true
    constraints:
      -type:primary_key
        columns:[id]
      -type:FOREIGN_KEY
        columns:[order_type,second_column]
        expression:"other_schema.other_model (other_col1, other_col2)"
    columns:
      -name:first_column
        data_type:int
        constraints:
          -type:unique
          -type:foreign_key
            expression:"other_schema.other_model (other_col)"

模式变更处理

当源表新增列时，可通过​​on_schema_change: append​​策略实现增量更新，避免合约失效。

三、语义数据合约与业务逻辑校验

语义验证确保数据符合业务逻辑，需通过外部规则显式实现，例如：

• 指标偏差：活跃用户数低于7日移动平均值的75%时触发预警。
• 事务逻辑：支付场景中异常交易金额强制置零。
• 数据血缘：订单完成时间不可早于创建时间。
• 参照完整性：退款记录的​​refund_id​​必须关联有效交易ID：

- name:refunds
columns:
    -name:refund_id
      tests:
        -relationships:
            to:ref('transactions')
            field:id

四、服务级别协议（SLA）与数据新鲜度

SLA用于定义数据更新时效，例如：

• dbt freshness测试：确保订单数据每日更新，延迟不超过1天：

- name:orders
tests:
    -dbt_utils.recency:
        datepart:day
        field:timestamp
        interval:1

• 实时管道：流处理场景中，要求数据延迟不超过5分钟，通过Datadog等工具监控故障恢复时间（MTTR）。

五、数据治理合约与隐私合规

数据治理合约聚焦敏感数据保护与权限管理，例如：

• GDPR合规：用户邮箱需通过SHA256哈希脱敏：

models:  
-name:customer_data
    columns:
      -name:user_email
        tests:
          -dbt_expectations.expect_column_values_to_not_match_regex:
              regex:"^(?!.*\b@\b).*"# 禁止明文邮箱

• 元数据管理：通过dbt​​meta​​字段标注数据所有者与隐私级别：

models:  
-name:users
    meta:
      owner:"@data_mike"
      contains_pii:true
    columns:
      -name:email
        meta:
          contains_pii:true

六、数据合约实现模式与工具

验证阶段

• 实时校验：在数据摄入前逐行验证（如CDC场景），过滤无效记录。
• 事后校验：原始数据湖加载后执行批量验证，生成问题数据视图。

工具生态

• dbt：通用合约框架，支持模式、约束与SLA校验。
• Great Expectations：Python库，用于语义层验证，支持自定义正则与统计规则。
• Soda.io：轻量级数据质量工具，通过YAML定义校验规则：

checks for dim_customer:  
-row_countbetween10and1000
-missing_count(birth_date)=0
-invalid_percent(phone)<1%:
      valid format:phonenumber

七、最佳实践指南

1. 可扩展性设计：预留模式变更策略（如字段追加）与版本管理机制。
2. 规则清晰化：使用简洁语言定义合约，避免技术歧义。
3. 跨团队协作：纳入业务、合规、技术等多方 stakeholders 共同制定规则。
4. 元数据完备性：详细记录字段定义、校验逻辑与责任人。
5. 定期评审机制：结合业务变化动态更新合约，确保合规性与时效性。

八、结语

在分布式数据架构日益普及的背景下，数据合约已成为保障数据质量的核心机制。

通过整合模式验证、语义规则、服务级别协议（SLA）与数据治理体系，企业能够构建稳健的数据管道，有效降低下游故障风险，最大化数据资产价值。

随着工具生态的不断成熟，数据合约将逐步成为数据驱动型组织的底层基础设施，为数据价值释放提供持续支撑。

本文转载自​​AI科技论谈​​​​​​​​，作者：AI科技论谈