Подсистема приема данных, не зависящая от данных

Статья
07/11/2023

В этой статье объясняется, как реализовать сценарии подсистемы приема данных, не зависящие от данных, с помощью сочетания PowerApps, Azure Logic Apps и задач копирования на основе метаданных в Фабрика данных Azure.

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

Регистрация ресурса данных
Подготовка рабочего процесса и сбор метаданных
Планирование приема

Вы можете увидеть, как взаимодействуют эти возможности:

Схема возможностей регистрации данных и взаимодействия

Рис. 1. Взаимодействие возможностей регистрации данных.

На следующей схеме показано, как реализовать этот процесс с помощью сочетания служб Azure.

Схема процесса приема данных, не зависящей от обработчика данных

Рис. 2. Автоматизированный процесс приема.

Регистрация ресурса данных

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

Техническая информация: имя ресурса данных, исходная система, тип, формат и частота.
Сведения об управлении: владелец, стюарды, видимость (в целях обнаружения) и конфиденциальность.

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

Схема регистрации ресурса данных.

Рис. 3. Регистрация ресурса данных.

Рабочий процесс подготовки и запись метаданных

На этапе рабочего процесса подготовки вы проверяете и сохраняете данные, собранные на этапе регистрации, в хранилище метаданных. Выполняются этапы технической и бизнес-проверки, в том числе:

Проверка веб-канала входных данных
Активация рабочего процесса утверждения
Логическая обработка для активации сохранения метаданных в хранилище метаданных
Аудит действий

Схема рабочего процесса регистрации

Рис. 4. Рабочий процесс регистрации.

После утверждения запросов на прием рабочий процесс использует REST API Azure Purview для вставки источников в Azure Purview.

Подробный рабочий процесс для подключения продуктов данных

Схема приема новых наборов данных (автоматически)

Рис. 5. Прием новых наборов данных (автоматизация).

На рисунке 5 показан подробный процесс регистрации для автоматизации приема новых источников данных.

Регистрируются сведения об источнике, включая рабочую среду и среду фабрики данных.
Фиксируются ограничения формы, формата и качества данных.
Группы приложений данных должны указать, являются ли данные конфиденциальными (персональные данные). Эта классификация управляет процессом, в ходе которого создаются папки озера данных для приема необработанных, обогащенных и курируемых данных. Источник называет необработанные и обогащенные данные, а продукты данных — курируемые данные.
Субъект-служба и группы безопасности создаются для приема и предоставления доступа к набору данных.
Задание приема создается в хранилище метаданных Фабрики данных в целевой зоне данных.
API вставляет определение данных в Azure Purview.
После проверки источника данных и утверждения командой операций сведения публикуются в хранилище метаданных Фабрики данных.

Планирование приема

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

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

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

Рис. 6. Планирование приема ресурсов данных.

Подробный рабочий процесс для приема новых источников данных

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

Схема приема новых источников данных

Конвейер приема фабрики данных master считывает конфигурации из хранилища метаданных фабрики данных База данных SQL, а затем выполняется итеративно с правильными параметрами. Данные перемещается из источника на необработанный уровень в Azure Data Lake практически без изменений. Форма данных проверяется на основе хранилища метаданных Фабрики данных. Форматы файлов преобразуются в форматы Apache Parquet или Avro, а затем копируются в обогащенный слой.

Прием данных подключается к рабочей области обработки и инжиниринга данных Azure Databricks, а определение данных создается в хранилище метаданных Apache Hive целевой зоны данных.

Если для предоставления данных необходимо использовать Azure Synapse бессерверный пул SQL, пользовательское решение должно создавать представления данных в озере.

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

Захваченные метаданные

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

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

Операционные метаданные можно использовать для отслеживания следующего:

Задания, шаги заданий и их зависимости.
Производительность заданий и журнал производительности.
Рост объема данных.
Сбои заданий.
Изменения метаданных источника.
Бизнес-функции, зависящие от продуктов данных.

Использование REST API Azure Purview для обнаружения данных

Rest API Azure Purview следует использовать для регистрации данных во время первоначального приема. Вы можете использовать API для отправки данных в каталог данных вскоре после их приема.

Дополнительные сведения см. в статье Использование REST API Azure Purview.

Регистрация источников данных

Используйте следующий вызов API для регистрации новых источников данных:

PUT https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}

Параметры URI для источника данных:

Имя	Обязательно	Тип	Описание
`accountName`	True	Строка	Имя учетной записи Azure Purview
`dataSourceName`	True	Строка	Имя источника данных

Использование REST API Azure Purview для регистрации

В следующих примерах показано, как использовать REST API Azure Purview для регистрации источников данных с полезными данными:

Регистрация источника данных Azure Data Lake Storage 2-го поколения:

{
  "kind":"AdlsGen2",
  "name":"<source-name> (for example, My-AzureDataLakeStorage)",
  "properties":{
    "endpoint":"<endpoint> (for example, https://adls-account.dfs.core.windows.net/)",
    "subscriptionId":"<azure-subscription-guid>",
    "resourceGroup":"<resource-group>",
    "location":"<region>",
    "parentCollection":{
      "type":"DataSourceReference",
      "referenceName":"<collection-name>"
    }
  }
}

Регистрация источника данных Базы данных SQL:

{
  "kind":"<source-kind> (for example, AdlsGen2)",
  "name":"<source-name> (for example, My-AzureSQLDatabase)",
  "properties":{
    "serverEndpoint":"<server-endpoint> (for example, sqlservername.database.windows.net)",
    "subscriptionId":"<azure-subscription-guid>",
    "resourceGroup":"<resource-group>",
    "location":"<region>",
    "parentCollection":{
      "type":"DataSourceReference",
      "referenceName":"<collection-name>"
    }
  }
}

Примечание

<collection-name> — Это текущая коллекция, существующая в учетной записи Azure Purview.

Создание проверки

Узнайте, как создать учетные данные для проверки подлинности источников в Azure Purview перед настройкой и запуском сканирования.

Используйте следующий вызов API для проверки источников данных:

PUT https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}/scans/{newScanName}/

Параметры URI для проверки:

Имя	Обязательно	Тип	Описание
`accountName`	True	Строка	Имя учетной записи Azure Purview
`dataSourceName`	True	Строка	Имя источника данных
`newScanName`	True	Строка	Имя новой проверки

Использование REST API Azure Purview для сканирования

В следующих примерах показано, как использовать REST API Azure Purview для сканирования источников данных с помощью полезных данных:

Проверка источника данных Azure Data Lake Storage 2-го поколения:

{
  "name":"<scan-name>",
  "kind":"AdlsGen2Msi",
  "properties":
  {
    "scanRulesetType":"System",
    "scanRulesetName":"AdlsGen2"
  }
}

Проверка источника данных Базы данных SQL:

{
  "name":"<scan-name>",
  "kind":"AzureSqlDatabaseMsi",
  "properties":
  {
    "scanRulesetType":"System",
    "scanRulesetName":"AzureSqlDatabase",
    "databaseName": "<database-name>",
    "serverEndpoint": "<server-endpoint> (for example, sqlservername.database.windows.net)"
  }
}

Используйте следующий вызов API для проверки источников данных:

POST https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}/scans/{newScanName}/run

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

Обзор Azure Data Lake Storage для аналитики в масштабе облака