Migration von Fabric Runtime 1.3 zu Runtime 2.0

Fabric Runtime 2.0 ist die neueste allgemein verfügbare (GA) und Standardlaufzeit für Apache Spark-Workloads in Microsoft Fabric. Es aktualisiert das Betriebssystem, Java, Scala, Python, R, Apache Spark und Delta Lake. Da mehrere dieser Updates die Grenzen der Hauptversionen überschreiten, sollten Sie Ihre Notebooks, Spark-Job-Definitionen, Bibliotheken und Datenpipelines validieren, bevor Sie Produktionsworkloads von Runtime 1.3 migrieren.

Dieser Leitfaden beschreibt die Änderungen, die eine Migration beeinflussen können, und bietet einen gestuften Prozess zum Umstellen Ihrer Workloads auf Runtime 2.0.

Was hat sich in Runtime 2.0 geändert

Die folgende Tabelle vergleicht die Hauptkomponenten in Runtime 1.3 und Runtime 2.0.

Component Laufzeit 1.3 Laufzeit 2.0 Migrationsüberlegungen
Freigabestufe Ende des Supports angekündigt (EOSA) GA Migriere Produktionsworkloads auf die unterstützte GA-Laufzeit.
Apache Spark 3.5.5 4.1.1 Überprüfen Sie Spark 4.1 Verhaltensänderungen und entfernte APIs.
Delta Lake 3.2 4,2 Validiere Tabellenmerkmale und Protokollkompatibilität über alle Fabric-Workloads hinweg, die deine Tabellen verwenden.
Java 11 21 Baue Java-Bibliotheken und Java Native Interface (JNI)-Abhängigkeiten neu auf und teste sie.
Scala 2.12.17 2.13.16 Kompiliiere Scala JAR-Dateien für Scala 2.13 neu. Die Artefakte von Scala 2.12 und 2.13 sind nicht binärkompatibel.
Python 3.11 3.13 Bestätigen Sie, dass jedes Python-Paket eine Python 3.13-kompatible Version und ein Linux-Wheel bereitstellt.
R 4.4.1 4.5.2 Installiere benutzerdefinierte R-Pakete erneut und teste sie. SparkR ist in Spark 4.1 veraltet.
Betriebssystem Azure Linux 2.0 (Mariner 2.0) Azure Linux 3.0 (Mariner 3.0) Baue native Bibliotheken und benutzerdefinierte Binärdateien für Azure Linux 3.0 neu auf.

Runtime 2.0 bietet außerdem neue Apache Spark 4.1-Funktionen, darunter den VARIANT-Datentyp, benutzerdefinierte SQL-Funktionen, Sessionsvariablen, Pipe-Syntax, String-Kollierung, die Python Data Source API, Python-benutzerdefinierte Tabellenfunktionen, einheitliches PySpark-Profiling sowie neue Structured Streaming State-Management- und Debugging-APIs. Für einen Überblick siehe Runtime 2.0 in Fabric.

Kompatibilitätsänderungen überprüfen

Überprüfen Sie die folgenden Bereiche, bevor Sie einen Arbeitsbereich oder eine Umgebung auf Runtime 2.0 umstellen.

Eingebaute und benutzerdefinierte Bibliotheken

Runtime 2.0 entfernt mehrere vorinstallierte Python- und R-Pakete, die in Runtime 1.3 verfügbar waren. Die Reduzierung des Standardpaketsets hält die Laufzeit schlank und verringert die Angriffsfläche für potenzielle Sicherheitsvorfälle. Ein Paket, das in Runtime 1.3 ohne Konfiguration verfügbar war, muss möglicherweise explizit zu Ihrer Runtime 2.0-Umgebung hinzugefügt werden.

