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).
Пять обязательных полей
Минимальный валидный ODCS контракт содержит ровно 5 полей:
apiVersion: v3.1.0
kind: DataContract
id: 53581432-6c55-4ba2-a65f-72344a91553a
version: 1.0.0
status: draftКаждое поле имеет строгое назначение:
| Поле | Описание | Формат |
|---|---|---|
apiVersion | Версия спецификации ODCS | v3.1.0 (фиксированная строка) |
kind | Тип документа | Всегда DataContract |
id | Уникальный идентификатор контракта | UUID или строковый ID |
version | Версия контракта (semver) | 1.0.0 — связь с версионированием из урока 05 |
status | Текущее состояние контракта | Один из 5 статусов жизненного цикла |
Жизненный цикл контракта (status)
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 — ключевая секция контракта, описывающая структуру данных: таблицы, колонки, типы и классификацию.
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Ключевые свойства: logicalType (абстрактный тип), physicalType (тип СУБД), classification (public/restricted/confidential), quality (inline-правила). Обратите внимание: classification задаётся на каждую колонку — customer_id (public) и email (restricted) в одной таблице.
Проверка знанийПочему classification на уровне колонки (а не таблицы) критичен для governance автоматизации?
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.
Проверка знанийКакие преимущества даёт переход от ad-hoc контрактов к ODCS стандарту?
Итоги
- 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.
Дополнительные материалы
Углублённые статьи по теме урока
Проверьте понимание
Закончили урок?
Отметьте его как пройденный, чтобы отслеживать свой прогресс
Войдите чтобы оценить урок