Fabric Runtime 1.2 (GA)
Die Microsoft Fabric Runtime ist eine in Azure integrierte Plattform, die auf Apache Spark basiert und die Ausführung und Verwaltung von Data Engineering- und Data Science-Umgebungen ermöglicht. Dieses Dokument behandelt die Runtime 1.2-Komponenten und -Versionen.
Zu den Hauptkomponenten von Runtime 1.2 gehören:
- Apache Spark 3.4.1
- Betriebssystem: Mariner 2.0
- Java: 11
- Scala: 2.12.17
- Python: 3.10
- Delta Lake: 2.4.0
- R: 4.2.2
Tipp
Verwenden Sie immer die neueste GA-Laufzeitversion für Ihre Produktionsworkloads, die derzeit Runtime 1.3 ist.
Microsoft Fabric Runtime 1.2 enthält eine Sammlung von Paketen auf Standardebene, einschließlich einer vollständigen Anaconda-Installation und häufig verwendeter Bibliotheken für Java/Scala, Python und R. Diese Bibliotheken werden automatisch einbezogen, wenn Notebooks oder Aufträge auf der Microsoft Fabric-Plattform verwendet werden. Eine vollständige Liste der Bibliotheken finden Sie in der Dokumentation. Microsoft Fabric veröffentlicht regelmäßig Wartungsupdates für Runtime 1.2, die Fehlerbehebungen, Leistungsverbesserungen und Sicherheitspatches bieten. Immer auf dem neuesten Stand zu bleiben, sorgt für optimale Leistung und Zuverlässigkeit für Ihre Datenverarbeitungsaufgaben.
Neue Features und Verbesserungen von Spark-Release 3.4.1
Apache Spark 3.4.0 ist das fünfte Release in der 3.x-Linie. Dieses Release, getragen von der Open-Source-Community, hat über 2.600 Jira-Tickets aufgelöst. Es führt einen Python-Client für Spark Connect ein, verbessert strukturiertes Streaming mit asynchroner Statusverfolgung und Python-Zustandsverarbeitung. Es erweitert die Pandas-API-Abdeckung mit NumPy-Eingabeunterstützung, vereinfacht die Migration von herkömmlichen Data Warehouses über ANSI-Compliance und neue integrierte Funktionen. Außerdem verbessert es die Produktivität der Entwicklung und die Debugbarkeit mit Speicherprofilerstellung. Darüber hinaus basiert Runtime 1.2 auf Apache Spark 3.4.1, einer Wartungsversion, die sich auf Stabilitätsfixes konzentriert.
Wichtigste Highlights
Lesen Sie die Vollversion der Versionshinweise für eine bestimmte Apache Spark-Version, indem Sie sowohl Spark 3.4.0 als auch Spark 3.4.1 besuchen.
Neue benutzerdefinierte Abfrageoptimierungen
Unterstützung für gleichzeitige Schreibvorgänge in Spark
Das Auftreten eines 404-Fehlers mit der Meldung „Vorgang fehlgeschlagen: Der angegebene Pfad ist nicht vorhanden“ ist ein häufiges Problem beim Ausführen paralleler Dateneinfügungen in dieselbe Tabelle mithilfe einer SQL INSERT INTO-Abfrage. Dieser Fehler kann zu Datenverlust führen. Unser neues Feature, der Dateiausgabe-Committeralgorithmus, behebt dieses Problem, sodass Kunden eine nahtlose parallele Dateneinfügung durchführen können.
Um auf dieses Feature zuzugreifen, aktivieren Sie das spark.sql.enable.concurrentWrites
-Feature-Flag, das standardmäßig ab Runtime 1.2 (Spark 3.4) aktiviert ist. Obwohl dieses Feature auch in anderen Spark 3-Versionen verfügbar ist, ist es standardmäßig nicht aktiviert. Dieses Feature unterstützt keine parallele Ausführung von INSERT OVERWRITE-Abfragen, bei denen jeder gleichzeitige Auftrag Daten auf verschiedenen Partitionen derselben Tabelle dynamisch überschreibt. Zu diesem Zweck bietet Spark ein alternatives Feature, das durch Konfigurieren der spark.sql.sources.partitionOverwriteMode
-Einstellung auf dynamisch aktiviert werden kann.
Intelligente Lesevorgänge, mit denen Dateien von fehlgeschlagenen Aufträgen übersprungen werden
Wenn ein Auftrag zum Einfügen in eine Tabelle fehlschlägt, aber einige Aufgaben erfolgreich sind, koexistieren die von den erfolgreichen Aufgaben generierten Dateien im aktuellen Spark-Committer-System mit Dateien aus dem fehlgeschlagenen Auftrag. Diese Koexistenz kann Verwirrung für Benutzer verursachen, da es schwierig wird, zwischen Dateien zu unterscheiden, die zu erfolgreichen und erfolglosen Aufträgen gehören. Wenn ein Auftrag aus einer Tabelle liest, während ein anderer Daten gleichzeitig in dieselbe Tabelle einfügt, greift der Leseauftrag möglicherweise auf nicht committete Daten zu. Wenn ein Schreibauftrag fehlschlägt, kann der Leseauftrag falsche Daten verarbeiten.
Das spark.sql.auto.cleanup.enabled
-Flag steuert unser neues Feature, das dieses Problem behebt. Wenn diese Option aktiviert ist, überspringt Spark automatisch das Lesen von Dateien, die beim Ausführen von spark.read
oder Auswählen von Abfragen aus einer Tabelle nicht committet wurden. Dateien, die vor dem Aktivieren dieses Features geschrieben wurden, werden weiterhin wie gewohnt gelesen.
Hier sind die sichtbaren Änderungen:
- Alle Dateien enthalten nun einen
tid-{jobID}
-Bezeichner in ihren Dateinamen. - Anstelle des
_success
-Markers, der in der Regel am Ausgabespeicherort nach erfolgreichem Auftragsabschluss erstellt wurde, wird ein neuer_committed_{jobID}
-Marker generiert. Dieser Marker ordnet erfolgreiche Auftrags-IDs bestimmten Dateinamen zu. - Wir haben einen neuen SQL-Befehl eingeführt, den Benutzer regelmäßig ausführen können, um Speicher zu verwalten und nicht committete Dateien zu bereinigen. Die Syntax für diesen Befehl lautet wie folgt:
- So bereinigen Sie ein bestimmtes Verzeichnis:
CLEANUP ('/path/to/dir') [RETAIN number HOURS];
- Zum Bereinigen einer bestimmten Tabelle:
CLEANUP [db_name.]table_name [RETAIN number HOURS];
In dieser Syntax stelltpath/to/dir
den Speicherort-URI dar, bei dem die Bereinigung erforderlich ist, undnumber
ist ein doppelter Typwert, der den Aufbewahrungszeitraum darstellt. Der Standardaufbewahrungszeitraum beträgt 7 Tage.
- So bereinigen Sie ein bestimmtes Verzeichnis:
- Wir haben eine neue Konfigurationsoption namens
spark.sql.deleteUncommittedFilesWhileListing
eingeführt, die standardmäßig auffalse
eingestellt ist. Wenn Sie diese Option aktivieren, wird die automatische Löschung von nicht committeten Dateien während Lesevorgängen durchgeführt. In diesem Szenario werden Lesevorgänge jedoch möglicherweise verlangsamt. Es wird empfohlen, den Bereinigungsbefehl manuell auszuführen, wenn der Cluster im Leerlauf ist, anstatt dieses Flag zu aktivieren.
Migrationsleitfaden von Runtime 1.1 zu Runtime 1.2
Überprüfen Sie bei der Migration von Runtime 1.1, unterstützt von Apache Spark 3.3, zu Runtime 1.2, unterstützt von Apache Spark 3.4, den offiziellen Migrationsleitfaden.
Neue Features und Verbesserungen von Delta Lake 2.4
Delta Lake ist ein Open-Source-Projekt zum Erstellen einer Lakehouse-Architektur auf der Grundlage von Data Lakes. Delta Lake ermöglicht ACID-Transaktionen, die skalierbare Metadatenverarbeitung sowie die Vereinheitlichung der Streaming- und Batchdatenverarbeitung auf der Grundlage vorhandener Data Lakes.
Delta Lake bietet insbesondere Folgendes:
- ACID-Transaktionen in Spark: Serialisierbare Isolationsstufen stellen sicher, dass Reader niemals inkonsistente Daten vorfinden.
- Skalierbare Metadatenverarbeitung: Die verteilte Verarbeitungsleistung von Spark wird genutzt, um alle Metadaten für Tabellen im Petabytebereich, die Milliarden von Dateien enthalten, problemlos zu verarbeiten.
- Streaming- und Batch-Vereinheitlichung: Eine Tabelle in Delta Lake ist eine Batchtabelle und eine Streamingquelle und -senke. Die Erfassung von Streamingdaten, der Abgleich älterer Batches und interaktive Abfragen sind standardmäßig möglich.
- Schemaerzwingung: Schemavariationen werden automatisch verarbeitet, um das Einfügen fehlerhafter Datensätze während der Erfassung zu verhindern.
- Zeitreise: Die Datenversionierung ermöglicht Rollbacks, vollständige Verlaufsüberwachungspfade und reproduzierbare Machine-Learning-Experimente.
- Upsert- und Löschvorgänge: Zusammenführungs-, Aktualisierungs- und Löschvorgänge werden unterstützt, um komplexe Anwendungsfälle wie CDC-Vorgänge (Change Data Capture), SCD-Vorgänge (Slowly-Changing Dimension), Streamingupserts und mehr zu ermöglichen.
Lesen Sie die Vollversion der Versionshinweise für Delta Lake 2.4.
Pakete auf Standardebene für Java, Scala, Python-Bibliotheken
Eine Liste aller Standardebenenpakete für Java, Scala, Python und ihre jeweiligen Versionen finden Sie in den Versionshinweisen.