Auswahl eines Notebook-Kernels in Microsoft Fabric

Notizbücher in Microsoft Fabric unterstützen drei Kerneltypen: Python, Spark und T-SQL. Der Spark-Kernel unterstützt vier Sprachen – PySpark, SparkSQL, Scala und SparkR –, die alle von demselben Spark compute unterstützt werden. Dieser Leitfaden konzentriert sich auf die Entscheidung zwischen dem Python Kernel und dem Spark-Kernel, da diese Kernel die am häufigsten verwendeten Optionen für Data Engineering-Workloads sind. Beide laufen in derselben Notebook-Umgebung, unterscheiden sich jedoch in Rechenmodell, Skalierbarkeit, Engine-Funktionen und Delta-Lake-Kompatibilität. Dieses Handbuch bietet eine ausgewogene Auswertung, die Ihnen bei der Auswahl des richtigen Kernels hilft und häufige Fehlannahmen hinsichtlich Kosten und Leistung vermeidet.

Important

Die Wahl des Notebook-Kernels ist nicht nur eine Frage von Kosten oder Datengröße. Rechenkonfiguration, Funktionsanforderungen von Delta Lake, der Reifegrad der Engine und das erwartete Datenwachstum spielen alle eine wichtige Rolle bei der richtigen Entscheidungsfindung.

Grundlegendes zu Ihren Berechnungsoptionen

Ein häufiges Missverständnis ist, dass der Python Kernel immer billiger ist als der Spark-Kernel für kleine Datenworkloads. Tatsächlich hängt die Kosten davon ab, wie Sie die Berechnung für jeden Kernel konfigurieren.

Python-Kernelberechnung

Der Python Kernel wird auf einem Einzelknotencomputer ausgeführt, der standardmäßig auf 2 vCores (1 CU) festgelegt ist und für den Start bei bis zu 64 vCores (32 CU) konfiguriert werden kann. Diese Umgebung hat keine verteilte Ausführung. Der Startpool initialisiert in ca. 5 Sekunden und macht ihn für interaktive Arbeit schnell.

Spark-Kernel-Rechenleistung

Der Spark-Kernel verwendet Spark-Pools mit mehreren Konfigurationsoptionen:

Clusterkonfiguration vCores für Executoren verfügbar Startzeit der Sitzung Nach Sitzungsbeginn verbrauchte CUs
Starterpool (Standard) Workerknoten mit 8 Kernen, Autoskalierung aktiviert; beginnt mit einem einzelnen Knoten und skaliert innerhalb weniger Minuten nach Sitzungsbeginn proaktiv auf einen dedizierten Workerknoten. ~5 Sekunden 8 CUs (Minimum, nach der proaktiven Hochskalierung)
Single-Node*, 8-vCore (über Starterpool) 8-Core-Executor und -Treiber teilen denselben Knoten ~5 Sekunden (mit vorgewarm Pool) 4 CUs
Einzelknoten*, benutzerdefinierter Pool mit 4 vCores 4-Core-Executor und -Treiber teilen denselben Knoten Erfordert einen benutzerdefinierten Pool; Der Sitzungsstart liegt in der Regel zwischen 3 und 5 Minuten. 2 CUs
Benutzerdefinierter Pool mit mehreren Knoten Skaliert mit der Clustergröße Der Sitzungsstart liegt in der Regel zwischen 3 und 5 Minuten. Variiert

Bei Verwendung des Startpools beginnt eine 8-vCore Spark-Sitzung mit einem einzigen Knoten in etwa 5 Sekunden – vergleichbar mit dem Python Kernel. Ein Spark-Cluster mit einem einzigen Knoten behält die Kosten ähnlich wie der Python Kernel bei und bietet gleichzeitig Zugriff auf alle Spark-nativen Funktionen, einschließlich des nativen Ausführungsmoduls (NATIVE Execution Engine, NEE).

Hinweis