Verwenden Sie den Bibliotheksmanager, um nur die Pakete hinzuzufügen, die Ihre Arbeitslast benötigt, und speichern und veröffentlichen Sie dann die Umgebung. Library Manager löst die erforderlichen Abhängigkeiten des Pakets auf, daher sollten Sie nicht jede Abhängigkeit einzeln in den folgenden Inventaren hinzufügen. Gehen Sie nicht davon aus, dass eine Bibliothek verfügbar ist oder dass ihre Version unverändert ist:

  • Vergleichen Sie die Runtime 1.3- und Runtime 2.0-Paketbestände im Fabric Runtime Releases-Repository.
  • Fügen Sie fehlende PyPI-, Conda-, Maven-, R- oder benutzerdefinierte Bibliotheken zu einer Umgebung hinzu und veröffentlichen Sie sie.
  • Pin-Versionen für Produktions-Workloads, um die Abhängigkeitsauflösung wiederholbar zu machen.
  • Bestätigen Sie, dass Python-Pakete Python 3.13 unterstützen. Pakete mit nativen Erweiterungen müssen ein kompatibles Linux-Wheel bereitstellen oder erfolgreich auf Azure Linux 3.0 gebaut werden.
  • Ersetzen Sie Scala 2.12-Abhängigkeiten durch Artefakte von Scala 2.13. Artefaktnamen umfassen üblicherweise die Scala-Binärversion, wie _2.12 oder _2.13.
  • Kompiliere benutzerdefinierte JAR-Dateien mit Java 21, Scala 2.13 und Spark 4.1 neu. Testen Sie transitive Abhängigkeiten auf Konflikte mit zur Laufzeit bereitgestellten Bibliotheken.
  • Baue benutzerdefinierte native Bibliotheken für Azure Linux 3.0 neu auf.

Fabric migriert Bibliotheksspezifikationen, wenn man die Laufzeitumgebung einer bestehenden Umgebung ändert, aber es kann nicht garantieren, dass diese Bibliotheken kompatibel bleiben. Publishing scheitert, wenn die Abhängigkeitslösung einen Konflikt findet. Für Paketinstallationsoptionen und Veröffentlichungsmodi siehe Bibliotheken in Fabric-Umgebungen verwalten.

Pakete, die aus der Standardumgebung entfernt wurden

Die folgenden Inventare umfassen benutzerorientierte Pakete und deren niedrigstufige oder transitive Abhängigkeiten. Durchsuchen Sie diese Listen nach Paketen, die von Ihrer Runtime 1.3-Workload verwendet werden. Wenn ein Paket aufgeführt ist, füge eine Python 3.13- oder R 4.5-kompatible Version über den Library Manager in deiner Runtime 2.0-Umgebung hinzu.

