Домены и дата-продукты

Чем больше в каталоге объектов, тем сложнее им пользоваться. Тысячи таблиц, сотни дашбордов, десятки конвейеров — и простой вопрос «чья это таблица?» превращается в часовую переписку. В Arenadata Catalog (ADC) версии 1.0 справиться с этой сложностью помогают две новые сущности — Домен и Дата-продукт. Они добавляют слой бизнес-смысла поверх технических объектов и закрепляют ответственность за данными так, чтобы она была видна каждому пользователю каталога.

Статья объясняет назначение и бизнес-ценность новых сущностей, показывает их связь с общепринятыми практиками управления данными и даёт два пошаговых сценария внедрения: с нуля (раздел 4) и поверх уже наполненного информацией каталога (раздел 5).

Отдельно для наглядного разъяснения процессов мы описали сквозной пример управления данными HR-блока на базе условной компании «Промтех» (читать статью): данные о сотрудниках есть в любой организации, поэтому описанные шаги одинаково применимы в банке, производственной компании, IT и госсекторе, а пример легко воспроизвести в собственном каталоге с помощью чек-листа внедрения (Приложение, А статьи «Пример внедрения доменов»).

1. Разъяснение сущностей: домены и дата-продукты

1.1. Что такое домен данных

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

В интерфейсе Arenadata Catalog домены живут в отдельном разделе «Домены» в боковой панели. У каждого домена есть техническое наименование, бизнес-наименование, описание, владелец — команда или пользователь, теги, иерархия «родитель — поддомен» и связи с другими сущностями каталога.

Карточка домена устроена интуитивно просто. Шесть вкладок отражают всё, что нужно знать о бизнес-области:

«Основная информация» — описание, разметка классификаторами, владелец; здесь же отображаются пользовательские атрибуты.

«Поддомены» — дочерние объекты; отсюда же создаются новые поддомены.

«Дата-продукты» — продукты данных, выпускаемые этим доменом.

«Объекты» — таблицы, дашборды, топики и другие ассеты, принадлежащие домену.

«Участники» — пользователи и команды, работающие с доменом.

«Связанные объекты» — связи с глоссарием и другими сущностями каталога.

Главная ценность домена для бизнеса — он делает зону ответственности видимой. Раньше «кто отвечает за HR-данные» было вопросом к памяти отдельных людей; теперь это поле карточки, обновляемое одним кликом.

1.2. Что такое дата-продукт

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

Идея продуктового подхода к данным проста: данные нужно проектировать как самостоятельный продукт, а не как побочный результат работы информационных систем. У хорошего дата-продукта есть набор обязательных качеств: он обнаруживаемый (его можно найти поиском), понятно описанный (дата-продукту можно задать описание, расширить карточку пользовательскими атрибутами), заслуживающий доверия (можно назначить владельца) и защищённый (доступ до объекта регулируется политиками доступа). Карточка дата-продукта в Arenadata Catalog закрывает каждый из этих пунктов штатными средствами.

В карточке продукта есть шапка с основной информацией по объекту, а также вкладки:

«Основная информация» — описание, разметка классификаторами, расширенные атрибуты.

«Объекты» — состав продукта: таблицы, дашборды, модели данных дашбордов, топики, конвейеры, ML-модели, объекты глоссария, контейнеры, хранимые процедуры.

«Связанные объекты» — связи с глоссарием и другими объектами каталога через настраиваемые типы связей.

В продукт можно включать объекты своего домена, другого домена и объекты без домена; один и тот же объект может входить в несколько продуктов. Тесты качества пишутся на таблицы и колонки — поэтому, включая таблицу в состав продукта, вы автоматически включаете в него гарантии и её проверки. Это убирает классический риск: «подключили данные, но забыли подключить проверки их качества».

1.3. Дата-контракт: следующий шаг модели

