Устранение проблем с доступом к хранилищу пула Apache Spark Azure Synapse Analytics

Область применения: Azure Synapse Analytics

Apache Spark — это платформа параллельной обработки, которая поддерживает обработку в памяти для повышения производительности приложений аналитики больших данных. Apache Spark в Azure Synapse Analytics — это одна из реализаций Apache Spark в облаке корпорации Майкрософт. Azure Synapse упрощает создание и настройку бессерверного пула Apache Spark в Azure. Пулы Spark в Azure Synapse совместимы со службой хранилища Azure и Хранилищем Azure Data Lake 2-го поколения. Поэтому для обработки данных, хранящихся в Azure, можно использовать пулы Spark.

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

Неподдерживаемые сценарии

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

  • Подключение к учетной записи хранения ADLS 1-го поколения
  • Подключение к учетной записи хранения ADLS 2-го поколения с помощью управляемого удостоверения, назначаемого пользователем
  • Подключение к учетной записи хранения ADLS 2-го поколения с:
    • Общая рабочая область Synapse виртуальной сети
    • Учетная запись хранения с поддержкой брандмауэра

Распространенные проблемы и решения

Error Решение
"errorMessage":"LSRServiceException имеет значение [{"StatusCode":400,"ErrorResponse":{"code":"LSRLinkedServiceFailure","message":"Не удалось найти связанную службу AzureDataLakeStorage1; Эта ошибка возникает, если рабочая область Synapse связана с репозиторием Git, Azure DevOps Services или GitHub. Он также создается, когда артефакт, например записная книжка или связанная служба, не публикуется.

Вручную опубликуйте изменения кода в ветви совместной работы в службе Synapse.
stdout: исключение в потоке "main" org.apache.hadoop.fs.FileAlreadyExistsException: операция завершилась ошибкой: "Эта конечная точка не поддерживает BlobStorageEvents или SoftDelete. Отключите эти функции учетной записи, если вы хотите использовать эту конечную точку.", 409, HEAD, https://< storageaccountname.dfs.core.windows.net/scripts/?upn=false&> action=getAccessControl&timeout=90 Убедитесь, что хранилище ADLS 2-го поколения настроено в качестве основного хранилища.

Чтобы отключить SoftDelete, снимите флажок Включить обратимое удаление BLOB-объектов для учетной записи хранения.

Устранение неполадок с "403"

Доступ к хранилищу и доступ к учетной записи

  • Для записи в хранилище через конвейер MSI рабочей области Synapse является субъектом безопасности, который выполняет в хранилище любые операции, такие как чтение, запись и удаление.
    • Убедитесь, что учетная запись MSI рабочей области имеет роль Участник данных BLOB-объектов хранилища для выполнения всех действий.
  • Если вы используете Записные книжки Azure для доступа к учетной записи хранения, используйте учетную запись входа, если вы не обращаетесь к хранилищу через связанные службы.
    • Учетная запись пользователя, выполнившего вход, должна иметь роль Участник данных BLOB-объектов хранилища, чтобы иметь полный доступ и разрешения.
  • Чтобы подключиться к хранилищу, используйте проверку подлинности связанной службы и субъекта-службы. Затем приложению, зарегистрированном в Azure Active, следует назначить "Участник данных BLOB-объектов хранилища" в службе хранилища Azure.

Для реализации управления доступом на основе ролей (RBAC) в хранилище подробные сведения управляются на уровне контейнера. Дополнительные сведения см. в статье Модель управления доступом в Azure Data Lake Storage 2-го поколения.

Управление доступом на основе ролей Azure

Управление доступом на основе ролей Azure использует назначения ролей для применения наборов разрешений к субъектам безопасности, таким как MSI рабочей области Synapse, вошедший в систему пользователь или регистрация приложения в Microsoft Entra ID. Такие роли, как владелец, участник, читатель и участник учетной записи хранения, позволяют субъекту безопасности управлять учетной записью хранения.

Списки управления доступом

Используйте списки управления доступом (ACL) для применения подробных уровней доступа к каталогам и файлам.

  • Если для субъекта безопасности обнаружены роли доступа к данным, такие как читатель данных BLOB-объектов хранилища или участник данных BLOB-объектов хранилища, выполняется проверка, чтобы проверить, имеет ли эта роль разрешения на выполнение таких действий, как запись, чтение и удаление. В этом случае субъект безопасности может получить доступ ко всем файлам и папкам на основе роли контейнера.
    • Дополнительные проверки ACL для файлов или папок отсутствуют.
  • Если роль доступа к данным не найдена для субъекта безопасности на уровне контейнера хранилища, проверки ACL выполняются для файлов и папок.

Ресурсы