Сканирование и прием в Microsoft Purview

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

• Сканирование захватывает метаданные из источников данных и переносит их в Microsoft Purview.
• Прием обрабатывает метаданные и сохраняет их в каталоге данных из обоих источников:
  • Проверка источников данных — в Схема данных Microsoft Purview добавляются отсканированные метаданные.
  • Связи происхождения. Ресурсы преобразования добавляют метаданные о своих источниках, выходных данных и действиях в Схема данных Microsoft Purview.

Сканирование

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

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

Выбор метода проверки подлинности для проверок

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

• Управляемое удостоверение
• Субъект-служба
• Проверка подлинности SQL
• Проверка подлинности Windows
• Роль ARN
• Делегированная проверка подлинности
• Ключ потребителя
• Ключ учетной записи или обычная проверка подлинности

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

Область сканирования

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

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

Для каждой сущности (папки или таблицы) будет три состояния выделения: полностью выбрано, частично выбрано и не выбрано. В приведенном ниже примере при выборе "Отдел 1" в иерархии папок "Отдел 1" считается полностью выбранным. Родительские сущности для "Отдел 1", такие как "Компания" и "пример", считаются частично выбранными, так как другие сущности в том же родительском элементе не были выбраны, например "Отдел 2". Различные значки будут использоваться в пользовательском интерфейсе для сущностей с разными состояниями выделения.

После выполнения проверки в исходной системе, скорее всего, будут добавлены новые ресурсы. По умолчанию будущие ресурсы под определенным родительским элементом будут выбраны автоматически, если родительский элемент выбран полностью или частично при повторном запуске проверки. В приведенном выше примере после выбора "Отдел 1" и выполнения проверки все новые ресурсы в папке "Отдел 1" или в разделе "Компания" и "Пример" будут включены при повторном запуске сканирования.

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

Если переключатель включен, при повторном запуске проверки будут автоматически выбраны новые ресурсы под определенным родительским элементом. Поведение включения будет таким же, как и до появления переключателя.

Примечание.

• Доступность переключателя будет зависеть от типа источника данных. В настоящее время он доступен в общедоступной предварительной версии для источников, включая Хранилище BLOB-объектов Azure, Azure Data Lake Storage 1-го поколения, Azure Data Lake Storage 2-го поколения, Файлы Azure и выделенный пул SQL Azure (ранее — хранилище данных SQL).
• Для всех проверок, созданных или запланированных до появления переключателя, состояние переключателя устанавливается как включено и не может быть изменено. Для любых проверок, созданных или запланированных после ввода переключателя, состояние переключателя нельзя изменить после сохранения сканирования. Чтобы изменить состояние переключателя, необходимо создать новую проверку.
• Если кнопка переключения отключена, для источников типа хранилища, таких как Azure Data Lake Storage 2-го поколения, может потребоваться до 4 часов, прежде чем функция просмотра по исходному типу станет полностью доступной после завершения задания сканирования.

Известные ограничения

Если переключатель отключен, выполните следующие действия:

• Сущности файлов в частично выбранном родительском элементе не будут проверяться.
• Если все существующие сущности в родительском элементе выбраны явным образом, родительский элемент будет считаться полностью выбранным, а все новые ресурсы в родительском элементе будут включены при повторном запуске проверки.

Набор правил сканирования

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

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

Планирование сканирования

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

Как сканирование обнаруживает удаленные ресурсы

Каталог Microsoft Purview знает о состоянии хранилища данных только при выполнении проверки. Чтобы каталог знал, был ли удален файл, таблица или контейнер, он сравнивает последние выходные данные сканирования с текущими выходными данными сканирования. Например, предположим, что при последнем сканировании учетной записи Azure Data Lake Storage 2-го поколения она включала папку с именем folder1. При повторном сканировании той же учетной записи папка 1 отсутствует. Таким образом, каталог предполагает, что папка была удалена.

Обнаружение удаленных файлов

Логика обнаружения отсутствующих файлов работает для нескольких проверок одного и того же пользователя и разных пользователей. Например, предположим, что пользователь выполняет однократное сканирование в Data Lake Storage 2-го поколения хранилище данных в папках A, B и C. Позже другой пользователь в той же учетной записи выполняет разовую проверку папок C, D и E одного хранилища данных. Так как папка C сканировалась дважды, каталог проверяет ее на наличие возможных удалений. Однако папки A, B, D и E сканировались только один раз, и каталог не будет проверка их на наличие удаленных ресурсов.

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

При перечислении больших хранилищ данных, таких как Data Lake Storage 2-го поколения, существует несколько способов (включая ошибки перечисления и удаленные события) пропускать информацию. При определенной проверке может пропустить, что файл был создан или удален. Таким образом, если каталог не уверен, что файл был удален, он не удалит его из каталога. Эта стратегия означает, что могут возникнуть ошибки, если файл, который не существует в сканированном хранилище данных, по-прежнему существует в каталоге. В некоторых случаях хранилище данных может потребоваться проверить два или три раза, прежде чем оно перехватывает некоторые удаленные ресурсы.

Примечание.

• Ресурсы, помеченные для удаления, удаляются после успешной проверки. Удаленные ресурсы могут оставаться видимыми в каталоге в течение некоторого времени, прежде чем они будут обработаны и удалены.
• В настоящее время обнаружение удаления источника не поддерживается для следующих источников: Azure Databricks, Amazon Redshift, Cassandra, DB2, Erwin, Google BigQuery, Hive Metastore, Looker, MongoDB, MySQL, Oracle, PostgreSQL, Salesforce, SAP BW, SAP ECC, SAP HANA, SAP S/4HANA, Snowflake и Teradata. При удалении объекта из источника данных последующая проверка не приведет к автоматическому удалению соответствующего ресурса в Microsoft Purview.

Приеме внутрь

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

Прием из сканирований

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

Прием данных из подключений к происхождению

Такие ресурсы, как Фабрика данных Azure и Azure Synapse, можно подключить к Microsoft Purview, чтобы перенести источник данных и сведения о происхождении данных в Схема данных Microsoft Purview. Например, когда конвейер копирования выполняется в Фабрика данных Azure, подключенном к Microsoft Purview, метаданные об источниках входных данных, действиях и выходных источниках помечаются в Microsoft Purview, а сведения добавляются в карту данных.

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

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

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

Дополнительные сведения или инструкции по проверке источников см. по ссылкам ниже.

• Сведения о наборах ресурсов см. в нашей статье о наборах ресурсов.
• Управление базой данных Azure SQL
• Происхождение происхождения в Microsoft Purview