Es gibt zwei Möglichkeiten zum Konfigurieren von Spark-Pools mit einem Knoten. Für die meisten Workloads wird in der Regel empfohlen, die erste Methode zu verwenden, Overprovisioned single-node. Die zweite Methode, classic single-node , ist besser, wenn treiberintensive Prozesse vorhanden sind, aber die Menge der von Spark-Executoren verwendbaren Ressourcen beschränkt.

  • Überbereitgestellter Einzelknoten: Beginnen Sie mit einem Spark Pool (d. h. einem Starter Pool), bei dem Autoskalierung und dynamische Zuweisung aktiviert sind, wobei Autoskalierung auf 1 bis > 1 Knoten festgelegt ist. Erstellen Sie ein Umgebungselement, das auf den Spark-Pool verweist, und legen Sie die Anzahl der Executoren auf 1 fest. Notizbücher, die diese Umgebung verwenden, stellen einen Spark-Cluster mit einem einzigen Knoten bereit, in dem sowohl der Treiber als auch der Executor alle Ressourcen gemeinsam nutzen.
  • Klassischer Einzelknoten: Erstellen Sie einen Spark Pool mit der maximalen Anzahl von Knoten, die auf 1 festgelegt sind. Diese Konfiguration funktioniert mit aktivierter oder deaktivierter autoskalierter und dynamischer Zuordnung , da die Auswahl keine Auswirkungen auf die Bereitstellungsstrategie hat. Notebooks, die diesen Spark-Pool verwenden, haben 50 % der v-Cores dem Treiber und 50 % den Executoren zugewiesen.

Leistung nach Workload-Größe

Benchmarks, die Fabric Spark mit der Native Execution Engine mit Python-Engines für Einzelrechner (wie Pandas, DuckDB oder Polars) über End-to-End-ELT-Workloads hinweg vergleichen, zeigen je nach Datenumfang klare Muster:

Datenskalierung (komprimiert) Motorvorteil
Ultra-klein (< ~140 MB) Python-Engines für Einzelrechner (DuckDB, Polars) sind schneller.
Klein (~1–2 GB) Python-Engines haben zwar immer noch einen Vorteil, aber Fabric Spark mit NEE wird wettbewerbsfähig, wenn die Anzahl der für jede Engine verfügbaren Kerne erhöht wird, insbesondere bei schreibintensiven Vorgängen.
Klein mittel (~10–13 GB) Fabric Spark mit der Native Execution Engine ist mit den meisten Single-Machine-Engines konkurrenzfähig oder schneller. Single-Machine-Python-Engines können bei einer geringeren Anzahl von vCores zu Out-of-Memory-Fehlern (OOM-Fehlern) führen.
Mittel und höher (~100 GB+) Für die meisten Workloads ist Fabric Spark mit dem nativen Ausführungsmodul das schnellste und zuverlässigste Modul.

Skalierung über kleine Daten hinaus

Berücksichtigen Sie bei der Auswahl einer Engine die Datenwachstumsrate. Nicht verteilte Python Engines funktionieren gut für wirklich kleine Daten, aber das Migrieren Ihres Codes, wenn Daten ihre Grenzen überschreiten, ist kostspielig. Wenn Sie mit Spark in einer Einzelknoten-Konfiguration beginnen, können Sie diese nahtlos auf eine Mehrknoten-Konfiguration erweitern, ohne Ihre Data-Engineering-Pipelines neu schreiben zu müssen.

Delta Lake-Kompatibilität

Die Delta-Lake-Kompatibilität ist ein entscheidender Faktor bei der Auswahl einer Engine. Fabric Spark verfügt über systemeigene, umfassende Delta Lake-Unterstützung, während Python Engines möglicherweise sinnvolle Lücken aufweisen:

Important

Die folgende Tabelle zur Featureunterstützung gibt den Stand jeder Engine mit Stand Juni 2026 wieder und basiert auf direkten Tests mit Fabric Spark Runtime 1.3 und 2.0. Das Open-Source-Software-(OSS-)Python-Ökosystem für Delta Lake entwickelt sich schnell – delta-rs, DuckDB und Polars veröffentlichen häufig neue Versionen, die den Support für das Delta-Protokoll schrittweise erweitern. Prüfen Sie immer die aktuelle Dokumentation und die Versionshinweise für jede Engine, bevor Sie sich im Produktivbetrieb auf eine bestimmte Funktion verlassen:

Delta Lake-Funktion Fabric Spark delta-rs (Python) DuckDB Polars
Delta-Tabellen lesen ✅ ✅ ✅ ✅
Delta-Tabellen schreiben ✅ ✅ Anhängen, Überschreiben (einschl. prädikatbasiertem), UPDATE, DELETE, MERGE ⚠️ Nur INSERT (erfordert ATTACH ... (TYPE delta, READ_WRITE)); kein UPDATE/DELETE/MERGE; für andere Schreibvorgänge delta-rs verwenden ⚠️ Anfügen, Überschreiben (einschließlich prädikatbasiertem Überschreiben), nur zusammenführen; kein UPDATE/DELETE
ACID-Garantien / Optimistische Parallelitätskontrolle ✅ ✅ ⚠️ INSERT fügt nur an; keine native Konflikterkennung; delta-rs mit Versionsfixierung für Read-then-Write-Isolation verwenden ⚠️ OCC bei Schreibvorgängen; Polars-Lesevorgänge liegen außerhalb der Transaktionsgrenze – erfordert explizite Versionsfixierung für die Read-then-Write-Isolation
Schemaentwicklung beim Schreiben ✅ ✅ ❌ Keine Schemaentwicklung bei INSERT ✅
Spaltenzuordnung ✅ ❌ ✅ ❌
Löschvektoren (lesen) ✅ ❌ ✅ ✅
Löschvektoren (Schreiben) ✅ ❌ ❌ ❌
Typverbreiterung (Lesen) ✅ ❌ ✅ ❌
Typverbreiterung (Schreiben) ✅ ❌ ❌ ❌
Überspringen von Dateien ✅ ✅ ✅ ✅
Partitionierte Schreibvorgänge ✅ ✅ ❌ Verwenden von Delta-rs zum Schreiben mit Partitionierung ✅
Liquid Clustering (Schreibvorgang) ✅ ❌ ❌ ❌
Zeitreise ✅ ✅ ✅ ✅
RESTORE ✅ ✅ ❌ Verwenden von Delta-rs zum Wiederherstellen von Tabellen ❌ Verwenden von Delta-rs zum Wiederherstellen von Tabellen
Oberflächlicher Klon (erstellen) ✅ ❌ ❌ ❌
Oberflächliches Klonen (schreibgeschützt) ✅ ❌ ❌ ❌
Zeilennachverfolgung ✅ ⚠️ Lese- und Schreibvorgänge sind erfolgreich, aber das Row-Tracking _metadata ist nicht verfügbar; Pipelines, die für die Deduplizierung oder Change Data Capture (CDC) auf row_id angewiesen sind, müssen zum Lesen Spark verwenden. ⚠– Lese- und Schreibvorgänge erfolgreich, die Zeilennachverfolgung _metadata ist jedoch nicht zugänglich. Pipelines, die auf row_id für die Deduplizierung oder CDC angewiesen sind, müssen Spark zum Lesen verwenden. ⚠– Lese- und Schreibvorgänge erfolgreich, die Zeilennachverfolgung _metadata ist jedoch nicht zugänglich. Pipelines, die auf row_id für die Deduplizierung oder CDC angewiesen sind, müssen Spark zum Lesen verwenden.
Identitätsspalten (gelesen) ✅ ✅ ✅ ✅
Identitätsspalten (Schreiben) ✅ ❌ ❌ ❌
Generierte Spalten (gelesen) ✅ ✅ ✅ ✅
Generierte Spalten (Schreiben) ✅ ❌ ❌ ❌
Datenfeed ändern (lesen) ✅ ✅ ❌ Verwenden Sie delta-rs, um Änderungsdatenfeeds zu lesen ❌ Verwenden Sie delta-rs, um Änderungsdatenfeeds zu lesen
Datenfeed ändern (Schreiben) ✅ ❌ ❌ ❌
V2-Prüfpunkte (lesen) ✅ ❌ ✅ ❌
V2-Prüfpunkte (Schreiben) ✅ ❌ ❌ ❌
Prüfpunktintervall ✅ Konfigurierbar (Standard 10) ⚠Konfigurierbar (Standard 100) ❌ INSERT schreibt keine Prüfpunkte; Log wächst ungebunden ohne externe Wartung über Delta-rs ⚠Konfigurierbar (Standard 100)
OPTIMIEREN ✅ ✅ ❌ Verwenden von Delta-Rs zum Optimieren ❌ Verwenden von Delta-Rs zum Optimieren
Automatische Komprimierung ✅ ❌ ❌ ❌
VAKUUM ✅ ❌ Risiko: Akkumulieren verwaister Dateien ❌ Risiko: Akkumulieren verwaister Dateien ❌ Risiko: Akkumulieren verwaister Dateien
VACUUM LITE ✅ ✅ ❌ Verwenden Sie delta-rs zum Bereinigen von lite ❌ Verwenden Sie delta-rs zum Bereinigen von lite

