Migracja z Fabric Runtime 1.3 do Runtime 2.0

Fabric Runtime 2.0 to najnowszy powszechnie dostępny (GA) i domyślny system uruchomieniowy dla obciążeń Apache Spark w Microsoft Fabric. Aktualizuje system operacyjny, Java, Scala, Python, R, Apache Spark oraz Delta Lake. Ponieważ wiele z tych aktualizacji obejmuje zmiany między głównymi wersjami, zweryfikuj swoje notatniki, definicje zadań w Spark, biblioteki i potoki danych, zanim przeniesiesz obciążenia produkcyjne z Runtime 1.3.

Ten przewodnik opisuje zmiany, które mogą wpłynąć na migrację, oraz zawiera etapowy proces przenoszenia obciążeń do Runtime 2.0.

Co się zmieniło w Runtime 2.0

Poniższa tabela porównuje główne komponenty w Runtime 1.3 i Runtime 2.0.

Component	Środowisko uruchomieniowe 1.3	Środowisko uruchomieniowe 2.0	Rozważania dotyczące migracji
Etap wydania	Ogłoszono zakończenie wsparcia (EOSA)	ogólna dostępność	Migruj obciążenia produkcyjne do obsługiwanego środowiska uruchomieniowego GA.
Apache Spark	3.5.5	4.1.1	Przejrzyj zmiany zachowania w Spark 4.1 i usunięte interfejsy API.
Jezioro Delta	3.2	4.2	Weryfikuj funkcje tabel i kompatybilność protokołów we wszystkich obciążeniach Fabric, które korzystają z Twoich tabel.
Java	11	21	Przebuduj i testuj biblioteki Java oraz zależności Java Native Interface (JNI).
Scala	2.12.17	2.13.16	Przekompiluj pliki JAR Scala dla Scala 2.13. Artefakty Scala 2.12 i 2.13 nie są kompatybilne binarnie.
Python	3.11	3.13	Upewnij się, że każdy pakiet Python ma wydanie zgodne z Pythonem 3.13 oraz pakiet wheel dla systemu Linux.
R	4.4.1	4.5.2	Przeinstaluj i przetestuj niestandardowe pakiety R. SparkR jest wycofany w Spark 4.1.
System operacyjny	Azure Linux 2.0 (Mariner 2.0)	Azure Linux 3.0 (Mariner 3.0)	Odbuduj natywne biblioteki i niestandardowe pliki binarne dla Azure Linux 3.0.

Runtime 2.0 oferuje także nowe możliwości Apache Spark 4.1, w tym VARIANT typ danych, funkcje SQL zdefiniowane przez użytkownika, zmienne sesyjne, składnię potoków, sortację ciągów znaków, API Python Data Source, funkcje tabelowe zdefiniowane przez użytkownika w Python, zunifikowane profilowanie PySpark oraz nowe API zarządzania stanem i debugowania Structured Streaming. Przegląd można znaleźć w artykule Runtime 2.0 w Fabric.

Przejrzyj zmiany zgodności

Przejrzyj następujące obszary, zanim zmienisz przestrzeń roboczą lub środowisko na Runtime 2.0.

Wbudowane i niestandardowe biblioteki

Runtime 2.0 usuwa kilka preinstalowanych pakietów Python i R, które były dostępne w Runtime 1.3. Zmniejszenie domyślnego zestawu pakietów pozwala utrzymać lekkie środowisko uruchomieniowe i zmniejsza powierzchnię ataku. Pakiet, który był dostępny bez konfiguracji w Runtime 1.3, może wymagać wprost dodania do środowiska Runtime 2.0.

Użyj Library Managera, aby dodać tylko pakiety wymagane przez Twoje obciążenie robocze, a następnie zapisać i opublikować środowisko. Library Manager rozwiązuje wymagane zależności pakietu, więc nie dodawaj każdej zależności z kolejnych spisów osobno. Nie zakładaj, że biblioteka jest dostępna lub że jej wersja pozostaje niezmieniona:

Porównaj spisy pakietów Runtime 1.3 i Runtime 2.0 w repozytorium wydań runtime Fabric.
Dodaj brakujące biblioteki PyPI, Conda, Maven, R lub niestandardowe biblioteki do środowiska i opublikuj je.
Przypnite wersje dla obciążeń produkcyjnych, aby rozwiązywanie zależności było powtarzalne.
Sprawdź, czy pakiety Python obsługują Python 3.13. Pakiety z natywnymi rozszerzeniami muszą zapewniać kompatybilny pakiet wheel dla systemu Linux lub być pomyślnie zbudowane na Azure Linux 3.0.
Zastąp zależności dla Scala 2.12 artefaktami dla Scala 2.13. Nazwy artefaktów zwykle zawierają wersję binarną Scali, np. _2.12 lub _2.13.
Przekompiluj niestandardowe pliki JAR dla Java 21, Scala 2.13 i Spark 4.1. Testuj zależności przechodnie pod kątem konfliktów z bibliotekami dostarczanymi przez środowisko uruchomieniowe.
Odbudowanie niestandardowych natywnych bibliotek dla Azure Linux 3.0.

Fabric migruje specyfikacje bibliotek podczas zmiany środowiska wykonawczego w istniejącym środowisku, ale nie może zagwarantować, że biblioteki te pozostaną kompatybilne z nowym środowiskiem wykonawczym. Publikacja kończy się niepowodzeniem, gdy rozwiązywanie zależności znajdzie konflikt. Aby poznać opcje instalacji pakietów i tryby publikacji, zobacz Zarządzanie bibliotekami w środowiskach Fabric.

Pakiety usunięte z domyślnego środowiska

Poniższe wykazy obejmują pakiety skierowane do użytkownika oraz ich niskopoziomowe lub pośrednie zależności. Przeszukaj te listy w poszukiwaniu pakietów, z których korzysta Twoje obciążenie robocze Runtime 1.3. Jeśli pakiet znajduje się na liście, dodaj wersję zgodną z Python 3.13 lub R 4.5 za pomocą Library Manager w środowisku Runtime 2.0.

Środowisko Python: 348 pakietów Conda

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`

Środowisko Python: 24 pakiety pip

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`