В литературе по управлению данными контракты называют логичным продолжением доменов и продуктов: контракт — это формальное обязательство продукта перед потребителями (схема, SLA, политика обратной совместимости). В текущей версии Arenadata Catalog дата-контракт отдельной сущностью каталога не является, но основа контрактной модели уже доступна: у продукта есть владелец, явный состав, а SLA, частота обновления и перечень потребителей фиксируются в расширенных атрибутах. Многие команды дополнительно заводят атрибут «Дата-контракт» со ссылкой на документ во внутреннем хранилище.

Полноценные дата-контракты — в планах развития функциональных возможностей Arenadata Catalog. Важно учесть одно: всё, что вы делаете с доменами и дата-продуктами сейчас, готовит почву для контрактной модели, поскольку переделывать ничего не придётся.

1.4. Иерархия и наследование

Иерархия домена двухуровневая: домен и поддомен. У карточки поддомена нет вкладки «Поддомены» — глубина дерева ограничена намеренно, чтобы декомпозиция не превращалась в многоэтажную бюрократию. Дата-продукты живут внутри домена или поддомена, но третьим уровнем иерархии не считаются — это отдельная сущность. Типовая корпоративная архитектура насчитывает 15−25 доменов: «Бюджетирование», «Клиенты», «Коммерция», «Логистика и складирование», «Маркетинг», «Менеджмент кадров», «Финансы» и другие. В этой статье мы подробно разберём один из них — «Менеджмент кадров».

К ключевой технической особенности относится наследование принадлежности к домену вниз по иерархии объектов. Назначили домен на сервис базы данных — его наследуют базы, схемы и таблицы. Назначили на схему — наследуют таблицы внутри. Дашборды, топики, конвейеры, ML-модели и контейнеры наследуют домен от своего сервиса, термины глоссария — от глоссария и предметной области, пользователи — от команды. Это делает разметку быстрой и масштабируемой: один клик на «контейнере» избавляет от ручной разметки тысяч страниц описания объектов.

Унаследованная принадлежность помечается в карточке специальной иконкой, и снять её с отдельного объекта нельзя, это происходит только при исключении из домена верхнеуровневого объекта. Вручную объекту доступно назначить до пяти доменов, а количество наследуемых не ограничено. Поддомены устроены иначе: объекты и продукты родителя не «протекают» в них автоматически, так как каждый поддомен ведёт собственное содержимое.

1.5. Чем домен и дата-продукт не являются

Несколько границ, которые помогают избежать терминологической путаницы:

Домен не классификация и не тег. Классификации (Tier1…Tier5, категории персональных данных) остаются и работают ортогонально: они отвечают на вопрос «насколько критичен объект», домен — на вопрос «к какой бизнес-области объект относится».

Домен не глоссарий. Глоссарий хранит бизнес-термины и их определения, домен оперирует зоной ответственности. Это разные сущности; между собой они связываются отдельным механизмом типов связей.

Домен не копия оргструктуры. Оргструктура меняется чаще, чем бизнес-функции. Декомпозицию стоит вести от функциональной карты компании: например, домен «Менеджмент кадров» может пережить три реорганизации HR-департамента.

Дата-продукт не таблица и не отчёт. Это сущность поверх них: в продукт обычно объединяется несколько ассетов, и наоборот, одна таблица может входить в разные продукты разных доменов.

Дата-продукт не пайплайн. Пайплайн — типовой ассет внутри продукта. Продукт — это обещание потребителю; пайплайн — то, как это обещание исполняется.

2. Концепция: какую задачу решают новые сущности

2.1. Что меняется в каталоге

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

Домены добавляют верхний слой смысла и зону ответственности. Дата-продукты — единицы выпуска данных с владельцем и заявленными гарантиями. Вместе они превращают каталог из энциклопедии объектов в карту: данные принадлежат бизнес-функциям и упакованы в продукты с понятными обязательствами. Дата-продукт — законченный продукт преобразования и обработки данных, который имеет заявленные свойства и ценности, который можно безопасно использовать в организации и передавать на сопровождение в отдел эксплуатации ИТ или внутренний отдел технической поддержки.