Wichtige Auswirkungen:

  • Neuere Delta-Features: Die Unterstützung für neuere Delta-Lake-Features – darunter Typerweiterung, V2-Checkpoints, Liquid Clustering, Identity-Spalten, Schreibvorgänge mit Change Data Feed und Lesevorgänge mit Shallow Clones – ist in OSS-Python-Engines inkonsistent oder fehlt ganz. Wenn Ihre Datenpipeline von einem dieser Features abhängt, verwenden Sie Fabric Spark. Betrachten Sie Python-Engines als Ergänzung zu Spark für bestimmte Workloads (leichtgewichtige Lesevorgänge, lokale Entwicklung, einfache Append-Vorgänge) und nicht als universellen Ersatz.

  • Löschvektoren: Löschvektoren sind eine bewährte Methode für Delta-Tabellen (die ab Fabric Spark Runtime 2.0 standardmäßig aktiviert sind), da sie die Leistung von MERGE-, UPDATE- und DELETE-Vorgängen mithilfe einer Merge-on-Read-Strategie erheblich verbessern. Keine Python Engine (Delta-rs, DuckDB oder Polars) unterstützt das Schreiben von Löschvektoren. Wenn Sie ein Python Modul verwenden, um in Tabellen zu schreiben, für die Löschvektoren aktiviert sind, treten Kompatibilitätsfehler auf.

  • ACID-Garantien: Nicht alle Python Motoren bieten native ACID-Garantien. Delta-rs unterstützt optimistische Parallelitätssteuerung (OCC) für Zusammenführungs-, Aktualisierungs- und Löschvorgänge. Cross-Engine-Pipelines, bei denen DuckDB oder Polars den Lesevorgang und delta-rs den Schreibvorgang ausführt, erfordern jedoch auf beiden Seiten eine explizite Versionsfixierung, um die Lese-/Schreibisolation aufrechtzuerhalten. DuckDB INSERT ist eine Append-Only-Operation ohne Konflikterkennung.

  • Checkpointing: Nicht alle Python-Engines schreiben Prüfpunkte, und diejenigen, die dies tun, schreiben standardmäßig nur alle 100 Commits einen Prüfpunkt statt wie bei Spark standardmäßig alle 10 Commits. DuckDB INSERT schreibt niemals Prüfpunkte, wodurch das Delta-Transaktionsprotokoll ungebunden wird. Erwägen Sie das Festlegen eines niedrigeren Prüfpunktintervalls in Delta-rs und Polars, und führen Sie regelmäßige Delta-rs-Wartung für Tabellen aus, die von DuckDB geschrieben wurden.

  • Zeilennachverfolgung: Alle Python-Engines können aus Tabellen mit aktivierter Zeilennachverfolgung lesen und in diese schreiben, aber auf die Spalte _metadata, die row_id und row_commit_version enthält, kann außerhalb von Spark nicht zugegriffen werden. Pipelines, die sich bei der Deduplizierung oder CDC auf row_id stützen, müssen mit Spark gelesen werden.

  • OPTIMIZE und VAKUUM: Python Motoren setzen auf die deltalake Bibliothek für Verdichtung und Vakuum. Während delta-rs für diese Vorgänge schnell sein kann, bringt dieser Ansatz zusätzlichen Aufwand bei der Abhängigkeitsverwaltung mit sich, und die Vorgänge sind nicht auf die gleiche Weise nativ orchestriert wie in Spark. Tabellen, die ausschließlich über Python Engines geschrieben wurden, sammeln kleine Dateien und ungebundene Transaktionsprotokolle ohne explizite Wartung.

  • Flache Klone: Python-Engines unterstützen das Lesen von Tabellen, die mittels eines flachen Klons erstellt wurden, aufgrund von Einschränkungen bei der Auflösung absoluter Pfade nicht. Kein Python-Modul unterstützt das Erstellen von flachen Klonen.

