Устранение проблем с доступом к хранилищу пула 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 выполняются для файлов и папок.