Python-Umgebung: 348 Conda-Pakete
Package Package Package Package
_libgcc_mutex _sysroot_linux-64_curr_repodata_hack abseil-cpp alabaster
aom appdirs archspec argon2-cffi
argon2-cffi-bindings arrow arrow-cpp asgiref
asn1crypto astropy async_generator async-lru
async-timeout autopep8 aws-c-auth aws-c-cal
aws-c-common aws-c-compression aws-c-event-stream aws-c-http
aws-c-io aws-c-mqtt aws-c-s3 aws-c-sdkutils
aws-checksums aws-crt-cpp aws-sdk-cpp azure-keyvault
azure-storage babel backports backports.shutil_get_terminal_size
bcrypt beautifulsoup4 binaryornot binutils_impl_linux-64
binutils_linux-64 bitarray bkcharts black
blas bleach blinker blosc
bokeh boltons boost-cpp boto
bottleneck brunsli c-ares c-blosc2
cached-property cfitsio chardet charls
cmake cmdstan conda-package-handling conda-package-streaming
configparser contextlib2 cookiecutter curl
cython cytoolz daal4py dal
dask dask-core dataclasses datasets
dav1d dill distributed distro
django docutils entrypoints expat
fastcache flake8 flit flit-core
fmt fonts-anaconda future gcc_impl_linux-64
gcc_linux-64 geographiclib geopy get_terminal_size
gevent gflags giflib glib
glob2 glog gmp gmpy2
gobject-introspection grpc-cpp gst-plugins-base gstreamer
gtk2 gxx_impl_linux-64 gxx_linux-64 hdf5
heapdict html5lib huggingface_hub imagecodecs
imageio imagesize inflection iniconfig
intel-openmp intervaltree ipython_genutils jaraco.classes
jeepney jpeg json5 jsonpatch
jsonpointer jupyter_console jupyter_events jupyter-lsp
jupyter_server jupyter_server_terminals jupyterlab jupyterlab_pygments
jupyterlab_server jxrlib kernel-headers_linux-64 keyring
lazy_loader lazy-object-proxy liac-arff libaec
libarchive libavif libclang libcurl
libev libevent libgcc-devel_linux-64 libgfortran-ng
liblief libllvm14 libmamba libmambapy
libnghttp2 libprotobuf libsolv libspatialindex
libssh2 libstdcxx-devel_linux-64 libthrift libtool
libwebp libzopfli lightning-utilities llvm-openmp
llvmlite locket lxml lz4
lz4-c lzo make markdown
mccabe menuinst minio mistune
mkl mkl_fft mkl_random mkl-service
mock more-itertools mpc mpfr
mpi mpich mpmath msgpack-python
msrest multipledispatch multiprocess mysql
nbclassic nbclient nbconvert nest-asyncio
networkx ninja ninja-base nose
notebook notebook-shim nspr nss
numba numexpr numpy-base numpydoc
oauthlib olefile openml orc
overrides pandocfilters paramiko partd
patch patchelf path path.py
pathlib2 pep8 pickleshare pkginfo
pluggy ply poppler poppler-data
prettytable prometheus_client py-cpuinfo py-lief
pybind11-abi pycodestyle pycosat pycurl
pydocstyle pyerfa pyflakes pynacl
pyopenssl pyqt pyqt5-sip pyrsistent
pytables pytest python-fastjsonschema python-json-logger
python-libarchive-c python-lmdb python-slugify python-xxhash
pytorch pytorch-lightning pytorch-mutex pywavelets
qdarkstyle qstylizer qt qt-main
qt-webengine qtawesome qtconsole qtpy
re2 reproc reproc-cpp requests-oauthlib
rfc3339-validator rfc3986-validator rhash ripgrep
rtree s2n safetensors scikit-build
scikit-image scikit-learn-intelex secretstorage send2trash
shap simplegeneric singledispatch sip
slicer snappy snowballstemmer sortedcollections
sortedcontainers soupsieve sphinx sphinxcontrib
sphinxcontrib-applehelp sphinxcontrib-devhelp sphinxcontrib-htmlhelp sphinxcontrib-jsmath
sphinxcontrib-qthelp sphinxcontrib-serializinghtml sphinxcontrib-websupport sqlite
sympy sysroot_linux-64 tbb tbb-devel
tbb4py tblib terminado testpath
text-unidecode textdistance tifffile tinycss2
tokenizers toml tomli-w toolz
torchdata torchmetrics transformers truststore
typed-ast ujson unicodecsv unidecode
utf8proc webencodings websocket-client wheel
whichcraft xlsxwriter xlwt xmltodict
xxhash xyzservices xz yaml-cpp
yapf zfp zict zlib
zope zope.event zope.interface zstandard
Python-Umgebung: 24 pip-Pakete
Package Package Package Package
accelerate astor dash dash-core-components
dash-cytoscape dash-html-components dash-table docker
interpret interpret-core json-tricks nni
nvidia-ml-py pyperclip pythonwebhdfs responses
retrying salib schema seqeval
simplejson tensorboardx thop typeguard
R-Umgebung: 67 Conda-Pakete
Package Package Package Package
_libgcc_mutex _sysroot_linux-64_curr_repodata_hack blosc cfitsio
expat fmt freetype freexl
geos geotiff giflib hdf4
hdf5 json-c kealib lcms2
libaec libarchive libgdal libgdal-core
libgdal-fits libgdal-grib libgdal-hdf4 libgdal-hdf5
libgdal-jp2openjpeg libgdal-kea libgdal-netcdf libgdal-pdf
libgdal-pg libgdal-postgisraster libgdal-tiledb libgdal-xls
libkml libnetcdf libnsl librttopo
libspatialite libsqlite libudunits2 libv8
libzip lzo minizip nspr
nss openjpeg poppler poppler-data
proj r-classint r-gsl r-jose
r-mgcv r-s2 r-sf r-units
r-wk spdlog sqlite tiledb
uriparser xerces-c xorg-kbproto xorg-renderproto
xorg-xextproto xorg-xproto xz

Notiz

Wenn Outbound Access Protection oder ein verwaltetes virtuelles Netzwerk den Zugriff auf öffentliche Repositories verhindert, laden Sie kompatible Wheel-Dateien herunter oder hosten Sie einen Paketspiegel. Für Anweisungen siehe Bibliotheken verwalten mit eingeschränktem Netzwerkzugriff in Fabric.

Änderungen an der Spark-Konfiguration

Runtime 2.0 fügt Spark-Einstellungen hinzu, entfernt welche und ändert einige Standardwerte. Fabric verwendet auch andere Standardeinstellungen als Apache Spark für einige Einstellungen.

