Как мы внедряли каталог данных DataHub и искали компромисс между BI, DWH и ИБ

Счастлив тот аналитик, у которого в компании есть дата-каталог — единая точка входа для поиска информации о данных невероятно экономит время, data lineage выстроен, а уровень заполненности документации на высоком уровне.

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

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

Как искали решение, которое удовлетворит всех

Внедрение DataHub: как поднимали систему и заполняли хранилище данными

Какие функции мы дописали сами

Что получилось в итоге и планы по развитию каталога

Рекомендации тем, кто решил внедрять дата-каталог

А точно ли нам нужен дата-каталог?

Если у вас нет единого места, где лежат все описания данных (или оно есть, но пользоваться им неудобно), то вы определенно в зоне риска. Иногда вопросы по данным до сих пор задаются в корпоративном мессенджере или в личку, иногда вся экспертность находится у двух-трёх человек, уход которых — риск потери информации.

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

Мы в СберМаркете прошли именно такой путь. 2,5 года назад работать с данными нам было непросто. Мы описывали все дашборды и данные, на которых они строятся, во внутренней Wiki-системе, но через какое-то время актуальность такой системы стало сложно поддерживать из-за масштаба. К тому же поиск там оставлял желать лучшего.

Внедрение дата-каталога назревало ещё и потому, что аналитический отдел увеличивался и СберМаркет активно развивал data-driven культуру.

Про data-driven’ность и её оценку подробнее можно почитать в статье моего коллеги Вани Леонтьева. 

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

Так начался наш квест по разработке и внедрению дата-каталога.

Решение, которое удовлетворит всех

Для начала нужно было совместно решить, будет ли у нас самописная разработка или мы выберем что-то из имеющегося на рынке.

1. Мы начали с описания требований к дата-каталогу. Получился doc-файл на 7 страниц: 29 требований со стороны аналитиков и 7 от инжиниринга.

   Это был мой первый опыт написания технического задания на создание приложения. Поэтому я старался максимально подробно описать бизнес-требования, а за технические отвечала команда DWH.

Примеры требований со стороны аналитики:

1. Владелец 
   Назначается через выбор пользователя, учётная запись которого была добавлена на сервис дата-каталога. Назначение пользователя происходит через выбор учетки в выпадающем меню.

2. Описание (Description)
   UI должен поддерживать стандартный набор инструментов для редактирования текста, включая:

   • заголовки;

   • вставка таблиц;

   • ссылки;

   • вставка кода;

   • создание списков;

   • вставка изображений.

   Для сервисов, базы данных, схем описание заполняется через UI.

   Для таблиц и атрибутов описание заполняется через UI либо загружается автоматически из ddl.

   Есть возможность настройки правил загрузки метаданных — описания таблиц и атрибутов. Например, при первичной загрузке метаданных описание тянется из ddl таблицы, далее описание может быть изменено пользователем через UI. При обновлении метаданных информация, которую занёс пользователь, не затирается данными из ddl.

   Если в схеме появляется новая таблица или атрибут, то поле Описание загружается из ddl.

3. Уровни важности сущностей (Tier)
   Для таблиц есть возможность проставить уровень важности из нескольких доступных, например.

   • Уровень важности 1 — критически важные таблицы, источники правды.

   • Уровень важности 2 — важные таблицы для бизнеса всей компании.

   • Уровень важности 3 — важные таблицы для определенного департамента.

   • Уровень важности 4 — важная таблица для команды.

   • Уровень важности 5 — личные таблицы или неиспользуемые таблицы.

Примеры требований со стороны инжиниринга:

1. Возможность программно обновлять метаданные. Минимальный набор: Kafka Connect, DBT, Airflow, Spark.

2. Возможность программно получить метаданные для объекта. Минимальный набор: Kafka Connect, DBT, Airflow, Spark.

3. Возможность программно осуществить bulk-export во внешнюю систему (iHub).

4. Возможность программно осуществить bulk-import из внешней системы (iHub).

5. Поддержка тегов на уровне таблиц.

6. Поддержка тегов на уровне полей.

7. Сквозной lineage через различные системы (Например Tableu → DBT (ClickHouse) → Spark → Kafka → Kafka Connect → Source Database).

