Каталог данных на примере DataHub. Часть I

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

Необходимость внедрения Data Catalog зависит от размера компании и сложности бизнеса. Крупные компании предпочитают внедрить какое-либо дорогостоящее вендорское ПО (список можно найти здесь), или разработать свое решение (как, например, это сделали в  Магните и Тинькофф).

Ну а если у вас нет ресурсов ни на то, ни на другое, но вы уже прочувствовали всю боль “плохих” данные, сложность ведения документации в Confluence, испытали проблемы с пониманием, какие вообще данные у вас есть, можно начать с open-source проектов.

Наиболее популярные open-source инструменты Data Catalog:

  • Apache Atlas

  • Amundsen Lyft

  • LinkedIn DataHub

  • Netflix Metacat

  • OpenMetadata

  • Open Data Discovery

Требования, которым должен соответствовать каталог данных, могут различаться от компании к компании, но можно выделить несколько основных:

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

  • понятный пользовательский интерфейс;

  • визуализация data lineage;

  • возможность поиска по ключевым словам, бизнес-терминам;

  • отображение структуры данных;

  • отображение data owner;

  • возможность интеграции с другими инструментами data management (airflow, great-expectations, dbt и т.д.);

  • управление доступом.

Welcome to DataHub!

Развернутая архитектура DataHub представлена ниже:

Изображение взято с сайта https://datahubproject.io/
Изображение взято с сайта https://datahubproject.io/

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

Pull-based интеграция обеспечивается за счет расширяемой библиотеки Python для извлечения метаданных из внешних систем (Postgres, Snowflake, MySQL и т.д.).

Push-based позволяет обновлять метаданные в момент их изменения (например, AirFlow, Great Expectations). Мы можем передать изменения с помощью Kafka, REST или эмиттера Python. 

Метаданные поступают на так называемый уровень обслуживания. Центральный компонент этого уровня — служба метаданных.

Изображение взято с сайта https://datahubproject.io/
Изображение взято с сайта https://datahubproject.io/

Служба метаданных предоставляет 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, и о том, как можно отслеживать изменение метаданных на платформе)

Источник: https://habr.com/ru/articles/748350/


Интересные статьи

Интересные статьи

Перед вами вторая часть из серии материалов, состоящей из двух публикаций. Здесь я предлагаю практическое руководство по архитектуре ML-проекта, освоение которого позволит вам оценить качество автомат...
В предыдущей части были описаны подходы, примененные при написании парсера для схемы MTProto. Статья получилась чуть более общей, чем я рассчитывал, на этот раз я постараюсь рассказать бо...
Хочу поделиться опытом проектирования, монтажа и эксплуатации своей системы приточной вентиляции совмещенной с канальным кондиционером. Система собиралась в 2012-2013 годах и с тех пор находит...
В этой самоизоляционной статье я расскажу о разварке проволочных микровыводов (англ. wire bonding). В контексте печатных плат речь пойдёт о технологии монтажа кристаллов на печатную плату (англ. ...
Введение В первой части статьи мы дали краткое описание механизма encrypted SNI (eSNI). Показали каким образом на его основе можно уклоняться от детектирования современными DPI-системами (на при...