Środowisko R: 67 pakietów Conda

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`

Note

Jeśli ochrona dostępu wychodzącego lub zarządzana sieć wirtualna uniemożliwia dostęp do publicznych repozytoriów, pobierz kompatybilne pliki wheel lub utrzymuj repozytorium lustrzane pakietów. Instrukcje można znaleźć w artykule Zarządzanie bibliotekami z ograniczonym dostępem do sieci w Fabric.

Zmiany konfiguracji Spark

Runtime 2.0 dodaje i usuwa ustawienia Spark oraz zmienia niektóre wartości domyślne. Fabric używa też dla niektórych ustawień innych wartości domyślnych niż Apache Spark.

Przed migracją przejrzyj ustawienia Sparka, które skonfigurowałeś dla swoich przestrzeni roboczych, środowisk, notatników i definicji zadań w Sparku. Usuń ustawienia, które już nie są wspierane, i testuj obciążenia opierające się na zmienionych domyślnych ustawieniach. Używaj domyślnych ustawień środowiska uruchomieniowego, chyba że dokumentacja poleca zmianę ustawienia.

Istotne zmiany wartości domyślnych

Poniższa tabela przedstawia wybrane zmiany bazowe. Nieustawione oznacza, że linia bazowa nie ustawia wyraźnie wartości; nie oznacza to, że cecha jest wyłączona.

Configuration	Wartość uruchomieniowa 1.3	Wartość Runtime 2.0	Rozważania dotyczące migracji
`spark.checkpoint.compress`	`false`	`true`	Pliki punktów kontrolnych są domyślnie skompresowane. Zweryfikuj interoperacyjność punktów kontrolnych i zachowanie pamięci masowej.
`spark.databricks.delta.optimizeWrite.enabled`	`true`	Nie ustawiono	Właściwość nie zostaje usunięta. Zweryfikowaj skuteczne zachowanie zoptymalizowanego zapisu za pomocą ustawień tabeli, sesji i profilu zasobów.
`spark.databricks.delta.optimizeWrite.partitioned.enabled`	`false`	`true`	Zweryfikować przepustowość zapisu i rozmiary plików wyjściowych dla podzielonych tabel Delta.
`spark.hadoop.parquet.block.size`	`1073741824` (1 GiB)	`134217728` (128 MiB)	Moduły zapisujące Parquet celują w mniejsze bloki. Weryfikuj rozmiary plików i wydajność odczytu po stronie downstream.
`spark.microsoft.delta.optimize.fast.enabled`	`false`	`true`	`OPTIMIZE` można pominąć pracę, chyba że spełnione są kryteria liczby plików lub szacowanego rozmiaru zagęszczenia. Zweryfikuj wyniki obsługi.
`spark.microsoft.delta.optimize.fileLevelTarget.enabled`	`false`	`true`	Pliki, które wcześniej osiągnęły co najmniej połowę docelowego rozmiaru kompaktowania, nie są ponownie kompaktowane. Waliduj układ pliku po `OPTIMIZE`.
`spark.microsoft.delta.targetFileSize.adaptive.enabled`	`false`	`true`	Delta oblicza docelowy rozmiar pliku na podstawie rozmiaru tabeli. Zweryfikować uzyskane rozmiary plików i wydajność odczytu.
`spark.speculation.multiplier`	`1.5`	`3`	Zadanie musi przebiegać trzy razy wolniej niż mediana, zanim Spark rozważy je do wykonania spekulacyjnego.
`spark.speculation.quantile`	`0.75`	`0.9`	Spark czeka, aż 90% zadań się zakończy, zanim rozważy spekulatywne wykonanie.
`spark.sql.files.maxPartitionBytes`	`134217728` (128 MiB)	`536870912` (512 MiB)	Skany plików mogą pakować więcej danych na każdą partycję. Zweryfikuj równoległość i wykorzystanie pamięci executora.
`spark.sql.maxSinglePartitionBytes`	`Long.MaxValue`	`128m`	Jedna partycja jest domyślnie ograniczona do 128 MiB. Waliduj zapytania generujące duże pojedyncze partycje.
`spark.sql.orc.compression.codec`	`snappy`	`zstd`	Nowe zapisy ORC domyślnie używają kompresji Zstandard. Zweryfikuj kompatybilność i wydajność z czytnikami downstream.
`spark.sql.sources.v2.bucketing.enabled`	`false`	`true`	Spark domyślnie umożliwia złączenia partycjonowane według sposobu przechowywania danych oraz inne zachowania związane z kubełkowaniem w modelu Data Source V2. Weryfikuj plany zapytań i wyniki.
`spark.sql.sources.v2.bucketing.pushPartValues.enabled`	`false`	`true`	Spark może przekazywać zgodne wartości partycjonowania dla bucketingu Data Source V2. Weryfikuj plany zapytań dla tabel kubełkowanych.

Runtime 2.0 również używa ROCKSDB zamiast LEVELDB dla spark.shuffle.service.db.backend i ustawia spark.shuffle.service.removeShuffle na true. Spark wykorzystuje zewnętrzną usługę external shuffle do usuwania niepotrzebnych bloków shuffle dla zwolnionych executorów.

Równoległe ładowanie migawek Delta, równoległe pomijanie danych oraz ładowanie migawek po stronie sterownika również zmieniają się z false na true. Testuj opóźnienia zapytań i zużycie zasobów sterownika, zwłaszcza dla zapytań uzyskujących dostęp do wielu tabel Delta.

Nadpisania przy uruchamianiu sesji i natywne wykonanie

Wdrożenia funkcji Fabric mogą nadpisać wartości bazowe na początku sesji.

Configuration	Wartość bazowa Runtime 2.0	Wartość Runtime 2.0 session-start w publicznych regionach produkcyjnych	Rozważania dotyczące migracji
`spark.gluten.sql.columnar.costBasedFallback.enabled`	`false`	`true`	Wdrożenie produkcyjne zarejestrowane 16 października 2026 roku umożliwia awaryjne przełączenie do Spark na podstawie kosztów. Sprawdź ponownie plany zapytań i wydajność, w tym obciążenia testowane przed tamtym wdrożeniem.
`spark.sql.parquet.native.writer.complexTypes.enabled`	`false`	`true`	Testuj natywne zapisy do Parquet i dalsze odczyty dla tablic, map i struktur.

Korzystając z natywnego silnika wykonawczego, uwzględnij następujące kontrole w testach regresji:

Zweryfikuj zużycie pamięci przy zwiększeniu domyślnego rozmiaru partii kolumnowej z 4 096 do 10 240.
Porównaj plany shuffle i wydajność przy progu kolumnowego shuffle opartego na sortowaniu obniżonym ze 100 000 do 4 000 partycji.
Porównaj wyniki i wydajność wyrażeń regularnych. Obsługa wyrażeń regularnych regex przez natywny silnik Java zmienia się z wyłączonej na włączoną, a ustawienie, które powoduje awaryjne przełączenie wszystkich wyrażeń regex na Spark, zmienia się z true na false.

Domyślne wartości Apache Spark 4.1 są zachowywane w inny sposób w Fabric

Fabric Runtime 2.0 celowo nadpisuje następujące domyślne ustawienia Apache Spark 4.1. Nie zakładaj, że domyślne ustawienie z upstreamowego Sparka 4.1 obowiązuje w Fabric bez zmian.

Configuration	Domyślny Apache Spark 4.1	Wartość Fabric Runtime 2.0
`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`

Zachowanie Spark SQL i DataFrame

Spark 4.1 wprowadza zmiany zachowania, które mogą zmieniać wyniki zapytań lub powodować niepowodzenie wcześniej zaakceptowanych zapytań. Szczególną uwagę zwróć na zachowanie ANSI SQL, casty, operacje związane z datą i znacznikiem czasu, typy danych, mapowania JDBC oraz przestarzałe konfiguracje SQL.

Wykonaj testy regresyjne, które porównują:

Schematy wyników, w tym typ, precyzja, skala i dopuszczalność wartości NULL.
Liczba wierszy i wyniki łączne.
Zachowanie null, przepełnienia, dzielenia przez zero oraz nieprawidłowego rzutowania.
Data, znacznik czasu, strefa czasowa i wyniki interwałów.
Mapowania typów źródeł i ujść JDBC.
Plany zapytań i wydajność dla krytycznych obciążeń.

Nie używaj starszych ustawień zgodności jako docelowej strategii migracji. Jeśli tymczasowo używasz jednego z nich do izolacji awarii, zaktualizuj dotknięty kod i usuń to ustawienie przed zakończeniem migracji. Pełny zestaw zmian zachowań można znaleźć w przewodniku migracji Spark SQL.

Python i pandas API na Spark

Runtime 2.0 przechodzi z Python 3.11 na Python 3.13 i zawiera zmiany w PySpark wprowadzone w Spark 4.1. Spark 4.1 podnosi także minimalne obsługiwane wersje pandas, NumPy i PyArrow oraz usuwa API, które we wcześniejszych wersjach zostały oznaczone jako przestarzałe.

Typowe aktualizacje API pandas w Spark to:

Zastąp DataFrame.iteritems i Series.iteritems elementem items.
Zastąp DataFrame.append i Series.append elementem ps.concat.
Zastąp usunięte inplace parametry operacji kategorycznych przypisaniami.
Przejrzyj zmienione nazwy parametrów i wartości domyślne, takie jak inclusive i Series.str.replace(regex=...).
Weryfikuj nazwy kolumn wyników, nazwy indeksów, dtypes i kolejność.

Pełną listę znajdziesz w przewodniku migracji PySpark.

Aplikacje Java i Scala

Scala 2.13 nie jest binarnie kompatybilna ze Scalą 2.12. Ponowne użycie JAR Runtime 1.3 w Runtime 2.0 może powodować błędy ładowania klas nawet wtedy, gdy kod źródłowy nie został zmieniony. Zbuduj osobny artefakt Runtime 2.0 i zaktualizuj wszystkie zależności crossbuilt w Scali.

Spark 4.1 zmienia również wewnętrzne referencje API serwletów z javax na jakarta. Przeglądaj niestandardowe listenery, rozszerzenia Spark i biblioteki, które współpracują z mechanizmami wewnętrznymi Sparka. W przypadku innych zmian na poziomie silnika zobacz przewodnik migracji rdzenia Spark.

Obciążenia strumieniowe i konektory

Wycofany element EventHubConnector zawarty w Runtime 1.3 nie jest dostępny w Runtime 2.0. Użyj konektora Apache Spark Kafka z endpointem kompatybilnym z Kafka dla Azure Event Hubs. Aby uzyskać wskazówki dotyczące konfiguracji, zobacz Używanie Apache Spark z usługą Azure Event Hubs dla Apache Kafka.

W odpowiednich scenariuszach możesz także wypróbować usługę Fabric Eventstream, aby pozyskiwać dane strumieniowe i przetworzyć je w notatniku za pomocą Spark Structured Streaming. Więcej informacji można znaleźć w artykule Wykonywanie zapytań dotyczących strumienia zdarzeń w usłudze Microsoft Fabric z poziomu notesu za pomocą technologii Spark Structured Streaming.

Dla każdego obciążenia Structured Streaming:

Sprawdź, czy zapytanie Runtime 2.0 może się zrestartować z kopii istniejącego punktu kontrolnego.
Zweryfikuj operacje stanowe, znaczniki wodne czasu zdarzenia, wyzwalacze, opcje źródła i ujścia oraz schematy wyjściowe.
Przechowuj dane źródłowe i oryginalny punkt kontrolny jako dostępne do czasu zakończenia weryfikacji.
Jeśli punkt kontrolny jest niekompatybilny, zaplanuj kontrolowany restart z nowym punktem kontrolnym. Uwzględnij powtórzone lub pominięte dane wejściowe i upewnij się, że odbiornik jest idempotentny przed ponownym uruchomieniem.

Zapoznaj się z przewodnikiem migracji Structured Streaming, aby poznać zmiany dotyczące zgodności z komponentami nadrzędnymi.

Tabele Delta Lake

Delta Lake utrzymuje kompatybilność wsteczną dla istniejących tabel, dzięki czemu Runtime 2.0 może pracować z tabelami utworzonymi w Runtime 1.3. Jednak włączenie nowszej funkcji tabeli może podnieść protokół odczytu lub zapisu tabeli i zapobiec używaniu tabeli przez starsze silniki lub inne środowiska Fabric.

Podczas początkowej migracji podczas działania:

Nie aktualizuj protokołów tabeli ani nie włączaj funkcji Delta Lake 4.2.
Sprawdź właściwości i wersje protokołów nowo utworzonych tabel oraz istniejących tabel. Runtime 2.0 ustawia spark.databricks.delta.properties.defaults.enableDeletionVectors na true; zweryfikuj wynikowe metadane tabeli, zamiast zakładać, że unikanie ręcznego włączania funkcji zachowuje kompatybilność.
Testy odczytu, zapisu, scalania, ewolucji schematu, operacji konserwacyjnych oraz jednoczesnego dostępu.
Zidentyfikuj każdy silnik, który odczytuje lub zapisuje każdą tabelę, w tym endpoint analityki SQL, Power BI, potoki, przepływy danych, strumienie zdarzeń oraz silniki zewnętrzne.
Włącz nową funkcję Delta dopiero po tym, jak wszyscy konsumenci ją obsługują.

Funkcje specyficzne dla Delta Lake 4.2 są eksperymentalne w Fabric i ograniczone do środowisk Spark. Aby poznać macierz wsparcia i domyślne wersje protokołu, zobacz interoperacyjność formatu tabeli Delta Lake.

Migruj swoje obciążenia

Zamiast natychmiastowej zmiany środowiska uruchomieniowego dla przestrzeni roboczej produkcyjnej, użyj migracji etapowej.

1. Inwentaryzuj obciążenia Runtime 1.3

Zarejestruj następujące informacje:

Notatniki, definicje zadań w Sparku, pipeline, harmonogramy i zależne elementy.
Przydziały środowisk na poziomie przestrzeni roboczej i elementów.
Konfiguracje Spark, w tym wszelkie ustawienia zgodności wstecznej.
Biblioteki publiczne, prywatne i niestandardowe oraz ich ustalone wersje.
Niestandardowe pliki JAR, pakiety wheel dla Pythona, pakiety R, natywne biblioteki i logika inicjalizacji.
Źródła danych, miejsca docelowe, sekrety, połączenia oraz wymagania sieciowe.
Tabele Delta i wszyscy użytkownicy tych tabel niekorzystający ze Sparka.
Punkty kontrolne strumieniowania, schematy, offsety i wymagania dotyczące odzyskiwania po awarii.
Oczekiwane schematy wyjściowe, liczba wierszy, kontrole jakości danych oraz bazowe wskaźniki wydajności.

Priorytetowo traktuj obciążenia wykorzystujące niestandardowe biblioteki, natywny kod, Scalę, stan streamingu lub zaawansowane funkcje Delty.

2. Stworzyć środowisko testowe Runtime 2.0

Stwórz osobny element środowiska i wybierz 2.0 (Spark 4.1, Delta 4.2) jako jego runtime. Dodaj wymagane biblioteki, zapisz środowisko i opublikuj je. Dołącz środowisko do kopii reprezentatywnych notebooków i definicji zadań Spark w przestrzeni roboczej dla deweloperów lub testów.

Jeśli Twój produkcyjny workspace nadal korzysta z Runtime 1.3, nie zmieniaj jego runtime, dopóki testy się nie zakończą. Zachowaj istniejącą konfigurację dostępną na potrzeby wycofania podczas walidacji.

Aby zweryfikować nadchodzące aktualizacje Runtime 2.0 zanim dotrą do domyślnego kanału, użyj kanału wczesnego dostępu w środowisku testowym. Więcej informacji można znaleźć w Fabric runtime release channels.

3. Zaktualizuj biblioteki i kod

Zastosuj zmiany wskazane w przeglądzie kompatybilności:

Zastąp brakujące wbudowane pakiety jawnymi zależnościami środowiskowymi.
Aktualizuj lub wymień pakiety, które nie obsługują Python 3.13, Java 21, Scala 2.13 lub Azure Linux 3.0.
Przebuduj niestandardowe pliki JAR i natywne pliki binarne.
Aktualizacja: usunięto API PySpark i pandas w wywołaniach Spark.
Wymień EventHubConnector na konektor Kafka.
Usuń ustawienia Spark dla konfiguracji, które nie są dostępne w Runtime 2.0, i przejrzyj wyraźne nadpisania konfiguracji, których domyślne ustawienia się zmieniły.
Rozwiąż różnice w zachowaniu Spark SQL w kodzie, zamiast polegać na starszych ustawieniach.
Zachowaj istniejące funkcje i protokoły tabel Delta bez zmian w tym etapie.

4. Przeprowadzenie testów zgodności i regresji

Uruchom te same reprezentatywne wejścia na Runtime 1.3 i Runtime 2.0. Porównaj:

Status ukończenia, logi, ostrzeżenia i ponowienia.
Schematy i typy danych.
Wyniki na poziomie wiersza i zagregowane.
Historia i protokół tabeli delta.
Postęp strumieniowania, stan, opóźnienie i obsługa duplikatów.
Czas realizacji, zużycie zasobów i koszty.
Wyniki podrzędne w punkcie końcowym analizy SQL, Power BI, potokach i innych odbiornikach.

Uwzględnij testy awarii i odtwarzania, nie tylko pomyślnych uruchomień. Ponowne uruchamianie sesji testowej, ponowienia zadań, odzyskiwanie punktów kontrolnych oraz współbieżny dostęp do tabeli.

5. Wdróż Runtime 2.0

Przenoś obciążenia w kontrolowanych partiach:

Publikuj zweryfikowane środowisko Runtime 2.0.
Dołącz to do małego zestawu produkcyjnych notatników lub definicji zadań w Sparku.
Uruchom zadanie wsadowe i monitoruj dane wyjściowe oraz systemy korzystające z danych wyjściowych.
Kontynuuj pozostałe obciążenia robocze po okresie obserwacji.
Ustaw Runtime 2.0 jako domyślne dla obszaru roboczego dopiero po zakończeniu migracji na poziomie elementów.

Zmiana środowiska uruchomieniowego obszaru roboczego wpływa na nowe sesje Spark. Istniejące sesje nadal korzystają z bieżącego środowiska uruchomieniowego aż do momentu, gdy się zatrzymają.

6. Zachowaj możliwość wycofania zmian

Zachowaj środowisko Runtime 1.3, artefakty, specyfikacje biblioteki i punkty kontrolne streamingu do końca okresu obserwacji Runtime 2.0. Aby wycofać zmiany, ponownie dołącz środowisko Runtime 1.3 lub przywróć poprzednie środowisko uruchomieniowe obszaru roboczego i rozpocznij nową sesję Spark.

Important

Aktualizacja protokołu Delta na ogół nie jest odwracalna. Nie włączaj funkcji tabeli, które podnoszą protokół, dopóki nie zakończysz walidacji Runtime 2.0 i nie potwierdzisz zgodności z każdym odbiorcą tabeli.

Lista kontrolna migracji

Przed zakończeniem migracji potwierdź, że:

[ ] Każdy wymagany pakiet Python i R jest dostępny i kompatybilny z Python 3.13 lub R 4.5.
[ ] Niestandardowe pliki JAR są przeznaczone dla Java 21, Scala 2.13 i Spark 4.1.
[ ] Natywne zależności działają na Azure Linux 3.0.
[ ] Ustawienia obszaru roboczego, środowiska, notesu i definicji zadań Spark nie używają usuniętych konfiguracji Spark.
[ ] Obciążenia są testowane względem zmienionych domyślnych ustawień konfiguracji Spark Runtime 2.0.
[ ] Testy regresji Spark SQL i PySpark przechodzą.
[ ] Obciążenia Event Hubs korzystają z konektora Kafka.
[ ] Obciążenia Structured Streaming restartują się i wznawiają działanie zgodnie z projektem.
[ ] Protokoły i funkcje tabeli Delta pozostają kompatybilne ze wszystkimi odbiorcami.
[ ] Jakość danych, wydajność i koszty spełniają Twoje kryteria akceptacji.
[ ] Procedury wdrażania, monitorowania i wycofania zmian są dokumentowane i testowane.

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-10-23