Уже на этом этапе мы поняли, что разработка собственного каталога нам не подойдет: требований достаточно много, значит разработка будет слишком долгой и дорогой. Поэтому мы…

2. Изучили, что предлагает рынок. В открытых источниках мы нашли сравнение имеющихся на рынке инструментов. Это послужило отправной точкой для собственного исследования. Посмотрели, попробовали, обсудили различные варианты и составили шорт-лист из двух Opensource-решений: OpenMetadata и DataHub. 

   Для нас, аналитиков, OpenMetadata казался более подходящим: он был более user friendly, с понятным интерфейсом и функциями. Для команды DWH, напротив, этот инструмент не подходил вовсе. Так Что же делать, если одни хотят одно, другие — второе?

3. Вместе провели оценку инструментов по ключевым критериям. Я создал таблицу, где расписал основные требования для оценки. Туда вошли фичи по каждому из разделов: подключения, работа с метаданными, UX\UI, функционал, сущности, резервное копирование, автоматизация, аутентификация ADFS, домены, безопасность и ролевая модель. Каждому критерию назначили вес от 0 до 3, где 0 — не важно, 1 — nice to have, 2 — important, 3 — must be. 

   Далее провели голосование, где команда аналитиков и команда DWH проставляли баллы от 0 до 3, где 0 — функционал отсутствует, 1 — представлен в каком-то виде, 2 — достаточно для работы, 3 — то, что нужно.

В итоге, критические требования обеих сторон удовлетворил именно DataHub. В нём больше интеграций из коробки, в то время как OpenMetaData, на наш взгляд, хорошо работает лишь с одним хранилищем данных (например, если бы у нас были только ClickHouse + DBT).

Внедрение DataHub: как это было

Итак, начался процесс внедрения.

1. Стартовал деплой. Мы попросили DevOps’ов взять эту задачу как одну из целей на квартал. При раскатке вылезли некоторые трудности, связанные с внутренними правилами и ограничениями отдела ИБ. Вместе с последними мы разработали ролевую модель (из коробки она достаточно ограниченная и не всегда может лечь на оргструктуру компании) и начали пускать первых тестовых пользователей. 

К слову, в плоско-организованных компаниях сложностей с внедрением возникнуть не должно, так как у DataHub’a отличные HELM-чарты. Если у вас нет ограничений по уровню доступов, то развернуть DataHub поверх K8S можно минут за 5.

2. Настроили ingest из dbt, чтобы все связи и документация хотя бы из одного хранилища данных автоматически проставлялась в DataHub. 

3. Загрузили метаданные одного из наших BI-инструментов. На тот момент это был Metabase.

4. Загрузили метаданные таблиц из хранилища Clickhouse — порядка 3500 таблиц. Помимо Clickhouse, мы загрузили в DataHub метаданные из BI-инструментов и источников баз данных. По некоторым таблицам удалось настроить lineage автоматически — так, например, произошло дашбордами из Metabase. 

Ура, у нас есть дата-каталог. Но есть нюанс, сейчс он пустой, поэтому таким инструментом никто не будет пользоваться — нужна документация по заполнению и ответственные. 

5. Для начала решили, что 3500 таблиц — много и сформировали список топ-500 таблиц на основе частоты запросов за последние 3 месяца.

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

7. Разработали метрику «заполняемость» и сформулировали цели по росту для разных доменов: операции, продукт, BI, финансы, маркетинг. Для этого пришлось описать методологию расчета, которая отражает полноту описания сущностей в DataHub. Мы проставили флаги «обязательного» заполнения полей. Это означало, что, если хоть один из элементов, помеченных единичкой, был не проставлен у сущности определенного Tier, то таблица считалась не заполненной. 

8. Настроили ETL для получения нужных данных. В DataHub нет встроенного удобного аналитического инструмента для отслеживания заполняемости. Это, кстати, был один из минусов выбранного решения по сравнению с тем же OpenMetadata. Поэтому мы написали свой ETL.

