Beheben von Speicherzugriffsproblemen mit Azure Synapse Analytics-Apache Spark-Pools
Gilt für: Azure Synapse Analytics
Apache Spark ist ein Parallelverarbeitungsframework, das die In-Memory-Verarbeitung unterstützt, um die Leistung von Big Data-Analyseanwendungen zu steigern. Apache Spark in Azure Synapse Analytics ist eine der Microsoft-Implementierungen von Apache Spark in der Cloud. Azure Synapse erleichtert das Erstellen und Konfigurieren eines serverlosen Apache Spark-Pools in Azure. Spark-Pools in Azure Synapse sind mit Azure Storage und Azure Data Lake Storage der Generation 2 kompatibel. Daher können Sie Spark-Pools verwenden, um Ihre in Azure gespeicherten Daten zu verarbeiten.
Wenn Probleme beim Zugriff auf Den Poolspeicher auftreten, z. B. "403"-Fehler oder der Fehler beim Suchen verknüpfter Dienste im Synapse-Arbeitsbereich, verwenden Sie die bereitgestellten Anleitungen, um Ihre Probleme zu beheben.
Nicht unterstützte Szenarien
Die folgenden Anwendungsfälle werden nicht unterstützt, wenn Sie über einen Synapse Spark-Pool eine Verbindung mit einem Speicherkonto herstellen:
- Herstellen einer Verbindung mit dem ADLS Gen 1-Speicherkonto
- Herstellen einer Verbindung mit dem ADLS Gen2-Speicherkonto mit benutzerseitig zugewiesener verwalteter Identität
- Herstellen einer Verbindung mit einem ADLS Gen 2-Speicherkonto mit:
- Freigegebener VNET Synapse-Arbeitsbereich
- Firewallfähiges Speicherkonto
Häufige Probleme und Lösungen
| Fehler | Lösung |
|---|---|
| "errorMessage":"LSRServiceException is [{"StatusCode":400,"ErrorResponse":{"code":"LSRLinkedServiceFailure","message":"Linked Service AzureDataLakeStorage1; | Dieser Fehler wird generiert, wenn ein Synapse-Arbeitsbereich einem Git-Repository, Azure DevOps Services oder GitHub zugeordnet ist. Es wird auch generiert, wenn ein Artefakt wie ein Notebook oder ein verknüpfter Dienst nicht veröffentlicht wird. Veröffentlichen Sie Ihre Codeänderungen manuell im Kollaborationsbranch im Synapse-Dienst. |
| stdout: Ausnahme im Thread "Standard" org.apache.hadoop.fs.FileAlreadyExistsException: Operation failed: "This endpoint does not support BlobStorageEvents or SoftDelete. Deaktivieren Sie diese Kontofeatures, wenn Sie diesen Endpunkt verwenden möchten.", 409, HEAD, https://< storageaccountname.dfs.core.windows.net/scripts/?upn=false&> action=getAccessControl&timeout=90 | Vergewissern Sie sich, dass ADLS Gen2-Speicher als primärer Speicher konfiguriert ist. Deaktivieren Sie zum Deaktivieren von SoftDelete das Kontrollkästchen Vorläufiges Löschen von Blobs aktivieren für das Speicherkonto. |
Behandeln von Problemen mit "403"
Speicherzugriff und kontozugriff
- Zum Schreiben in den Speicher über eine Pipeline ist synapse Workspace MSI der Sicherheitsprinzipal, der alle Vorgänge wie Lesen, Schreiben und Löschen im Speicher ausführt.
- Stellen Sie sicher, dass das MSI-Konto des Arbeitsbereichs über die Rolle Mitwirkender an Storage-Blobdaten verfügt, um alle Aktionen auszuführen.
- Wenn Sie Azure Notebooks für den Zugriff auf das Speicherkonto verwenden, verwenden Sie das angemeldete Konto, es sei denn, Sie greifen über verknüpfte Dienste auf den Speicher zu.
- Das angemeldete Benutzerkonto sollte über die Rolle Mitwirkender an Storage-Blobdaten verfügen, um vollzugriff und Berechtigungen zu erhalten.
- Verwenden Sie die Authentifizierung des verknüpften Diensts und des Dienstprinzipals, um eine Verbindung mit dem Speicher herzustellen. Anschließend sollte der Anwendung, die bei Azure Active registriert ist, "Mitwirkender an Storage-Blobdaten" im Azure-Speicher zugewiesen werden.
Für die Implementierung der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) im Speicher werden Details auf Containerebene gesteuert. Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage Gen2.
Rollenbasierte Zugriffssteuerung in Azure
Die rollenbasierte Zugriffssteuerung in Azure verwendet Rollenzuweisungen, um Berechtigungssätze auf Sicherheitsprinzipale wie die MSI des Synapse-Arbeitsbereichs, den angemeldeten Benutzer oder das Anwendungsregister im Microsoft Entra ID anzuwenden. Rollen wie Besitzer, Mitwirkender, Leser und Mitwirkender an Speicherkonten ermöglichen es einem Sicherheitsprinzipal, ein Speicherkonto zu verwalten.
Zugriffssteuerungslisten
Verwenden Sie Zugriffssteuerungslisten (Access Control Lists, ACLs), um detaillierte Zugriffsebenen auf Verzeichnisse und Dateien anzuwenden.
- Wenn Datenzugriffsrollen wie Leser von Storage-Blobdaten oder Mitwirkender an Storage-Blobdaten für den Sicherheitsprinzipal gefunden werden, wird eine Überprüfung ausgeführt, um zu überprüfen, ob die Rolle über die Berechtigungen zum Ausführen von Aktionen wie Schreiben, Lesen und Löschen verfügt. Wenn dies der Grund ist, kann der Sicherheitsprinzipal basierend auf der Containerrolle auf alle Dateien und Ordner zugreifen.
- Es gibt keine zusätzlichen ACL-Überprüfungen für die Dateien oder Ordner.
- Wenn für den Sicherheitsprinzipal auf Speichercontainerebene keine Datenzugriffsrolle gefunden wird, werden ACL-Überprüfungen für die Dateien und Ordner ausgeführt.