Всем привет! Меня зовут Роман Грибов, я директор по развитию данных и аналитики в «Спортмастере». Вместе с моей коллегой Татьяной Шишкиной, руководителем направления «Каталог данных», мы расскажем о том, что это за инструмент, как он работает и как позволяет сделать проще жизнь аналитиков, архитекторов и многих других (включая даже тех из нас, кто просто когда-либо смотрел на аббревиатуру «GMV» с немым вопросом «Что ты такое?»), а еще объясним главные цели его внедрения.
Цели внедрения каталога данных
Итак, начнем с определения.
Каталог данных – это единая платформа, на которой собрана информация о данных компании.

Цели его внедрения просты:
упростить поиск ответов на вопросы, которые возникают у коллег, т.е. предоставить инструмент, с помощью которого мы все вместе сможем находить нужные нам отчеты, дашборды, данные для бизнес-пользователей, а также получать новые сведения и знания для того, чтобы эффективнее выполнять свою работу;
сократить случаи появления одинаковых отчетов и наборов данных;
помочь аналитикам данных, архитекторам и дата-инженерам находить качественные источники данных. Например, для того, чтобы разрабатывать рекомендательные алгоритмы, хорошо бы знать, где найти нужные сведения о том, что делают наши пользователи на сайте, в мобильном приложении или в контактном центре – на все эти вопросы должен отвечать каталог Данных.
Итак, каталог данных – это класс программ, который помогает систематизировать информацию компании для работы с данными.
Содержание каталога данных
В каталоге представлено два основных вида метаданных:
технические метаданные – это сведения о базах данных, об отчетах, т.е. обо всем, что есть, скажем так, в реальной жизни, в физической модели данных, в системах визуализации и т.д. Взятые в совокупности технические метаданные позволяют ответить на два жизненно важных вопроса. Во-первых, как мы в компании храним данные, в каких базах данных, условно, в каком столбце какой таблицы, какой базы хранится ІТ-сессия. Во-вторых, как мы перекладываем и преобразуем при этом перекладывание данных, к примеру, что мы взяли данные из таблички, мы их переложили, что хранится в каждой вкладке каждого отчета, в каждой системе;
бизнес-метаданные (они же глоссарии) – это такой контролируемый корпоративный словарь терминов, который используется в компании. Выделяют три основных вида терминов глоссария. Например, у нас это товар, клиент, возврат, доставка и т.д. У этих сущностей есть определенные свойства и характеристики – это их атрибуты. Например, отвечая на вопрос о том, какой у нас есть клиент, мы описываем именно его свойства, его атрибуты. И, конечно же, в глоссарии есть расчетные показатели, т.е. определенные показатели, которые получаются в результате использования фиксированных в компании формул.
Способы получения каталога данных

Есть три основных способа получить каталог данных для компани:
купить определенное платное решение;
взять open source и его доработать;
разработать собственное решение.
Мы очень тщательно думали о том, какой путь нам подойдет больше, отталкиваясь в первую очередь от конкретных целей для внедрения каталога.
Исходя из этого, фиксировались на конкретных функциональных требованиях, которые у нас были, на том, как мы видим характер его использования, т.к. часть компаний делает каталоги данных лимитированными по доступу. Для нас же каталог – это открытая для всех работающих в компании платформа. Ну и, конечно же, смотрели на издержки, насколько дорого, долго и сложно будет доработать open source и разработать собственное решение. После очень тщательного, длительного и многофактного обсуждения у нас был обнаружен очевидный лидер – каталог OMD, он же OpenMetaData, open source решение.
Каталог выбран – что же дальше?

Итак, мы выбрали каталог, запустили, развернули и, казалось бы, все, хэппи-энд – но тут наступил великий и ужасный Disillusionment Point (он же этап разочарования). Мы все загрустили из-за количества неописанных отчетов, показателей, незаполненного глоссария, отсутствия подключения всех необходимых баз данных.
Однако мы не стали исключением: подавляющее большинство компаний, запускающих каталоги данных, проходят через этот этап.
Поскольку мы спортивная компания, сравним это с таким примером: кто-то решает заняться спортом. Он очень ответственно подходит к этому решению: тщательно выбирает спортивную форму и т.д. – это не про какую-то мини-цель, а про новый образ жизни! То же самое можно сказать и про каталог данных – это не сколько про какую-то мини-цель, столько про переход к новой культуре работы с данными и управления методами. Так что этот этап разочарования происходит со всеми, главное через него пройти. В прохождении этого этапа каталог тоже предлагает определенную помощь.
В первую очередь с помощью возможности рассортировать все активы, т.е. все описания таблиц, отчетов, терминов, которые есть в каталоге, сгруппировав их в определенные логические блоки.

Есть три основных вида таких связей, т.е. три основных вида блоков в каталоге:
карточки терминов глоссария – иерархические (например, если у нас есть множество видов Conversion Rate, то мы их собираем в один общий зонтик) или ассоциативные (термины не связаны в определенную иерархию, однако соотносятся друг с другом, например, термин «активная клиентская база» и «клиент);
маппинг – это связь термина глоссария и технических метаданных. Например, отчет об активной клиентской базе можно связать с термином «активная клиентская база», а то и с термином «клиент»;
и, конечно же, одна из самых важных видов связи в каталоге – линедж. Это схема, которая показывает путешествия, которые проходят данные в компании. От точки входа и до отчета, где они в конечном итоге у нас уже предстают.
Какие задачи решает каталог данных

Например, пришел человек из другой компании и думает: а что такое «сезон» в «Спортмастере»? Это весна, лето или что-то другое? Идет в каталог, ищет в глоссарии и получает однозначное определение термина именно в рамках компании.
То же самое относится и к показателям. Например, он не знает, что такое GMV. Идет в глоссарий каталога, ищет и обнаруживает определение, которое используем именно мы.
Или, например, он разработчик и ему интересно узнать, какие отчеты у него сломаются через 20 переходов, если он изменит микросервис, который пишет данные в определенную таблицу. Проверяет в каталоге линедж и видит, какая ответственность связана с его решением. Обратная ситуация. Он аналитик и ему интересно, откуда он берет данные для своих отчетов, насколько он может им доверять и что следует учитывать. Если ему интересно, кто отвечает за данный термин, таблицу, отчет в каталоге, очень удобно проявить владение именно конкретным активом данных. Например, один человек отвечает за отчет об активной клиентской базе, а другой за источники, на которых этот отчет строится.
Если ему интересно, как изменялся источник (будь то таблица, отчет или термин), то в каталоге всегда есть история, информация об удаленных отчетах и т.д. и, например, если у него есть конкретный, вдумчивый запрос, каталог тоже подскажет ответ.
Итоги
Отметим основные этапы экзистенциального осознания человека, который приходит в каталог. Первая реакция, конечно же, прохладная – какой-то новый инструмент, в котором нужно ретроспективно описать много чего. Однако на смену этому быстро приходят радость, удовольствие и счастье в жизни, когда вы понимаете, что вместо того, чтобы 20 раз отвечать на один и тот же вопрос, вы сначала скидываете ссылку на описание отчета в каталоге, а потом люди сами привыкают и вместо того, чтобы спрашивать какой-то абсолютно базовый вопрос, сначала идут в каталог и только потом к человеку, который указан владельцем или контактным лицом по определенному активу.
IlyaNovozhilov
А как вы собираете и поддерживаете в актуальном состоянии data lineage? Какая то автоматизация? Внутренние регламенты?