9. Начали заполнять документацию и построили дашборд для отслеживания заполняемости. Благодаря обучению и тому, что метрика заполняемости попала в цели командам, за месяц нам удалось заполнить 70% всех топ таблиц. Дата-каталог стал единой точкой входа с удобным поиском с удобным фильтром.

Тюнинг: функции, которые мы дописали своими руками

Этап внедрения у нас занял один квартал, дальше продолжили активнее заполнять каталог и думать над улучшениями. При выборе DataHub, понимали, что коробочного решения нам будет недостаточно, так что после внедрения мы дополнительно написали еще несколько инструментов. 

• Скрипты, которые автоматически копируют описания таблиц из Sandbox, если они уже были написаны, но пришло время для переезда в продовую схему. 

• Инструментарий для DataHub, который помогает автоматически отфильтровать персональные и чувствительные данные из хранилищ. Теперь сотрудники ИБ, заходя в DataHub, могут проставить галочки напротив таблиц и колонок, содержащих такие данные, и наши интеграции автоматически отфильтруют ПДН и чувствительные данные. Сейчас эта механика прошла стадию экспериментов и находится на этапе продуктивизации и последующего масштабирования.

• Скрипт, который ежедневно проверяет изменения в структуре таблиц. Например, если было добавлено новое поле или изменено старое, отдел ИБ получает алерт и проверяет его на наличие ПДН.

• Ещё один инструмент позволил автоматически тегировать таблицы. Как писал выше, у нас есть 3500 таблиц в ClickHouse, из них 500 самые популярные. Поэтому первый тег — это топ-таблица и есть другие уровни — Tier-1,2,3, 4 по уровню важности. Все новые таблицы, созданные в продовых схемах, автоматически тегируются как топ-таблицы, обязательные к заполнению. 

Результаты и планы

В итоге DataHub стал популярным среди аналитиков, дата-инженеров, менеджеров, специалистов DWH и ИБ. Текущее значение

На этом останавливаться не хотим, поэтому дальше в планах: 

• Внедрить удобный процесс заполняемости описания метаданных. Основная сложность при внедрении каталога данных, с которой мы столкнулись, — это то, что довольно сложно убедить людей заполнять описания таблицы и остальную документацию. Но импульс дан, и сейчас если не заполнена та самая ТОП-таблица, можно найти ответственного и попросить внести данные в DataHub. Надо этот процесс улучшать и дальше. 

• Продолжить наполнение документацией и новыми источниками данных. В идеале мы хотим иметь все метаданные по сервисам и источникам в DataHub до того, как они подгружаются в хранилище данных и соответственно их описание. 

• Совместно с командой DWH автоматизировать полный lineage на основе скриптов из GitLab. У lineage есть сложности, связанные с тем, что в СберМаркете большое количество промежуточных узлов обработки и транспортов данных. Проинтегрировать их все за короткий срок хоть и хочется, но очень сложно.

• Масштабировать инструмент по работе с персональными и чувствительными данными. Нам хочется, чтобы у компании было полное представление о том, какие данные есть, являются ли они персональными, где они находятся — всё это для дальнейшей автоматизации по предоставлению доступов. Также хочется, чтобы когда автоматика отрезает ПДН из нижних слоев хранилища, то в верхних слоях мы тоже максимально автоматически от них избавлялись, а теги перетекали наверх. 

• Провести сертификацию дашбордов второго уровня. Она подразумевает под собой описание фундаментальных метрик, которые у нас не меняются, а в DataHub есть для этого специальный раздел — Глоссарий. Его и начнем использовать. 

Рекомендации тем, кто решил внедрять каталог

Внедрять ли дата-католог? Если ваша компания уделяет аналитике должное внимание и хочет развивать data-driven подход, то, однозначно, да. Чтобы эффективно использовать возможности данных, в них должен быть порядок.

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

Главный инсайт для меня, что хоть для моей команды дата-хаб был нужен в качестве удобного интерфейса, команде DWH и ИБ он открыл возможность для реализации более глубоких задач (таких как автоматизация полного lineage и работа с персональными данными). Рекомендую и вам сходить к соседним командам — вместе проще затащить такой масштабный проект. 

Буду рад ответить на вопросы в комментариях!

Product&data команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.