Что такое каталог данных Azure?
Для обновленных функций службы «Каталог данных» используйте новую службу Azure Purview, которая обеспечивает единое управление данными для всего пространства данных.
Каталог данных Azure — это полностью управляемая облачная служба. Она позволяет пользователям обнаруживать требуемые источники данных и изучать их. В то же время каталог данных помогает организациям получать большую отдачу от своих вложений.
С помощью каталога данных любой пользователь (аналитик, специалист по анализу и обработке данных или разработчик) может обнаруживать, распознавать и использовать источники данных. Каталог данных включает в себя модель совместной работы над метаданными и создание заметок. Это единое централизованное место, где все пользователи организации могут делиться знаниями для формирования сообщества и культуры данных.
Сложности обнаружения для потребителей данных
Как правило, обнаружение корпоративных источников данных является неотъемлемым процессом, основанным на общей информации, известной ограниченной группе лиц внутри компании. Это создает множество проблем для компаний, желающих извлечь максимум пользы из своих информационных ресурсов:
Сложности обнаружения для поставщиков данных
Хотя потребители данных сталкиваются с перечисленными ранее сложностями, пользователи, ответственные за создание и обслуживание информационных ресурсов, вынуждены решать собственные проблемы:
Вместе эти трудности образуют серьезный барьер для компаний, желающих способствовать и содействовать использованию и осмыслению данных предприятия.
Решение проблем с помощью каталога данных Azure
Каталог данных предназначен для того, чтобы решать эти проблемы и помогать предприятиям извлекать максимальную пользу из существующих у них информационных ресурсов. Благодаря каталогу данных источники данных легко обнаруживаются и являются понятными для пользователей, которые управляют данными.
Каталог данных предоставляет облачную службу, в которой можно зарегистрировать источник данных. Эти данные остаются в существующем расположении, однако копия этих метаданных добавляется в каталог данных вместе со ссылкой на расположение источника данных. Кроме того, чтобы облегчить обнаружение каждого источника данных с помощью функции поиска и сделать их доступными для пользователей, метаданные индексируются.
После регистрации источника данных его метаданные можно дополнить. Это может сделать пользователь, зарегистрировавший метаданные, или другие пользователи на предприятии. Любой пользователь может добавить комментарий к источнику данных, предоставляя описания, теги и другие метаданные, например документацию и инструкции по запросу доступа к источнику данных. Эти описательные метаданные дополняют структурные метаданные (например, имена столбцов и типы данных), зарегистрированные из источника данных.
Основной целью регистрации источников являются обнаружение, понимание и использование источников данных. Корпоративным пользователям могут потребоваться данные для бизнес-аналитики, разработки приложений, обработки и анализа данных или любой другой задачи, требующей корректных данных. Они могут использовать интерфейс обнаружения каталога данных, чтобы быстро найти соответствующие требованиям данные, оценить их целевую пригодность и использовать, открыв источник данных в выбранном средстве.
В то же время пользователи каталога данных могут дополнять его, помечая, документируя и добавляя комментарии к уже зарегистрированным источникам данных. Они также могут регистрировать новые источники данных, которые сообщество пользователей каталога сможет обнаруживать, распознавать и использовать.
Подробнее о каталоге данных
Чтобы получить дополнительные сведения о возможностях каталога данных, см. следующие статьи:
Дальнейшие действия
Чтобы начать работу с Каталогом данных, перейдите к следующим ресурсам:
Как мы выбирали 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 и их возможности. Если у вас есть успешный (или не очень) опыт внедрения подобных систем, то поделитесь им в комментариях.
Первый полностью автоматизированный каталог данных
Удобное и простое формирование базы знаний о ландшафте данных и управление ей. Подключите источники данных, а остальное сделают автоматизированные алгоритмы и искусственный интеллект.
Слишком много данных?
Каталог данных — без лишних усилий
Удобное и простое формирование базы знаний о ландшафте данных и управление ею. Подключите источники данных, а остальное сделают автоматизированные алгоритмы и искусственный интеллект.
Медленные процессы или внедрение?
Автоматизируйте руководство данными
Автоматизируйте применение политик, бизнес-правил и классификацию данных.
На доступ к данным уходит слишком много времени?
Площадка для обмена данными — из коробки
Открывайте доступ к данным нужным пользователям в нужное время — с помощью автоматически применяемых политик безопасности и конфиденциальности.
Посмотрите, сколько информации Ataccama ONE генерирует автоматически
Оставайтесь в курсе. Никакой работы вручную.
Обнаружение изменений
Изменения в доменах и структурах данных в подключенных системах автоматически фиксируются и импортируются в каталог данных.
Самосовершенствующийся AI
Наш искусственный интеллект предлагает бизнес-правила, назначает бизнес-термины и находит новые взаимосвязи.
Легкий поиск нужных данных — с помощью подсказок AI, фильтрации и запросов на естественном языке
Забудьте о сложном техническом синтаксисе. Просто напишите, что вам нужно.
Каталог данных = площадка для обмена данными
Не ждите получения доступа к данным. Найдите нужное и сразу начинайте использовать.
Интеллектуальное централизованное определение политик
Определение и настройка политики управления данными в отношении маскирования, обезличивания и скрытия данных и метаданных.
Автоматическая защита данных
Ataccama ONE применяет политики ко всем соответствующим данным из каталога данных или за его пределами. Каждый видит то, что должен видеть.
Простое предоставление данных
Простая загрузка данных или их экспорт в BI платформу без необходимости ручного подтверждения. Защита данных — всегда на страже.
Данные постоянно меняются. С легкостью настраивайте мониторинг и очистку, а также
отслеживайте аномалии автоматически. Просто поставьте флажок.*
Подключите все источники данных
Подключайте к каталогу реляционные и NoSQL базы данных, озера данных, хранилища данных, облачные
хранилища, хранилища метаданных, потоки и файлы.
Azure Data Lake Storage
Microsoft SQL Server
И многие другие коннекторы.
Достигайте большего — благодаря автоматизированному каталогу данных
Профилирование данных
Для всех данных в каталоге генерируются профили данных. Система показывает количество дублей, частоту различных значений, закономерности и многое другое.
Расширенное происхождение данных
Для всех источников данных, подключенных к каталогу, определяется происхождение данных. Оно дополняется бизнес-терминами и сведениями о качестве данных, что полезно бизнес-пользователям, ИТ-специалистам и инженерам данных.
Мониторинг данных
Удобный мониторинг на предмет аномалий, проблем с качеством данных и изменений в структуре набора данных.
Каталог отчетов
Поиск и использование отчетов бизнес-аналитики, сопоставление их с данными в каталоге и понимание того, как они были созданы.
Классификация данных
Обнаружение бизнес-терминов, доменов данных, конфиденциальных данных и иных категорий, относящихся к вашей организации. ИИ может автоматически классифицировать наборы данных по указанию пользователя.
Исследование взаимосвязей
Ataccama ONE с помощью ИИ обнаруживает связанные и повторяющиеся наборы данных. Можно объединить их или использовать только наиболее актуальные.
Бизнес-глоссарий
Управление бизнес-терминами и соответствующими иерархиями из каталога данных. Определение связей с бизнес-правилами и политиками, отслеживание происхождения и качества данных на базе терминов и применение их в автоматизации.
Управление метаданными
Не просто каталог данных. Отслеживание KPI, учет отчетов, моделей машинного обучения, API, систем и практически чего угодно. Всё полностью настраивается.
Informatica Enterprise Data Catalog
Содержание
Informatica Enterprise Data Catalog обеспечивает инвентаризацию данных с помощью «умного» каталога данных.
2021: Enterprise Data Catalog 10.5 на платформе Nomad и Mongo DB
Informatica обновила Enterprise Data Catalog до версии 10.5. Об этом 30 июня 2021 года сообщила компания DIS Group. Одним из наиболее значимых изменений стало обновление архитектуры: решение перейдёт с платформы Hadoop на Nomad и Mongo DB. Смена технологического стека не отразится на работе пользователей: разработчики предусмотрели возможность бесшовного перехода на обновленную версию с сохранением всех данных. Кроме того, пользователи могут воспользоваться пошаговым руководством для быстрого перехода на платформу.
Решение Informatica Enterprise Data Catalog сохранило весь функционал, который был доступен в предыдущих версиях, требования к вычислительным ресурсам для работы решения также не изменились. В обновленной версии Enterprise Data Catalog добавлены сканеры для подключения к информационным системам-источникам, разбора SQL-кода и хранимых процедур, обновлен интерфейс системы поиска и выдачи результатов. Появилась панель дополнительной информации об объектах поисковой выдачи, где отображаются данные о дате последнего сканирования, ответственных лицах, происхождении данных (data lineage), а также описание, назначенные термины и другая полезная информация.
Также было добавлено пошаговое руководство пользователя Enterprise Data Catalog для быстрого знакомства и начала работы с инструментом. Кроме того, обновлен интерфейс отслеживания изменений в источниках данных.
2019: Функция Catalog of Catalogs
27 декабря 2019 года компания DIS Group сообщила, что в составе платформы управления данными Informatica Intelligent Data Platform с искусственным интеллектом (ИИ) CLAIRE появились дополнительные функции, среди которых – каталог каталогов Catalog of Catalogs (в решении Informatica Enterprise Data Catalog) и супермаркет данных Data Marketplace (в решении Informatica Axon Data Governance). Подробнее здесь.
Оптимизация алгоритмов ИИ
Компания DIS Group 5 июня 2018 года сообщила о том, что обновился Enterprise Data Catalog: были улучшены алгоритмы искусственного интеллекта, которые с ним работают. Также он получил умные API (программные интерфейсы приложения). API позволяют пользователям со своих приложений в один клик получать доступ к обширным данным Enterprise Data Catalog.
Реализована интеграция с Axon Data Governance.
Возможности Enterprise Data Catalog
Для обеспечения возможности эффективной работы при взрывном росте данных и бизнес-задачах, основанных на работе с данными, корпорация Informatica предлагает корпоративный каталог данных с механизмом индексирования на основе машинного обучения, который автоматически сканирует данные по всему предприятию, каталогизирует их в удобном виде с возможностью поиска и быстрой оценки данных для дальнейшего использования по всем бизнес-направлениям.
Informatica Enterprise Data Catalog позволяет создавать бизнес-классификации и связывать их с техническими данными, что облегчает дальнейшую работу, поиск и использование нужных в конкретной задаче данных.
Каталог данных, основанный на искусственном интеллекте позволит классифицировать и использовать все информационные активы компании.
Ключевые характеристики (на июнь 2018 года):
Концепции каталога данных Azure для разработчиков
Для обновленных функций службы «Каталог данных» используйте новую службу Azure Purview, которая обеспечивает единое управление данными для всего пространства данных.
Каталог данных Azure — это полностью управляемая облачная служба, предоставляющая возможности обнаружения источников данных и совместной работы над метаданными источников данных. Разработчики могут взаимодействовать с этой службой через интерфейс API REST. Для успешной интеграции с каталогом данных Azure разработчикам важно понимать концепции, реализованные в каталоге.
Основные понятия
В основе концептуальной модели каталога данных Azure лежат четыре основных понятия: каталог, пользователи, ресурсы и аннотации.
Каталог
Каталог содержит пользователей и ресурсы.
Пользователи
Пользователи являются субъектами безопасности, у которых есть разрешения на выполнение определенных действий в каталоге (поиск, добавление, изменение, удаление элементов и т. д).
Существует несколько различных ролей, которые может иметь пользователь. Дополнительные сведения о ролях приведены в разделе «Роли и авторизация».
Можно добавлять отдельных пользователей и группы безопасности.
Для управления доступом и идентификации пользователей каталог данных Azure использует Azure Active Directory. Каждый пользователь каталога должен быть членом Active Directory для учетной записи.
Активы
Каталог содержит ресурсы данных. Ресурс — это единица детализации, управляемая каталогом.
Детализация ресурса может быть разной в зависимости от источника данных. Для базы данных Oracle или SQL Server в качестве ресурса могут выступать таблица или представление. В службах SQL Server Analysis Services ресурсами могут быть меры, измерения или ключевые показатели эффективности. В службах SQL Server Reporting Services ресурсом может быть отчет.
Ресурс — это элемент, который добавляется в каталог или удаляется из него. Ресурс является единицей данных, получаемых в результате поиска.
Ресурс включает данные об имени, расположении и типе ресурса, а также аннотации с описанием ресурса.
Заметки
Аннотации — это элементы, представляющие метаданные ресурсов.
Примеры заметок: описание, теги, схема, документация и т. д. Полный список типов ресурсов и типов заметок см. в разделе Объектная модель ресурса.
Совместная работа над аннотациями и мнения пользователей (множественность мнений)
Важным аспектом каталога данных Azure является то, как он поддерживает совместную работу над метаданными в системе. В отличие от подхода wiki, где есть только одно мнение и оно принадлежит последнему написавшему, в модели каталога данных Azure возможно одновременное сосуществование нескольких мнений.
Этот подход отражает реальный мир корпоративных данных, в которых пользователи могут иметь различный взгляд на один и тот же ресурс:
В этом примере каждый пользователь — администратор базы данных, менеджер данных и аналитик — может добавить свое описание к одной и той же таблице, зарегистрированной в каталоге. Все описания сохраняются в системе и отображаются на портале каталога данных Azure.
Этот шаблон применяется к большинству элементов объектной модели. Поэтому в полезных данных JSON там, где можно было ожидать одноэлементный объект, часто встречаются массивы свойств.
Например в корневом ресурсе находится массив объектов описаний. Свойство массива называется «описанием». Объект описания имеет одно свойство — описание. Каждый пользователь, который набирает описание, получает объект описания, созданный для введенных им значений.
Затем можно выбрать способ отображения сочетания. Существует три различных шаблона отображения.
Объектная модель ресурса
Как описано в разделе «Ключевые концепции», объектная модель каталога данных Azure включает элементы, которые могут быть ресурсами или заметками. Элементы имеют свойства, которые могут быть обязательными или необязательными. Некоторые свойства применяются ко всем элементам. Некоторые свойства применяются ко всем ресурсам. Некоторые свойства применяются только к ресурсам определенного типа.
Свойства системы
| Имя свойства | Тип данных | Комментарии |
| TIMESTAMP | Дата и время | Время последнего изменения элемента. Это поле создается сервером при вставке и каждом изменении элемента. Значение этого свойства игнорируется во входных данных операции публикации. |
| ID | URI | Абсолютный URL-адрес элемента (только для чтения). Это уникальный адресуемый URI для элемента. Значение этого свойства игнорируется во входных данных операции публикации. |
| тип | Строка | Тип ресурса (только для чтения). |
| etag | Строка | Строка, соответствующая версии элемента, которую можно использовать для оптимистического управления параллелизмом при выполнении операций, изменяющих элементы в каталоге. Можно указать «*» для соответствия любому значению. |
Общие свойства
Эти свойства применяются ко всем корневым типам ресурсов и ко всем типам аннотаций.
| Имя свойства | Тип данных | Комментарии |
| fromSourceSystem | Логическое | Указывает, получены ли данные из исходной системы (например базы данных SQL Server или Oracle Database) или созданы пользователем. |
Общие свойства корневого ресурса
Эти свойства применяются ко всем типам корневых ресурсов.
| Имя свойства | Тип данных | Комментарии |
| name | Строка | Имя, полученное на основе данных о расположении источника данных |
| dsl | DataSourceLocation | Однозначно определяет источник данных и является одним из идентификаторов ресурса. (См. раздел о двойной идентификации.) Структура dsl зависит от протокола и типа источника. |
| dataSource | DataSourceInfo | Дополнительные сведения о типе ресурса. |
| lastRegisteredBy | SecurityPrincipal | Описание пользователя, который последним зарегистрировал этот ресурс. Содержит уникальный идентификатор пользователя (upn) и отображаемое имя пользователя (lastName и firstName). |
| containerID | Строка | Идентификатор ресурса-контейнера для источника данных. Это свойство не поддерживается для типа контейнера. |
Общие свойства неодноэлементной аннотации
Эти свойства применяются ко всем типам неодноэлементных аннотаций (аннотаций, которых может быть несколько на один ресурс).
| Имя свойства | Тип данных | Комментарии |
| ключ | Строка | Указанный пользователем ключ, однозначно определяющий аннотацию в текущей коллекции. Длина ключа не может превышать 256 символов. |
Типы корневых ресурсов
Типы корневых ресурсов — это типы, представляющие различные типы ресурсов данных, которые могут быть зарегистрированы в каталоге. Для каждого корневого типа существует представление, описывающее ресурс и аннотации, включенные в представление. Имя представления следует использовать в соответствующем сегменте <имя_представления>URL-адреса при публикации ресурса с помощью REST API.
| Тип ресурса (имя представления) | Дополнительные свойства | Тип данных | Разрешенные аннотации | Комментарии |
| Таблица («tables») | Описание Preview (Предварительный просмотр) | Таблица представляет любые табличные данные. Например, таблица SQL, представление SQL, таблица Analysis Services, многомерное измерение Analysis Services, таблица Oracle и т. д. | ||
| Мера («measures») | Описание | Этот тип представляет измерение Analysis Services. | ||
| measure | Столбец | Метаданные, описывающие измерение | ||
| isCalculated | Логическое | Указывает, вычисляется измерение или нет. | ||
| measureGroup | Строка | Физический контейнер для измерения | Ключевой показатель эффективности («kpis») | Описание Документация |
| measureGroup | Строка | Физический контейнер для измерения | ||
| goalExpression | Строка | Численное многомерное выражение или вычисление, которое возвращает целевое значение ключевого показателя эффективности. | ||
| valueExpression | Строка | Численное многомерное выражение, которое возвращает фактическое значение ключевого показателя эффективности. | ||
| statusExpression | Строка | Многомерное выражение, которое отражает состояние ключевого показателя эффективности в определенный момент времени. | ||
| trendExpression | Строка | Выражение MDX, которое оценивает значение ключевого индикатора производительности во времени. Тренд может быть любым критерием, основанным на времени и имеющим смысл в некотором бизнес-контексте. | ||
| Отчет («reports») | Описание | Этот тип представляет отчет для служб отчетов SQL Server | ||
| assetCreatedDate | Строка | |||
| assetCreatedBy | Строка | |||
| assetModifiedDate | Строка | |||
| assetModifiedBy | Строка | |||
| Контейнер («containers») | Описание | Этот тип представляет контейнер других ресурсов, таких как база данных SQL, контейнер больших двоичных объектов Azure или модель служб Analysis Services. |
Типы аннотаций
Типы аннотаций представляют типы метаданных, которые могут быть назначены другим типам в каталоге.
| Тип аннотации (имя вложенного представления) | Дополнительные свойства | Тип данных | Комментарии |
| Описание («descriptions») | Это свойство содержит описание ресурса. Каждый пользователь системы может добавлять собственное описание. Изменить объект описания может только пользователь, создавший его. (Администраторы и владельцы ресурса могут удалить объект Description, но не изменить его.) Система хранит описания пользователей отдельно. Таким образом формируется массив описаний для каждого ресурса (по одному для каждого пользователя, который добавил информацию о ресурсе, и, возможно, еще одно описание, которое содержит сведения, полученные из источника данных). | ||
| description | строка | Краткое описание ресурса (2–3 строки). | |
| Тег («tags») | Это свойство определяет тег для ресурса. Каждый пользователь системы может добавить несколько тегов для ресурса. Изменить объекты Tag может только создавший их пользователь. (Администраторы и владельцы ресурса могут удалить объект Tag, но не изменить его.) Система хранит теги пользователей отдельно. Таким образом, для каждого ресурса существует массив объектов Tag. | ||
| тег | строка | Тег, описывающий ресурс. | |
| FriendlyName («friendlyName») | Это свойство содержит понятное имя для ресурса. FriendlyName — это одноэлементная аннотация. Для ресурса можно добавить только одну аннотацию FriendlyName. Изменить объект FriendlyName может только создавший его пользователь. (Администраторы и владельцы ресурса могут удалить объект FriendlyName, но не изменить его.) Система хранит понятные имена пользователей отдельно. | ||
| friendlyName | строка | Понятное имя ресурса. | |
| Схема («schema») | Схема описывает структуру данных. Она содержит список имен (столбец, атрибут, поле и т. д.) и типов атрибутов, а также другие метаданные. Вся эта информация извлекается из источника данных. Schema — это одноэлементная аннотация. Для ресурса можно добавить только одну аннотацию Schema. | ||
| столбцы | Column[] | Массив объектов столбцов. Они описывают столбец с информацией, полученной из источника данных. | |
| ColumnDescription («columnDescriptions») | Это свойство содержит описание столбца. Каждый пользователь системы может добавить собственные описания для нескольких столбцов (не более одного на столбец). Изменить объекты ColumnDescription может только создавший их пользователь. (Администраторы и владельцы ресурса могут удалить объект ColumnDescription, но не изменить его.) Система хранит эти описания столбцов пользователей отдельно. Таким образом формируется массив объектов ColumnDescription для каждого ресурса (по одному на столбец для каждого пользователя, который добавил информацию о столбцах, и, возможно, еще один объект, который содержит сведения, полученные из источника данных). Свойство ColumnDescription слабо привязано к схеме, поэтому может оказаться несинхронизированным. ColumnDescription может описывать столбец, которого уже не существует в схеме. За синхронизацию описания и схемы отвечает автор. Источник данных также может иметь описание. Оно может быть представлено в виде дополнительных объектов ColumnDescription, создаваемых при запуске средства. | ||
| columnName | Строка | Имя столбца, на который ссылается это описание. | |
| description; | Строка | Краткое описание столбца (2-3 строки). | |
| ColumnTag («columnTags») | Это свойство содержит тег для столбца. Каждый пользователь системы может добавить несколько тегов для заданного столбца, а также теги для нескольких столбцов. Изменить объекты ColumnTag может только создавший их пользователь. (Администраторы и владельцы ресурса могут удалить объект ColumnTag, но не изменить его.) Система хранит эти теги столбцов пользователей отдельно. Таким образом, для каждого ресурса существует массив объектов ColumnTag. Свойство ColumnTag слабо привязано к схеме, поэтому может оказаться несинхронизированным. ColumnTag может описывать столбец, которого уже не существует в схеме. За синхронизацию тегов столбцов отвечает тот, кто производит запись. | ||
| columnName | Строка | Имя столбца, на который ссылается этот тег. | |
| тег | Строка | Тег, описывающий столбец. | |
| Эксперт («experts») | Это свойство содержит пользователя, который считается экспертом в наборе данных. Мнения экспертов (их описания) перемещаются в верхнюю часть списков описаний. Каждый пользователь может задавать своих собственных экспертов. Изменить объект эксперта может только пользователь, создавший его. (Администраторы и владельцы ресурса могут удалить объект Expert, но не изменить его.) | ||
| expert | SecurityPrincipal | ||
| Предварительный просмотр («previews») | Предварительный просмотр содержит моментальный снимок 20 верхних строк данных ресурса. Имеет смысл просматривать только некоторые типы ресурсов (например, таблицы, но не измерения). | ||
| предварительный просмотр | object[] | Массив объектов, представляющих столбцы. Каждый объект имеет сопоставление свойства на столбец со значением для этого столбца и строки. | |
| AccessInstruction («accessInstructions») | |||
| mimeType | строка | Тип mime содержимого. | |
| содержимое | строка | Инструкции для получения доступа к этому ресурсу-контейнеру данных. Это может быть URL-адрес, адрес электронной почты или набор инструкций. | |
| TableDataProfile («tableDataProfiles») | |||
| numberOfRows | INT | Количество строк в наборе данных | |
| размер; | long | Размер набора данных в байтах. | |
| schemaModifiedTime | строка | Время последнего изменения схемы. | |
| dataModifiedTime | строка | Время последнего изменения набора данных (добавление, изменение или удаление данных). | |
| ColumnsDataProfile («columnsDataProfiles») | |||
| столбцы | ColumnDataProfile[] | Массив профилей данных столбцов. | |
| ColumnDataClassification («columnDataClassifications») | |||
| columnName | Строка | Имя столбца, на который ссылается эта классификация. | |
| классификация; | Строка | Классификация данных в этом столбце. | |
| Документация («documentation») | Данный ресурс может иметь только одну связанную с ним документацию. | ||
| mimeType | строка | Тип mime содержимого. | |
| содержимое | строка | Содержимое документации |
Общие типы
Общие типы можно использовать в качестве типов свойств, но не элементов.
| Общий тип | Свойства | Тип данных | Комментарии |
| DataSourceInfo | |||
| sourceType | строка | Описывает тип источника данных. Например, SQL Server, база данных Oracle и т. д. | |
| objectType | строка | Описывает тип объекта в источнике данных. Например, «таблица», «представление для SQL Server». | |
| DataSourceLocation | |||
| protocol | строка | Обязательный. Описывает протокол, используемый для связи с источником данных. Например: `tds` для SQL Server, `oracle` для Oracle и т. д. Список поддерживаемых протоколов см. в разделе [Спецификация ссылки на источник данных](data-catalog-dsr.md), в столбце «Структура DSL». | |
| address | Словарь | Обязательный. Адрес — это набор данных, относящийся к протоколу. Он используется для определения источника данных, указанного в ссылке. Так как данные адреса относятся к определенному протоколу, это значит, что знать их нет смысла, не зная протокол. | |
| проверка подлинности | строка | Необязательный параметр. Схема проверки подлинности, используемая для связи с источником данных. Например, Windows, OAuth и т. д. | |
| connectionProperties | Словарь | Необязательный элемент. Дополнительные сведения о том, как подключиться к источнику данных. | |
| SecurityPrincipal | Cерверная часть не выполняет проверку указанных свойств в Azure Active Directory во время публикации. | ||
| upn | строка | Уникальный адрес электронной почты пользователя. Должен быть указан, если не задан objectId или используется контекст свойства «lastRegisteredBy», в противном случае необязателен. | |
| objectId | Guid | Удостоверение пользователя или группы безопасности Azure Active Directory. Необязательный элемент. Должен быть указан, если не задан upn, в противном случае необязателен. | |
| firstName | строка | Имя пользователя (для отображения). Необязательный элемент. Допустим только в контексте свойства «lastRegisteredBy». Не может быть указан при предоставлении субъекта безопасности для «roles», «permissions» и «experts». | |
| lastName | строка | Фамилия пользователя (для отображения). Необязательный элемент. Допустим только в контексте свойства «lastRegisteredBy». Не может быть указан при предоставлении субъекта безопасности для «roles», «permissions» и «experts». | |
| Столбец | |||
| name | строка | Имя столбца или атрибута. | |
| type | строка | тип данных столбца или атрибута. Допустимые для использования типы зависят от типа источника данных ресурса. Поддерживается только подмножество типов. | |
| maxLength | INT | Максимальная длина столбца или атрибута. Определяется по информации из источника данных. Применимо только к некоторым типам источников данных. | |
| точность | byte | Точность для столбца или атрибута. Определяется по информации из источника данных. Применимо только к некоторым типам источников данных. | |
| isNullable | Логическое | Указывает, разрешены ли значения null для этого столбца. Определяется по информации из источника данных. Применимо только к некоторым типам источников данных. | |
| expression | строка | Если значение представляет собой вычисляемый столбец, то это поле содержит выражение для этого значения. Определяется по информации из источника данных. Применимо только к некоторым типам источников данных. | |
| ColumnDataProfile | |||
| columnName | строка | Имя столбца | |
| type | строка | Тип столбца | |
| мин | строка | Минимальное значение в наборе данных | |
| max | строка | Максимальное значение в наборе данных | |
| avg | double | Среднее значение в наборе данных | |
| stdev | double | Стандартное отклонение для набора данных | |
| nullCount | INT | Число значений null в наборе данных | |
| distinctCount | INT | Число различающихся значений в наборе данных |
Удостоверение ресурса
Каталог данных Azure использует свойство protocol и свойства удостоверения из контейнера свойств address свойства DataSourceLocation dsl для создания удостоверения ресурса, используемого для адресации ресурса в каталоге. Например, свойства удостоверения для протокола TDS (поток табличных данных) — server, database, schema и object. Сочетание протокола и свойств удостоверения используется для создания удостоверения ресурса таблицы SQL Server. Каталог данных Azure предоставляет несколько встроенных протоколов источников данных, которые перечислены в спецификации ссылки на источник данных в разделе структуры DSL. Набор поддерживаемых протоколов можно расширить программно (см. справочник по REST API каталога данных). Администраторы каталога могут регистрировать пользовательские протоколы источников данных. В следующей таблице описаны свойства, необходимые для регистрации пользовательского протокола.
Спецификация пользовательского протокола источника данных
| Тип | Свойства | Тип данных | Комментарии |
| DataSourceProtocol | |||
| namespace | строка | Пространство имен протокола. Пространство имен должно содержать от 1 до 255 знаков и включать в себя одну или несколько непустых частей, разделенных точкой (.). Каждая часть должна включать в себя от 1 до 255 знаков, начинаться с буквы и содержать только буквы и цифры. | |
| name | строка | Имя протокола. Имя должно включать в себя от 1 до 255 знаков, начинаться с буквы и содержать только буквы, цифры и тире (-). | |
| identityProperties | DataSourceProtocolIdentityProperty[] | Список свойств удостоверения. Должен содержать по крайней мере одно свойство, но их должно быть не более 20. Пример: «server», «database», «schema», «object» — свойства удостоверения «tds». | |
| identitySets | DataSourceProtocolIdentitySet[] | Список наборов идентификаторов. Определяет наборы свойств удостоверения, которые представляют допустимое удостоверение ресурса. Должен содержать по крайней мере один, но не более 20 наборов. Пример: <"server", "database", "schema" и "object">— набор удостоверения для протокола TDS, который определяет удостоверение ресурса таблицы SQL Server. | |
| DataSourceProtocolIdentityProperty | |||
| name | строка | Имя свойства. Имя должно включать в себя от 1 до 100 знаков, начинаться с буквы и содержать только буквы и цифры. | |
| type | строка | Тип свойства. Поддерживаемые значения: «bool», boolean», «byte», «guid», «int», «integer», «long», «string», «url». | |
| ignoreCase | bool | Указывает, следует ли игнорировать регистр при использовании значения свойства. Можно указать только для свойств с типом «string». Значение по умолчанию — false. | |
| urlPathSegmentsIgnoreCase | bool[] | Указывает, следует ли игнорировать регистр в каждом сегменте пути URL-адреса. Можно указать только для свойств с типом «url». Значение по умолчанию — false. | |
| DataSourceProtocolIdentitySet | |||
| name | строка | Имя набора идентификаторов. | |
| properties | string[] | Список свойств удостоверения, включенных в этот набор идентификаторов. Не может содержать повторяющиеся значения. Каждое свойство, на которое ссылается набор идентификаторов, должно быть определено в списке «identityProperties» протокола. |
Роли и авторизация
Каталог данных Azure поддерживает авторизацию для выполнения операций над ресурсами и аннотациями.
Каталог данных Azure использует два механизма авторизации:
Существуют три роли: администратор, владелец и участник. Каждая роль имеет собственную область действия и права, указанные в следующей таблице.
| Роль | Область действия | Права |
| Администратор | Каталог (все ресурсы и аннотации в составе каталога) | Read, Delete, ViewRoles. ChangeOwnership, ChangeVisibility, ViewPermissions. |
| Владелец | Каждый ресурс (каждый корневой элемент) | Read, Delete, ViewRoles. ChangeOwnership, ChangeVisibility, ViewPermissions. |
| Участник | Каждый отдельный ресурс и аннотация | Read Update Delete ViewRoles Примечание: при лишении участника права Read (Чтение) он также лишается всех остальных прав |
Права Read, Update, Delete и ViewRoles применяются ко всем элементам (ресурсам и заметкам), а права TakeOwnership, ChangeOwnership, ChangeVisibility, ViewPermissions — только к корневому ресурсу.
Delete применяется к самому элементу, а также ко всем вложенным элементам и элементам, расположенным ниже по иерархии. Например, при удалении ресурса также удаляются все аннотации для этого ресурса.
Разрешения
Разрешение представляет собой список записей управления доступом. Каждая запись управления доступом назначает субъекту безопасности набор прав. Разрешения могут задаваться только для ресурсов (корневых элементов) и применяются к ресурсам и всем вложенным элементам.
В предварительной версии каталога данных Azure из всего списка разрешений поддерживается только право Read. Оно может использоваться для ограничения видимости ресурса.
По умолчанию любой пользователь, прошедший проверку подлинности, получает право доступа Read, распространяющееся на все элементы каталога. Это актуально за исключением случаев, когда видимость элементов каталога ограничена набором субъектов, заданным в разрешениях.
REST API
Для управления ролями и разрешениями можно использовать запросы на просмотр элементов PUT и POST. В дополнение к полезным данным элемента можно указать еще два системных свойства: roles и permissions.
permissions применимо только к корневому элементу.
владельца применима только к корневому элементу.
Примеры
Назначение роли участника при публикации элемента. Специальный субъект безопасности имеет следующий код объекта: 00000000-0000-0000-0000-000000000201. POST https://api.azuredatacatalog.com/catalogs/default/views/tables/?api-version=2016-03-30
Текст
Назначение владельцев и ограничение видимости для существующего корневого элемента: PUT https://api.azuredatacatalog.com/catalogs/default/views/tables/042297b0. 1be45ecd462a?api-version=2016-03-30
В теле запроса PUT не обязательно указывать полезные данные: запрос PUT можно использовать только для обновления ролей и/или разрешений.
