Data Product

Data Product (дата-продукт) это самостоятельная единица данных, которую домен-производитель отдаёт другим командам через явный интерфейс с гарантиями качества, а не сырой выгрузкой из таблицы. Подход вырос из архитектуры Data Mesh, но применяется и там, где никакого mesh нет, везде, где команда хочет, чтобы её данные находили, понимали и использовали без личного разговора с автором.

Что такое Data Product и какую задачу он решает

По классу решений Data Product ближе к программному продукту, чем к таблице в хранилище. У него есть владелец, версия схемы, документация и обязательства перед потребителями, поэтому слово «продукт» здесь не метафора. Задача, которую он закрывает, простая по формулировке и сложная на практике. Аналитик или инженер из другой команды должен подключиться к данным самостоятельно, без тикета в очередь дата-инженерии и без созвона с автором таблицы. У обычной таблицы часто нет даже человека, к которому идти с вопросом о качестве данных, а у продукта такой контакт закреплён по определению.

Термин ввела Zhamak Dehghani (Жамак Дехгани), на момент публикации директор по новым технологиям в Thoughtworks, как один из четырёх принципов Data Mesh, децентрализованной архитектуры данных. Позже понятие отделилось от Data Mesh и используется само по себе, в том числе в централизованных платформах вроде корпоративного каталога данных. Если Data Mesh описывает, кто владеет данными и по каким правилам домены обмениваются ими, то Data Product описывает, из чего состоит сама единица обмена.

Архитектура Data Product и её составные части

Data Product собирает вместе три слоя, которые в классической витрине данных обычно живут порознь. Данные и метаданные, то есть сама таблица или файл плюс схема, описание полей и владелец. Код, который эти данные вычисляет, проверяет и обслуживает, а именно ingest, трансформации и тесты качества. Инфраструктура, на которой код исполняется и данные хранятся, от планировщика задач до объектного хранилища. Пока эти три слоя не упакованы вместе и не версионируются как единое целое, речь идёт об обычном датасете, а не о продукте.

Входные и выходные порты

С внешним миром Data Product общается через порты. Входной порт (input port) забирает данные из операционных систем или из других data products, эта точка входа обслуживает процесс создания продукта, а не внешних пользователей. Выходной порт (output port) отдаёт готовый результат, и именно он виден потребителям снаружи домена. Один продукт обычно держит несколько выходных портов под разные сценарии доступа, например таблицу в аналитическом хранилище для SQL-запросов, файлы в объектном хранилище для пакетной обработки и топик очереди сообщений для потоковых подписчиков. Подробное описание архитектуры портов даёт сообщество проекта Data Mesh Architecture, откуда взята и терминология этого раздела.

Как выходной порт становится контрактом доступа

Сам по себе выходной порт это просто адрес, куда можно подключиться. Контрактом (data contract) он становится, когда рядом фиксируются условия использования, а именно схема данных с типами полей, правила качества вроде допустимой доли пустых значений, показатели свежести и норматив по времени отклика, а также условия доступа и биллинга, если продукт платный внутри организации. Потребитель читает контракт до подключения и понимает, чего ждать от продукта, не открывая переписку с командой-производителем.

Контракт версионируется отдельно от кода. Смена типа поля или удаление колонки это breaking change, и производитель обязан либо сохранить старую версию порта на переходный период, либо заранее предупредить подписчиков. Эта дисциплина и отличает Data Product от таблицы, к которой можно применить произвольный ALTER TABLE в любой момент, не думая, кто смотрит на неё с другой стороны.

Шесть свойств качественного Data Product

Data Mesh Architecture формулирует шесть свойств, которым должен отвечать зрелый Data Product, и на практике они работают как чек-лист приёмки нового продукта в каталог данных.

• Discoverable. Продукт зарегистрирован в каталоге данных и находится поиском по названию или тегу, а не по личным договорённостям.
• Addressable. У каждого выходного порта стабильный адрес, который не меняется при внутренних перестройках инфраструктуры домена.
• Trustworthy. Метрики качества и SLA публикуются рядом с продуктом и обновляются автоматически, а не по запросу.
• Self-describing. Схема, семантика полей и владелец доступны без обращения к автору, обычно прямо в карточке каталога.
• Interoperable. Продукт использует общие для организации стандарты идентификаторов и типов, поэтому его можно соединить с другим продуктом без ручного маппинга.
• Secure. Доступ к порту проходит через единую политику авторизации, а не через расшаренный пароль от базы.