Методологически это два ключевых принципа современного управления данными — доменное владение данными и отношение к данным как к продукту, — реализованные на уровне каталога. При этом перестраивать архитектуру под децентрализованную модель не обязательно: доменная разметка и продуктовая упаковка наводят порядок как в централизованной архитектуре с корпоративным DWH, так и в Lakehouse. Новые сущности делают управление данными и стюардство операционными: зоны ответственности перестают быть таблицей в Confluence и презентацией раз в полгода. Это актуальное состояние, которое видит любой пользователь каталога.

2.2. Где это даёт эффект

Новые сущности затрагивают сразу несколько практик управления данными. В таблице собрали информацию о ценностях, которые получает организация при внедрении доменов и продуктов:

Практика управления данными	Что меняет домен	Что меняет дата-продукт
Управление данными и стюардство	Закрепляет ответственность и иерархию стюардов; политики доступа могут опираться на принадлежность к домену	Назначает владельца на единицу выпуска данных
Архитектура данных	Делает доменную декомпозицию ландшафта явной; работает наследование вниз	Делает явным, какие данные публикуются для потребителей
Мастер-данные и справочники	Отделяет мастер-домены от транзакционных	Формализует справочные дата-продукты
Качество данных	Связывает политики качества с зоной ответственности	Отражает, как проверяются объекты в составе дата-продукта
Метаданные и описание	Расширяется через настраиваемые атрибуты	Описывает гарантии (SLA, потребители, источники) через атрибуты

*Подробнее про «Качество данных» можно почитатьв статье.

2.3. Какие задачи становятся проще

Из рутины DG-офиса уходит большая часть переписок «на пальцах»:

Поиск владельца объекта. Если раньше велась длинная переписка по чатам, то теперь достаточно открыть карточку домена с полем «Владелец».

Понимание зоны ответственности. У владельца появляется видимое «своё»: все объекты и продукты домена, политики над ними.

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

Декомпозиция работы DG-офиса. Каждый домен является отдельным планом работ по качеству, документированию и согласованиям.

Onboarding потребителя данных. Хождения по таблицам заменил список дата-продуктов с описанием гарантий: что внутри, как часто обновляется, кому жаловаться.

Сверка приоритетов с бизнесом. Домены соотносятся с бизнес-направлениями, метрики продуктов — с бизнес-KPI.

3. Интеграция с глоссарием, метаданными и качеством

Новые сущности не отменяют того, что уже есть в каталоге. Они встраиваются поверх и связывают существующие механизмы в единую систему. Четыре точки интеграции позволяют выполнить эту задачу эффективно, сохранив присущую каталогу ADC гибкость и удобство.

3.1. Связь с глоссарием

Глоссарий каталога ведёт описания бизнес-терминов с определениями, кастомизируемым атрибутным составом, синонимами и ответственными. Корпоративный глоссарий обычно насчитывает сотни и тысячи терминов. В нашем примере их около сорока из финансов и HR (НДС, Бухгалтерская проводка, Точечный рекрутинг, Текучесть кадров и др.).

Связь домена или дата-продукта с термином устанавливается через отдельный механизм типов связей, а не через теги. Для пары «домен ↔ объект глоссария» (и аналогично для связи «дата-продукт ↔ объект глоссария») создаётся свой тип связи с настройкой направленности. Результат отображается на вкладке «Связанные объекты» в табличном виде: тип связи, наименование объекта, тип объекта. То же видно и со стороны термина: на его карточке появляется блок связанных доменов и продуктов. Кроме того, сами термины и предметные области могут принадлежать домену, поскольку они наследуют его от глоссария.

Что важно на практике: на уровне дата-продукта стоит связывать 4−7 ключевых терминов — тех, без которых нельзя понять, что внутри. Десяток связей превращает карточку в свалку; четыре-пять читаются как оглавление.