Bevor Sie migrieren, überprüfen Sie die Spark-Einstellungen, die Sie für Ihre Arbeitsbereiche, Umgebungen, Notizbücher und Spark-Job-Definitionen konfiguriert haben. Entferne Einstellungen, die nicht mehr unterstützt werden, und teste Workloads, die auf geänderten Standardeinstellungen angewiesen sind. Verwenden Sie die Laufzeit-Standardeinstellungen, es sei denn, die Dokumentation weist Sie an, eine Einstellung zu ändern.

Bemerkenswerte Änderungen an Standardwerten

Die folgende Tabelle listet ausgewählte Baseline-Änderungen auf. "Nicht gesetzt " bedeutet, dass die Basislinie keinen Wert explizit festlegt; es bedeutet nicht, dass die Funktion deaktiviert ist.

Configuration Runtime-Wert 1.3 Runtime-2.0-Wert Migrationsüberlegungen
spark.checkpoint.compress false true Checkpoint-Dateien sind standardmäßig komprimiert. Validierung der Interoperabilität von Checkpoints und des Speicherverhaltens.
spark.databricks.delta.optimizeWrite.enabled true Nicht festgelegt Die Eigenschaft wird nicht entfernt. Validiere effektives optimiertes Schreibverhalten mit deinen Tabellen-, Sitzungs- und Ressourcenprofileinstellungen.
spark.databricks.delta.optimizeWrite.partitioned.enabled false true Validiere den Schreibdurchsatz und die Größen der Ausgabedateien für partitionierte Delta-Tabellen.
spark.hadoop.parquet.block.size 1073741824 (1 GiB) 134217728 (128 MiB) Parquet-Writer zielen auf kleinere Blöcke ab. Überprüfen Sie Dateigrößen und die nachgelagerte Leseleistung.
spark.microsoft.delta.optimize.fast.enabled false true OPTIMIZE kann Arbeit überspringen, es sei denn, die Kriterien für Dateianzahl oder geschätzte Kompaktierungsgröße sind erfüllt. Überprüfen Sie die Wartungsergebnisse.
spark.microsoft.delta.optimize.fileLevelTarget.enabled false true Dateien, die zuvor mindestens die Hälfte ihres Kompaktierungsziels erreichten, werden nicht wieder kompaktiert. Überprüfen Sie das Dateilayout nach OPTIMIZE.
spark.microsoft.delta.targetFileSize.adaptive.enabled false true Delta berechnet die Zieldateigröße basierend auf der Tabellengröße. Überprüfen Sie die resultierenden Dateigrößen und die Leseleistung.
spark.speculation.multiplier 1.5 3 Eine Aufgabe muss dreimal so langsam ablaufen wie der Median, bevor Spark sie für spekulative Ausführung in Betracht zieht.
spark.speculation.quantile 0.75 0.9 Spark wartet, bis 90% Aufgaben abgeschlossen sind, bevor es spekulative Ausführung in Betracht zieht.
spark.sql.files.maxPartitionBytes 134217728 (128 MiB) 536870912 (512 MiB) Datei-Scans können mehr Daten in jede Partition packen. Validiere Parallelismus und den Executor-Speicherverbrauch.
spark.sql.maxSinglePartitionBytes Long.MaxValue 128m Eine einzelne Partition ist standardmäßig auf 128 MiB begrenzt. Validiere Abfragen, die große einzelne Partitionen erzeugen.
spark.sql.orc.compression.codec snappy zstd Neue ORC-Schreibvorgänge verwenden standardmäßig Zstandard-Kompression. Prüfen Sie die Kompatibilität und Leistung mit nachgelagerten Readern.
spark.sql.sources.v2.bucketing.enabled false true Spark ermöglicht standardmäßig speicherpartitionierte Joins und anderes Data Source V2-Bucketing-Verhalten. Validiere Abfragepläne und -ergebnisse.
spark.sql.sources.v2.bucketing.pushPartValues.enabled false true Spark kann kompatible Partitionswerte für Data Source V2 Bucketing pushen. Abfragepläne für Bucket-Tabellen validieren.

Laufzeit 2.0 verwendet ROCKSDB ebenfalls statt LEVELDB für spark.shuffle.service.db.backend und setzt spark.shuffle.service.removeShuffle auf true. Spark nutzt den externen Shuffle-Service, um unnötige Shuffle-Blöcke für freigegebene Executors zu löschen.

