Как мы выбирали Data Catalog, но в итоге оставили все как есть

Меня зовут Никита Василюк, я инженер по работе с данными в департаменте данных и аналитики Lamoda. Я и моя команда занимаемся всем, что связано с распределенной системой хранения и обработки данных.

Периодически нам приходится отвечать на вопросы, где у нас лежат те или иные данные. Поэтому однажды мы решили провести эксперимент и внедрить Data Catalog, чтобы запросы приходили уже не к нам, а в систему. Например, если человеку понадобилась информация, связанная с заказами, он может перейти в систему, ввести слово order и найти все, что ему нужно по этой теме. Мы рассмотрели три инструмента и в итоге… не стали ничего менять. Рассказываю почему.

3-u3a9pgflwjumydo_mvgrw_apq.jpeg

В идеальном мире Data Catalog — это инструмент, в котором можно найти краткую сводку по данным в хранилище, увидеть их структуру, проследить lineage (путь данных от системы-источника до целевой таблицы), посмотреть profiling (краткую статистику по полям таблицы) и историю проверок качества данных, увидеть владельцев данных и запросить доступ. Сейчас у нас есть подобие этого каталога: все таблицы нашего хранилища описываются вручную аналитиками в Confluence.

Мы решили поставить небольшой эксперимент и представить, что было бы, если роль Data Catalog исполнял не Confluence, а другая система.


Требования к системе

Мы определили несколько важных требований к потенциальной системе, в которой бы начали строить Data Catalog:


  • Автоматический сбор данных из разных СУБД. Это позволит нам избавить аналитиков от ручного обновления описаний таблиц.
  • Отображение структуры датасета с понятными описаниями и полнотекстовым поиском по этой информации.
  • Web UI с поиском. Это очень важное требование, поскольку в первую очередь Data Catalog задумывается как инструмент для поиска метаданных.
  • Визуализация data lineage от системы-источника до отчета в BI-системе.
  • Отображение data owner. С помощью этого можно понять, к какому человеку обратиться по всем вопросам, связанных с данными.

Остальные требования входят в разряд «хотелок» — их наличие упростило бы жизнь, однако отсутствие не так критично:


  • SSO SAML авторизация;
  • визуализация Data Profiling;
  • визуализация Data Quality;
  • добавление кастомной информации для отображения;
  • трекинг изменения датасетов.

Мы решили рассмотреть три популярных open source проекта: Amundsen, LinkedIn DataHub и Marquez.


Amundsen

fcreuraiszbr7w3jnjll8fau4ek.png

Amundsen — это типичный справочник. То есть просто хорошая штука, чтобы поискать информацию по имеющимся таблицам. Он состоит из следующих сервисов:


  • neo4j — хранилище метаданных (также может использоваться Apache Atlas);
  • elasticsearch — поисковый движок;
  • amundsensearch — сервис для поиска по данным в Elasticsearch;
  • amundsenfrontendlibrary — Web UI (написан на Flask);
  • amundsenmetadatalibrary — отвечает за работу с метаданными в Neo4j или Atlas;
  • amundsendatabuilder — библиотека для извлечения данных из различных СУБД.

wsmgipnsyys9yxqaly_cpbnhcqq.png

Принцип работы довольно простой. ETL-процесс сбора метаданных состоит из извлечения записей из источника при помощи выполнения SQL-запросов, преобразования записей и их загрузки в хранилище метаданных. Extractor выполняет запрос к хранилищу метаданных и преобразует их в набор вершин и связей между ними. Промежуточные результаты сохраняются в локальную директорию. Transformer преобразует загруженные данные в нужную структуру. Loader подхватывает промежуточные данные и складывает их либо во временный слой, либо сразу в финальное хранилище. Publisher подхватывает промежуточные данные и отправляет в хранилище.

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

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

Плюсы:


  • автоматический сбор данных из разных СУБД;
  • API для добавления или редактирования данных в автоматическом режиме за счет обращения напрямую к Metastore/information_schema;
  • Web UI с полнотекстовым поиском;
  • поиск по базам, таблицам, полям и тэгам;
  • добавление кастомной информации для отображения (programmatic description)
  • визуализация data profiling (например, количество записей, дата последнего обновления, исторические значения);
  • визуализация data quality (какие проверки навешаны на датасет, история результатов проверок);
  • отображение data owner.

