Привет! Я Николай, аналитик во ВкусВилле, я запустил и поддерживаю проект по каталогу данных в ВВ. 

Поиск данных — нелегкая задача, особенно при большом объеме бизнеса. Много источников информации и множество аналитиков связаны со сложностями как при онбординге, так и в процессе работы. Чтобы жить стало проще, мы решили создать свою систему для каталогизации источников и определения единого источника правды. 

Сделали каталог своими руками, как подошли к этому вопросу и что получили в итоге —расскажу в этом материале. 

Подготовка 

Мы решили создать каталог данных с нуля, без привлечения дополнительных ресурсов. Сразу сформировали небольшую команду, в которую вошли: системный аналитик, инженер данных и BI-аналитик. Системный аналитик реализовывал архитектуру решения и методологию, инженер данных формировал БД и разные загрузчики из форм, в которые вносили описания. BI-аналитик занимался фронтом, отвечал за то, как будет выглядеть каталог данных.

Так как в компании довольно много дублирующихся отчетов, меняются разрабатывающие их команды, мы решили в качестве MVP сосредоточиться на описании отчетов Power BI. Мы приоритизировали отчеты, оценив их по двум ключевым критериям: важность (происходит из охвата) и популярность (в основе частота запуска отчета).

Собрали ожидания и требования с пользователей каталога – всего Управления Аналитики. Основными моментами стали поиск информации и состав описаний: например, в какой таблице лежат данные, возможность фильтрации по схемам/БД.

Далее мы приступили к первоначальному описанию отчетов Power BI. Для каждого отчета мы собрали общую информацию: количество пользователей, заказчик и основная цель отчета. Затем мы начали детально описывать поля, содержащиеся в отчетах. К примеру, тип торговой точки (ТТ) ВкусВилл, который в наших отчетах назывался по-разному – формат ТТ, тип ТТ, формат тип ТТ.

В процессе этой работы мы погружались в скрипты формирования отчетов, изучая формулы расчета показателей. Иногда мы находили расхождения между тем, как показатель назывался в отчете и его фактическим смыслом. Например, один показатель в отчете назывался "маржа", но по сути это была "рентабельность". Чтобы не вносить сразу изменения в названия, мы решили сначала собрать облако синонимов для каждого показателя, а затем уже приводить все к единообразному виду и сделали это через связку родительской и дочерней сущностей, где в роли родителя выступало корректное, точно передающее бизнес-смысл описание, а роли дочерних иллюстрировали все возможные виды аналогичных терминов, использующихся в отчетах. Также мы заполнили информацию о lineage данных, включая алгоритмы преобразования. Этот первый этап работы позволил нам понять, какую информацию мы можем извлечь из отчетов для описания и какая информация может быть интересна пользователям каталога, и начать прорабатывать архитектурную схему хранения описаний для нашего каталога данных.

Архитектура и бэкенд

Для бэка нашего каталога данных мы выбрали Greenplum как систему хранения каталога и загрузчик, который берет данные из форм на Google Sheets и проверяет их на правильность заполнения. 

Фронт состоял из двух частей: формы загрузки на Google Sheets и отображения результата в виде отчета Power BI.

Для архитектуры базы данных нашего каталога мы выбрали схему data vault 2.0. После того, как мы столкнулись с невозможностью вывести результаты описаний и отчетов и БД в Power BI, мы перестроили структуру в виде классической “Звезды” (star schema). Мы выбрали базу данных на основе предварительного расчёта того, что мы будем в ней хранить — бизнес-глоссарий приблизительно 10 тысяч строк, а техническая мета DWH не больше миллиона строк. Основное преимущество модели “Звезда” в её быстрой реализации. Недостатки включают малую масштабируемость базы данных, что потенциально могло бы потребовать переработки всей структуры хранения данных, что увеличило бы длительность проекта.

В загрузчик описаний из Google Sheets в БД мы встроили несколько проверок качества заполнения, например, одинаковые имена элементов данных, проверки на соответствие нормальным формам и пр. Также реализовали механизм реджектов, в котором все описания,не связанные с технической метой БД и отчетов, падали в отдельный файл с ошибками. Тем самым мы отобрали ту техническую мету, над которой еще ведется работа по описанию. Кроме того, загрузчик производил сканирование технической метаинформации DWH, включая имена таблиц, список их полей, типы данных и т.д.

Фронт

Основными требованиями к фронту каталога от пользователей были: описание полей в БД и отчетах, lineage, скрипты и формулы формирования расчетных показателей.

