Azure Synapse-Runtimes
Apache Spark-Pools in Azure Synapse verwenden Runtimes, um wichtige Komponentenversionen wie Azure Synapse-Optimierungen, Pakete und Connectors mit einer bestimmten Apache Spark-Version zu verknüpfen. Jede Laufzeit wird regelmäßig aktualisiert, um neue Verbesserungen, Features und Patches einzuschließen. Wenn Sie einen serverlosen Apache Spark-Pool erstellen, wählen Sie die entsprechende Apache Spark-Version aus. Auf dieser Grundlage wird der Pool mit den zugehörigen Laufzeitkomponenten und -paketen vorinstalliert.
Die Runtimes haben die folgenden Vorteile:
- Schnellere Startzeiten von Sitzungen
- Getestete Kompatibilität mit bestimmten Apache Spark-Versionen
- Zugriff auf beliebte, kompatible Connectors und Open-Source-Pakete
Unterstützte Azure Synapse-Runtime-Releases
Tipp
Es wird dringend empfohlen, Workloads proaktiv auf eine neuere GA-Version der Laufzeit zu aktualisieren, die Azure Synapse Runtime für Apache Spark 3.4 (GA) ist. Weitere Informationen finden Sie im Apache Spark-Migrationshandbuch.
In der folgenden Tabelle sind der Runtime-Name, die Apache Spark-Version und das Releasedatum für unterstützte Azure Synapse-Runtime-Releases aufgeführt.
Runtime-Name | Veröffentlichungsdatum | Releasestufe | Ankündigungsdatum des Supportendes | Gültigkeitsdatum des Supportendes |
---|---|---|---|---|
Azure Synapse Runtime für Apache Spark 3.4 | 21. November 2023 | GA (ab dem 8. April 2024) | Q2 2025 | Q1 2026 |
Azure Synapse Runtime für Apache Spark 3.3 | 17. November 2022 | Ende des angekündigten Supports | 12. Juli 2024 | 31.03.2025 |
Azure Synapse Runtime für Apache Spark 3.2 | 8. Juli 2022 | veraltet und bald deaktiviert | 8. Juli 2023 | 8. Juli 2024 |
Azure Synapse Runtime für Apache Spark 3.1 | 26. Mai 2021 | veraltet und bald deaktiviert | 26. Januar 2023 | 26. Januar 2024 |
Azure Synapse Runtime für Apache Spark 2.4 | 15. Dezember 2020 | veraltet und bald deaktiviert | 29. Juli 2022 | 29. September 2023 |
Runtime-Releasestufen
Informationen zur vollständigen Runtime für Apache Spark-Lebenszyklus- und Supportrichtlinien finden Sie unter Synapse-Runtime für Apache Spark-Lebenszyklus und -Unterstützung.
Runtime-Patchen
Azure Synapse-Runtimes für Apache Spark-Patches werden monatlich bereitgestellt, die Fehler-, Feature- und Sicherheitsfixes für das Apache Spark Core-Modul, Sprachumgebungen, Connectors und Bibliotheken enthalten.
Hinweis
- Wartungsupdates werden automatisch auf neue Sitzungen für einen bestimmten serverlosen Apache Spark-Pool angewendet.
- Sie sollten testen und überprüfen, ob Anwendungen bei Verwendung neuer Runtime-Versionen ordnungsgemäß ausgeführt werden.
Wichtig
Sicherheitspatches für Log4j 1.2.x
In Version 1.2.x der Open-Source-Bibliothek Log4j liegen einige CVEs (Common Vulnerabilities and Exposures, allgemeine Sicherheitslücken und Schwachstellen) vor. Diese sind hier beschrieben.
Die JAR-Dateien für Log4j 1.2.17 wurden für alle Spark-Pool-Runtimes in Synapse gepatcht, um die folgenden CVEs zu beheben: CVE-2019-1751, CVE-2020-9488, CVE-2021-4104, CVE-2022-23302, CVE-2022-2330, CVE-2022-23307.
Der angewendete Patch funktioniert durch Entfernen der folgenden Dateien, die zum Aufrufen der Sicherheitsrisiken erforderlich sind:
org/apache/log4j/net/SocketServer.class
org/apache/log4j/net/SMTPAppender.class
org/apache/log4j/net/JMSAppender.class
org/apache/log4j/net/JMSSink.class
org/apache/log4j/jdbc/JDBCAppender.class
org/apache/log4j/chainsaw/*
Die obigen Klassen wurden zwar in den Standardkonfigurationen von Log4j in Synapse nicht verwendet, aber es ist möglich, dass einige Benutzeranwendungen immer noch davon abhängig sind. Wenn Ihre Anwendung diese Klassen verwenden muss, fügen Sie mithilfe der Bibliotheksverwaltung eine sichere Version von Log4j zum Spark-Pool hinzu. Verwenden Sie nicht Log4j-Version 1.2.17, da dadurch die Sicherheitsrisiken wieder eingeführt werden.
Die Patchrichtlinie unterscheidet sich je nach Runtime-Lebenszyklusphase:
Allgemein verfügbare (GA)-Laufzeit: Erhalten Sie keine Upgrades für Hauptversionen (d. h. 3.x -> 4.x). Außerdem wird eine Nebenversion (d. h. 3.x -> 3.y) aktualisiert, solange keine Auswirkungen auf veraltete oder Regressionen bestehen.
Vorschauruntime: Keine Hauptversionsupgrades, nur wenn unbedingt erforderlich. Nebenversionen (3.x -> 3.y) werden aktualisiert, um neueste Features zu einer Runtime hinzuzufügen.
Die Long Term Support (LTS)-Laufzeit wird nur mit Sicherheitsupdates gepatcht.
Das Ende des angekündigten Supports hat keine Fehler- und Featurefixes. Sicherheitsfixes werden basierend auf der Risikobewertung zurückportiert.
Migration zwischen Apache Spark-Versionen – Unterstützung
Dieses Handbuch bietet einen strukturierten Ansatz für Benutzer, die ihre Azure Synapse-Runtime für Apache Spark-Workloads von Version 2.4, 3.1, 3.2 oder 3.3 auf die neueste GA-Version aktualisieren möchten, z. B. 3.4. Durch das Upgrade auf die neueste Version können Benutzer von Leistungsverbesserungen, neuen Features und verbesserten Sicherheitsmaßnahmen profitieren. Es ist wichtig zu beachten, dass der Übergang zu einer höheren Version möglicherweise Anpassungen an Ihren vorhandenen Spark-Code aufgrund von Inkompatibilitäten oder veralteten Features erfordert.
Schritt 1: Auswerten und Planen
- Bewerten der Kompatibilität: Beginnen Sie mit der Überprüfung von Apache Spark-Migrationshandbüchern, um mögliche Inkompatibilitäten, veraltete Features und neue APIs zwischen Ihrer aktuellen Spark-Version (2.4, 3.1, 3.2 oder 3.3) und der Zielversion (z. B. 3.4) zu identifizieren.
- Analysieren Sie Codebase: Untersuchen Sie Ihren Spark-Code sorgfältig, um die Verwendung veralteter oder geänderter APIs zu identifizieren. Achten Sie besonders auf SQL-Abfragen und benutzerdefinierte Funktionen (User Defined Functions, UDFs), die möglicherweise vom Upgrade betroffen sind.
Schritt 2: Erstellen eines neuen Spark-Pools zum Testen
- Erstellen eines neuen Pools: Wechseln Sie in Azure Synapse zum Abschnitt "Spark pools", und richten Sie einen neuen Spark-Pool ein. Wählen Sie die Spark-Zielversion (z. B. 3.4) aus, und konfigurieren Sie sie entsprechend Ihren Leistungsanforderungen.
- Konfigurieren der Spark Pool-Konfiguration: Stellen Sie sicher, dass alle Bibliotheken und Abhängigkeiten in Ihrem neuen Spark-Pool aktualisiert oder ersetzt werden, damit sie mit Spark 3.4 kompatibel sind.
Schritt 3: Migrieren und Testen des Codes
- Migrieren Sie Code: Aktualisieren Sie Ihren Code so, dass er mit den neuen oder überarbeiteten APIs in Apache Spark 3.4 kompatibel ist. Dies umfasst die Adressierung veralteter Funktionen und die Einführung neuer Features, wie in der offiziellen Apache Spark-Dokumentation beschrieben.
- Test in Entwicklungsumgebung: Testen Sie Ihren aktualisierten Code in einer Entwicklungsumgebung in Azure Synapse, nicht lokal. Dieser Schritt ist wichtig, um Probleme zu identifizieren und zu beheben, bevor Sie zur Produktion wechseln.
- Bereitstellen und Überwachen: Nach gründlichen Tests und Überprüfungen in der Entwicklungsumgebung stellen Sie Ihre Anwendung im neuen Spark 3.4-Pool bereit. Es ist wichtig, die Anwendung auf unerwartete Verhaltensweisen zu überwachen. Nutzen Sie die in Azure Synapse verfügbaren Überwachungstools, um die Leistung Ihrer Spark-Anwendungen nachzuverfolgen.
Frage: Welche Schritte sollten bei der Migration von 2.4 zu 3.X unternommen werden?
Antwort: Lesen Sie den Apache Spark-Migrationsleitfaden.
Frage: Ich habe eine Fehlermeldung erhalten, wenn ich versucht habe, spark pool runtime using PowerShell cmdlet when they have attached libraries zu aktualisieren.
Antwort: Verwenden Sie das PowerShell-Cmdlet nicht, wenn in Ihrem Synapse-Arbeitsbereich benutzerdefinierte Bibliotheken installiert sind. Führen Sie stattdessen die folgenden Schritte aus:
- Erstellen Sie Spark Pool 3.3 von Grund auf neu.
- Aktualisieren Sie den aktuellen Spark Pool 3.3 auf 3.1, entfernen Sie alle angefügten Pakete, und aktualisieren Sie dann erneut auf 3.3.
Frage: Warum kann ich kein Upgrade auf 3.4 durchführen, ohne einen neuen Spark-Pool neu zu erstellen?
Antwort: Dies ist von der UX nicht zulässig, der Kunde kann Azure PowerShell zum Aktualisieren der Spark-Version verwenden. Verwenden Sie "ForceApplySetting", damit vorhandene Cluster (mit alter Version) außer Betrieb genommen werden.
Beispielabfrage:
$_target_work_space = @("workspace1", "workspace2")
Get-AzSynapseWorkspace |
ForEach-Object {
if ($_target_work_space -contains $_.Name) {
$_workspace_name = $_.Name
Write-Host "Updating workspace: $($_workspace_name)"
Get-AzSynapseSparkPool -WorkspaceName $_workspace_name |
ForEach-Object {
Write-Host "Updating Spark pool: $($_.Name)"
Write-Host "Current Spark version: $($_.SparkVersion)"
Update-AzSynapseSparkPool -WorkspaceName $_workspace_name -Name $_.Name -SparkVersion 3.4 -ForceApplySetting
}
}
}