Delta-paralleles Laden von Snapshots, paralleles Datenüberspringen und treiberseitiges Laden von Snapshots ändern sich ebenfalls von false zu true. Teste Abfragelatenz und den Treiberressourcenverbrauch, insbesondere bei Abfragen, die auf mehrere Delta-Tabellen zugreifen.

Session-Start-Oversteuerungen und native Ausführung

Fabric-Feature-Rollouts können Baseline-Werte zu Beginn einer Sitzung überschreiben.

Configuration Runtime 2.0-Basiswert Runtime 2.0 Session-Start-Wert in öffentlichen Produktionsregionen Migrationsüberlegungen
spark.gluten.sql.columnar.costBasedFallback.enabled false true Der Produktions-Rollout, der am 16. Oktober 2026 verzeichnet wurde, ermöglicht kostenbasierten Fallback zu Spark. Überprüfe die Abfragepläne und die Leistung erneut, einschließlich der vor der Einführung getesteten Workloads.
spark.sql.parquet.native.writer.complexTypes.enabled false true Testen nativer Parquet-Schreibvorgänge und nachgelagerter Lesevorgänge für Arrays, Maps und Structs.

Wenn Sie die native Ausführungs-Engine verwenden, fügen Sie die folgenden Prüfungen in Ihre Regressionstests ein:

  • Überprüfen Sie den Speicherverbrauch, wobei die Standard-Batch-Größe für spaltenorientierte Daten von 4.096 auf 10.240 erhöht wird.
  • Vergleichen Sie Shuffle-Pläne und Performance bei einer Senkung des Schwellenwerts für sortierungsbasiertes spaltenbasiertes Shuffle von 100.000 auf 4.000 Partitionen.
  • Vergleichen Sie die Ergebnisse regulärer Ausdrücke und die Leistung. Die Unterstützung für Java-Regex durch die native Engine wechselt von deaktiviert zu aktiviert, und die Einstellung, die alle Regex-Ausdrücke auf Spark zurückfallen lässt, ändert sich von true zu false.

Die Standardwerte von Apache Spark 4.1 werden in Fabric anders beibehalten

Fabric Runtime 2.0 überschreibt absichtlich die folgenden Apache Spark 4.1-Standardeinstellungen. Gehe nicht davon aus, dass ein Upstream-Standard von Spark 4.1 in Fabric unverändert gilt.

Configuration Apache Spark 4.1 Standardvorgabe Fabric Runtime 2.0 Wert
spark.eventLog.compress true false
spark.eventLog.rolling.enabled true false
spark.sql.ansi.enabled true false
spark.sql.catalog.spark_catalog builtin org.apache.spark.sql.delta.catalog.DeltaCatalog
spark.sql.hive.metastore.version 2.3.10 2.3.2

Spark SQL und DataFrame-Verhalten

Spark 4.1 führt Verhaltensänderungen ein, die Abfrageergebnisse verändern oder dazu führen können, dass zuvor akzeptierte Abfragen fehlschlagen. Achten Sie besonders auf das ANSI-SQL-Verhalten, Casts, Datums- und Zeitstempeloperationen, Datentypen, JDBC-Zuordnungen und veraltete SQL-Konfigurationen.

Führen Sie Regressionstests zum Vergleichen von Folgendem durch:

  • Ausgabeschemata, einschließlich Typ, Präzision, Skalierung und Nullfähigkeit.
  • Zeilenanzahlen und aggregierte Ergebnisse.
  • Null-, Überlauf-, Verhalten bei Division durch Null und Verhalten bei ungültiger Typumwandlung.
  • Datums-, Zeitstempel-, Zeitzonen- und Intervallergebnisse.
  • JDBC-Quell- und Zieltypzuordnungen.
  • Abfragepläne und Leistung für kritische Arbeitslasten.

Verwenden Sie keine Legacy-Kompatibilitätseinstellungen als dauerhafte Migrationsstrategie. Wenn du vorübergehend eine davon verwendest, um einen Fehler zu isolieren, aktualisiere den betroffenen Code und entferne die Einstellung, bevor du die Migration abschließt. Für die vollständige Reihe der Verhaltensänderungen siehe den Spark SQL-Migrationsleitfaden.

Python und pandas API auf Spark