3.2. Связь с метаданными и lineage

К главной технической особенности домена относится наследование вниз по иерархии (подробно — в разделе 1.4). Иконка «Наследован» в карточке отличает наследуемую принадлежность от назначенной вручную; прямых назначений у объекта может быть до пяти доменов.

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

Доменом можно разметить широкий перечень типов: сервисы, базы данных, схемы, таблицы, дашборды и их модели данных, топики, конвейеры, ML-модели, контейнеры, хранимые процедуры, глоссарии, предметные области, объекты глоссария, команды и пользователей. Дата-продукт принимает в состав более узкий набор объектов, критически важных в его формировании: таблицы, дашборды, модели данных дашбордов, топики, конвейеры, ML-модели, объекты глоссария, контейнеры, хранимые процедуры.

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

Функционал внутренних справочников внутри Arenadata Catalog (RDM) не является элементом доменной модели. Таким образом, справочники не потребуют дополнительных корректировок при обновлении на новую версию ADC.

3.3. Связь с качеством данных

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

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

•На уровне дата-продукта появляется честный ответ на вопрос «можно ли полагаться на этот продукт целиком»: он определяется статусами тестов входящих в него таблиц, а не субъективной оценкой.

•На уровне домена стюард получает контур своей зоны ответственности: все таблицы домена и состояние их проверок формируют готовую основу для регулярных встреч DG-офиса.

Командам, у которых тесты уже настроены, делать дополнительно ничего не нужно: инженеры по качеству данных работают как и раньше.

3.4. Глобальная фильтрация по домену

Помимо ассоциаций «домен ↔ объект», домен можно использовать как режим работы. В шапке приложения есть выбор домена: после выбора необходимого домена раздел «Обзор» показывает только объекты этого домена и его поддоменов. Значение «Все домены» возвращает полный каталог, включая объекты без назначенного домена.

Отдельные домены можно скрыть из списка для части пользователей, это настраивается политиками доступа. Команды получают возможность «жить» в своём домене, не отвлекаясь на чужие объекты; DG-офис переключается между доменами, как между папками.

4. Как внедрить с нуля

Раздел будет полезен для организаций, которые только разворачивают каталог данных. В этот момент у них ещё нет накопленных привычек разметки объектов каталога, поэтому самый правильный ход — сразу заложить доменно-продуктовую модель, без переходного периода и миграционных болей.

4.1. Шаг 1. Подготовительные договорённости

Самый продолжительный по времени этап не относится к функционалу ADC. Он про договорённости в организации:

Согласовать декомпозицию предприятия на домены. Это совместная работа DG-офиса, архитектуры и руководителей бизнес-функций. Ведите её от функциональной карты организации или цепочек создания ценности; оргструктура — запасной вариант, она меняется чаще, чем бизнес-функции.

Утвердить владельцев. Для каждого корневого домена — одна команда-владелец и один человек, отвечающий за бизнес-смысл домена («бизнес-стюард»).

Определить базовые классификации. Tier1… Tier5 для критичности, категории персональных данных, контуры доступа. Эти теги работают параллельно с доменами и применяются к любым объектам каталога.

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

Хорошая декомпозиция узнаётся по трём признакам: у каждого домена есть единый владелец в виде команды; содержимое домена остаётся обозримым, обычно это 3−10 ключевых объектов или 1−5 продуктов; название домена отражает бизнес-функцию, а не систему («Менеджмент кадров», а не «1С: ЗУП»).

4.2. Шаг 2. Завести структуру в каталоге данных

Все операции выполняются через раздел «Домены» в боковой панели. Кнопка создания открывает выбор типа сущности.

Создаём в следующем порядке:

№1 Корневые домены создаются последовательно, с заполнением имени, обязательного описания и указанием владельца.