Motorreife und Microsoft Unterstützung

Fabric Spark-Unterstützung

Fabric Spark ist Microsofts eigene Abspaltung des Open-Source-Projekts Apache Spark. Microsoft verwaltet und liefert die Laufzeit, d. h.:

  • Microsoft unterstützt die internen Komponenten von Spark und Delta Lake durchgängig, einschließlich der Native Execution Engine (NEE), die auf Velox und Apache Gluten basiert.
  • Sie können Supporttickets für Spark-Verhalten, Abfragepläne, Speicherprobleme und Modulfehler öffnen.
  • Leistungsverbesserungen werden kontinuierlich als Teil Fabric Laufzeitupdates ausgeliefert– Ihr vorhandener Code wird schneller ohne Codeänderungen.

Python-Engine-Unterstützung

Microsoft pflegt keinen Fork von Open-Source-Python-Engines wie DuckDB oder Polars. Die Unterstützung ist auf Probleme in den OneLake-Integrationen beschränkt, die als Teil der Fabric Laufzeit bereitgestellt werden, z. B. Authentifizierung oder Dateisystemzugriff. Wenn eine Leistungsregression, ein Modulfehler oder eine fehlerhafte API zwischen Bibliotheksversionen auftritt, müssen Sie direkt mit den Open Source-Communitys für diese Bibliotheken interagieren.

Operativer Reifegrad

Reale Erfahrung beim Aufbau von End-to-End-ELT-Benchmarks mit diesen Motoren hebt sinnvolle Unterschiede in der Betriebsreife hervor:

  • Spark: Code, der für eine Laufzeitversion geschrieben wurde, wird ohne Änderungen an neueren Versionen ausgeführt und führt aufgrund kontinuierlicher Microsoft Engineering-Investition schneller aus. Die Spark UI und die Fabric-Telemetrie bieten Echtzeitüberwachung mit vollständiger Transparenz über aktive Abfragen, Ausführungspläne und historische Auftragsausführungen.
  • DuckDB und Polars: API- und Verhaltensänderungen zwischen Versionen können eine Codeumgestaltung erfordern, wenn die Engines reif sind und APIs weiterentwickelt werden. Beiden Engines fehlt eine Live-Überwachung – wenn ein Auftrag länger als erwartet läuft, gibt es kein Äquivalent zur Spark-UI, um nachzuvollziehen, was passiert. Die Authentifizierung für OneLake kann versionsspezifische Umgehungslösungen erfordern.
  • Overhead eines komponierbaren Daten-Stacks: Die Verwendung von DuckDB oder Polars für einen vollständigen ELT-Workflow bedeutet in der Regel, mehrere Bibliotheken miteinander zu verknüpfen (z. B. DuckDB für Datenscans und -transformation, delta-rs für Schreiboperationen und Wartung). Die Bibliothekskompatibilität zwischen den Komponenten muss gewahrt bleiben und sollte immer dann berücksichtigt werden, wenn die Version der Bibliothek über die mit der Laufzeit ausgelieferte Version hinaus aktualisiert wird.

Entscheidungsleitfaden

Verwenden Sie den Python-Kernel, wenn

  • Ihre Daten sind klein – unter ca. 1 GB komprimiert – und die Rohleistung bei Einzelmaschinenmotoren ist am wichtigsten.
  • Sie erstellen einfache API-Orchestrierung, REST/gRPC-Integrationen oder Steuerungsflussautomatisierung, bei der verteilte Compute unnötigen Aufwand hinzufügt.
  • Sie führen eine schnelle interaktive Exploration kleiner Datensätze durch, bei der die Latenz von Ad-hoc-Abfragen im Vordergrund steht.
  • Ihre Workload erfordert eine ältere Python Version als das, was in der aktuellen Fabric Spark-Laufzeit enthalten ist.
  • Sie verstehen und akzeptieren die Einschränkungen der Delta Lake-Funktion des verwendeten Python-Moduls.

