Open Data Contract Standard (ODCS)

Введение

В предыдущем уроке мы изучили Data Contracts как концепцию. Но каждая организация изобретала собственный формат — DataTech использовала ad-hoc YAML с полями contract.name, contract.version, contract.owner. Такие контракты невозможно валидировать автоматически.

Open Data Contract Standard (ODCS) — индустриальный стандарт, созданный в PayPal и в 2023 году переданный проекту Bitol (Linux Foundation AI & Data). Конкурирующий Data Contract Specification (DCS) объявлен устаревшим (поддержка заканчивается в 2026). ODCS — единственный индустриальный стандарт. Текущая версия — ODCS v3.1.0 (январь 2026).

Пять обязательных полей

apiVersion: v3.1.0
kind: DataContract
id: 53581432-6c55-4ba2-a65f-72344a91553a
version: 1.0.0
status: draft

Fundamentals

После обязательных полей контракт описывает метаданные data product:

name: customer_data_product
domain: crm
tenant: DataTech
description:
  purpose: Customer master data for CRM and analytics
  limitations: No financial transaction data included
  usage: Use for customer segmentation and retention analysis

Поля: name (snake_case, naming conventions из урока 04), domain (Domain Ownership из урока 05), tenant (организация). Объект description содержит purpose, limitations, usage.

Schema

schema:
  - name: customers
    physicalType: table
    properties:
      - name: customer_id
        logicalType: integer
        physicalType: bigint
        required: true
        primaryKey: true
        classification: public
      - name: email
        logicalType: string
        physicalType: varchar
        required: true
        classification: restricted
        quality:
          - metric: nullValues
            mustBe: 0
            type: library
            dimension: completeness
      - name: full_name
        logicalType: string
        physicalType: varchar
        required: true
        classification: restricted
      - name: created_at
        logicalType: timestamp
        physicalType: timestamp
        required: true
        classification: public

Quality Rules

ODCS также поддерживает top-level quality rules на уровне таблицы:

quality:
  - metric: rowCount
    mustBeGreaterThan: 1000
    type: library
    dimension: completeness
    severity: error
  - metric: duplicateValues
    mustBe: 0
    type: library
    dimension: uniqueness
    arguments:
      properties:
        - customer_id
  - type: sql
    query: "SELECT COUNT(*) FROM customers WHERE email NOT LIKE '%@%.%'"
    mustBe: 0
    dimension: conformity
    description: Email format validation

ODCS поддерживает 4 типа правил: library (встроенные метрики), sql (произвольные запросы), text (документация), custom (внешняя логика). Поле dimension связывает правило с измерениями качества (accuracy, completeness, conformity, uniqueness, timeliness) — подробнее в Модуле 04.

SLA Properties

SLA определяет обязательства producer перед consumers в машиночитаемом формате:

slaProperties:
  - property: latency
    value: 1
    unit: d
  - property: retention
    value: 7
    unit: y
  - property: availability
    value: 99.5

В отличие от строковых SLA (freshness: "1 hour" из урока 05), числовые значения с единицами можно мониторить автоматически. Latency 1d, retention 7y (бухгалтерские требования), availability 99.5%.

Team и Roles

Контракт фиксирует ответственных за data product и уровни доступа:

team:
  name: CRM Domain Team
  members:
    - username: aivanov
      role: Data Steward
      dateIn: "2025-01-15"
roles:
  - role: analyst
    access: read
  - role: engineer
    access: write

team определяет producer (кто отвечает). roles определяет consumer access levels (связь с RBAC из Модуля 06).

Справочник дополнительных секций

ODCS v3.1.0 определяет дополнительные секции для специализированных сценариев:

Эти секции опциональны. Для большинства организаций достаточно required fields + schema + quality + slaProperties + team.

Сценарий: DataTech переходит на ODCS

В уроке 05 DataTech создала ad-hoc data contract. Теперь CRM Domain Team переводит его в ODCS.

До (ad-hoc формат):

contract:
  name: customer_data_product
  version: "2.1.0"
  owner: CRM Domain Team
  schema:
    properties:
      customer_id: { type: integer, pii: false }
      email: { type: string, pii: true, classification: confidential }
  sla:
    freshness: "1 hour"
    availability: "99.5%"

После (ODCS v3.1.0):

apiVersion: v3.1.0
kind: DataContract
id: dt-customer-001
version: 2.1.0
status: active
name: customer_data_product
domain: crm
tenant: DataTech
description:
  purpose: Customer master data for CRM and analytics
  limitations: No financial transaction data included
  usage: Use for customer segmentation and retention analysis
schema:                          # типизированная schema
  - name: customers
    physicalType: table
    properties:
      - name: customer_id
        logicalType: integer
        classification: public   # column-level classification
      - name: email
        logicalType: string
        classification: restricted
        quality:                 # inline quality rules
          - metric: nullValues
            mustBe: 0
slaProperties:                   # машиночитаемый SLA
  - property: latency
    value: 1
    unit: d
team:
  name: CRM Domain Team

Ключевые изменения: обязательные поля вместо произвольной вложенности, типизированная schema (logicalType/physicalType), column-level classification вместо pii: true/false, машиночитаемый SLA, inline quality rules.

Итоги

• ODCS v3.1.0 — единственный индустриальный стандарт data contracts (DCS устарел)
• 5 обязательных полей: apiVersion, kind, id, version, status
• Schema — column-level classification + inline quality rules
• Quality rules — 4 типа (library, sql, text, custom) с привязкой к dimension качества
• SLA — машиночитаемые обязательства (latency, retention, availability)
• Team/roles — ответственные и уровни доступа
• Контракты версионируются через semver: major (breaking), minor (additive), patch (fix)

ODCS определяет ЧТО — формальный контракт между producer и consumer. Но контракт без enforcement — бумажный тигр. Data Integration Governance (управление интеграцией данных) определяет КАК данные физически перемещаются между системами: ETL/ELT pipeline governance, API versioning, schema registry governance, B2B data exchange. В следующем уроке мы изучим governance-практики для каждого паттерна интеграции — от Airflow DAGs DataTech до Kafka topics FinSecure.