Хранилища и архитектура данных
MDM — управление мастер-данными
Создаю единый достоверный источник справочных данных (клиенты, товары, контрагенты) — без дублей и расхождений между CRM, 1С и другими системами.
Что такое Master Data Management
Master Data Management (MDM, управление мастер-данными) создаёт единое достоверное представление ключевых сущностей бизнеса — клиентов, товаров, контрагентов, — когда одна и та же сущность по-разному записана в CRM, ERP, 1С и других системах. Результат — «золотая запись» (golden record): эталонный профиль каждой сущности, который формируется за счёт сопоставления (matching), дедупликации и правил консолидации данных из разных источников.
Что входит
Аудит и профилирование
Анализирую системы-источники, оцениваю качество данных, выявляю дубли, конфликты и пробелы. Это фундамент для модели и правил matching.
Модель мастер-данных
Определяю домены (клиенты, товары, поставщики, контрагенты), структуру «золотой записи» (golden record) и иерархии связей.
Правила качества и матчинга
Настраиваю нормализацию, дедупликацию, алгоритмы сопоставления и слияния записей (matching & merging) и правила консолидации (survivorship).
Data governance
Ввожу роли и владельцев данных (data stewards), регламенты, политики и процессы согласования изменений мастер-данных.
Интеграция и синхронизация
Подключаю системы-источники и потребителей через ETL/ELT, API и шину данных, настраиваю регулярную синхронизацию.
Миграция, запуск и поддержка
Провожу первичную загрузку с очисткой, тестирование и обучение пользователей, готовлю документацию и сопровождаю решение после запуска.
Как идёт работа
- 01
Стратегия и оценка
Фиксируем бизнес-цели, выбираем приоритетные домены (клиенты, товары, контрагенты), оцениваю зрелость данных и обосновываю проект.
- 02
Аудит и профилирование
Обследую источники, профилирую данные, оцениваю текущее качество и масштаб дублей. Фиксирую проблемные зоны и конфликты.
- 03
Проектирование
Проектирую модель данных и архитектуру, выбираю стиль MDM (registry / consolidation / coexistence / centralized), задаю правила качества, матчинга и модель governance.
- 04
Интеграция и загрузка
Подключаю источники через Airbyte и гружу сырые данные в staging-слой. При необходимости нормализую отдельным слоем трансформаций (dbt/Python) перед сопоставлением.
- 05
Матчинг, дедупликация, золотые записи
Настраиваю сопоставление и дедупликацию в Zingg (ML с активным обучением), формирую золотые записи в PostgreSQL и identity-граф в Neo4j, каталогизирую хранилище в OpenMetadata.
- 06
Тестирование и пилот
Проверяю решение на ограниченном объёме, контролирую корректность золотых записей, подключаю интерфейс стюарда с обратной связью в Zingg.
- 07
Запуск и эксплуатация
Вывожу в промышленную эксплуатацию с обучением пользователей. Дальше — мониторинг качества и governance как постоянный процесс, а не разовый проект.
Пример архитектуры кастомного MDM-решения
Схема показывает вертикальный конвейер от систем-источников к мастер-хранилищу: загрузка, сопоставление и консолидация в золотую запись. MDM раскладывается на функциональные слои — загрузка, сопоставление, хранение, каталог и стюардшип, — и под каждый есть проверенный open-source-инструмент. Стек разворачивается в инфраструктуре заказчика; сплошные стрелки — поток данных, пунктир — метаданные и обратная связь стюарда.
Системы-источники
CRM, ERP, интернет-магазин, служба поддержки и другие системы, где одни и те же клиенты, товары и контрагенты хранятся разрозненно, с дублями и расхождениями. Это вход конвейера.
Airbyte
Извлекает и загружает (EL) сырые данные из источников в staging-слой через готовые и кастомные коннекторы. Отвечает за доставку данных, не выполняя сопоставление; нормализация и приведение к общей схеме идут отдельным слоем трансформаций (dbt/Python).
Zingg
Ядро entity resolution: блокинг, сопоставление (matching) и кластеризация записей на основе ML с активным обучением. Zingg сам отбирает информативные спорные пары для разметки, а по небольшому числу примеров склеивает записи в единые сущности и присваивает общий идентификатор (ZINGG_ID).
PostgreSQL — золотые записи
Операционный источник правды: хранит золотые записи и crosswalk (какая исходная запись какому golden-ID соответствует) и отдаёт мастер-данные системам-потребителям через API. Транзакционность (ACID) и целостность из коробки; версионирование и аудит — на уровне схемы (history-таблицы).
Neo4j — identity-граф
Граф тождественности: исходные записи и мастер-сущность как узлы, сопоставления и связи как рёбра. Хранит домохозяйства и иерархии вида «компания → дочерние → контакты» — то, что неудобно и дорого обходить в SQL, — и даёт цельный профиль сущности (360°).
OpenMetadata
Не хранит сами мастер-данные, а каталогизирует обе базы: lineage от источника до золотой записи, бизнес-глоссарий, владельцев, классификацию PII и метрики качества. Контекст, прослеживаемость и governance вокруг ядра MDM.
Интерфейс стюарда
Ревью спорных совпадений, ручное слияние/расщепление кластеров и переопределение правил survivorship. Готового open-source здесь почти нет — слой строится кастомно (BPM-движок вроде Camunda плюс свой фронтенд); решения стюарда возвращаются в Zingg и дообучают сопоставление (human-in-the-loop).
Реализованные проекты
Аналитическая платформа для диджитал-агентства YA AGENCY
Аналитическое хранилище данных и дашборды для Ash
Сквозная аналитика и миграция инфраструктуры для WiseAdvice-IT
Аналитическое хранилище данных для сети баров и ресторанов
Аналитическое хранилище для сети ломбардов Неоломбард
Единое хранилище данных и дашборды для сервиса доставки «Едостав»
Хранилище данных для финансово-аналитического проекта VISUALSECTORS
Миграция данных в ClickHouse и пересборка дашбордов для «МногоСна»
Технологии
Airbyte 
dbt 
Zingg 
Splink 
Neo4j 
OpenMetadata Клиенты
Благодарственные письма
Отзывы с бирж услуг
Когда один и тот же клиент или товар по-разному записан в CRM, 1С, ERP и других системах, страдает всё — от точности отчётности до качества коммуникаций с клиентами. Я создаю единый достоверный источник справочных данных: собираю записи из всех систем, сопоставляю и дедуплицирую их, формирую золотую запись и identity-граф, а каталог и интерфейс стюарда обеспечивают качество и контроль. Решение строится на open-source-стеке и разворачивается в вашей инфраструктуре — без дублей, расхождений и зависимости от дорогих лицензий.
Обсудим вашу задачу?
FAQ
Чем MDM отличается от обычного хранилища или CRM? +
Хранилище собирает данные, но не разрешает противоречия: один клиент остаётся в нём в виде нескольких разных записей из разных систем. CRM хранит данные одной системы и не знает, что тот же клиент уже есть в ERP или биллинге. MDM решает именно это: сопоставляет записи между системами, склеивает дубли и формирует единую золотую запись, на которую опираются и хранилище, и CRM.
Обязателен ли облачный MDM-продукт или можно на open-source? +
Нет, дорогой облачный продукт не обязателен. Я собираю кастомное MDM на проверенном open-source-стеке — Airbyte, dbt, Zingg, PostgreSQL, Neo4j, OpenMetadata — и разворачиваю его в вашей инфраструктуре. Это полный контроль над данными, без лицензионных платежей за пользователя и с гибкой настройкой под вашу отраслевую специфику.
Зачем в архитектуре две базы — PostgreSQL и Neo4j? +
PostgreSQL — операционный источник правды: хранит золотые записи и crosswalk (какая исходная запись какому golden-ID соответствует) и отдаёт мастер-данные системам-потребителям через API. Neo4j хранит identity-граф — связи между записями, домохозяйства и иерархии «компания → дочерние → контакты», которые неудобно и дорого обходить в SQL. Вместе они дают и быстрый доступ к эталону, и гибкую навигацию по связям.
Как matching работает с неточными данными? +
Сопоставление бывает детерминированным — по точным ключам и правилам — и вероятностным (fuzzy), которое находит совпадения даже при опечатках, разном написании и неполных полях. Zingg использует ML с активным обучением: система сама отбирает спорные пары и предлагает их на разметку «совпадает / не совпадает», и по небольшому числу размеченных примеров модель учится сопоставлять записи именно на ваших данных. Спорные случаи уходят на ручное решение стюарда, а не сливаются вслепую.
Сколько времени занимает внедрение? +
Базовое решение по одному домену — например, клиенты — с интеграцией нескольких источников и первыми золотыми записями обычно занимает от нескольких недель. Точные сроки зависят от числа источников, качества и объёма данных, сложности правил matching. На обследовании я оцениваю объём работ конкретно под вашу задачу.
Что с безопасностью и персональными данными (PII)? +
Всё решение разворачивается в вашей инфраструктуре — данные не покидают её периметр. OpenMetadata автоматически классифицирует чувствительные поля (email, телефон, документы) и хранит lineage — видно, откуда пришёл каждый атрибут и куда уходят мастер-данные, что важно для аудита и соответствия требованиям (152-ФЗ, GDPR). Доступ разграничивается по ролям.
Как поддерживается качество данных после запуска? +
Качество держится на трёх вещах. OpenMetadata по расписанию прогоняет проверки качества и профилирование, сигнализируя о деградации на входе. Стюард через свой интерфейс разбирает спорные совпадения и исправляет ошибки автоматики, а его решения возвращаются в Zingg и дообучают сопоставление (matching). Плюс я сопровождаю решение, подключаю новые источники и домены по мере роста бизнеса.