Verwenden Sie den Spark-Kernel, wenn

  • Ihre Daten sind 1 GB oder größer in komprimierter Form, oder Sie erwarten, dass die Daten auf diese Skala wachsen.
  • Sie benötigen vollständige Delta Lake-Kompatibilität, einschließlich Löschvektoren, Spaltenzuordnung, Typverbreiterung, OPTIMIZE, VACUUM und ACID-Garantien.
  • Sie benötigen Funktionen auf Produktionsniveau, z. B. Umgebungsvariablen, elementbasierte Bibliotheksverwaltung, hohe Parallelität und FAIR- oder First-In-First-Out-FiFO-Auftragsplanung.
  • Sie benötigen Echtzeitüberwachung und vollständige Transparenz über laufende Jobs.
  • Sie verlassen sich auf Spark-native APIs wie MLlib, Spark SQL oder Spark Streaming.
  • Sie möchten Microsoft End-to-End-Unterstützung für Ihr Datenverarbeitungsmodul verwenden.
  • Sie möchten die Möglichkeit haben, ohne Code neu schreiben zu müssen von Single-Node- auf Multi-Node-Computing zu skalieren.
  • Sie müssen Notizbücher in PySpark, SparkSQL, Scala oder SparkR erstellen.

Tipp

Für Workloads ab einem komprimierten Datenvolumen von 1 GB sollten Sie mit einem Single-Node-Spark-Cluster mit 8 vCores unter Verwendung des Starterpools beginnen. Sie erhalten nahezu sofortige Startzeiten der Sitzung, vollständige Fabric Spark-Funktionen einschließlich NEE und die Möglichkeit, bei Bedarf auf mehrere Knoten zu skalieren – alles, während Sie nur auf einem einzelnen Knoten wie dem Python Kernel arbeiten.

Wichtige Unterschiede auf einen Blick

Kategorie Python-Kernel Spark-Kernel
Standardberechnung 2-vCore-Einzelknoten-virtuelle Maschine (VM) (auf bis zu 64 vCores skalierbar) Startpool: 8-vCore-Workerknoten mit automatischer Skalierung
Minimale Konfiguration mit einem einzelnen Knoten 2 virtuelle Kerne 8 vCores (Startpool, ~5 Sek. Start); 4 vCores (benutzerdefinierter Pool, längerer Start)
Startzeit ~5 Sekunden ~5 Sekunden (Startpool); länger für benutzerdefinierte Pools
Verteilte Ausführung No Ja
Unterstützte Sprachen Python PySpark, SparkSQL, Scala, SparkR
Python-Version Mehrere Verfügbare Versionen An Fabric Spark-Laufzeitversion gebunden
Delta Lake (vollständige Featureunterstützung) No Ja
Liveüberwachung Begrenzt Vollständig (Jobüberwachungsseite + Spark UI)
Microsoft Engine-Unterstützung Nur OneLake-Integrationen Vollständige Laufzeitunterstützung
Python Bibliothekszugriff PIP-Installation pip install + Umgebungselemente
Spark-native APIs (MLlib, Streaming) No Ja
Produktionsfunktionen (Umgebungsvariablen, Umgebungen) Begrenzt Vollständig
Unterstützung für hohe Parallelität No Ja
V-Ordnung für schnelle Direct-Lake-semantische Modelle No Ja
Objektspeichercache, der beschleunigte Wiederholungslesevorgänge ermöglicht Engine-abhängig (DuckDB verfügt über ein integriertes Caching, Polars nicht) Ja (intelligenter Cache)
Lässt sich auf mehrere Knoten skalieren No Ja

