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

Меня зовут Юрий Орлов, я тимлид команды Cloud ML Platform. В этой статье я подробно разберу, что такое каталоги данных и какие они бывают, а также расскажу о нашем выборе инструмента для построения каталога под запросы аналитиков данных.

Что такое data-каталоги

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

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

• Поиск и исследование данных: схемы данных, имена полей БД, теги, информация об использовании и запросах тех или иных данных.

• Контроль доступа к данным: группами и обычными пользователями, политики доступа policies.

• Отслеживание происхождения данных: исполнение пайплайнов подготовки данных, запросов в БД и/или API, логи API, схемы API.

• Работа с данными: конфигурация источников данных, конфигурация внесения данных, политики исключения/удаления данных из источников.

• Обеспечение объяснимости и воспроизводимости моделей AI: определение функции, определение модели, выполнение тренировочных прогонов обучения, постановка задачи.

• Операции с данными: выполнение последовательностей преобразования/подготовки данных (ETL), обработка разделов данных, статистика по наборам данных.

• Обеспечение и контроль качества предоставляемых данных: установка правил для повышения качества данных, статистика результатов работы правил, статистика по данным.

Каталоги данных можно формально разделить на две большие группы:

• Каталоги для построения пайплайнов ETL-процессов дата-инженерами. Вариант для ситуаций, когда точно известны местонахождение и формат данных.

• Каталоги для исследования данных дата-инженерами и дата-аналитиками. 

Поколения data-каталогов

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

• Первое поколение. Простейшие реализации, которые разрабатываются по принципу «здесь и сейчас» без детальной проработки и прицела на дальнейшее развитие. То есть приоритет именно на решении текущих задач.

• Второе поколение. Для него характерны глубокая проработка интеграций и процессов, а также активное задействование технологий по работе с данными.

• Третье поколение. Наиболее продвинутые реализации, которые включают максимальную автоматизацию рутинных процессов, в том числе обработки и загрузки метаинформации.

Архитектура каталогов первого поколения

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

• Есть источники данных — например, база данных и логи (запросов, очередей, приложений).

• Есть ETL-инструмент для поиска по индексу или полнотекстового поиска.

• Есть приложение с интерфейсом, через которое можно обращаться к разрозненным данным «под капотом» приложения.

К каталогам первого уровня (и инструментам для их построения) можно отнести Amundsen, Lexikon, Artifact и DataPortal.

У решений подобного класса есть как преимущества, так и недостатки. Среди плюсов:

• простая архитектура, которую легко поддерживать;

• минимальные требования к архитектуре и ресурсам команды администрирования.

Минусов больше:

• В таких каталогах можно использовать только pull-модель, что приводит к «хрупкости» доставки до источника метаданных. 

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

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

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

Архитектура каталогов второго поколения

Каталоги второго уровня обычно более функциональны. Поэтому их архитектура, в сравнении с реализациями первого уровня, более «прокачанная». При этом ключевые компоненты системы, как правило, неизменны:

• хранилище данных и логов;

• ETL-инструмент;

• хранилище метаданных;

• приложение с интерфейсом.

Алгоритм их работы примерно следующий:

• данные из хранилища поступают (push model) в слой кастомных ETL-процессов;

• выполняется обработка/очистка данных с утвержденными контрактами загрузки;

• данные доставляются (push model) в хранилище метаданных.

При этом в хранилище метаданных есть индексируемый полнотекстовый поиск и кластер с реплицируемыми БД, к которым подключен сервис метаданных. И всё это работает «под капотом» приложения.

К решениям этого поколения можно отнести:

• Collibra;

• Alation;

• Marquez (единственный Open-Source-инструмент).

У каталогов второго уровня ряд достоинств.

• Командам, которые генерируют данные, легко взаимодействовать с командой очистки метаданных, поскольку есть готовые и описанные Push API.

• Команда поддержки метаданных может использовать программируемые варианты загрузки и фильтрации данных, а также предусматривать программируемое поведение на основе тех или иных данных. 

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

Но каталоги второго поколения не лишены и недостатков. Среди них:

• Отсутствие журнала изменений. Контракты помогают организовать чтение и запись метаданных, но потоковой передачи изменений метаданных из внешних систем или подписки на поток изменений нет. В результате становится сложно править баги и апдейтить индекс, а также трудно обнаруживать неконтролируемый доступ.

