Data catalog что это
Как мы создали custom resource в Informatica EDC и пронесли его в Axon
Привет! Меня зовут Яна, я администратор Data Governance в Билайне. Этот туториал будет о том, как сконнектить то, что вендор коннектить не планировал. Речь пойдет о связи QlikSense c Informatica Enterprise Data Catalog (EDC) и Informatica Axon (Axon).
EDC – это умный каталог данных, который предоставляет единое представление метаданных, а Informatica Axon объединяет знания всех пользователей, позволяя выстроить и поддерживать в актуальном состоянии систему наиболее значимых для бизнеса информационных активов.
Зачем вообще их коннектить?
В Qlik Sense есть стримы, принадлежащие дирекциям, департаментам и отделам, каждый из этих стримов содержит набор дашбордов, например: считать трафик, количество пользователей в месяц, наиболее популярные услуги и прочее.
Количество стримов и дашбордов стремительно растет. Чтобы как-то ими управлять, ребятам из Qlik team приходилось вести каталог с паспортами дашбордов вручную на корпоративном портале. На это тратилось много времени и периодически возникали ошибки заполнения.
Встала задача — вести паспорта дашбордов в общем Каталоге данных, при этом максимально автоматизировать занесение информации:
Расположение дашборда (Стрим- папка)
Наборы мер и измерений
А ещё нам нужно было привязывать бизнес-термины к конкретным дашбордам для ответов на вопросы типа «А в каких дашбордах я могу посмотреть на Активную абонентскую базу?»
Дано:
— Informatica Enterprise Data Catalog v10.4.1
— Informatica Axon v7.1
Прежде, чем начать: про технику
Мы создали шаблон паспорта дашборда в каталоге, нарезали поля для автоматического заполнения, поля для заполнения пользователями вручную, пропустили шаблон через Qlik team и начали автоматизировать.
Ход процесса
Встроенный коннектор EDC предполагает поддержку версии QlikSense только 2019 года, а на дворе у нас был февраль 2021. Вариант с даунгрейдом не рассматривался, доработка от вендора заняла бы непрогнозируемое количество времени. EDC предлагает возможность разработать коннектор к системам самостоятельно.
1. Первое, что понадобится — это создать custom model, которая отображала бы всю структуру, взаимосвязи между объектами, классы и их описание. У нас она выглядит так (часть модели):
В данном случае модель основана на двух интегрированных системных моделях: Core и BI (Business intelligence)
2. Теперь нужно создать и загрузить модель в каталог
Экспортировать шаблон файлов links.csv (связи метаданных внутри ресурса) и objects.csv (атрибуты для всех классов) и заполнить согласно структуре qlik.
bi.qlik.HubStream,qlik_beeline_ru,qlik_beeline_ru/001 Unified KPI [TECH]
bi.qlik.StreamApplication,qlik_beeline_ru/001 Unified KPI [TECH],qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month
bi.qlik.ApplicationSheet,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)
bi.qlik.ApplicationTable,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/TBL_REP_REV_M_end
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/Total Revenue B2B over time
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/ARPU Vizlib
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/4f5ceb4b-ec13-4ab6-b518-2b54ef97e148
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/Total Revenue by market segment
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/2a29b7b2-581d-4281-b691-5223251172bf
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/5361730d-0f48-4063-aa13-4a4377f36077
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/a0213872-db28-4037-99b5-e6f1952ff2e8
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/SRapyTC
bi.qlik.SheetChart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/MJajU
bi.qlik.TableColumn,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/TBL_REP_REV_M_end,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/TBL_REP_REV_M_end/market_key
bi.qlik.Stream,qlik_beeline_ru/001 Unified KPI [TECH],001 Unified KPI [TECH],Stream,001 Unified KPI [TECH].
bi.qlik.Application,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month,Revenue Month,Dashboards,Revenue Month. 09.08.2021 14:17,
bi.qlik.Table,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/TBL_REP_REV_M_end,TBL_REP_REV_M_end,SourceTable,TBL_REP_REV_M_end.
bi.qlik.Sheet,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars),Revenue month (Vertical bars),Dashboard,Revenue month (Vertical bars).
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/Total Revenue B2B over time,Total Revenue B2B over time,Linechart Total Revenue,Total Revenue B2B over time.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/ARPU Vizlib,ARPU Vizlib,ARPU Linechart,ARPU Vizlib.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/4f5ceb4b-ec13-4ab6-b518-2b54ef97e148,4f5ceb4b-ec13-4ab6-b518-2b54ef97e148,Total Revenue by Regions,4f5ceb4b-ec13-4ab6-b518-2b54ef97e148.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/Total Revenue by market segment,Total Revenue by market segment,Barchart Total Revenue by market segment,Total Revenue by market segment.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/2a29b7b2-581d-4281-b691-5223251172bf,2a29b7b2-581d-4281-b691-5223251172bf,Barchart Total Revenue by service,2a29b7b2-581d-4281-b691-5223251172bf.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/5361730d-0f48-4063-aa13-4a4377f36077,5361730d-0f48-4063-aa13-4a4377f36077,Barchart Total Revenue by stream,5361730d-0f48-4063-aa13-4a4377f36077.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/a0213872-db28-4037-99b5-e6f1952ff2e8,a0213872-db28-4037-99b5-e6f1952ff2e8,Barchart Commercial KPIs,a0213872-db28-4037-99b5-e6f1952ff2e8.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/SRapyTC,SRapyTC,Barchart Total Revenue by product stream,SRapyTC.
bi.qlik.Chart,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/Revenue month (Vertical bars)/MJajU,MJajU,Barchart Total Revenue factor analysis,MJajU.
bi.qlik.Column,qlik_beeline_ru/001 Unified KPI [TECH]/Revenue Month/TBL_REP_REV_M_end/market_key,market_key,Column,market_key.
Теперь, когда описание готово, мы можем проверить насколько верно и согласованно все выполнено с помощью утилиты валидации. Возможно, результат будет выглядеть так, и нужно будет исправить ошибки:
Но в итоге отчет станет таким:
All Validations Passed Successfully.You can now upload the files.
3. Cоздать custom resource в каталоге, куда нужно сложить модель и мету (links+objects).
Переходим в EDC LDMAdmin-New-Resource, создаем ресурс с именем Custom_Qlik, прикрепляем архив с нашими заполненными csv-файлами
Жмякаем save and run, и через некоторое время видим, что сканирование ресурса завершено успешно.
Проверяем в EDC Ldmcatalog, что у нас получилось, вводим в строке поиска qlik и видим, что наш дашборд Revenue Month появился, а также отображается кастомный ресурс Custom_Qlik, и все это собрано в глоссарий GlossaryforQlik.
Проваливаемся в глоссарий, где видим структуру, которая описана в модели.
Как мы выбирали Data Catalog, но в итоге оставили все как есть
Меня зовут Никита Василюк, я инженер по работе с данными в департаменте данных и аналитики Lamoda. Я и моя команда занимаемся всем, что связано с распределенной системой хранения и обработки данных.
Периодически нам приходится отвечать на вопросы, где у нас лежат те или иные данные. Поэтому однажды мы решили провести эксперимент и внедрить Data Catalog, чтобы запросы приходили уже не к нам, а в систему. Например, если человеку понадобилась информация, связанная с заказами, он может перейти в систему, ввести слово order и найти все, что ему нужно по этой теме. Мы рассмотрели три инструмента и в итоге… не стали ничего менять. Рассказываю почему.
В идеальном мире Data Catalog — это инструмент, в котором можно найти краткую сводку по данным в хранилище, увидеть их структуру, проследить lineage (путь данных от системы-источника до целевой таблицы), посмотреть profiling (краткую статистику по полям таблицы) и историю проверок качества данных, увидеть владельцев данных и запросить доступ. Сейчас у нас есть подобие этого каталога: все таблицы нашего хранилища описываются вручную аналитиками в Confluence.
Мы решили поставить небольшой эксперимент и представить, что было бы, если роль Data Catalog исполнял не Confluence, а другая система.
Требования к системе
Мы определили несколько важных требований к потенциальной системе, в которой бы начали строить Data Catalog:
Остальные требования входят в разряд «хотелок» — их наличие упростило бы жизнь, однако отсутствие не так критично:
Мы решили рассмотреть три популярных open source проекта: Amundsen, LinkedIn DataHub и Marquez.
Amundsen
Amundsen — это типичный справочник. То есть просто хорошая штука, чтобы поискать информацию по имеющимся таблицам. Он состоит из следующих сервисов:
Принцип работы довольно простой. ETL-процесс сбора метаданных состоит из извлечения записей из источника при помощи выполнения SQL-запросов, преобразования записей и их загрузки в хранилище метаданных. Extractor выполняет запрос к хранилищу метаданных и преобразует их в набор вершин и связей между ними. Промежуточные результаты сохраняются в локальную директорию. Transformer преобразует загруженные данные в нужную структуру. Loader подхватывает промежуточные данные и складывает их либо во временный слой, либо сразу в финальное хранилище. Publisher подхватывает промежуточные данные и отправляет в хранилище.
В целом Amundsen — хороший справочник, который может отображать текущее состояние данных, но, к сожалению, он не способен хранить историю. Мы не можем отследить, когда таблица или колонка была добавлена, удалена или модифицирована.
Во время тестирования Amundsen показался достаточно сырым — например, из коробки не было авторизации, а поиск работал только по тегам и названиям баз, таблиц и колонок, не было возможности искать по описаниям. Но он действительно хорошо работает, когда нужно посмотреть, какие данные есть у нас в схемах.
Плюсы:
Минусы:
LinkedIn DataHub
Как можно понять из названия, это платформа поиска и обнаружения метаданных от LinkedIn. Из коробки она состоит из целого зоопарка сервисов:
Основная сущность DataHub — dataset. Он может включать в себя таблицы (RDBMS и не только), топики в Kafka, директории на HDFS или другие сущности, имеющие схему.
Метаданные обновляются через отправку сообщений Metadata Change Event (MCE) в Kafka. MCE — это сообщение в формате AVRO с указанием пунктов, которые необходимо обновить. Гибкость обновления данных в системе достигается за счет возможности в одном сообщении обновить владельцев датасета, в другом — обновить схему, в третьем — upstream datasets.
Отличительная особенность DataHub — приятный веб-интерфейс. Он нам сразу понравился и запал в душу. У него все хорошо в плане поиска, обновлений типов таблиц и типов датасетов, информация о схеме датасета выглядит очень приятно. Можно добавлять владельцев датасетов, можно зайти в профиль пользователя и посмотреть, какими датасетами он владеет. У DataHub есть lineage, для каждого датасета можно наблюдать его взаимосвязи с другими объектами. Также есть возможность к каждому датасету прикладывать ссылки на документацию или исходный код.
Самый большой минус DataHub — он состоит из огромного числа компонентов. Плохо это тем, что за каждым надо следить и для каждого из них нужно настроить отказоустойчивость.
Плюсы:
Минусы:
Marquez
Третий инструмент — Marquez. Он состоит из основного приложения, базы данных и веб-интерфейса для отображения датасетов, джобов и связей между ними.
Метаданные в Marquez отправляются с помощью REST API. Еще он поддерживает создание следующих типов объектов:
Marquez на самом деле очень простой и не имеет в себе ничего лишнего. У него хорошая модель данных: абстракции, которые заложили в него разработчики, позволяют довольно полно описывать процессы обработки и трансформации данных.
Его самый главный минус — слишком минималистичный интерфейс, он плохо справляется с отображением lineage, в котором есть много таблиц и ветвлений. Нет возможности отображать владельца данных, нельзя в режиме справочника посмотреть, какие таблицы у нас есть. Нет возможности отображать информацию по качеству данных, по профилированию, невозможно добавить кастомную информацию. То есть Marquez — максимально простой инструмент, который может подойти для каких-то простых use-case’ов, но не подойдет для чего-то масштабного.
Плюсы:
Минусы:
Бонус: загоняем lineage из DWH в Neo4j
В качестве бонуса мы решили попробовать графовую базу данных Neo4j для отображения lineage. Источником данных стала сервисная таблица в нашем хранилище, в которой для каждой другой таблицы указано, какие объекты участвовали в ее формировании. Мы взяли три самых массивных представления и прошлись по их lineage вплоть до систем-источников.
В первом подходе мы решили действовать в лоб: прошлись по всем таблицам в цепочке и соединили их промежуточными вершинами-джобами aka SQL-запросами, которые заполняют таблицу данными. Таким образом, получилось большое дерево связей, которое невозможно внятно читать (зато его забавно рассматривать и двигать).
Очевидно, что ничего дельного из этого графа мы не вычленим: вершин слишком много, для просмотра полного названия каждой вершины на нее нужно сначала нажать и не промазать, а поиск интересующей таблицы в графе может занять много времени.
Во втором подходе мы попробовали убрать джобы и просто связать таблицы между собой. Вершин в графе стало очевидно меньше, однако читать его легче не стало.
После этого мы загнали данные из Neo4j в инструмент под названием neo4j-explorer, который создан для более структурированного отображения графа из Neo4j.
Зеленые блоки — джобы, серые — таблицы. Можно выделить джоб или таблицу и подсветить его зависимости в обе стороны. Несмотря на то, что выглядит это мощно (и напоминает кусок производства из игры Factorio), ничего полезного из этого мы вынести тоже не можем.
Что мы выбрали в итоге и почему не стали внедрять
В результате нашим фаворитом стал LinkedIn DataHub. Но мы поняли, что большинство текущих «хотелок» полностью покрываются Confluence, а у команд аналитиков сложились устоявшиеся процессы по работе с данными. Внедрять новую сложную систему и изменять текущие подходы к работе стоит только ради очень серьезных улучшений. Помимо этого, плюсы систем и их ограничения не перевешивают для нас трудоемкости внедрения и перехода.
Проведя Customer Development среди потенциальных пользователей, мы пришли к выводу, что ни одна из систем не поможет сэкономить рабочее время тех людей, которые работают с данными. При этом сложность внедрения и перестройки процессов будет существенной. Поэтому мы решили на какое-то время отложить выбор.
Мы отслеживаем развитие рассмотренных в статье сервисов, изучаем платные варианты Data Catalog и их возможности. Если у вас есть успешный (или не очень) опыт внедрения подобных систем, то поделитесь им в комментариях.
Что такое каталог данных Azure?
Для обновленных функций службы «Каталог данных» используйте новую службу Azure Purview, которая обеспечивает единое управление данными для всего пространства данных.
Каталог данных Azure — это полностью управляемая облачная служба. Она позволяет пользователям обнаруживать требуемые источники данных и изучать их. В то же время каталог данных помогает организациям получать большую отдачу от своих вложений.
С помощью каталога данных любой пользователь (аналитик, специалист по анализу и обработке данных или разработчик) может обнаруживать, распознавать и использовать источники данных. Каталог данных включает в себя модель совместной работы над метаданными и создание заметок. Это единое централизованное место, где все пользователи организации могут делиться знаниями для формирования сообщества и культуры данных.
Сложности обнаружения для потребителей данных
Как правило, обнаружение корпоративных источников данных является неотъемлемым процессом, основанным на общей информации, известной ограниченной группе лиц внутри компании. Это создает множество проблем для компаний, желающих извлечь максимум пользы из своих информационных ресурсов:
Сложности обнаружения для поставщиков данных
Хотя потребители данных сталкиваются с перечисленными ранее сложностями, пользователи, ответственные за создание и обслуживание информационных ресурсов, вынуждены решать собственные проблемы:
Вместе эти трудности образуют серьезный барьер для компаний, желающих способствовать и содействовать использованию и осмыслению данных предприятия.
Решение проблем с помощью каталога данных Azure
Каталог данных предназначен для того, чтобы решать эти проблемы и помогать предприятиям извлекать максимальную пользу из существующих у них информационных ресурсов. Благодаря каталогу данных источники данных легко обнаруживаются и являются понятными для пользователей, которые управляют данными.
Каталог данных предоставляет облачную службу, в которой можно зарегистрировать источник данных. Эти данные остаются в существующем расположении, однако копия этих метаданных добавляется в каталог данных вместе со ссылкой на расположение источника данных. Кроме того, чтобы облегчить обнаружение каждого источника данных с помощью функции поиска и сделать их доступными для пользователей, метаданные индексируются.
После регистрации источника данных его метаданные можно дополнить. Это может сделать пользователь, зарегистрировавший метаданные, или другие пользователи на предприятии. Любой пользователь может добавить комментарий к источнику данных, предоставляя описания, теги и другие метаданные, например документацию и инструкции по запросу доступа к источнику данных. Эти описательные метаданные дополняют структурные метаданные (например, имена столбцов и типы данных), зарегистрированные из источника данных.
Основной целью регистрации источников являются обнаружение, понимание и использование источников данных. Корпоративным пользователям могут потребоваться данные для бизнес-аналитики, разработки приложений, обработки и анализа данных или любой другой задачи, требующей корректных данных. Они могут использовать интерфейс обнаружения каталога данных, чтобы быстро найти соответствующие требованиям данные, оценить их целевую пригодность и использовать, открыв источник данных в выбранном средстве.
В то же время пользователи каталога данных могут дополнять его, помечая, документируя и добавляя комментарии к уже зарегистрированным источникам данных. Они также могут регистрировать новые источники данных, которые сообщество пользователей каталога сможет обнаруживать, распознавать и использовать.
Подробнее о каталоге данных
Чтобы получить дополнительные сведения о возможностях каталога данных, см. следующие статьи:
Дальнейшие действия
Чтобы начать работу с Каталогом данных, перейдите к следующим ресурсам:
Data Catalog
Oracle Cloud Infrastructure (OCI) Data Catalog is a metadata management service that helps data professionals discover data and support data governance. Designed specifically to work well with the Oracle ecosystem, it provides an inventory of assets, a business glossary, and a common metastore for data lakes.
Discover more about OCI Data Catalog.
Watch the Developer Live Event to get a hands-on experience on how OCI Data Catalog helps you gain insight into the data you have in Oracle Cloud and beyond.
Metadata harvesting
Harvest metadata from data sources across the Oracle Cloud Infrastructure ecosystem and on-premises to create an inventory of data assets. This helps data consumers easily find the data they need for analytics.
Harvest technical metadata and gain insight into data in OCI Object Storage, Oracle Autonomous Database, and more.
Support for Oracle on-premises sources
OCI Data Catalog harvests metadata from systems in private networks and on-premises, providing more expansive access to data.
Automatic harvesting
Utilize on-demand or schedule-based automatic harvesting to ensure the data catalog always has up-to-date information.
Unified metastore
Data engineers running Spark workloads in OCI Data Flow service can use OCI Data Catalog’s metastore as the central repository for metadata about the databases, tables, and partitions represented by files in an OCI Object Storage data lake. This helps increase reuse and collaboration with improved semantic consistency.
Search and discovery
With search, data consumers can gain details on data assets to see whether they are fit for use. Additional details of different data objects are also available for further exploration.
Search and browse
Data consumers can search based on technical names, business terms, and tags, and use filters to find objects of interest.
Browse objects based on system hierarchy
Through browsing, data consumers can easily locate data in the system hierarchy of available data sources, folders, files, and more.
Business glossary and metadata enrichment
Data stewards can manage enterprise glossaries with categories, subcategories, and business terms to build a taxonomy of business concepts. Other users can contribute their knowledge in the form of tags to make search more productive.