Glossar

  • ACID-Transaktionen: Eine Reihe von Eigenschaften (Atomität, Konsistenz, Isolation, Haltbarkeit), die garantieren, dass Datenbankvorgänge zuverlässig verarbeitet werden. Delta Lake implementiert ACID-Semantik mit optimistischer Parallelitätskontrolle und Transaktionsprotokollen.
  • Optimistische Nebenläufigkeitskontrolle (OCC): Eine Nebenläufigkeitsstrategie, bei der Transaktionen ohne Sperren durchgeführt werden und beim Commit geprüft wird, dass keine konfligierenden Änderungen aufgetreten sind. Delta Lake verwendet OCC; engineübergreifende Pipelines (z. B. Polars-Lesevorgänge, gefolgt von delta-rs-Schreibvorgängen) erfordern eine explizite Versionsfixierung, um die Isolation zu wahren.
  • Automatische Komprimierung: Ein Delta Lake-Feature in der Fabric Spark-Laufzeit, die kleine Dateien automatisch nach Schreibvorgängen in größere zusammenführt, wodurch die Dateifragmentierung ohne einen separaten OPTIMIZE-Schritt reduziert wird.
  • Ändern des Datenfeeds (CDF): Ein Delta Lake-Feature, das Änderungen auf Zeilenebene (Einfügen, Aktualisieren, Löschen) in einer Tabelle aufzeichnet und inkrementelle Datenverarbeitung und CDC-Pipelines ermöglicht. Nur Fabric Spark unterstützt das Schreiben von CDF-Metadaten (Change Data Feed); OSS-Python-Engines können sie lesen, aber nicht schreiben.
  • Spaltenzuordnung: Ein Delta Lake-Feature, mit dem Spalten umbenannt oder gelöscht werden können, ohne die zugrunde liegenden Parkettdateien neu zu schreiben. Unterstützt von Fabric Spark; wird von Delta-rs oder Polars nicht unterstützt.
  • delta-rs: Eine Open-Source Rust-Implementierung des Delta Lake-Protokolls mit Python Bindungen (das deltalake PyPI-Paket). Bietet Delta-Lese-/Schreibunterstützung in OSS-Python-Umgebungen, verfügt jedoch über einen geringeren Funktionsumfang als delta-spark, die die Fabric Spark-Laufzeit unterstützen.
  • Löschvektoren: Eine Delta Lake-Optimierung, die merge-on-read verwendet, um die Menge der während MERGE-, UPDATE- und DELETE-Vorgängen neu geschriebenen Daten zu reduzieren. In Fabric Spark Runtime 2.0 standardmäßig aktiviert; wird für Schreibvorgänge durch ein OSS-Python Modul nicht unterstützt.
  • FAIR-Planung: Eine Spark-Planungsrichtlinie, die Clusterressourcen fair für gleichzeitige Aufträge zuordnet, wobei sichergestellt wird, dass kein einzelner Auftrag den Cluster monopolisiert.
  • FIFO-Planung: Eine Spark-Planungsrichtlinie, die Aufträge in der Reihenfolge "First-In-First-Out" ausführt und dem ersten übermittelten Auftrag Priorität verleiht.
  • Liquid Clustering: Ein Delta Lake-Feature, das Daten für eine optimale Abfrageleistung inkrementell neu organisiert, ohne dass eine explizite Partitionierung erforderlich ist. Wird nur von Fabric Spark unterstützt.
  • NEE (Native Execution Engine): Ein vektorisiertes C++-Abfragemodul, das auf Velox und Apache Gluten basiert, das Fabric Spark-Workloads beschleunigt. NEE ist ohne zusätzliche Berechnungskosten verfügbar und erfordert keine Codeänderungen.
  • Zeilenverfolgung: Eine Delta-Lake-Funktion, die jeder Zeile über eine row_id-Spalte eine stabile row_commit_version und _metadata zuweist. Alle Module können aus Tabellen mit aktivierter Zeilenverfolgung lesen und schreiben, aber nur Fabric Spark kann auf den _metadata Spalteninhalt zugreifen.
  • Spark-Pool: Eine gemeinsam genutzte Computeressource für die Ausführung verteilter Spark-Workloads. Der Starterpool bietet vorab warmte Knoten für nahezu sofortige Sitzungsstartzeiten (~5 Sekunden) mit standardmäßig aktivierter automatischer Skalierung.
  • V-Order: Eine Fabric-Schreiboptimierung, die Parquet-Daten sortiert und komprimiert, um die Leseleistung für Power BI Direct Lake semantische Modelle und andere Fabric-Lesepfade zu verbessern.
  • Intelligenter Cache: Ein intelligenter Datenträgercache in Fabric Spark, der wiederholte Lesevorgänge derselben Delta-Tabellendateien beschleunigt, indem Dateidaten lokal auf den Executorknoten zwischengespeichert werden.

Verwandte Inhalte

  • Last updated on