Ни одно свойство не работает изолированно. Доверенный, но ненаходимый продукт никто не станет искать, а находимый, но недокументированный продукт никто не рискнёт подключить к продакшену, поэтому слабое звено в любом из шести обесценивает остальные пять. На практике список заменяет долгое устное обсуждение готовности нового продукта: рецензент каталога данных проходит по шести пунктам вместо того, чтобы придумывать критерии приёмки заново для каждой заявки.

Чем Data Product отличается от обычной витрины данных

Понятия пересекаются, потому что оба живут в аналитическом слое, но продуктовый подход добавляет владение, контракт и обязательства там, где витрина данных обычно ограничивается схемой и правами доступа.

Разница не в технологии. Одна и та же таблица PostgreSQL может быть и витриной, и выходным портом продукта, разница в договорённостях и в том, кто отвечает, когда потребитель находит в данных ошибку.

Переход от витрины к продукту обычно постепенный. Сначала домен документирует схему и назначает ответственного, затем добавляет проверки качества, и только на последнем шаге оформляет версионированный контракт и регистрирует продукт в каталоге. Требовать от каждой таблицы сразу весь набор из шести свойств контрпродуктивно, потому что домены начинают тратить время на бюрократию вместо данных, которые реально нужны потребителям.

Когда продуктовый подход к данным оправдан, а когда нет

Продуктовый подход окупается там, где данные потребляет много независимых команд с разными требованиями к свежести и формату, а централизованная команда данных физически не успевает разбирать заявки по одной. Роль владельца продукта данных (Data Product Owner, DPO) появляется именно в этой точке, она подробно разобрана в статье школы про оптимизацию аналитических нагрузок с Data Mesh, где DPO переводит сценарии использования домена в требования к продукту. На практике так устроены внутренние маркетплейсы данных крупных платформ, в частности Snowflake Marketplace и Databricks Marketplace, где потребитель подключает чужой продукт самостоятельно, без переписки с поставщиком.

Подход не оправдан там, где данные использует одна команда для одного сценария. Оформление выходного порта, контракта и записи в каталоге ради единственного потребителя это чистые накладные расходы, и обычной витрины с понятной схемой и прямым каналом связи с автором вполне достаточно. Пограничный случай, где решение неочевидно, это две-три смежные команды с разными требованиями к свежести данных. Здесь часто выгоднее сначала описать общий data contract без полноценной записи в каталоге, а к продуктовому оформлению переходить, когда появляется следующий независимый потребитель. Для системного взгляда на то, когда какая архитектура данных уместна, полезен курс школы «Практическая архитектура данных», где разбираются критерии выбора между централизованными и доменными подходами.

Как выглядит data contract на практике

Синтаксис ниже иллюстрирует Open Data Contract Standard (ODCS), открытую спецификацию проекта Bitol под управлением Linux Foundation AI & Data. Стандарт описывает схему полей выходного порта, порог качества и норматив по свежести данных.

# иллюстрация синтаксиса Open Data Contract Standard (ODCS), см. bitol.io
apiVersion: v3.1.0
kind: DataContract
id: orders_data_product
version: 2.3.0
status: active
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        physicalType: bigint
        primaryKey: true
      - name: order_amount
        physicalType: decimal
        required: true
      - name: updated_at
        physicalType: timestamp with time zone
quality:
  - column: order_amount
    mustBeGreaterThan: 0
slaProperties:
  - property: freshness
    value: 15
    unit: m

Такой файл живёт рядом с кодом продукта и проверяется в CI при каждом изменении схемы. Потребитель, прежде чем подключиться, читает контракт, а не звонит владельцу продукта, чтобы спросить, какие поля есть в таблице сегодня.

Заключение

Data Product переносит в мир данных дисциплину, которая в разработке ПО давно стала нормой, а именно явный интерфейс, версионирование и ответственность одного владельца. Это не архитектурный паттерн ради моды, а способ снять с центральной команды данных бесконечную очередь заявок, переложив её на понятные контракты между доменами. Там, где потребитель один и требования не меняются, обычная витрина справится дешевле и быстрее.

Референсные ссылки

• Data Mesh Architecture, определение и структура Data Product
• dbt Labs, Key components of data mesh: creating and managing data products
• Zhamak Dehghani, «Data Mesh: Delivering Data-Driven Value at Scale», O’Reilly, 2022
• Bitol, Open Data Contract Standard (ODCS), проект Linux Foundation AI & Data