Разработка пользовательского интерфейса (фронта) потребовала наибольших усилий и времени. Мы решили использовать для этой цели Power BI. Хотя он подходит в качестве инструмента для фронта каталога, у него есть особенность — он лучше работает с числовыми данными, чем с текстом, который преобладает в каталоге данных. Из-за этого реализация некоторого функционала заняла больше времени, чем планировалось. Например, реализация глобального поиска: мы настроили дополнительные таблицы, в которые затягивалась информация со всех полей БД каталога со значением поля и наименованием поля и таблицы, где они лежат в каталоге данных. В итоге получился аналог Elastic Search в Power BI. 

Также мы были ограничены форматом одного экрана в Power BI, что не позволяло нам вывести все поля в одну форму. Тогда мы проранжировали все поля по наиболее критичным требованиям и оставили их обязательными, а остальные критерии можно было дополнительно выбрать в этой же форме. Это было реализовано с помощью связанных списков.

Основные трудности вызвал lineage данных. Некоторые инструменты для отрисовки графов требовали дополнительной настройки для корректного отображения информации на ребрах и вершинах, при этом необходимо было обеспечить их совместимость с глобальным поиском.

Среди плюсов реализации фронта каталога данных на Power BI можно выделить гибкий подход, который позволяет нам добавлять дополнительные страницы в отчет "Каталог данных" и выводить на них любую необходимую информацию для пользователей. Например, отдельно вывести список отчетов, информацию по БД/схемам/таблицам.

Однако среди минусов стоит отметить, что для некоторых задач Power BI может быть не самым подходящим инструментом, и каждая новая функция требует длительного изучения возможностей BI инструмента. 

Форма описания каталога данных

Единственным решением, которое оказалось для нас узким горлышком, стала форма описания каталога данных в Google Sheets. Взаимодействие с базой данных каталога было односторонним – загрузчик выгружал данные из Google Sheets в базу, но не обратно.

Предполагалось, что основными пользователями, заполняющими каталог, будут аналитики. Мы провели несколько обучающих сессий по заполнению каталога. Обратная связь была однозначной: “Мы сначала создали отчет, а затем потратили столько же времени на его описание”. В итоге количество пользователей, вносящих описания в каталог, не увеличилось.

Именно односторонняя интеграция создавала определенные сложности для пользователей, заполняющих каталог. Им приходилось вручную вводить всю необходимую информацию, не имея возможности автоматически подтягивать данные из базы, что могло бы упростить и ускорить процесс заполнения.

После нескольких попыток изменить процедуру и форму описания мы решили, что необходимо менять инструмент целиком. 

Мы начали оценивать различные решения, которые могли бы помочь нам реализовать более удобную форму загрузки в каталог. Среди рассматриваемых вариантов были Streamlit, а также готовые инструменты для управления данными, такие как Datahub, Open-Metadata и Amundsen.

В итоге мы выбрали готовое решение Open-Metadata, которое, по нашему мнению, лучше всего подходило для закрытия наших потребностей.

Итоги

Как уже было сказано ранее, мы провели сначала сбор требований к продукту у пользователей. Первая версия каталога данных с такой архитектурой была готова уже через месяц. Дальше началась систематическая работа по наполнению каталога бизнес-глоссарием, поэтому первый полноценный релиз мы сделали через первые два месяца. Через полгода в нашу команду вышел еще один системный аналитик, и мы нарастили темпы описаний, и уже через 9 месяцев проекта мы описали 1300 бизнес-терминов глоссария и более 200 таблиц нашего хранилища данных. Так как фронт у нас на Power BI, мы так и не смогли померить обычные продуктовые метрики типа DAU и MAU, длину сессии или наиболее частые запросы в каталог. Зато мы регулярно проводили опросы, в результате которых получали ценную ОС по новым идеям для каталога, и формировали от этого наш бэклог. По итогам выяснилось, что 80% аналитиков использовали каталог данных. 

Создание собственного каталога данных с нуля вполне осуществимо. Это не является чрезмерно сложной задачей при наличии правильного подхода и необходимых ресурсов. Ключевым становится выбор подходящих инструментов для реализации трех основных компонентов каталога:

• Форма для заполнения

• База данных каталога

• Визуализация

Также важно уделить внимание формированию команды, которая будет заниматься этим проектом. Это должны быть люди с высокой мотивацией, готовые искать нестандартные решения для нетривиальных задач.

В целом, как и при разработке любого другого продукта, необходимо четко определить целевых пользователей каталога данных и двигаться итеративно, собирая обратную связь и улучшая пользовательский опыт. Это позволит сделать каталог действительно полезным и востребованным инструментом data governance.