MDM и справочники: владение сущностями и единые определения

Data Governance (DG) в современном Data Platform, включая DWH и Lakehouse, всё чаще опирается на концепцию Master Data Management (MDM) и управляемых справочников (reference data) и глоссариев. МDM отвечает на вопрос: как “один источник истины” держится за ключевые сущности предприятия — клиенты, поставщики, продукция, сотрудники, локации, контрагенты и т.д. Специалисты по DG создают единые определения и бизнес-глоссарии, которые затем внедряются в хранилища, каталоги данных и ETL/ELT-процессы.

Почему это критично в DWH/Lakehouse? Когда разные источники — 1С, ERP, CRM, файловые источники, IoT-приборами — приходят с разными атрибутами и кодами, риск “разноречивых” сущностей возрастает: дубли, расхождение в именовании, неконсистентность кодов, расхождение в атрибутах и единицах измерения. МDM и справочники позволяют:

определить владение (owners) и ответственности (stewards) за каждую сущность.
согласовать единые определения и форматы данных (canonical models).
создавать «золотой» мастер-объект (golden record), который служит единственным источником истины.
управлять качеством данных через валидаторы, правила преобразований и мониторинг.
поддерживать судебную трассируемость (data lineage) и прозрачность изменений для регуляторов и бизнеса.
синхронизировать справочники между операционной системой (оперативная обработка) и аналитической средой (DWH/Lakehouse).

Терминология на старте:

Master Data (мастер-данные): ключевые бизнес-сущности и их атрибуты, которые используются во многих системах.
Reference Data (справочные данные): предопределённые наборы кодов и констант (например, коды стран, единицы измерения, валюты).
Master Data Management (MDM): подходы к созданию, поддержанию и доставке «золотой» копии мастер-данных.
Golden Record: единый, очищенный и обновляемый мастер-объект, учитывающий консолидацию дубликатов.
Business Glossary / Taxonomy / Ontology: бизнес-глоссарий и структура терминов, синонимов и взаимосвязей, помогающие бизнесу и технике говорить на одном языке.
Steward / Owner: лица или роли, ответственные за качество, классификацию и актуализацию данных.

Эта глава объясняет, как внедрить MDM и справочники в архитектуру DG для DWH, Lakehouse и общей Data Platform, как выстроить процессы владения и поддержки, какие практические решения можно применить на практике и какие риски стоят на пути.

Архитектура MDM и справочников в DG

Центральный узел владения (MDM Hub)

Центральное хранилище для «золотого» мастера данных по определённой доменной области (например, клиенты, товары).
Интегрируется с источниками (OLTP-системами, файловыми存), системами каталога и аналитическими слоями.
Обеспечивает консолидацию дубликатов и survivorship (когда несколько версий мастера объединяются в одну).

Локальные источники и «плавающие» справочники

Опротестируемые источники, которые держат доп. атрибуты и кодировку в конкретном контексте.
Могут синхронизироваться с MDM Hub через конвейеры интеграции (ETL/ELT).

Глоссарий и бизнес-слой

Business Glossary: общепринятые термины, определения, связи, синонимы.
Связи Glossary-Terms с сущностями и атрибутивными данными в хранилищах.
Обеспечивает единый бизнес-язык между аналитикой и операционкой.

Metadata и Data Lineage

Метаданные об источниках, трансформациях и зависимостях.
Линия данных (lineage) отслеживает, как мастер-данные проходят через конвейеры, какие правила применяются и кто изменял данные.

Управление качеством данных

Валидации на входе и в процессе синхронизации.
Очистка и нормализация атрибутов (единицы измерения, форматы дат, коды стран и валидные значения).
Мониторинг и алерты.

Безопасность и соответствие требованиям

Ролевой доступ, сегментация по доменам.
Журналы изменений, аудит и соответствие регуляторным требованиям (например, локализация данных, обработка персональных данных).

Подходы к реализации MDM

Централизованный MDM: единый источник истины в Hub. Все данные проходят через центр, который обеспечивает консолидацию и качество. Минусы: высокая нагрузка на интеграционные слои и сложная миграция.
Регистровый (Registry) MDM: хранение указателей на «золотые» записи в разных системах; широко применяется, когда хотят сохранять локальные копии и синхронизировать их периодически.
Гибридный/глобальный MDM: комбинация централизованного и реестр-ориентированного подходов. Часто встречается в крупных холдингах и в индустриях с разной скоростью изменений.

Управление сущностями и владение

Владелец (Owner): роль или человек, ответственный за формализацию бизнес-определений, корректность домена, принятие изменений.
Наставник данных (Data Steward): исполнитель по качеству, правилам и атрибутам; поддерживает справочники и глоссарий.
RACI-модель для DG и MDM: кто отвечает, кто отвечает за информирование, кто консультирует и кто информирует.

