Поделиться через


Продукты данных аналитики в облаке в Azure

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

Рекомендации по проектированию

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

схема использования межданновой зоны приземления.

В приведенном выше примере показано:

  • Потребление данных внутри зоны:
    • Продукт данных B использует данные из продукта данных A и других продуктов данных или данных, существующих в озере данных в пределах собственной зоны приземления.
    • Продукты данных C и D используют данные только из собственных целевых зон данных.
  • Потребление данных между зонами:
    • Продукт данных B также использует данные из продукта данных C и данные из озера данных в зоне посадки 3.

Важный

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

Важный

Продукт данных B использует данные из продуктов данных A и C. Прежде чем это может произойти, продукт данных B должен зарегистрировать потребление продуктов данных с помощью соглашений об обмене данными. Это соглашение об обмене данными должно обновить происхождение от продукта данных A до продукта данных B и от продукта данных C до продукта данных B.

Группа ресурсов для продукта данных включает все службы, необходимые для создания и обслуживания. Мы можем назвать эту группу ресурсов приложением данных. Примеры служб, которые могут быть частью приложения данных, включают Функции Azure, Службу приложений Azure, Logic Apps, Azure Analysis Services, Azure Cognitive Services, Машинное обучение Azure, Базу данных SQL Azure, Базу данных Azure для MySQL и Azure Cosmos DB.

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

Рекомендации по проектированию

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

Развертывание нескольких групп ресурсов

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

схема групп ресурсов приложения данных.

Установка рамок

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

Важный

Чтобы обеспечить согласованность, настройте одну политику Azure для каждого приложения данных.

Использование данных из нескольких мест

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

Масштабируйте по мере необходимости

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

Включение обнаружения данных

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

Определение продуктов данных

На этапе планирования зоны высадки данных определите столько продуктов данных (и приложений данных, которые их создают и обслуживают), сколько необходимо для содействия разработке архитектуры приложений продуктов данных. Соответствие реализации системы управления платформой должно играть большую роль в ваших решениях.

Сосредоточьтесь на том, как ваши приложения данных являются производителями данных и потребителями для других пользователей. Например, предположим, что вы определили набор продуктов данных (A, B, C и D), которые создаются и используются. Вам требуются продукты данных A и D в качестве источников для данных в приложении данных B для продукта данных B. Продукт данных B создается из данных, которые приложение данных B использует из продуктов данных A и D. Приложение данных B выступает в качестве производителя данных, а также создает данные для продукта данных C.

схема производителя данных и потребителей.

Управление средой приложения данных с помощью инфраструктуры как кода

Управление и инфраструктура как код должны управлять средой приложения данных в экосистеме продуктов данных, как показано на предыдущей схеме.

Публикация моделей данных

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

Настройка ожиданий для пользователей продукта данных

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

Фиксация родословной

Если продукт данных B создаётся из данных, поступающих из продуктов данных A и D, происхождение данных должно быть зафиксировано от A и D к B. Происхождение данных следует также зафиксировать для продукта данных C, так как он создаётся на основе данных из продукта данных B. Обновленное происхождение данных должно быть зафиксировано в приложении управления происхождением данных перед каждым выпуском вашего продукта данных.

Заметка

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

Определение архитектуры приложения данных

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

Дальнейшие действия

приложениях данных (с выравниванием по источнику)