• Сохранение зависимости от центральной команды по работе с метаданными. То есть нет возможности распределенной работы, а часть задач может пересекаться с командой data-warehouse, если таковая есть в компании.

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

Архитектура каталогов третьего поколения

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

Так, в data-каталогах третьего уровня поставщик метаданных может использовать потоковый API или выполнять CRUD-операции с сервисным API каталога. При этом изменения в метаданных приводят к созданию журнала изменений метаданных, который может быть автоматически доставлен в соответствующие хранилища и индексы (например, поисковый индекс, графовый индекс, озеро данных, OLAP-хранилище) для всех необходимых шаблонов запросов. В результате получается разветвленная архитектура БД метаданных. То есть в случае возникновения каких-либо несоответствий появляется возможность по желанию загрузить, например, свой поисковый индекс и исправлять ошибки.

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

Среди решений третьего поколения можно выделить DataHub (один из немногих data-каталогов этого поколения в Open Source), ApachAtlas, Egeria и Uber DataBook. 

К плюсам каталогов третьего поколения относится:

• гарантированная «свежесть» данных;

• отсутствие зависимости от центральной команды аналитиков и разработчиков;

• низкие задержки при поиске данных;

• поддержка полнотекстового и ранжированного поиска;

• возможность «пристраивания» ETL-процессов поверх метаданных без ущерба их согласованности и «свежести»;

• возможность обработки в отдельной таблице метаданных.

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

Наш кейс: выбор решения для построения публичного сервиса

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

С учетом предполагаемых сценариев использования и запросов к искомому решению нам подходило всего несколько вариантов:

• Amundsen;

• Marquez;

• OpenMetadata;

• DataHub.

При выборе и сравнении инструментов мы решили учитывать ряд базовых параметров:

• готовность для развертывания в K8s;

• имеющиеся и отсутствующие компоненты;

• используемые технологии;

• системы авторизации;

• доступные интеграции с приложениями по работе с данными.

Amundsen

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

Для развертывания Amundsen в Kubernetes нужны:

• Helm 2.14+;

• Kubernetes 1.14+;

• Elasticsearch 7.13.4.

При этом в Amundsen есть:

• полнотекстовый поиск (только для тегов, таблиц, баз и колонок);

• хранилище метаданных;

• Programmatic Description;

• визуализация Data Profiling;

• визуализация Data Quality;

• отображение Data Owner.

Одновременно с этим в решении:

• отсутствует Data Lineage;

• нет сохранения истории изменений данных (дата-сетов);

• полнотекстовый поиск не работает для описания колонок.

Основной язык программирования для Amundsen — Python 3.6. Для работы с UI используется Flask + Jinja2 + JavaScript. 

В качестве системы авторизации в Amundsen предусмотрена OIDC.

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

• Коннекторы дашбордов: Apache Superset, Mode Analytics, Redash, Tableau, Databricks SQL.

• Коннекторы ETL: Apache Airflow.

Marquize

Marquize — Open-Source-решение для сбора, агрегирования, визуализации данных и метаданных. 

Marquize представляет собой модульную систему, разработанную как масштабируемое, расширяемое решение для управления метаданными. Оно состоит из трех ключевых компонентов:

• Хранилище метаданных. Хранит все метаданные задания и набора данных, включая полную историю запусков заданий и статистику на уровне заданий (например, общее количество запусков, среднее время выполнения, успех/неудачи).

• API метаданных. RESTful API, позволяющий клиентам взаимодействовать с метаданными при создании и потреблении набора данных.

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

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

Для развертывания Marquize в K8s достаточно Helm 2.14+ и Kubernetes 1.14+.

Что касается доступных компонентов и функций, то в Marquize предусмотрены:

• быстрый и минималистичный UI с простым поиском;

• поддержка Airflow из коробки;

• простая, гибкая модель данных;

• понятный и простой API для добавления или редактирования данных;

• формирование Data Lineage;

• визуализация Data Quality.

При этом Marquize не лишен и недостатков. Так, в инструменте:

• слишком простой и недоработанный UI;

• отсутствует авторизация;

• не отображается Data Owner;

• поиск работает только для дата-сетов и джобов;

• нет возможности прослеживать изменения в дата-сетах;

