Единая версия мастер-данных для десятков корпоративных систем
Ольга Куликова, руководитель проектов компании DBI, рассказывает об опыте создания MDM-сервиса для крупной российской авиакомпании и задачах, которые пришлось решить при формировании единой версии данных.
Одни и те же сведения могут использоваться сразу в нескольких корпоративных системах. Будь то информация о клиенте, номенклатура сырья и комплектующих, расписания рейсов или каталоги товаров. Каждая из систем использует эти данные в своих целях, пользователи редактируют их по собственным правилам, а затем информация может передаваться дальше. Но что происходит, когда источники присылают разные значения или изменение уже получено, хотя действовать оно должно только через неделю?
С такими вопросами приходится работать при развитии централизованной системы управления мастер-данными. В одном из проектов для крупной российской авиакомпании перед нами стояла задача создать сервис для управления продуктами и услугами компании, который на данный момент содержит данные более чем 150 справочников. Информация поступает приблизительно из 30 систем-источников, а результат используют более 20 систем-потребителей. Самый крупный справочник содержит свыше 350 тысяч записей и объединяет данные из четырех источников.
При таком количестве участников недостаточно собрать информацию в одном хранилище и настроить интеграции. Необходимо определить, каким образом из поступивших данных сформировать эталонную запись, какие изменения считать актуальными и в каком виде передавать информацию потребителям.
От исходных данных к эталонной записи
Путь данных начинается с источников, информация из которых поступает в первичные справочники. Это первое понятие, которое я хочу ввести. Первичные справочники содержат данные, полученные из источников без изменений или с минимальными преобразованиями. Мы забираем их практически в том виде, в каком они хранятся в исходных системах.
Первая сложность возникает еще до выбора итоговых значений. Разные системы могут хранить сведения об одном объекте в разных моделях данных: использовать собственные названия атрибутов и передавать неодинаковый набор полей. Поэтому для каждого сценария необходимо определить соответствие между атрибутами источников и эталонного справочника. Это уже второе понятие: эталонный справочник содержит данные, которые считаются единственно верными.
К тому же один эталонный справочник может формироваться из данных нескольких источников. Пока наш максимум — четыре источника, но все впереди. Нужно решить, какие значения должны попасть в эталонную запись. Если несколько источников передают значения одного и того же атрибута, их данные не обязательно совпадают (чаще всего не совпадают). Для формирования итогового результата используются приоритеты источников и политики обработки.
При этом единый приоритет для всего справочника подходит не всегда. Разные системы могут отвечать за разные атрибуты, поэтому правила выбора значений необходимо гибко определять с учетом того, откуда поступает конкретная информация. Иначе централизация лишь переносит расхождения между источниками в одно место, но не устраняет их.
Почему правил выбора источника бывает недостаточно
Даже после того, как определены соответствия атрибутов и выставлены приоритеты источников, остаются ситуации, в которых нельзя просто выбрать значение, поступившее из источника, и записать его в эталонный справочник. Важны также история изменений и период, в течение которого данные должны считаться актуальными.
Мы столкнулись с этим, когда подключали источник информации о расписании рейсов. В чем была сложность?
Источник заранее сообщает об изменениях: новое расписание на следующую неделю приходит каждый понедельник. То есть мы знаем о смене расписания заранее. При этом изменение может затрагивать не только значение атрибута, но и саму запись: если рейс перестает выполняться в один из дней, прежнюю запись уже нельзя просто обновить.
Старое расписание должно остаться в истории за тот период, когда оно действительно действовало, а новое — начать действовать с нужной даты. Поэтому система должна сохранить прежнюю запись с соответствующим периодом действия и создать новую с другой датой начала действия.
При этом дата поступления изменения и дата начала его действия могут отличаться: новая информация уже известна, а прежняя запись еще должна использоваться потребителями. Задача системы управления мастер-данными — корректно обработать это изменение и не оставить прежнее расписание действующим после установленной даты.
Этот случай не связан с разрешением расхождений между несколькими источниками, но показывает другую сторону формирования единой версии данных: получить новое значение еще не значит сделать его актуальным. В сложных системах необходимо учитывать не только само изменение, но и период действия данных.
Единая версия должна дойти до потребителя
После формирования эталонной записи ее необходимо опубликовать и передать подключенным системам. Для интеграционного обмена мы используем Apache Kafka и Apache NiFi.
Сейчас путь данных от источника до потребителя занимает от 10 до 30 секунд в зависимости от сложности конфигурации самого эталонного справочника и количества передаваемых данных. Система обрабатывает от 500 до 250 тыс. записей в сутки. По мере развития проекта отдельной задачей стала оптимизация потока данных: важно было учитывать не только скорость обработки внутри отдельных сервисов, но и время прохождения изменения по всей цепочке.
При этом скорость и корректность нельзя рассматривать отдельно друг от друга. Быстрая доставка ошибочно сформированной записи не решает задачу единой версии данных. Потребителю важно получить не просто последнее опубликованное сообщение, а значение, сформированное по согласованным правилам и актуальное для нужного периода.
Не менее важно сохранять согласованность процесса при изменении самой системы управления мастер-данными. В самом начале работы над функционалом формирования мастер-данных перед нами стояла задача перенести справочники из предыдущей MDM-системы. Такой переход затрагивает не только хранение и преобразование данных. Нужно было учесть существующие интеграции: потребителям важно продолжать получать привычную информацию без доработок со своей стороны. Переход от одной системы к другой должен был быть бесшовным.
Вывод из проекта
Опыт проекта показал, что для формирования единой версии мастер-данных необходимо заранее определить, какая система отвечает за конкретную информацию, как обрабатывать расхождения и как учитывать период действия изменений.
На практике это означает, что путь от источника до потребителя нужно рассматривать как единый процесс: данные должны быть не только доставлены, но и сформированы по согласованным правилам и переданы потребителю в тот момент, когда они действительно становятся актуальными.
Опубликовано 21.10.2026
