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

Reference Data (справочные данные) — подмножество мастер-данных: коды стран (RU, US, DE), валюты (RUB, USD, EUR), категории продуктов. Governance reference data — часть MDM-дисциплины.

Четыре архитектурных паттерна MDM

Выбор архитектуры MDM — одно из ключевых решений governance-программы. DMBOK2 описывает 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 справочных данных

1. Единый владелец — один Data Steward на каждый справочник
2. Канонический формат — ISO 3166-1 alpha-2 для стран (RU), ISO 4217 для валют (RUB)
3. Версионирование — каждое изменение имеет версию и дату
4. Change management — добавление нового значения требует одобрения владельца
5. Распространение — все системы получают обновления из единого источника

В этом модуле вы встретите код-челлендж 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: 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.