• нет сохранения истории изменений данных (дата-сетов);

• отсутствует визуализация Data Profiling;

• нет Programmatic Description.

В качестве основного языка программирования Marquize предлагает использовать Java 17, а для UI — TypeScript (React). Встроенной системы авторизации в решении нет. При этом Marquize не может похвастаться большим разнообразием готовых интеграций — глобально они сводятся к коннектору ETL для Apache Airflow.

OpenMetadata

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

Для развертывания OpenMetadata нужны Helm 2.14+, Kubernetes 1.14+, Elasticsearch 7.13.4 и MySQL. Примечательно, что все решения могут быть установлены on-prem.

К числу преимуществ OpenMetadata относят:

• удобный UI;

• формирование Data Lineage;

• визуализацию Data Lineage от источника до отчета в BI-системе;

• отображение Data Owner;

• автоматический сбор данных из разных источников.

Недостатков у инструмента несколько. 

• Добавление или редактирование данных в автоматическом режиме выполняется через отправку AVRO-сообщений в Kafka.

• В OpenMetadata модульная архитектура, которая позиционируется как микросервисная, но таковой не является — по сути это монолит с подключаемыми модулями. 

• В инструменте нет автоматизации редактирования данных.

DataHub

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

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

В части развертывания в Kubernetes — самое сложное и «требовательное» решение. Так, для развертывания нужны:

• Helm 2.14+;

• Kubernetes 1.14+;

• Elasticsearch 7.13.4;

• MySQL;

• Kafka;

• Neo4J (не обязательно).

Среди достоинств DataHub можно выделить:

• удобный UI с поиском;

• возможность формирования Data Lineage;

• визуализацию Data Lineage от источника до отчета в BI-системе;

• визуализацию Data Profiling (может отрабатывать медленно при запросах в множество таблиц);

• отображение Data Quality;

• отображение Data Owner;

• автоматический сбор данных из разных источников;

• добавление или редактирование данных в автоматическом режиме через отправку AVRO-сообщений в Kafka;

• возможность добавления ссылок на документацию к дата-сету.

Без недостатков тоже не обходится. Так, в DataHub:

• нет сохранения истории изменений данных (дата-сетов);

• Data Lineage присутствует в ограниченном виде;

• отсутствует визуализация Data Profiling;

• нет возможности добавить кастомную информацию для дата-сета;

• нет возможности прослеживать изменения в дата-сетах;

• поиск работает только для дата-сетов и пользователей.

Основными языками программирования в DataHub являются Java (Core) и Python 3.7, а технологией для работы с UI — TypeScript (React).

В качестве системы авторизации DataHub предлагает Policies Engine.

Что важно, DataHub имеет наиболее широкий пул готовых интеграций. Среди них:

• Коннекторы дашбордов: Redash, Tableau, PowerBI.

• Коннекторы ETL: Apache Airflow, MLflow, Spark, Presto, S3, Trino, Glue, Athena, DataBricks, DeltaLake, Elasticsearch, Kafka, Kafka Connect.

По функционалу DataHub похож на OpenMetadata. Но, в отличие от конкурента, у DataHub микросервисная архитектура с поддержкой гибких настроек скалирования, а также предусмотрена автоматизация редактирования данных.

Что в итоге: наш выбор

После анализа и сравнения инструментов для своих задач мы решили использовать DataHub. Причин выбора в его пользу много:

• является системой третьего поколения (по заявлению авторов);

• развертывание в Kubernetes с помощью чартов;

• есть много коннекторов для работы с БД и ETL из коробки;

• авторизация через Policy Engine, есть интеграция с LDAP;

• есть интеграция с MLflow, Spark, Kafka, Kafka Connect при помощи расширений;

• активно поддерживается и развивается сообществом.

Краткие выводы

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

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

Попробуйте ML Platform от VK Cloud — она помогает построить процесс работы с ML-моделями от дизайна до деплоя, контролировать качество экспериментов и моделей. Для тестирования мы начисляем новым пользователям 3000 бонусных рублей и будем рады вашей обратной связи.

Stay tuned

Присоединяйтесь к телеграм-каналу «Данные на стероидах». В нем вы найдете все об инструментах и подходах к извлечению максимальной пользы из работы с данными: регулярные дайджесты, полезные статьи, а также анонсы конференций и вебинаров.