Привет, Хабр! Меня зовут Даниил Зайцев. Уже почти 20 лет я работаю в области управления данными: прошел путь от обычного разработчика до исполнительного директора практики. Сейчас в составе команды вендора Data Sapience занимаюсь развитием решения в области Reference Data Management (RDM) – продукта Ingresso One, который входит в платформу Data Ocean Governance.
Эта статья открывает серию материалов о задачах, которые стоят перед современными системами управления справочными данными (RDM / НСИ), способах их решения, типичных заблуждениях и стратегиях внедрения. В этой статье постараемся разобраться в разнице терминологии и том, почему это понимание может быть важно при выборе правильного инструмента.
Под НСИ (нормативно-справочной информацией) в этой статье я рассматриваю термин в ИТ-контексте: как управление корпоративными справочными данными. В промышленности и госсекторе НСИ может включать также нормативно-технические документы и государственные классификаторы, однако здесь фокус именно на системах управления данными.
На что опираемся
Изначально был план начать с прикладных сценариев, но по ходу работы стало очевидно: без общей базы и прояснения терминологии сложно говорить о деталях. Особенно учитывая, насколько российская практика отличается от международной.
Многие считают, что локального опыта вполне достаточно. Но в заказной и внутренней разработке мы часто опираемся на лучшие мировые практики. Они формализованы, проверены временем и разнообразием кейсов и в результате дают большую вариативность для принятия решений.
Важно: несмотря на общий характер статьи, я буду отсылаться к тому, как мы с командой решаем эти задачи в рамках продукта Ingresso One. Он отражает наше видение этой области и, возможно, наш подход отличается от традиционного.
Что такое RDM: международный взгляд
В международной классификации (например, в рамках DAMA DMBOK) RDM (Reference Data Management) — это управление кодовыми списками:
классификаторами,
справочниками,
иерархией,
перекодировками,
списками значений, которые меняются редко и используются во множестве систем.
Ключевые черты:
Централизованное ведение справочников;
Распространение версий на разные системы и процессы;
Стремление к тому, чтобы один справочник равнялся одному источнику правды.
Важно отличать RDM от MDM (Master Data Management).
На первый взгляд, и там, и там – «справочники», например, клиентов, контрагентов, товаров. Но есть фундаментальная разница:
Параметр | RDM | MDM |
Источник данных | Централизованный | Множественные учетные системы |
Проблемы | Согласование значений, версия данных, качество пользовательских данных | Дубли, расхождения между источниками |
Задачи | Ведение, дистрибуция, валидация | Сопоставление и слияние, гармонизация, формирование «золотой записи» |
В рамках MDM требуется:
устранение дублей (а их появление практически гарантировано, так как по определению работа идет с данными одной и той же физической сущности, но описанной по-разному в разных учетных системах);
формирование единого представления о сущности;
для всего этого – реализация сложных алгоритмов сравнения и слияния данных.
RDM — это лишь часть всей области MDM, которая охватывает подмножество его задач. Но его, тем не менее, выделяют, особенно когда речь идет о продуктах и решаемых ими задачах.
При этом под справочными данными понимаются данные, служащие для классификации и категоризации других данных: как основных (область ответственности MDM), так и транзакционных.
НСИ в России: почему все смешалось
Сам термин НСИ (нормативно-справочная информация) употребляется уже давно, лично я слышу его на протяжении всей карьеры в сфере данных (уже почти 20 лет), но отследить его происхождение мне не удалось.
Формально он полностью соответствует термину RDM.
Но в российской практике под НСИ часто (радует, что не всегда) подразумевают несколько большее:
справочники (как RDM);
мастер-данные (как MDM), обычно в формате, близком к аналитическому MDM, то есть задачи дедубликации и определения «золотой записи», хотя ровно такие термины обычно никто и не использует;
задачи качества данных в расширенном виде (как DQ), то есть не только контроль пользовательского ввода данных, но и, например, автоматические преобразования различных форматов к единому.
Откуда это взялось?
Исторически: НСИ-системы создавались как центр обмена данными между ERP, CRM, DWH и пр. При этом под «системой НСИ» часто имеют в виду централизованное ведение ключевых данных предприятия (товарная номенклатура, контрагенты, филиалы и др., что все же больше, чем просто кодовые списки);
Ожидания бизнеса: «Если уж ведем справочник контрагентов в этой системе — пусть он сразу чистит дубли и приводит ИНН к формату». Но тут нетрудно заметить, что такие задачи возникают, только если вы начинаете его наполнять из разных источников, а не ведете централизованно. Что уже, конечно, относится к MDM;
Организационно: в компаниях часто нет отдельной MDM-системы, и все ложится на НСИ.
В результате:
НСИ в российских компаниях = RDM + часть MDM + немного DQ.
Гармонизация – термин, который часто путают
Гармонизация — термин из MDM/ETL (Extract Transform Load, обычно подразумеваются и инструменты, и практика реализации процессов преобразования данных), и про него я бы хотел сказать отдельно, так как он с некоторой периодичностью встречается в требованиях, которые предъявляют к системам НСИ. Означает он приведение значений к:
единому формату (например, дата, ИНН);
классификациям (например, ISO 3166 для стран);
бизнес-логике (например, правила заполнения атрибутов).
Пример:
«Россия», «РФ», «Rossiya» → RU (ISO 3166);
8 (999) 345-67-89 → +7-999-3456789.
В MDM гармонизация — это часть DQ (Data Quality). В RDM — максимум простая валидация (но и то не всегда).
Но российские заказчики часто ожидают, что «НСИ-система» умеет все в расширенном понимании.
Почему это важно: разные ожидания → разные подходы
В мировой практике:
RDM и MDM— это разные классы систем;
Часто RDM дополняет MDM, предоставляя пользовательские справочные данные для корректной настройки правил в MDM-системе;
У вендоров они бывают в одной линейке (Ataccama, Informatica и др.), но как отдельные продукты.
В российских реалиях клиенты довольно часто хотят обладать одним решением на все случаи жизни.
Идея красивая, но:
Разработка такой системы — это тысячи человеко-дней;
Чем больше функций – тем выше риск получить продукт, который «умеет все, но плохо».
Лично мое мнение: в IT нет ничего невозможного, но, чтобы не приходилось выбирать между функциональностью и качеством, требуется несколько больше времени. Если спрос не сократится в разы от текущего уровня, то, пожалуй, на горизонте 3-5 лет уже можно будет говорить о таких универсальных решениях. Но пока я бы подбирал продукт под каждую отдельную решаемую задачу, не пытаясь найти редко встречаемого единорога…
Наш подход на текущий момент (под «нашим» я имею в виду команду, работающую над продуктом Ingresso One):
RDM должен быть специализированным решением;
MDM — другим;
Да, могут быть от одного вендора, но задачи и команды — разные.
Мысль на вырост: границы RDM можно расширять
Обычно RDM — это про справочники. Но в Data Sapience в команде Ingresso One мы смотрим шире.
Видим ценность в том, чтобы использовать RDM-платформу в том числе для прикладных задач, таких как:
управление корректировками данных в DWH (Data Warehouse, то есть хранилище данных, здесь речь не о конкретной архитектуре, а о концепции корректировок данных в аналитическом контуре компании);
загрузки и доставки до получателя пользовательских датасетов;
поддержки data science экспериментов;
управление распространением табличных данных по ролевой модели и т.д.
Почему это работает:
Такие задачи тоже требуют версионирования, контроля доступа, аудита, согласований, пользовательского UI и возможности полноценной совместной работы с данными;
Бизнесу нужно решение, которое в подобных задачах сделает его менее зависимым от ограниченного ресурса IT («Приходите в следующем квартале, на этот бэклог забит»).
Да, это не канонический RDM, но при этом и не то самое «универсальное» решение. Мы пытаемся рассуждать в терминах не только технических задач, но и прикладных, чуть более понятных бизнесу. На наш взгляд, они не настолько далеки по требованиям от того, что может закрываться, в частности, нашим продуктом. Многие из этих задач централизованно используют данные, доступ к которым надо предоставлять бизнес-пользователям, а не только IT, с расширенными возможностями контроля за качеством данных и дальнейшей доставкой до места назначения. А это, как мы рассматривали раньше, пересекается с ожиданиями от систем RDM/НСИ.
В дальнейших статьях я постараюсь осветить уже более специализированные темы и проблемы, решаемые инструментами класса RDM. Если для вас это актуально – stay tuned!