Runtime 2.0 wechselt von Python 3.11 zu Python 3.13 und enthält die in Spark 4.1 eingeführten PySpark-Änderungen. Spark 4.1 erhöht außerdem die minimalunterstützten Versionen von pandas, NumPy und PyArrow und entfernt APIs, die in früheren Versionen eingestellt wurden.

Gängige Pandas-API-Updates bei Spark sind:

  • Ersetze DataFrame.iteritems und Series.iteritems durch items.
  • Ersetze DataFrame.append und Series.append durch ps.concat.
  • Ersetzen Sie entfernte inplace Parameter bei kategorischen Operationen durch Zuweisungen.
  • Überprüfen Sie geänderte Parameternamen und Vorgabewerte, wie inclusive und Series.str.replace(regex=...).
  • Überprüfen Sie die Ergebnis-Spaltennamen, Indexnamen, D-Typen und die Reihenfolge.

Die vollständige Liste finden Sie im PySpark-Migrationsleitfaden.

Java- und Scala-Anwendungen

Scala 2.13 ist nicht binär kompatibel mit Scala 2.12. Die Wiederverwendung eines Runtime 1.3 JAR in Runtime 2.0 kann auch dann zu Klassenladefehlern führen, wenn sich der Quellcode nicht geändert hat. Baue ein separates Runtime 2.0-Artefakt und aktualisiere alle Scala-Cross-Built-Abhängigkeiten.

Spark 4.1 ändert außerdem seine internen Servlet-API-Referenzen von javax zu jakarta. Überprüfen Sie benutzerdefinierte Listener, Spark-Erweiterungen und Bibliotheken, die mit Spark-Internals interagieren. Weitere Änderungen auf Engine-Ebene finden Sie im Spark Core Migrationsleitfaden.

Streaming-Workloads und Connectoren

Das in Runtime 1.3 enthaltene veraltete EventHubConnector Feature ist in Runtime 2.0 nicht verfügbar. Verwenden Sie den Apache Spark Kafka Connector mit dem Kafka-kompatiblen Endpunkt für Azure Event Hubs. Eine Anleitung zum Einrichten finden Sie unter Verwenden von Apache Spark mit Azure Event Hubs für Apache Kafka.

Für anwendbare Szenarien können Sie Fabric Eventstream auch so evaluieren, dass Streaming-Daten aufgenommen und in einem Notebook mit Spark Structured Streaming verarbeitet werden. Weitere Informationen finden Sie unter Query eventstream in Microsoft Fabric from a notebook with Spark Structured Streaming.

Für jede strukturierte Streaming-Workload:

  • Testen Sie, ob die Runtime 2.0-Abfrage von einer Kopie des bestehenden Checkpoints neu gestartet werden kann.
  • Validiere zustandsbehaftete Operationen, Ereigniszeit-Wasserzeichen, Trigger, Quell- und Senkoptionen sowie Ausgabeschemata.
  • Halten Sie die Quelldaten und den ursprünglichen Checkpoint verfügbar, bis die Validierung abgeschlossen ist.
  • Wenn ein Checkpoint nicht kompatibel ist, plane einen kontrollierten Neustart mit einem neuen Checkpoint. Berücksichtigen Sie wiederholte oder übersprungene Eingaben und machen Sie den Sink idempotent, bevor Sie neu starten.

Überprüfen Sie den Leitfaden für die Structured Streaming Migration auf Änderungen der Upstream-Kompatibilität.

Delta Lake-Tabellen

Delta Lake behält die Abwärtskompatibilität für bestehende Tabellen, sodass Runtime 2.0 mit Tabellen arbeiten kann, die von Runtime 1.3 erstellt wurden. Das Aktivieren einer neueren Tabellenfunktion kann jedoch das Reader- oder Writer-Protokoll der Tabelle erhöhen und verhindern, dass ältere Engines oder andere Fabric-Umgebungen die Tabelle verwenden.