Единые определения и словари

Бизнес-глоссарий должен содержать:

определение термина (например, “Клиент”),
атрибуты справочника (коды, названия, локализация),
правила согласования и допустимые значения,
связи с другими терминами (синонимы, родственные связи).

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

Методы обеспечения качества и соответствия

Правила единиц измерения, форматов дат, нормализации имен и кодировок.
Правила дедупликации и сопоставления (match rules) для Survivorship.
Процедуры аудита изменений и сохранение истории.

Связь с другими доменами

Продукты и товары (PIM vs MDM): часто нужен отдельный домен справочников для продукции, который тесно взаимодействует с MDM клиентов и поставщиков.
География и организация: коды стран, подразделений, регионов — классические примеры справочников.
Финансовые атрибуты: валюты, единицы измерения, учетные политики — справочники, используемые во многих системах.

Практические примеры

Ниже приведены примеры, как можно реализовать части MDM и справочников на практике, включая open-source решения и российскую специфику.

Пример 1: Архитектура на базе Apache Atlas и Amundsen (open-source)

Что делаем:

Atlas выступает как метаданные и глоссарий (термины, определения, типы объектов).
Amundsen — каталог данных с фокусом на обнаружение и доступ к данным, включает интеграцию glossaries, теги и связь с таблицами.

Как это устроено:

Atlas хранит бизнес-глоссарий, определяет типы сущностей (например, Customer, Product) и условия их атрибутов.
Amundsen связывает таблицы и их колонки с терминами глоссария, обеспечивает поиск и навигацию.
Механизм синхронизации поддерживает соответствие между Atlas и Amundsen через REST/SDK.

Пример конфигурации и кода: Atlas: определение типа сущности и атрибутов (JSON-описание)

Типы можно определить как Глоссарий и сущности (EntityDefinition) в Atlas.

Пример REST-запроса к Atlas для создания термина:

  curl -u admin:admin -X POST -H "Content-Type: application/json" \
  -d '{ "typeName": "GlossaryTerm", "attributes": {"name": "Клиент", "description": "Универсальный клиент организации", "termSource": "BUSINESS"} }' \
  http://atlas-host:31000/api/atlas/v2/entity

Пример запроса Amundsen для привязки таблицы (файла) к термину GlossaryTerm в Atlas через сервис синхронизации.

Что получаем:

Единый бизнес-термин и связь с данными в каталоге.
Возможность поиска по терминам и контексту (кто владелец, какие атрибуты, источник).

Технические детали:

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

Пример 2: Open Metadata и Egeria (open-source)

Что делаем:

Egeria — открытая платформа управления метаданными (Open Metadata) с моделями Glossary, Metadata, Asset, Connection, Port и т. д.
Реализация «правил» и жизненного цикла мастер-данных через Open Metadata и собственные сервисы.

Пример кода (Python) для создания Glossary и Terms в Egeria:

- from eagleeye.open_metadata import OpenMetadata
# Предположим, что у вас запущен сервер Open Metadata
metadata = OpenMetadata(host='http://localhost:8080')
glossary = metadata.create_glossary('MDM_Business', description='Главный бизнес-глоссарий')
term_customer = metadata.create_glossary_term(glossary.id, name='Клиент', description='Лицо, получающее услуги', synonyms=['Клиент-ежедневник'])

Как использовать:

Создать термины и связи с сущностями (например, таблицей customers в Postgres или микросервисами).
Связать Term с Asset (например, таблицей customers) для облегчения поиска и управления.

Что получаем:

Единый набор терминов и их связь с активами в инфраструктуре.
Возможности для бизнес-пользователя и аналитиков работать с терминами и их определениями в едином формате.

Пример 3: Мастер-данные на базе российского контекста через 1С и интеграцию с DWH

Российская специфика нередко требует тесной интеграции с 1С и локальными ERP-системами. Реализация MDM в РФ часто строится на базе открытых инструментов с локализацией и адаптациями под регуляторные требования, а также активной интеграцией с 1С.

Что можно сделать на практике:

1С как источник мастера для клиентов и номенклатуры, где атрибуты могут иметь специфическую форматировку, коды и локализацию.
Интеграция 1С с хранилищем Master Data через конвейеры ELT (например, на базе Airbyte или собственных коннекторов).
В DWH или Lakehouse хранение «золотого» клиента и продуктов, объединённых с данными из 1С и CRM.
В глоссарий включаются термины, связанные с российскими регуляторами, локализацией и формами документов.

Пример схемы:

Источники: 1С:ERP, CRM-система, файл CSV с планами продаж.
MDM Hub: Golden Customer (ID, name, region, OKPO, ИНН, локации).
Справочники: RegionCode, CurrencyCode, ProductCode.
Аналитика: агрегированные таблицы по клиентам, их сегментация и т. д.

Технические детали:

Архитектура синхронизации может быть реализована через ELT-пайплайн (например, dbt + SQL-передачи) для обработки чистки и нормализации, интеграции с 1С через адаптеры и коннекторы.
Влияние на безопасность: ограничения по доступу к данным клиентов, соответствие локальным законам (например, ФЗ-152 о персональных данных).

Модели данных и канонический слой

Каноническая модель: единый набор атрибутов для конкретной доменной области (например, клиент — customer_id, name, legal_entity, region, source_system, etag, valid_from, valid_to).
Surviving (Survivorship) правила: выбрать «лучшую» запись из нескольких версий по набору критериев (например, доверие к источнику, дату последнего обновления, полноту атрибутов).
Сопоставление (matching): правила сопоставления записей из разных источников по набору атрибутов (например, name+address+ИНН).
История изменений: хранение временных штампов и версионирование атрибутов для отслеживания изменений.

Таблицы и хранилища

Master data hub (MDM): таблицы/объекты для мастер-данных.
Staging/landing: временные слои для подготовки данные к консолидированию.
Reference data: справочники, содержащие коды, допустимые значения и локализацию.
Data catalog and lineage: хранение зависимости между сущностями, источниками и конвертациями.

Безопасность и доступ

Ролевой доступ и политика на уровне доменов (DWH, слои обработки).
Аудит и журнал изменений.
Защита персональных данных: минимизация доступа, защита и шифрование по данным.

Инструменты и практическая настройка

Open-source: Atlas, Amundsen, Egeria — для метаданных, глоссариев и управления линейной связью.
Russian context: интеграционные коннекторы к 1С и ERP, локальные инструментальные средства мониторинга качества и аудит изменений, адаптации под локальные регуляторные требования.
ETL/ELT: использование современных движков (Airflow, Dagster, dbt) для конвейеров миграции мастера и справочников, демонстрирующих согласование между источниками и целевыми системами.

Примеры кода и конфигурации

Пример SQL-диапазона для сопоставления клиентов и создание золотой записи:

  -- Таблица staging_clients: raw_client_id, raw_name, raw_inn, raw_region, source_system
  -- Таблица mdm_clients: client_id, canonical_name, inn, region_code, source_record_id, is_active, last_updated

  WITH ranked AS (
    SELECT raw_client_id, raw_name, raw_inn, raw_region,
           ROW_NUMBER() OVER (PARTITION BY raw_inn ORDER BY last_updated DESC) AS rn
    FROM staging_clients
  )
  INSERT INTO mdm_clients (client_id, canonical_name, inn, region_code, source_record_id, is_active, last_updated)
  SELECT CONCAT('CUST_', raw_inn),
         CASE WHEN raw_name IS NULL THEN 'Unknown' ELSE raw_name END,
         raw_inn,
         raw_region,
         raw_client_id,
         TRUE,
         CURRENT_TIMESTAMP
  FROM ranked
  WHERE rn = 1;

Пример использования REST API Atlas для регистрации золотой записи:

  curl -X POST -u admin:admin -H "Content-Type: application/json" \
  -d '{"entity": {"typeName": "Customer", "attributes": {"name": "ООО Ромашка", "inn": "1234567890", "region": "RU-MO"}}}' \
  http://atlas-host:31000/api/atlas/v2/entity

Пример Python-кода для создания GlossaryTerm в Egeria:

  from open_metadata.api_client import OpenMetadata
  client = OpenMetadata(host="http://localhost:8080")
  glossary = client.create('glossary', {'name': 'MDM_Business', 'description': 'Глоссарий бизнес-терминов'})
  term = client.create('glossary_term', {'glossary_id': glossary['id'], 'name': 'Клиент', 'description': 'Лицо, получающее услуги'})

Эти примеры показывают, как начать формировать единый язык и «золотые» записи в рамках вашего DG-подхода.

Риски и ограничения внедрения

Сложность овладения доменной областью: бизнес-термины часто варьируются по подразделениям, поэтому требуется синхронизация между бизнес- и ИТ-слоями.
Разногласия по владению и ответственности: без четкой RACI-модели диагностика процессов может тормозиться.
Стоимость и инфраструктура: внедрение MDM и справочников требует ресурсов на ETL/ELT, хранение, мониторинг и сопровождение.
Модели данных и эволюция: каноническая модель может устаревать, требуя изменений в процессе и системах.
Интеграция с 1С и локальными системами: частое появление специфических атрибутов, форматов и кодировок может потребовать адаптаций и миграций.
Регуляторные ограничения: локализация данных, хранение и обработка персональных данных, требования к аудиту и хранению истории.