№2 Поддомены создаются из карточки родительского домена, с вкладки «Поддомены», с автоматическим заполнением родительского домена. При таком процессе создания родитель проставляется автоматически. Дата-продукты — из карточки соответствующего домена, с вкладки «Дата-продукты» с автоматическим заполнением связи с доменом, или же из левого меню в разделе «Домены» с ручным выбором нужного домена. Имя сущности ограничено 128 символами. Отображаемое наименование используется в карточке и навигации; его рекомендуется заполнять на естественном, понятном всем пользователям языке, избегая сложных или путанных сокращений. Имена и описания индексируются, по ним работает поиск из раздела «Обзор».

4.3. Шаг 3. Подвязать объекты

Объекты добавляются в два слоя — в домен и в продукт. Это разные действия:

Подвязка к домену делается из карточки конкретного объекта (виджет «Домен»). Часто разметка «верхних контейнеров» — сервисов и схем — сразу даёт принадлежность сотням таблиц через наследование. Это самый быстрый способ покрыть каталог доменной структурой.

Подвязка к дата-продукту делается из карточки конкретного объекта (виджет «Дата-продукт»). Один объект может входить в несколько продуктов.

Не пытайтесь подвязать к продукту сто таблиц, «чтобы было». Больше не означает лучше. Карточка работает, когда в ней 4−6 ключевых ассетов из тех, к которым обращаются потребители. Тогда вкладка «Объекты» читается как состав продукта, а не как папка файлов.

4.4. Шаг 4. Расширить атрибутный состав

Расширенные атрибуты превращают карточку домена и продукта из «карточки сущности» в полноценный профиль зоны ответственности.

Процесс состоит из двух частей:

Администратор регистрирует атрибуты для типов «Домен» и «Дата-продукт» в разделе «Конфигурация карточек», на вкладке «Объекты метаданных», через общий реестр атрибутов. Это разовая настройка: после её выполнения поля автоматически появляются во всех карточках соответствующего типа.
Пользователи заполняют атрибуты в карточках конкретных сущностей на вкладке «Основная информация». Значения попадают в версионируемую историю объекта.

Рекомендованный минимальный объём атрибутов приведён в разделе 6.8. Главное правило: один и тот же набор атрибутов на всех карточках типа. Единообразие превращает каталог в инструмент, а не в коллекцию разнородных карточек.

4.5. Шаг 5. Назначить владельцев и теги

Виджеты «Владелец» и «Теги» доступны на карточках домена и дата-продукта. Владелец выбирается из существующих команд и пользователей; теги назначаются из существующих классификаций (Tier, категории ПДн и т. п.). При необходимости новую классификацию администратор может создать в меню настройки.

Связи с глоссарием устанавливаются на вкладке «Связанные объекты» через типы связей, а не через теги. На той же вкладке отображаются связи и с другими сущностями каталога.

4.6. Шаг 6. Подключить операционные функции

Когда карточки заполнены, стоит сразу активировать функции, которые часто остаются без внимания:

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

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

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

Политики доступа с учётом доменов. Через политики («Доступ к методам API», «Доступ к объектам и их полям», «Доступ к атрибутам объекта») можно скрыть домены из списка фильтрации, ограничить доступ к дата-продуктам и операции с атрибутами «Домен» и «Дата-продукт» в карточках объектов.

5. Как внедрить тем, у кого каталог уже работает

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

5.1. Шаг 1. Снять «фотографию» текущего состояния

До любых изменений нужна инвентаризация. Зафиксируйте:

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

Цель шага — увидеть, какая фактическая декомпозиция уже сложилась через теги и владельцев. На практике она часто близка к доменной модели, и её остаётся только формализовать.

5.2. Шаг 2. Картировать «как есть → как будет»

Подготовьте таблицу соответствия. Колонки: текущий тег или префикс, будущий домен, будущая команда-владелец, кандидаты в дата-продукты внутри домена. Этот документ является артефактом миграции. Согласуйте его со стюардами и руководителями бизнес-функций до начала технических действий.

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

