В современных компаниях генерируемые и собираемые объемы данных растут с поразительной скоростью, создавая необходимость в их систематизации и управлении. Каталоги данных становятся частью информационных систем, предоставляя организациям удобный и эффективный инструмент для хранения, доступа и управления различными типами данных.
Каталог данных — это центральное хранилище информации о структуре, свойствах и отношении между данными. Он позволяет различным пользователям легко находить, понимать и использовать данные для принятия решений и выполнения задач, и будет полезен аналитикам данных, бизнес-аналитикам, специалистам по DWH и управлению данными.
Необходимость внедрения Data Catalog зависит от размера компании и сложности бизнеса. Крупные компании предпочитают внедрить какое-либо дорогостоящее вендорское ПО (список можно найти здесь), или разработать свое решение (как, например, это сделали в Магните и Тинькофф).
Ну а если у вас нет ресурсов ни на то, ни на другое, но вы уже прочувствовали всю боль “плохих” данные, сложность ведения документации в Confluence, испытали проблемы с пониманием, какие вообще данные у вас есть, можно начать с open-source проектов.
Наиболее популярные open-source инструменты Data Catalog:
Требования, которым должен соответствовать каталог данных, могут различаться от компании к компании, но можно выделить несколько основных:
автоматическое обнаружение наборов данных из различных источников;
понятный пользовательский интерфейс;
визуализация data lineage;
возможность поиска по ключевым словам, бизнес-терминам;
отображение структуры данных;
отображение data owner;
возможность интеграции с другими инструментами data management (airflow, great-expectations, dbt и т.д.);
управление доступом.
Welcome to DataHub!
Развернутая архитектура DataHub представлена ниже:
DataHub имеет гибкую архитектуру приема метаданных, которая обеспечивает возможность поддерживать push и pull модели интеграции.
Pull-based интеграция обеспечивается за счет расширяемой библиотеки Python для извлечения метаданных из внешних систем (Postgres, Snowflake, MySQL и т.д.).
Push-based позволяет обновлять метаданные в момент их изменения (например, AirFlow, Great Expectations). Мы можем передать изменения с помощью Kafka, REST или эмиттера Python.
Метаданные поступают на так называемый уровень обслуживания. Центральный компонент этого уровня — служба метаданных.
Служба метаданных предоставляет API REST и API GraphQL для выполнения операций с метаданными. Запросы полнотекстового и расширенного поиска отправляются в поисковый индекс, а сложные графовые запросы, как, например, lineage — в индекс графа.
Любое изменение метаданных фиксируется в постоянном хранилище. Событие об этом поступает в журнал Metadata Change Log (Kafka), который создает служба метаданных. Поток этих событий — общедоступный API, на который могут подписаться внешние системы, что позволяет реагировать на изменения в метаданных (например, путем уведомлений в Slack).
Metadata Change Log используется заданием Spring, для внесения соответствующих изменений в графовый и поисковой индексы.
Настройка DataHub
Развернуть DataHub не составляет труда, достаточно установить необходимые библиотеки:
pip install ‘acryl-datahub’
и развернуть экземпляр DataHub в Docker:
datahub docker quickstart
Доступ к интерфейсу можно получить через браузер (http://localhost:9002).
По умолчанию создается root пользователь datahub с паролем datahub. Способ смены пользователя по умолчанию зависит от того, как развернут DataHub. Подробнее об этом можно прочитать здесь.
О поддержке концепции Data Mesh
Data Mesh — это децентрализованный подход к управлению данными. Данные хранятся в разных доменах и управляются экспертами в предметной области. При этом, данные должны быть общедоступны.
DataHub позволяет командам отображать их группы активов данных в домены (Domains) — категории верхнего уровня, например, все данные, принадлежащие организации продаж.
Также, команды или бизнес-группы могут связать свои данные со стандартными отраслевыми бизнес-терминами с помощью бизнес-глоссария (Business Glossary).
Рассмотрим эти концепции на примере.
P.S. Пример отражает мое понимание, и если я где-то не прав, прошу меня поправить)
Допустим, мы хотим создать домен Финансовые операции. В верхнем углу справа видим вкладку Govern:
Для создания домена нажимаем + New Domain
:
Добавляем некоторое описание нашему домену и сохраняем:
К домену мы можем добавить некоторые продукты данных. Обычно название соответствует логической цели продукта данных, например, "Кредитные операции", "Платежные операции" и т.д., и также привязывается к какому-либо активу или набору активов данных:
Далее мы хотим дополнить наше понимание данных и определить группу бизнес-терминов, которая относится к нашему домену. Идем на вкладу Glossary:
Давайте создадим группу терминов Финансы и добавим в эту группу несколько других терминов:
Термины можно перемещать в другие родительские группы, связывать несколько терминов глоссария с помощью отношений наследования и разбиения термина на подтермины.
Создадим еще несколько терминов и свяжем их между собой:
Можем убедиться, что подтермины правильно отображают родительский термин:
Надо заметить, что создание бизнес-глоссария и доменов требует разработки руководящих принципов, которым могли бы следовать команды, управляющие данными, чтобы использовать концепции метаданных одинаково.
В целом, набор концепций методанных, предоставляемый DataHub является хорошей отправной точкой и позволяет создавать комплексные модели данных.
Теперь мы можем легко связать наш актив данных с созданным доменом и бизнес-терминами.
Добавление источника данных
Здесь нет ничего сложного, DataHub поддерживает множество интеграций из коробки. На вкладке Ingestion можем увидеть доступные источники приема данных:
Также мы можем добавлять метаданные с помощью рецепта — это основной файл конфигурации, который сообщает сценариям приема, откуда извлекать данные и куда их помещать.
Давайте развернем локальную базу данных Postgres
с небольшим набором данных (отсюда), и подключим ее в DataHub. Клонировать репозиторий здесь.
docker compose -f "simple-postgres-container/docker-compose.yaml" up -d --build
Наша база данных доступна по адресу localhost:5432
. Теперь нам понадобится приконнектить наш контейнер к сети datahub_network
и узнать его IPAddress
(иначе мне не удалось подключиться):
docker network connect datahub_network postgresdb
docker inspect -f '{{ .NetworkSettings.Networks.datahub_network.IPAddress }}' postgresdb
Выбираем источник данных Postgres
и выполняем шаги по подключению:
Наша база данных успешно подключилась:
И если мы вернемся на стартовую страничку, увидим, что к нашим данным добавилась информация о платформе:
Теперь мы можем перейти к нашей табличке и связать с ней домен, пользователя, ответственного за этот актив, добавить термины, тэги и документацию:
Надо заметить, что на данный момент один актив данных может принадлежать только одному домену.
Также DataHub поддерживает установку тэгов — это неофициальные, свободно контролируемые ярлыки, которые служат для поиска и обнаружения данных, и призваны упростить маркировку данных без необходимости связывать их с более широким бизнес-глоссарием.
Заключение
Каталог данных — это отличный инструмент для решения проблем, связанных с обнаружением, понятностью и использованием данных. Данные должны быть хорошо задокументированы, чтобы показать, кто несет ответственность за их авторство, подробное описание, управление и качество.
DataHub отличная отправная точка для внедрения каталога данных в компании, с гибким функционалом и возможностью его расширения под свои потребности.
В следующей части погорим немного о политиках доступа, data lineage, и о том, как можно отслеживать изменение метаданных на платформе)
UPD Как справедливо заметили в комментарии, простота деплоя DataHub относится именнно к локальному развертыванию с помощью Docker. Легко поиграть, попробовать, что это такое. В боевой среде зоопарк компонентов это скорее минус DataHub, потому что требует значительных усилий для обслуживания и поддержания отказоустойчивости платформы.
Fa11en_Angel
"Развернуть DataHub не составляет труда"
Для тестов в собственном окружении, может быть, и не составит. Но собрать отказоустойчивую платформу - то ещё приключение. Как и с любым open-source, конечно
ArtDobryy Автор
Да, имел в виду именно локальный деплой) пожалуй, поправлю этот момент, спасибо)