Минусы:


  • нет трекинга изменения датасетов (хранит только актуальное состояние и работает как справочник);
  • нет data lineage (источник можно идентифицировать только в блоке с кастомной информацией);
  • не нашли SSO-аутентификацию, доступна только OIDC;
  • полнотекстовой поиск работает только для тегов, таблиц, баз и колонок (нет возможности искать по описаниям колонок).

LinkedIn DataHub

drf7z1fk1hkd8boraq7bvuudjmq.png

Как можно понять из названия, это платформа поиска и обнаружения метаданных от LinkedIn. Из коробки она состоит из целого зоопарка сервисов:


  • kafka-broker — брокер Kafka;
  • zookeeper — координатор для Kafka;
  • kafka-rest-proxy — RESTful интерфейс для Kafka;
  • kafka-topics-ui — Web UI для топиков Kafka;
  • schema-registry — Kafka Schema Registry;
  • schema-registry-ui — Kafka Schema Registry UI;
  • elasticsearch — поисковый движок;
  • kibana — дашборд для Elasticsearch;
  • neo4j — графовая база данных;
  • datahub-gms — Generalized Metadata Store;
  • datahub-frontend — Web UI;
  • datahub-mae-consumer — сервис для обработки сообщений Metadata Audit Events;
  • datahub-mce-consumer — сервис для обработки сообщений Metadata Change Events;
  • mysql — база данных для хранения метаданных.

0x8ahbdlefmflax-nmdnj3sld_q.png

Основная сущность DataHub — dataset. Он может включать в себя таблицы (RDBMS и не только), топики в Kafka, директории на HDFS или другие сущности, имеющие схему.

Датасет имеет:


  • схему (включая типы и комментарии к полям),
  • статус (active или deprecated),
  • владельцев,
  • relationships (он же lineage),
  • docs с указанием ссылок на документацию.

Метаданные обновляются через отправку сообщений Metadata Change Event (MCE) в Kafka. MCE — это сообщение в формате AVRO с указанием пунктов, которые необходимо обновить. Гибкость обновления данных в системе достигается за счет возможности в одном сообщении обновить владельцев датасета, в другом — обновить схему, в третьем — upstream datasets.

Отличительная особенность DataHub — приятный веб-интерфейс. Он нам сразу понравился и запал в душу. У него все хорошо в плане поиска, обновлений типов таблиц и типов датасетов, информация о схеме датасета выглядит очень приятно. Можно добавлять владельцев датасетов, можно зайти в профиль пользователя и посмотреть, какими датасетами он владеет. У DataHub есть lineage, для каждого датасета можно наблюдать его взаимосвязи с другими объектами. Также есть возможность к каждому датасету прикладывать ссылки на документацию или исходный код.

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

Плюсы:


  • удобный UI с поиском;
  • автоматический сбор данных из разных СУБД (большая гибкость, поддерживает сбор данных не только из СУБД, работает для всего, у чего есть схема);
  • добавление или редактирование данных в автоматическом режиме через отправку AVRO-сообщений в Kafka;
  • добавление ссылок на документацию к датасету;
  • визуализация data lineage от источника до отчета в BI-системе (однако нет возможности отобразить всю цепочку сразу, отображается только upstream и downstream датасеты на один уровень вверх и вниз);
  • отображение data owner;
  • есть возможность сделать связку с интранетом компании.

Минусы:


  • огромное количество внутренних сервисов, за каждым из которых нужно следить;
  • отсутствует трекинг изменения датасетов;
  • data lineage показывает только upstream и downstream датасеты;
  • отсутствие визуализации data profiling;
  • отсутствие визуализации data quality (в roadmap на Q2 2021 есть пункт про отображение визуализаций и интеграцию с такими системами, как Great Expectations и deequ);
  • нет возможности добавить кастомную информацию для датасета;
  • нет возможности прослеживать изменения в датасетах;
  • поиск работает только для датасетов и пользователей.

Marquez