Während der anfänglichen Laufzeit-Migration:

  • Aktualisieren Sie keine Tabellenprotokolle und aktivieren Sie keine Funktionen von Delta Lake 4.2.
  • Überprüfen Sie die Features und Protokollversionen neu erstellter Tabellen sowie bestehender Tabellen. Laufzeit 2.0 setzt spark.databricks.delta.properties.defaults.enableDeletionVectors auf true; verifizieren Sie die resultierenden Tabellenmetadaten, anstatt davon auszugehen, dass das Vermeiden manueller Funktionsaktivierung die Kompatibilität bewahrt.
  • Lesevorgänge, Schreiben, Zusammenführungen, Schema-Entwicklung, Wartungsoperationen und gleichzeitiger Zugriff testen.
  • Identifizieren Sie jede Engine, die jede Tabelle liest oder schreibt, einschließlich des SQL-Analytics-Endpunkts, Power BI, Pipelines, Datenflüsse, Eventstreams und externer Engines.
  • Aktivieren Sie eine neue Delta-Funktion erst, nachdem alle Clients sie unterstützen.

Delta Lake 4.2-spezifische Funktionen sind in Fabric experimentell und auf Spark-Umgebungen beschränkt. Informationen zur Supportmatrix und zu den Standardprotokollversionen finden Sie unter Delta Lake Table Format Interoperabilität.

Migrieren Sie Ihre Workloads

Verwenden Sie eine gestaffelte Migration, anstatt die Laufzeit für einen Produktionsarbeitsbereich sofort zu ändern.

1. Inventarisieren Sie Ihre Runtime 1.3-Workloads

Notieren Sie sich folgende Informationen:

  • Notizbücher, Spark-Job-Definitionen, Pipelines, Zeitpläne und abhängige Einträge.
  • Umgebungszuweisungen auf Arbeitsbereichs- und Elementebene.
  • Spark-Konfigurationen, einschließlich aller Legacy-Kompatibilitätseinstellungen.
  • Öffentliche, private und benutzerdefinierte Bibliotheken und deren ermittelte Versionen.
  • Benutzerdefinierte JAR-Dateien, Python wheels, R-Pakete, native Bibliotheken und Initialisierungslogik.
  • Datenquellen, Ziele, Secrets, Verbindungen und Netzwerkanforderungen.
  • Delta-Tabellen und alle Nicht-Spark-Nutzer dieser Tabellen.
  • Streaming-Checkpoints, Schemata, Offsets und Wiederherstellungsanforderungen.
  • Erwartete Ausgabeschemata, Zeilenanzahl, Datenqualitätsprüfungen und Leistungsbaselines.

Priorisieren Sie Workloads, die benutzerdefinierte Bibliotheken, nativen Code, Scala, Streamingzustand oder erweiterte Delta-Funktionen verwenden.

2. Erstelle eine Testumgebung für Laufzeit 2.0

Erstellen Sie ein separates Umgebungselement und wählen Sie 2.0 (Spark 4.1, Delta 4.2) als Laufzeit aus. Füge die erforderlichen Bibliotheken hinzu, speichere die Umgebung und veröffentliche es. Ordnen Sie die Umgebung Kopien repräsentativer Notebooks und Spark-Job-Definitionen in einem Entwicklungs- oder Testarbeitsbereich zu.

Wenn dein Produktionsarbeitsbereich weiterhin Runtime 1.3 verwendet, ändere seine Runtime nicht, bis das Testen abgeschlossen ist. Halte die vorhandene Konfiguration während der Validierung für Rollback verfügbar.

Um kommende Runtime 2.0-Updates zu validieren, bevor sie den Standardkanal erreichen, verwenden Sie den Early-Access-Release-Kanal in Ihrer Testumgebung. Weitere Informationen finden Sie unter Fabric Runtime Release Channels.

3. Aktualisierung von Bibliotheken und Code

Wenden Sie die in der Kompatibilitätsprüfung identifizierten Änderungen an:

  1. Ersetzen Sie fehlende eingebaute Pakete durch explizite Umgebungsabhängigkeiten.
  2. Aktualisieren oder ersetzen Sie Pakete, die Python 3.13, Java 21, Scala 2.13 oder Azure Linux 3.0 nicht unterstützen.
  3. Benutzerdefinierte JAR-Dateien und native Binärdateien neu erstellen.
  4. Das Update hat die PySpark- und pandas-API bei Spark-Aufrufen entfernt.
  5. Ersetze EventHubConnector durch den Kafka-Connector.
  6. Entferne Spark-Einstellungen für Konfigurationen, die in Runtime 2.0 nicht verfügbar sind, und überprüfe explizite Überschreibungen von Konfigurationen, deren Standardwerte geändert wurden.
  7. Lösen Sie die Verhaltensunterschiede in Spark SQL im Code, anstatt sich dauerhaft auf Legacy-Einstellungen zu verlassen.
  8. Lassen Sie bestehende Funktionen und Protokolle der Delta table in dieser Phase unverändert.