Особые риски в российском контексте:

Локализация и регуляторика: требования к хранению персональных данных на территории РФ, ограничение передачи данных за пределы страны, аудит и контроль доступа.
Внедрение на базе отечественных сервисов: часто требуют адаптации сторонних инструментов под российские политики безопасности и интеграцию с 1С.
Облачная зависимость: при работе с облачными решениями важно учитывать законодательно ограниченное использование личных данных и требования к хранению.

Минимизация рисков:

Этапная реализация: начинать с основного домена (например, Customer) и закрепить управляемость и доверие.
Четкая роль владения и процесса управления качеством: регулярные ревью глоссариев и правил.
Контроль доступа и аудит: внедрение политики доступа, логирования изменений и мониторинга.
Инфраструктура и устойчивость: резервирование, мониторинг задержек, план восстановления.

Выводы

MDM и справочники — краеугольный камень качественной DG в DWH, Lakehouse и Data Platform. Они позволяют бизнесу и IT говорить на одном языке, обеспечивают «один источник истины» для ключевых сущностей и единых определений.
Архитектура DG должна поддерживать модулярность: MDM Hub, справочники, глоссарий и линейку метаданных.
Open-source решения (Apache Atlas, Amundsen, Egeria) дают сильный старт для реализации глоссариев и метаданных, легко расширяются под конкретные домены.
Российские условия требуют интеграции с локальными источниками (1С, ERP) и адаптации под регуляторику, а также внимания к локализации, безопасности и управлению доступом.
Внедрение MDM — это путь: от планирования категорий и владельцев к построению золотой копии мастер-данных, интеграции с конвейерами обработки и формированию устойчивого глоссария бизнес-терминов.

FAQ (Вопрос–Ответ)

1) Что такое Golden Record и зачем он нужен в DG?

- Golden Record — это единая, очищенная и согласованная версия мастер-данных, которая служит источником истины для аналитики и операционных систем. Он нужен для устранения дубликатов, консолидации противоречивых атрибутов и обеспечения единых правил для бизнес-логики. В DG это поддерживает согласованность процессов, улучшает качество отчётности и упрощает соответствие регуляторным нормам.

2) Каковы ключевые роли в DG и MDM?

Владелец (Owner) за домен: отвечает за стратегию и согласование изменений.
Стюард данных (Data Steward): обеспечивает качество, правила и атрибуты домена.
Аналитики и архитекторы: создают модели, глоссарии и метаданные, проводят анализ соответствия.
Инженеры данных: реализуют конвейеры, интеграцию и загрузку в MDM Hub и справочники.

3) Какие источники данных наиболее рискованны для MASTER данных?

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

4) Как начать внедрение MDM в нашей компании?

Определите домены мастера (например, Клиент, Продукт, Постачальник).
Назначьте владельцев и стюардов для каждого домена.
Выберите базовую архитектуру (централизованный или гибридный подход).
Включите глоссарий и каноническую модель, запустите пилот на одной доменной области.
Постепенно расширяйте до остальных доменов и интегрируйте с источниками данных и ML/анализом.

5) Какой функционал чаще всего нужен в Open-Source-решениях для MDM?

- Глоссарий и термины, управление моделями сущностей, сопоставления и дедупликацию, линейка метаданных, аудит изменений, API для интеграций и поддержка стандартов (OGC, JSON-LD и пр.).

6) Какие примеры российских решений можно применить для РФ?

- В РФ часто применяется интеграция с 1С и локальными ERP/CRM. Реализация может быть на базе Open-Source инструментов с локализацией и адаптацией под регуляторику и требования по локализации данных. Важно сочетать открытые платформы метаданных с локальными адаптациями и интеграцией с 1С.

7) Какие риски наиболее критичны на старте проекта по MDM?

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

8) Какова роль глоссария в MDM?

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

9) В чем различие между Reference Data и Master Data?

- Reference Data — предопределённые наборы кодов/значений (например, коды стран, валюты). Master Data — ключевые бизнес-сущности (клиенты, товары, контрагенты), которые используются в рамках процессов и аналитики по всей организации.

10) Какие шаги стоит включать в стратегию DG при внедрении MDM?

- Определение доменов мастера и владельцев, формирование бизнес-глоссария, выбор архитектуры, настройка MDM Hub, создание канонических моделей, построение pipelines ETL/ELT, интеграция с каталогами и требования к безопасности, мониторинг качества и обучение персонала.

← Предыдущая статья

Управление доступом и безопасность: IAM, RBAC, ABAC, приватность

Следующая статья →

Управление данными по жизненному циклу: создание, хранение, архивирование, удаление