mflsdfo4hp0upvngga4hkxrrkvi.png

Третий инструмент — Marquez. Он состоит из основного приложения, базы данных и веб-интерфейса для отображения датасетов, джобов и связей между ними.

Метаданные в Marquez отправляются с помощью REST API. Еще он поддерживает создание следующих типов объектов:


  • data source — системы-источники;
  • dataset — таблицы, из которых читаются и в которые пишутся данные, обрабатываемые джобами;
  • job — абстракция над процессом трансформации данных, которая принимает таблицы на вход и записывают в них данные;
  • job run — запуск конкретной джобы.

4h5zgs3vv1tupjzoyjazuiuqbsy.png

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

Его самый главный минус — слишком минималистичный интерфейс, он плохо справляется с отображением lineage, в котором есть много таблиц и ветвлений. Нет возможности отображать владельца данных, нельзя в режиме справочника посмотреть, какие таблицы у нас есть. Нет возможности отображать информацию по качеству данных, по профилированию, невозможно добавить кастомную информацию. То есть Marquez — максимально простой инструмент, который может подойти для каких-то простых use-case«ов, но не подойдет для чего-то масштабного.

Плюсы:


  • быстрый и минималистичный UI;
  • поддержка airflow из коробки;
  • простая, но гибкая модель данных, позволяет с минимальным набором абстракций описывать данные;
  • понятный и простой API для добавления или редактирования данных;
  • Web UI с поиском;
  • есть lineage;
  • минимум компонентов.

Минусы:


  • слишком минималистичный UI;
  • отсутствует авторизация;
  • плохо работает в режиме «пробежаться глазами и посмотреть, какие данные вообще есть»;
  • не отображается data owner;
  • поиск работает только для датасетов и джобов;
  • нет возможности прослеживать изменения в датасетах;
  • отсутствует трекинг изменения датасетов;
  • отсутствует визуализация data profiling;
  • отсутствует визуализация data quality;
  • нет возможности добавить кастомную информацию для датасета.

Бонус: загоняем lineage из DWH в Neo4j

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

calsrba4zp8sdvmllw7xvxgbvoy.png

В первом подходе мы решили действовать в лоб: прошлись по всем таблицам в цепочке и соединили их промежуточными вершинами-джобами aka SQL-запросами, которые заполняют таблицу данными. Таким образом, получилось большое дерево связей, которое невозможно внятно читать (зато его забавно рассматривать и двигать).

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

lxhktitd0e4zo67d-g4v0xvop1o.png

Во втором подходе мы попробовали убрать джобы и просто связать таблицы между собой. Вершин в графе стало очевидно меньше, однако читать его легче не стало.
После этого мы загнали данные из Neo4j в инструмент под названием neo4j-explorer, который создан для более структурированного отображения графа из Neo4j.

bimgl-pv5no8ubu5brfq7cjux90.png

Зеленые блоки — джобы, серые — таблицы. Можно выделить джоб или таблицу и подсветить его зависимости в обе стороны. Несмотря на то, что выглядит это мощно (и напоминает кусок производства из игры Factorio), ничего полезного из этого мы вынести тоже не можем.


Что мы выбрали в итоге и почему не стали внедрять

В результате нашим фаворитом стал LinkedIn DataHub. Но мы поняли, что большинство текущих «хотелок» полностью покрываются Confluence, а у команд аналитиков сложились устоявшиеся процессы по работе с данными. Внедрять новую сложную систему и изменять текущие подходы к работе стоит только ради очень серьезных улучшений. Помимо этого, плюсы систем и их ограничения не перевешивают для нас трудоемкости внедрения и перехода.

Проведя Customer Development среди потенциальных пользователей, мы пришли к выводу, что ни одна из систем не поможет сэкономить рабочее время тех людей, которые работают с данными. При этом сложность внедрения и перестройки процессов будет существенной. Поэтому мы решили на какое-то время отложить выбор.

Мы отслеживаем развитие рассмотренных в статье сервисов, изучаем платные варианты Data Catalog и их возможности. Если у вас есть успешный (или не очень) опыт внедрения подобных систем, то поделитесь им в комментариях.

© Habrahabr.ru