4. Führen Sie Kompatibilitäts- und Regressionstests durch

Führe dieselben repräsentativen Eingaben in Runtime 1.3 und Runtime 2.0 aus. Vergleichen:

  • Abschlussstatus, Protokolle, Warnungen und Wiederholungsversuche.
  • Schemata und Datentypen.
  • Ergebnisse auf Reihenebene und aggregierte Ergebnisse.
  • Geschichte und Protokoll der Delta-Tabelle.
  • Streaming-Fortschritt, Zustand, Latenz und Duplikatbehandlung.
  • Ausführungszeit, Ressourcenverbrauch und Kosten.
  • Nachgelagerte Ergebnisse im SQL-Analyseendpunkt, in Power BI, Pipelines und anderen Konsumenten.

Schließen Sie Fehlschlags- und Wiederherstellungstests ein, nicht nur erfolgreiche Durchläufe. Testsitzungs-Neustarts, Job-Wiederholungen, Checkpoint-Wiederherstellung und gleichzeitige Tabellenzugriffe.

5. Rollen Sie Runtime 2.0 aus

Workloads in kontrollierten Chargen verschieben:

  1. Veröffentlichen Sie die validierte Runtime 2.0-Umgebung.
  2. Hänge es an eine kleine Anzahl von Produktions-Notebooks oder Spark-Job-Definitionen an.
  3. Führe den Batch aus und überwache Ausgaben sowie nachgelagerte Systeme.
  4. Machen Sie nach der Beobachtungszeit mit den restlichen Workloads weiter.
  5. Setze Runtime 2.0 erst nach Abschluss der Migrierung auf Item-Ebene als Standard für den Arbeitsbereich.

Die Änderung der Workspace-Laufzeit wirkt sich auf neue Spark-Sitzungen aus. Bestehende Sitzungen nutzen weiterhin ihre aktuelle Laufzeitumgebung, bis sie enden.

6. Halte einen Rollback-Pfad

Behalte die Runtime 1.3-Umgebung, Artefakte, Bibliotheksspezifikationen und Streaming-Checkpoints bis zum Ende der Runtime 2.0-Beobachtungsperiode. Um zurückzurollen, hängen Sie die Runtime 1.3-Umgebung wieder an oder stellen Sie die vorherige Workspace-Laufzeit wieder her und starten Sie eine neue Spark-Sitzung.

Important

Ein Delta-Protokoll-Upgrade ist in der Regel nicht reversibel. Aktivieren Sie keine Tabellenfunktionen, die die Protokollversion anheben, bis Sie die Runtime 2.0-Validierung abgeschlossen und die Kompatibilität mit jedem Tabellenkonsumenten bestätigt haben.

Migrationscheckliste

Bevor Sie die Migration abschließen, bestätigen Sie, dass:

  • [ ] Jedes erforderliche Python- und R-Paket ist explizit verfügbar und kompatibel mit Python 3.13 oder R 4.5.
  • [ ] Benutzerdefinierte JAR-Dateien zielen auf Java 21, Scala 2.13 und Spark 4.1 ab.
  • [ ] Native Abhängigkeiten funktionieren unter Azure Linux 3.0.
  • [ ] Arbeitsbereich, Umgebung, Notizbuch und Spark-Job-Definitionseinstellungen verwenden keine entfernten Spark-Konfigurationen.
  • [ ] Workloads werden anhand der geänderten Runtime 2.0 Spark-Standardkonfigurationen getestet.
  • [ ] Spark SQL- und PySpark-Regressionstests bestehen.
  • [ ] Event-Hubs-Workloads verwenden den Kafka-Connector.
  • [ ] Strukturierte Streaming-Workloads neu starten und erholen sich wie vorgesehen.
  • [ ] Delta-Tabellenprotokolle und -Funktionen bleiben mit allen Clients kompatibel.
  • [ ] Datenqualität, Leistung und Kostenergebnisse erfüllen Ihre Akzeptanzkriterien.
  • [ ] Produktionsrollout-, Monitoring- und Rollback-Verfahren werden dokumentiert und getestet.

Verwandte Inhalte

  • Zuletzt aktualisiert um