5.3. Шаг 3. Завести домены поверх существующих структур

Создавайте домены и поддомены так же, как описано в разделе 4. Существующие теги и глоссарий не трогайте, поскольку они продолжают работать ортогонально. Не нужно «переводить» теги в домены: это разные сущности с разной семантикой.

Лайфхак, экономящий дни работы: сначала размечайте «верхние контейнеры» — сервисы, базы, схемы. Большая часть таблиц получит домен автоматически через наследование. Далее останется точечно доразметить объекты, которым нужна другая принадлежность. При этом прямое назначение имеет приоритет над унаследованным.

5.4. Шаг 4. Перевести ассеты в дата-продукты

Это самая трудоёмкая часть миграции. Подход последовательный, по одному домену за раз:

Выберите приоритетный домен. Хороший кандидат — «Менеджмент кадров»: он есть в любой компании, и эффект миграции виден буквально всем сотрудникам.
Определите 2−4 дата-продукта внутри домена. Для HR это типично «Сотрудник 360», «Воронка найма», «Контроль ПДн сотрудников», «HR-метрики».
Подвяжите к каждому продукту 4−6 ключевых объектов, к которым потребители уже фактически обращаются. Вместе с таблицами в гарантии продукта попадут и их тесты качества.
Подвяжите к каждому продукту 4−6 ключевых объектов, к которым потребители уже фактически обращаются. Вместе с таблицами в гарантии продукта попадут и их тесты качества.
Опубликуйте продукт во внутренних каналах компании. Зафиксируйте: теперь это «продукт», у него есть владелец и заявленные гарантии.
Через две недели соберите обратную связь. Сразу становится очевидно, помогло потребителям или нет.

5.5. Шаг 5. Не сломать существующее

Несколько правил, проверенных на миграциях больших каталогов:

Не отключайте старые теги, пока не убедились, что весь содержательный контент перенесён.
Не переименовывайте таблицы и не меняйте FQN, поскольку это сломает lineage и привязанные тесты.
Не назначайте «временных» владельцев без согласования. Лучше оставить поле пустым, чем создать ложную ответственность.
Документируйте процесс миграции в карточке домена через расширенные атрибуты. Через год это будет неоценимо.
Помните правила удаления: домен удаляется, только когда он пуст. Поэтому сначала придётся исключить поддомены, продукты и объекты; это защита от случайной потери структуры. Дата-продукт удаляется мягко, с возможностью восстановления — это безопасно (и его тоже нельзя удалить, пока в нём есть объекты).

5.6. Шаг 6. Развивать модель волнами

Расширенные атрибуты вводите волнами, а не пытайтесь придумать всё сразу:

Первая волна — минимум гарантий: SLA, частота обновления, этап жизненного цикла, потребители. Этого достаточно, чтобы потребитель понимал, чего ждать.

Вторая волна — коммуникация с потребителем: источники данных, уровень SLA (Gold/Silver/Bronze), уровень доступа, тип данных.

Третья волна — формализация: ссылка на документ дата-контракта, состояние lineage, регуляторные ссылки. Это уровень зрелости «Управляемый» по моделям зрелости управления данными.

Заключение

Домены и дата-продукты не являются просто «ещё одной сущностью в каталоге». Это переход к зрелой модели управления данными, где у каждого набора данных есть владелец, у каждой публикации есть заявленные гарантии, у каждой ответственности есть видимая зона. Каталог перестаёт быть энциклопедией объектов и становится картой ответственности и обязательств.

Для компании, которая разворачивает каталог с нуля, рецепт простой: 6–10 корневых доменов, в каждом 2–5 дата-продуктов, единый набор расширенных атрибутов, публикация для команды. Далее следуют итерации: развитие модели качества, постепенное подключение политик доступа, подготовка к контрактной модели.

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

Продолжение в статье «Пример внедрения доменов»

2026-06-25 17:00