Счастлив тот аналитик, у которого в компании есть дата-каталог — единая точка входа для поиска информации о данных невероятно экономит время, data lineage выстроен, а уровень заполненности документации на высоком уровне.
Чтобы это были не только мечты, наша команда аналитиков задумалась, как претворить их в реальность. Нам хотелось, чтобы инструмент для поиска описания данных был удобным как библиотечный каталог с широким функционалом.
Меня зовут Костя Тюрин, я руковожу командой BI в СберМаркете. Год назад мы решили внедрить дата-каталог, и сейчас его MAU превышает количество аналитиков в два раза: им пользуется наша команда, а ещё дата-инженеры, менеджеры и команда ИБ. В статье делюсь нашим опытом внедрения DataHub’a и планами на дальнейшее развитие инструмента. Поехали!
Как мы поняли, что нам нужен дата-каталог
Как искали решение, которое удовлетворит всех
Внедрение DataHub: как поднимали систему и заполняли хранилище данными
Какие функции мы дописали сами
Что получилось в итоге и планы по развитию каталога
Рекомендации тем, кто решил внедрять дата-каталог
А точно ли нам нужен дата-каталог?
Если у вас нет единого места, где лежат все описания данных (или оно есть, но пользоваться им неудобно), то вы определенно в зоне риска. Иногда вопросы по данным до сих пор задаются в корпоративном мессенджере или в личку, иногда вся экспертность находится у двух-трёх человек, уход которых — риск потери информации.
В таких случаях для начала подойдет вариант использования внутренних вики. Но чем больше аналитиков в компании, количество таблиц, объема данных, отчетов, дашбордов, витрин, тем выше вероятность, что вскоре потребуется дата-каталог.
Мы в СберМаркете прошли именно такой путь. 2,5 года назад работать с данными нам было непросто. Мы описывали все дашборды и данные, на которых они строятся, во внутренней Wiki-системе, но через какое-то время актуальность такой системы стало сложно поддерживать из-за масштаба. К тому же поиск там оставлял желать лучшего.
Внедрение дата-каталога назревало ещё и потому, что аналитический отдел увеличивался и СберМаркет активно развивал data-driven культуру.
Про data-driven’ность и её оценку подробнее можно почитать в статье моего коллеги Вани Леонтьева.
Одновременно с этим у команды DWH и информационной безопасности появилась потребность в отслеживании полного lineage данных от источника до потребителя. Мы решили синхронизироваться с ними по этой задаче.
Так начался наш квест по разработке и внедрению дата-каталога.
Решение, которое удовлетворит всех
Для начала нужно было совместно решить, будет ли у нас самописная разработка или мы выберем что-то из имеющегося на рынке.
Мы начали с описания требований к дата-каталогу. Получился doc-файл на 7 страниц: 29 требований со стороны аналитиков и 7 от инжиниринга.
Это был мой первый опыт написания технического задания на создание приложения. Поэтому я старался максимально подробно описать бизнес-требования, а за технические отвечала команда DWH.
Примеры требований со стороны аналитики:
Владелец
Назначается через выбор пользователя, учётная запись которого была добавлена на сервис дата-каталога. Назначение пользователя происходит через выбор учетки в выпадающем меню.Описание (Description)
UI должен поддерживать стандартный набор инструментов для редактирования текста, включая:заголовки;
вставка таблиц;
ссылки;
вставка кода;
создание списков;
вставка изображений.
Для сервисов, базы данных, схем описание заполняется через UI.
Для таблиц и атрибутов описание заполняется через UI либо загружается автоматически из ddl.
Есть возможность настройки правил загрузки метаданных — описания таблиц и атрибутов. Например, при первичной загрузке метаданных описание тянется из ddl таблицы, далее описание может быть изменено пользователем через UI. При обновлении метаданных информация, которую занёс пользователь, не затирается данными из ddl.
Если в схеме появляется новая таблица или атрибут, то поле Описание загружается из ddl.Уровни важности сущностей (Tier)
Для таблиц есть возможность проставить уровень важности из нескольких доступных, например.Уровень важности 1 — критически важные таблицы, источники правды.
Уровень важности 2 — важные таблицы для бизнеса всей компании.
Уровень важности 3 — важные таблицы для определенного департамента.
Уровень важности 4 — важная таблица для команды.
Уровень важности 5 — личные таблицы или неиспользуемые таблицы.
Примеры требований со стороны инжиниринга:
Возможность программно обновлять метаданные. Минимальный набор: Kafka Connect, DBT, Airflow, Spark.
Возможность программно получить метаданные для объекта. Минимальный набор: Kafka Connect, DBT, Airflow, Spark.
Возможность программно осуществить bulk-export во внешнюю систему (iHub).
Возможность программно осуществить bulk-import из внешней системы (iHub).
Поддержка тегов на уровне таблиц.
Поддержка тегов на уровне полей.
Сквозной lineage через различные системы (Например Tableu → DBT (ClickHouse) → Spark → Kafka → Kafka Connect → Source Database).
Уже на этом этапе мы поняли, что разработка собственного каталога нам не подойдет: требований достаточно много, значит разработка будет слишком долгой и дорогой. Поэтому мы...
Изучили, что предлагает рынок. В открытых источниках мы нашли сравнение имеющихся на рынке инструментов. Это послужило отправной точкой для собственного исследования. Посмотрели, попробовали, обсудили различные варианты и составили шорт-лист из двух Opensource-решений: OpenMetadata и DataHub.
Для нас, аналитиков, OpenMetadata казался более подходящим: он был более user friendly, с понятным интерфейсом и функциями. Для команды DWH, напротив, этот инструмент не подходил вовсе. Так Что же делать, если одни хотят одно, другие — второе?
Вместе провели оценку инструментов по ключевым критериям. Я создал таблицу, где расписал основные требования для оценки. Туда вошли фичи по каждому из разделов: подключения, работа с метаданными, 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: как это было
Итак, начался процесс внедрения.
Стартовал деплой. Мы попросили DevOps’ов взять эту задачу как одну из целей на квартал. При раскатке вылезли некоторые трудности, связанные с внутренними правилами и ограничениями отдела ИБ. Вместе с последними мы разработали ролевую модель (из коробки она достаточно ограниченная и не всегда может лечь на оргструктуру компании) и начали пускать первых тестовых пользователей.
К слову, в плоско-организованных компаниях сложностей с внедрением возникнуть не должно, так как у DataHub’a отличные HELM-чарты. Если у вас нет ограничений по уровню доступов, то развернуть DataHub поверх K8S можно минут за 5.
Настроили ingest из dbt, чтобы все связи и документация хотя бы из одного хранилища данных автоматически проставлялась в DataHub.
Загрузили метаданные одного из наших BI-инструментов. На тот момент это был Metabase.
Загрузили метаданные таблиц из хранилища Clickhouse — порядка 3500 таблиц. Помимо Clickhouse, мы загрузили в DataHub метаданные из BI-инструментов и источников баз данных. По некоторым таблицам удалось настроить lineage автоматически — так, например, произошло дашбордами из Metabase.
Ура, у нас есть дата-каталог. Но есть нюанс, сейчс он пустой, поэтому таким инструментом никто не будет пользоваться — нужна документация по заполнению и ответственные.
Для начала решили, что 3500 таблиц — много и сформировали список топ-500 таблиц на основе частоты запросов за последние 3 месяца.
Подготовили обучение и сделали инструкцию, как заполнять таблицы. На корпоративной wiki подробно расписали, что обозначает каждая сущность в датасете и основные рекомендации по заполнению.
Разработали метрику «заполняемость» и сформулировали цели по росту для разных доменов: операции, продукт, BI, финансы, маркетинг. Для этого пришлось описать методологию расчета, которая отражает полноту описания сущностей в DataHub. Мы проставили флаги «обязательного» заполнения полей. Это означало, что, если хоть один из элементов, помеченных единичкой, был не проставлен у сущности определенного Tier, то таблица считалась не заполненной.
Настроили ETL для получения нужных данных. В DataHub нет встроенного удобного аналитического инструмента для отслеживания заполняемости. Это, кстати, был один из минусов выбранного решения по сравнению с тем же OpenMetadata. Поэтому мы написали свой ETL.
Начали заполнять документацию и построили дашборд для отслеживания заполняемости. Благодаря обучению и тому, что метрика заполняемости попала в цели командам, за месяц нам удалось заполнить 70% всех топ таблиц. Дата-каталог стал единой точкой входа с удобным поиском с удобным фильтром.
Тюнинг: функции, которые мы дописали своими руками
Этап внедрения у нас занял один квартал, дальше продолжили активнее заполнять каталог и думать над улучшениями. При выборе DataHub, понимали, что коробочного решения нам будет недостаточно, так что после внедрения мы дополнительно написали еще несколько инструментов.
Скрипты, которые автоматически копируют описания таблиц из Sandbox, если они уже были написаны, но пришло время для переезда в продовую схему.
Инструментарий для DataHub, который помогает автоматически отфильтровать персональные и чувствительные данные из хранилищ. Теперь сотрудники ИБ, заходя в DataHub, могут проставить галочки напротив таблиц и колонок, содержащих такие данные, и наши интеграции автоматически отфильтруют ПДН и чувствительные данные. Сейчас эта механика прошла стадию экспериментов и находится на этапе продуктивизации и последующего масштабирования.
Скрипт, который ежедневно проверяет изменения в структуре таблиц. Например, если было добавлено новое поле или изменено старое, отдел ИБ получает алерт и проверяет его на наличие ПДН.
Ещё один инструмент позволил автоматически тегировать таблицы. Как писал выше, у нас есть 3500 таблиц в ClickHouse, из них 500 самые популярные. Поэтому первый тег — это топ-таблица и есть другие уровни — Tier-1,2,3, 4 по уровню важности. Все новые таблицы, созданные в продовых схемах, автоматически тегируются как топ-таблицы, обязательные к заполнению.
Результаты и планы
В итоге DataHub стал популярным среди аналитиков, дата-инженеров, менеджеров, специалистов DWH и ИБ. Текущее значение WAU дата-каталога — 118. А ежемесячное количество пользователей около 200 человек. Когда к нам приходят новые аналитики, они очень рады, что есть такой подробно описанный каталог информации.
На этом останавливаться не хотим, поэтому дальше в планах:
Внедрить удобный процесс заполняемости описания метаданных. Основная сложность при внедрении каталога данных, с которой мы столкнулись, — это то, что довольно сложно убедить людей заполнять описания таблицы и остальную документацию. Но импульс дан, и сейчас если не заполнена та самая ТОП-таблица, можно найти ответственного и попросить внести данные в DataHub. Надо этот процесс улучшать и дальше.
Продолжить наполнение документацией и новыми источниками данных. В идеале мы хотим иметь все метаданные по сервисам и источникам в DataHub до того, как они подгружаются в хранилище данных и соответственно их описание.
Совместно с командой DWH автоматизировать полный lineage на основе скриптов из GitLab. У lineage есть сложности, связанные с тем, что в СберМаркете большое количество промежуточных узлов обработки и транспортов данных. Проинтегрировать их все за короткий срок хоть и хочется, но очень сложно.
Масштабировать инструмент по работе с персональными и чувствительными данными. Нам хочется, чтобы у компании было полное представление о том, какие данные есть, являются ли они персональными, где они находятся — всё это для дальнейшей автоматизации по предоставлению доступов. Также хочется, чтобы когда автоматика отрезает ПДН из нижних слоев хранилища, то в верхних слоях мы тоже максимально автоматически от них избавлялись, а теги перетекали наверх.
Провести сертификацию дашбордов второго уровня. Она подразумевает под собой описание фундаментальных метрик, которые у нас не меняются, а в DataHub есть для этого специальный раздел — Глоссарий. Его и начнем использовать.
Рекомендации тем, кто решил внедрять каталог
Внедрять ли дата-католог? Если ваша компания уделяет аналитике должное внимание и хочет развивать data-driven подход, то, однозначно, да. Чтобы эффективно использовать возможности данных, в них должен быть порядок.
Внедрять ли именно DataHub? Выбор решения зависит от вашей текущей инфраструктуры. Нам подошел DataHub, но уверен, что это решение универсальное. Обязательно пропишите все технические и бизнес требования и только потом решайте, что лучше и удобнее внедрить именно вам. Метод приоритизации с помощью весов разными командами горячо рекомендую, нам это помогло посмотреть на вопрос со всех сторон и принять решение, от которого выиграют все заинтересованные лица.
Главный инсайт для меня, что хоть для моей команды дата-хаб был нужен в качестве удобного интерфейса, команде DWH и ИБ он открыл возможность для реализации более глубоких задач (таких как автоматизация полного lineage и работа с персональными данными). Рекомендую и вам сходить к соседним командам — вместе проще затащить такой масштабный проект.
Буду рад ответить на вопросы в комментариях!
Product&data команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
