Master Data Management (MDM)
Введение
Сценарий: DataTech Solutions (ДатаТех Солюшенз)
VP Engineering открывает отчёт по качеству данных: 15% клиентских записей — дубликаты. Клиент ID 12345 имеет 3 разных адреса в 3 системах: CRM хранит полный адрес, billing — только город, web analytics — null. VP спрашивает: “Почему один и тот же клиент выглядит по-разному в каждой системе?”
Ответ на этот вопрос — Master Data Management (управление мастер-данными), одна из ключевых knowledge areas DMBOK2 (DAMA-DMBOK2, ISBN 978-5-9693-0404-8). В уроке 04 мы определили домены данных и владение, в уроке 06 — политики и enforcement. Теперь рассмотрим governance-процессы для особого типа данных, который пересекает все домены.
Определение и область применения MDM
Master Data (мастер-данные) — это данные, описывающие ключевые бизнес-сущности: клиенты, продукты, поставщики, локации, сотрудники. В отличие от транзакционных данных (заказы, платежи, логи), мастер-данные:
- Не привязаны к событию — клиент существует независимо от заказов
- Используются множеством систем — CRM, billing, analytics, marketing
- Меняются медленно — адрес клиента меняется реже, чем появляются заказы
- Критичны для согласованности — один клиент = один golden record
| Тип данных | Примеры | Характер изменений | Количество систем |
|---|---|---|---|
| Master Data | Клиенты, Продукты, Поставщики, Локации | Медленные, редкие | 3-10+ |
| Reference Data | Коды стран, валют, категорий | Очень медленные | 5-20+ |
| Transactional Data | Заказы, Платежи, Логи | Постоянные, высокочастотные | 1-3 |
Reference Data (справочные данные) — подмножество мастер-данных: коды стран (RU, US, DE), валюты (RUB, USD, EUR), категории продуктов. Governance reference data — часть MDM-дисциплины.
Четыре архитектурных паттерна MDM
Выбор архитектуры MDM — одно из ключевых решений governance-программы. DMBOK2 описывает 4 паттерна:
Сложность внедрения (20%) | Качество данных (27%) | Инвазивность (20%) | Единая версия правды (33%) | Итого | |
|---|---|---|---|---|---|
| Registry | 4 | 2 | 5 | 2 | 3.0 |
| Consolidation | 3 | 4 | 3 | 4 | 3.6 |
| Coexistence | 2 | 4 | 2 | 4 | 3.2 |
| Centralized (Hub) | 1 | 5 | 1 | 5 | 3.4 |
Registry (Реестровый паттерн)
Принцип: создать перекрёстный индекс (cross-reference) между ID клиентов в разных системах, не перемещая данные. CRM ID 12345 = Billing ID A-789 = Web ID usr_abc.
Когда использовать: Level 1-2 организации, ограниченные ресурсы, нужна видимость без изменений.
DataTech рекомендация: Registry — стартовый паттерн. Не требует изменений в CRM, billing, web. Даёт ответ на вопрос VP Engineering: “ID 12345 = A-789 = usr_abc”.
Consolidation (Консолидация)
Принцип: данные из всех источников копируются в MDM-хаб, где создаётся golden record — единая каноническая версия. Хаб доступен аналитике и BI, но источники продолжают работать автономно.
Когда использовать: Level 2-3, потребность в аналитике на golden records, нет необходимости обновлять источники.
Coexistence (Сосуществование)
Принцип: golden records в MDM-хабе синхронизируются обратно в источники. Изменения в хабе обновляют CRM; изменения в CRM обновляют хаб.
Когда использовать: Level 3+, legacy + microservices, потребность в согласованности operational систем.
FinSecure Bank (ФинСекьюр Банк)
FinSecure (Level 3, 2000+ сотрудников) имеет Oracle (800+ таблиц core banking) + 15 микросервисов на PostgreSQL. Для клиентских данных FinSecure выбрала Coexistence: golden record в MDM-хабе синхронизируется с Oracle и микросервисами. Это единственный паттерн, обеспечивающий согласованность в гибридной архитектуре без полной миграции на centralized hub.
Centralized / Hub (Централизованный хаб)
Принцип: MDM-хаб — единственное место, где создаются и редактируются мастер-данные. Все системы читают из хаба.
Когда использовать: Level 4-5, greenfield проекты, полный контроль над архитектурой. Максимальное качество, максимальная инвазивность.
Эволюция паттерна
Типичная эволюция для DataTech: Registry (Level 1) -> Consolidation (Level 2) -> Coexistence (Level 3). Не нужно начинать с Centralized Hub — это антипаттерн для организаций без зрелых governance-процессов.
Governance справочных данных
Reference Data (справочные данные) — коды стран, валют, категорий — используются всеми системами DataTech. Без governance каждая команда ведёт свои справочники:
- CRM:
Russia,Russian Federation,RU,RUS - Billing:
Россия,643(ISO numeric) - Web:
ru,ru-RU
Результат: joins не работают, аналитика показывает 6 “разных стран” вместо одной.
Принципы governance справочных данных
- Единый владелец — один Data Steward на каждый справочник
- Канонический формат — ISO 3166-1 alpha-2 для стран (
RU), ISO 4217 для валют (RUB) - Версионирование — каждое изменение имеет версию и дату
- Change management — добавление нового значения требует одобрения владельца
- Распространение — все системы получают обновления из единого источника
В этом модуле вы встретите код-челлендж CC-47 (MDM Reference Data Validator): JSON-задание, в котором нужно создать конфигурацию governance справочных данных с массивом reference_lists, владельцами и версионированием.
Жизненный цикл Golden Record
Golden record — не одноразовая операция, а непрерывный процесс из 5 этапов:
DataTech: от дубликатов к golden record
Identify: DataTech сканирует CRM, billing, web — находит 3 записи для Иванова И.П.:
- CRM:
{name: "Иванов Иван Петрович", email: "[email protected]", address: "Москва, ул. Тверская, д. 10, кв. 5"} - Billing:
{name: "Иванов И.П.", email: "[email protected]", address: "Москва"} - Web:
{name: "ivanov_ivan", email: "[email protected]", address: null}
Match: Алгоритм определяет, что все 3 записи — один клиент (совпадение email-домена, фамилии, телефона).
Merge: Применяются survivorship rules (правила выживания) — какое значение каждого поля “выживает” в golden record.
Publish: Golden record становится доступен всем системам через Registry/Consolidation/Coexistence.
Maintain: Мониторинг новых дубликатов, обновление golden records при изменениях в источниках.
Правила выживания (Survivorship Rules)
Survivorship rules определяют, какое значение каждого поля “побеждает” при создании golden record. Основные стратегии:
| Стратегия | Принцип | Пример DataTech |
|---|---|---|
| Source Priority | Доверяем источнику с наивысшим приоритетом | name: CRM > billing > web |
| Most Recent | Берём самое свежее значение по timestamp | email: последний обновлённый |
| Most Complete | Берём самое полное значение (highest completeness_score) | address: полный адрес из CRM |
| First Non-Null | Берём первое непустое значение по приоритету | phone: первый non-null по source priority |
| Custom Business Rule | Специфичная логика для домена | tax_id: только из billing (авторитетный источник) |
DataTech: survivorship rules для клиента
Поле: customer_name
Правило: Source Priority (CRM > billing > web)
CRM: "Иванов Иван Петрович" <-- ВЫБРАНО (CRM = highest priority)
billing: "Иванов И.П."
web: "ivanov_ivan"
Поле: email
Правило: Most Recent (по timestamp)
CRM (2025-11-15): "[email protected]"
billing (2026-02-15): "[email protected]" <-- ВЫБРАНО (самый свежий)
web (2026-01-10): "[email protected]"
Поле: address
Правило: Most Complete (highest completeness_score)
CRM (0.85): "Москва, ул. Тверская, д. 10, кв. 5" <-- ВЫБРАНО (самый полный)
billing (0.60): "Москва"
web (0.40): nullВ этом модуле вы встретите код-челлендж CC-46 (MDM Golden Record Builder): Python-задание, в котором нужно реализовать survivorship rules и создать golden record из 5 записей.
MDM-зрелость
MDM-процессы развиваются вместе с общей зрелостью governance:
DataTech находится на Level 1 (ad-hoc): 15% дубликатов, нет процесса дедупликации. Roadmap: Level 1 -> Level 2 (Registry + ручная дедупликация) -> Level 3 (Consolidation + автоматический matching). Путь к Level 2 описан в уроке 05 (бизнес-кейс и оценка зрелости).
Итоги
- Master Data (мастер-данные) — клиенты, продукты, поставщики — ключевые бизнес-сущности, пересекающие все домены
- Reference Data (справочные данные) — коды стран, валют, категорий — подмножество мастер-данных, требующее единого владельца и канонического формата
- 4 архитектурных паттерна MDM: Registry (индекс), Consolidation (golden record для аналитики), Coexistence (двусторонняя синхронизация), Centralized Hub (единый system of record)
- Golden record lifecycle: Identify -> Match -> Merge -> Publish -> Maintain
- Survivorship rules определяют, какое значение “выживает”: source priority, most recent, most complete, first non-null
- MDM — не дедупликация, а governance-дисциплина: процессы, роли, правила, мониторинг
В этом уроке мы изучили MDM как governance-дисциплину. MDM формализует процессы, которые DataTech ранее выполняла ad-hoc. Модуль M01 завершён: от определения governance (урок 01) через DMBOK-фреймворки (02), организационные роли (03), домены данных (04), бизнес-кейс (05), политики (06) до управления мастер-данными (07). В следующем модуле мы перейдём к Архитектуре и Моделированию Данных — техническому фундаменту любой программы governance.