Migration de Fabric Runtime 1.3 vers Runtime 2.0

Fabric Runtime 2.0 est la dernière version généralement disponible (GA) et le runtime par défaut pour les charges de travail Apache Spark sous Microsoft Fabric. Il met à jour le système d’exploitation, Java, Scala, Python, R, Apache Spark et Delta Lake. Comme plusieurs de ces mises à jour franchissent les limites des versions majeures, validez vos notebooks, définitions de jobs Spark, bibliothèques et pipelines de données avant de déplacer les charges de travail en production depuis Runtime 1.3.

Ce guide décrit les changements pouvant affecter une migration et fournit un processus par étapes pour transférer vos charges de travail vers le runtime 2.0.

Ce qui a changé dans Runtime 2.0

Le tableau suivant compare les composants principaux de Runtime 1.3 et Runtime 2.0.

Component Runtime 1.3 Runtime 2.0 Considérations migratoires
Phase de mise en production Annonce de la fin du support (EOSA) GA Migrer les charges de travail de production vers l’environnement d’exécution GA pris en charge.
Apache Spark 3.5.5 4.1.1 Examinez les changements de comportement de Spark 4.1 et les API supprimées.
Lac Delta 3.2 4,2 Validez les caractéristiques des tables et la compatibilité des protocoles sur chaque charge de travail Fabric qui utilise vos tables.
Java 11 Vingt-et-un Reconstruire et tester les bibliothèques Java et les dépendances de l’interface native Java (JNI).
Scala 2.12.17 2.13.16 Recompilez les fichiers JAR de Scala pour Scala 2.13. Les artefacts de Scala 2.12 et 2.13 ne sont pas compatibles au niveau binaire.
Python 3.11 3.13 Confirmez que chaque paquet Python propose une version compatible avec Python 3.13 ainsi qu’un wheel Linux.
R 4.4.1 4.5.2 Réinstallez et testez les paquets R personnalisés. SparkR est obsolète dans Spark 4.1.
Système d'exploitation Azure Linux 2.0 (Mariner 2.0) Azure Linux 3.0 (Mariner 3.0) Reconstruis les bibliothèques natives et les binaires personnalisés pour Azure Linux 3.0.

Runtime 2.0 offre également de nouvelles fonctionnalités d’Apache Spark 4.1, incluant le type de données VARIANT, les fonctions SQL définies par l’utilisateur, les variables de session, la syntaxe des pipes, la collation de chaînes, l’API Python Data Source, les fonctions de table définies par l’utilisateur Python, le profilage unifié de PySpark, ainsi que de nouvelles API de gestion d’état et de débogage en streaming structuré. Pour un aperçu, voir Runtime 2.0 dans Fabric.

Examiner les modifications de compatibilité

Examinez les zones suivantes avant de modifier un espace de travail ou un environnement pour utiliser Runtime 2.0.

Bibliothèques intégrées et personnalisées

Runtime 2.0 supprime plusieurs paquets Python et R préinstallés qui étaient disponibles dans Runtime 1.3. Réduire le jeu de paquets par défaut maintient l’environnement d’exécution léger et réduit la surface pour les incidents de sécurité potentiels. Un package disponible sans configuration en Runtime 1.3 pourrait devoir être ajouté explicitement à votre environnement Runtime 2.0.

Utilisez Library Manager pour n’ajouter que les paquets que votre charge de travail exige, puis sauvegardez et publiez l’environnement. Library Manager résout les dépendances requises du paquet, donc n’ajoutez pas chaque dépendance individuellement dans les inventaires suivants. Ne supposez pas qu’une bibliothèque est disponible ou que sa version est restée inchangée :

  • Comparez les inventaires de paquets Runtime 1.3 et Runtime 2.0 dans le dépôt des versions de runtime Fabric.
  • Ajoutez les bibliothèques PyPI, Conda, Maven, R ou personnalisées manquantes dans un environnement et publiez-le.
  • Épinglez les versions pour les charges de travail en production afin de rendre la résolution des dépendances reproductible.
  • Confirmez que les packages Python prennent en charge Python 3.13. Les packages avec extensions natives doivent fournir un wheel Linux compatible ou être construits avec succès sur Azure Linux 3.0.
  • Remplacer les dépendances de Scala 2.12 par des artefacts de Scala 2.13. Les noms d’artefacts incluent couramment la version binaire de Scala, comme _2.12 ou _2.13.
  • Recompiler des fichiers JAR personnalisés pour Java 21, Scala 2.13 et Spark 4.1. Tester les dépendances transitives pour détecter les conflits avec les bibliothèques fournies à l’exécution.
  • Reconstruis des bibliothèques natives personnalisées pour Azure Linux 3.0.

Fabric migre les spécifications des bibliothèques lorsque vous modifiez le runtime d'un environnement existant, mais il ne peut pas garantir que ces bibliothèques restent compatibles. La publication échoue lorsque la résolution de dépendances rencontre un conflit. Pour les options d’installation de paquets et les modes de publication, voir Gérer les bibliothèques dans les environnements Fabric.

Paquets retirés de l’environnement par défaut

Les inventaires suivants incluent les paquets destinés à l’utilisateur et leurs dépendances de bas niveau ou transitives. Recherchez dans ces listes les paquets utilisés par votre charge de travail Runtime 1.3. Si un paquet est listé, ajoutez une version compatible Python 3.13 ou R 4.5 via Library Manager dans votre environnement Runtime 2.0.

Environnement Python : paquets 348 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
Environnement Python : 24 paquets 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
Environnement R : 67 packages 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

Si la protection de l’accès sortant ou un réseau virtuel géré empêche l’accès aux dépôts publics, téléchargez des fichiers wheel compatibles ou hébergez un miroir de paquets. Pour les instructions, voir Gérer les bibliothèques avec un accès réseau limité dans Fabric.

Changements de configuration de Spark

Runtime 2.0 ajoute et supprime les paramètres Spark et modifie certaines valeurs par défaut. Fabric utilise aussi des paramètres par défaut différents d’Apache Spark pour certains réglages.

Avant de migrer, consultez les paramètres Spark que vous avez configurés pour vos espaces de travail, environnements, notebooks et définitions de tâches Spark. Supprimez les paramètres qui ne sont plus pris en charge et testez les charges de travail qui dépendent de paramètres par défaut modifiés. Utilisez les paramètres par défaut à l’exécution, sauf si la documentation vous demande de modifier un réglage.

Changements notables de valeurs par défaut

Le tableau suivant présente certains changements de référence. Pas défini signifie que la baseline ne définit pas explicitement une valeur ; cela ne signifie pas que la fonctionnalité est désactivée.

Configuration Valeur Runtime 1.3 Valeur Runtime 2.0 Considérations migratoires
spark.checkpoint.compress false true Les fichiers checkpoint sont compressés par défaut. Validez l’interopérabilité des checkpoints et le comportement de stockage.
spark.databricks.delta.optimizeWrite.enabled true Non défini La propriété n’est pas retirée. Validez un comportement efficace d’écriture optimisée avec vos paramètres de table, de session et de profil de ressources.
spark.databricks.delta.optimizeWrite.partitioned.enabled false true Validez le débit d’écriture et les tailles des fichiers de sortie pour les tables Delta partitionnées.
spark.hadoop.parquet.block.size 1073741824 (1 GiB) 134217728 (128 MiB) Les writers Parquet ciblent des blocs plus petits. Validez la taille des fichiers et les performances de lecture ultérieures.
spark.microsoft.delta.optimize.fast.enabled false true OPTIMIZE peut ignorer le traitement à moins que des critères de nombre de fichiers ou de taille de compaction estimée ne soient remplis. Validez les résultats de maintenance.
spark.microsoft.delta.optimize.fileLevelTarget.enabled false true Les fichiers qui avaient déjà atteint au moins la moitié de leur taille cible après compactage ne sont pas compactés à nouveau. Validez la structure du fichier après OPTIMIZE.
spark.microsoft.delta.targetFileSize.adaptive.enabled false true Delta calcule la taille cible du fichier en fonction de la taille de la table. Validez les tailles de fichiers et les performances de lecture obtenues.
spark.speculation.multiplier 1.5 3 Une tâche doit être exécutée trois fois plus lentement que la médiane avant que Spark ne la considère pour une exécution spéculative.
spark.speculation.quantile 0.75 0.9 Spark attend que 90% de tâches soient terminées avant d’envisager une exécution spéculative.
spark.sql.files.maxPartitionBytes 134217728 (128 MiB) 536870912 (512 Mio) Les analyses de fichiers peuvent stocker plus de données dans chaque partition. Validez le parallélisme et l’utilisation de la mémoire de l’exécuteur.
spark.sql.maxSinglePartitionBytes Long.MaxValue 128m Une seule partition est limitée par défaut à 128 Mio. Validez les requêtes qui produisent une seule partition volumineuse.
spark.sql.orc.compression.codec snappy zstd Les nouvelles écritures ORC utilisent par défaut la compression Zstandard. Validez la compatibilité et les performances avec les lecteurs en sortie.
spark.sql.sources.v2.bucketing.enabled false true Spark permet par défaut les jointures partitionnées par le stockage et d’autres comportements de bucketing Data Source V2. Validation des plans de requête et des résultats.
spark.sql.sources.v2.bucketing.pushPartValues.enabled false true Spark peut pousser des valeurs de partition compatibles pour le bucketing Data Source V2. Validez les plans de requête pour les tables compartimentées.

Runtime 2.0 utilise également ROCKSDB au lieu de LEVELDB pour spark.shuffle.service.db.backend et définit spark.shuffle.service.removeShuffle sur true. Spark utilise le service externe de shuffle pour supprimer les blocs de shuffle inutiles pour les executors déalloués.

Le chargement parallèle delta des instantanés, le saut parallèle des données et le chargement des instantanés côté pilote changent également de false à true. Testez la latence des requêtes et l’utilisation des ressources du pilote, en particulier pour les requêtes qui accèdent à plusieurs tables Delta.

Substitutions de démarrage de session et exécution native

Les déploiements de fonctionnalités Fabric peuvent remplacer les valeurs de référence au début d’une session.

Configuration Valeur de référence du runtime 2.0 Valeur de démarrage de session Runtime 2.0 dans les régions de production publiques Considérations migratoires
spark.gluten.sql.columnar.costBasedFallback.enabled false true Le déploiement en production enregistré le 16 octobre 2026 permet un basculement de secours vers Spark en fonction du coût. Revérifiez les plans de requête et les performances, y compris les charges de travail testées avant ce déploiement.
spark.sql.parquet.native.writer.complexTypes.enabled false true Testez les écritures natives Parquet et les lectures en aval pour les tableaux, mappages et structures.

Lorsque vous utilisez le moteur d’exécution natif, incluez les vérifications suivantes dans vos tests de régression :

  • Validez l’utilisation de la mémoire avec la taille par défaut du lot en colonnes passant de 4 096 à 10 240.
  • Comparez les plans de shuffle et les performances avec le seuil de shuffle en colonnes basé sur le tri qui descend de 100 000 à 4 000 partitions.
  • Comparez les résultats et les performances des expressions régulières. La prise en charge des regex Java par le moteur natif passe de désactivée à activée, et le paramètre qui revient à Spark pour toutes les expressions régulières passe de true à false.

Les paramètres par défaut d’Apache Spark 4.1 sont conservés différemment dans Fabric

Fabric Runtime 2.0 remplace intentionnellement les paramètres par défaut suivants d’Apache Spark 4.1. Ne supposez pas qu'un paramètre par défaut de la version amont de Spark 4.1 s'applique inchangé dans Fabric.

Configuration Par défaut Apache Spark 4.1 Valeur de 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

Comportement de Spark SQL et DataFrame

Spark 4.1 introduit des changements de comportement qui peuvent modifier les résultats des requêtes ou provoquer l’échec des requêtes précédemment acceptées. Prêtez une attention particulière au comportement ANSI SQL, aux casts, aux opérations de date et d’horodatage, aux types de données, aux mappages JDBC et aux configurations SQL obsolètes.

Effectuez des tests de régression pour comparer :

  • Schémas de sortie, incluant type, précision, échelle et nullabilité.
  • Nombre de lignes et résultats agrégés
  • Comportement nul, de débordement, de division par zéro et de conversion de type non valide.
  • Date, horodatage, fuseau horaire et résultats d’intervalles.
  • Correspondances de type source et puits JDBC.
  • Plans de requête et performances pour les charges de travail critiques.

N’utilisez pas les paramètres de compatibilité hérités comme stratégie de migration permanente. Si vous en utilisez temporairement un pour isoler une défaillance, mettez à jour le code affecté et supprimez le paramètre avant de terminer la migration. Pour l’ensemble complet des changements de comportement, voir le guide de migration SQL de Spark.

API Python et pandas sur Spark

Runtime 2.0 passe de Python 3.11 à Python 3.13 et inclut les modifications de PySpark introduites dans Spark 4.1. Spark 4.1 augmente également les versions minimales prises en charge de pandas, NumPy et PyArrow et supprime les API qui étaient dépréciées dans les versions précédentes.

Les mises à jour courantes de l’API pandas sur Spark incluent :

  • Remplacez DataFrame.iteritems et Series.iteritems par items.
  • Remplacez DataFrame.append et Series.append par ps.concat.
  • Remplacer les paramètres supprimés inplace dans les opérations catégorielles par des affectations.
  • Révisez les noms de paramètres modifiés et les valeurs par défaut, tels que inclusive et Series.str.replace(regex=...).
  • Validez les noms des colonnes de résultat, les noms d’index, les dtypes et l’ordre.

Pour la liste complète, consultez le guide de migration de PySpark.

Applications en Java et Scala

Scala 2.13 n’est pas compatible en binaire avec Scala 2.12. La réutilisation d’un JAR Runtime 1.3 en Runtime 2.0 peut provoquer des erreurs de chargement de classe même lorsque le code source n’a pas changé. Construisez un artefact Runtime 2.0 séparé et mettez à jour toutes les dépendances Scala cross-built.

Spark 4.1 modifie également ses références internes d’API servlets de javax vers jakarta. Examinez les listeners personnalisés, les extensions Spark et les bibliothèques qui interagissent avec les composants internes de Spark. Pour d’autres changements au niveau du moteur, consultez le guide de migration de Spark Core.

Charges de travail et connecteurs en streaming

L’élément obsolète EventHubConnector inclus dans Runtime 1.3 n’est pas disponible dans Runtime 2.0. Utilisez le connecteur Apache Spark Kafka avec le point d’extrémité compatible Kafka pour Azure Event Hubs. Pour des conseils de configuration, voir Utiliser Apache Spark avec Azure Event Hubs pour Apache Kafka.

Pour les scénarios applicables, vous pouvez également évaluer Fabric eventstream pour ingérer les données en streaming et les traiter dans un notebook avec Spark Structured Streaming. Pour plus d’informations, voir Interroger un eventstream dans Microsoft Fabric à partir d’un notebook avec Spark Structured Streaming.

Pour chaque charge de travail de streaming structuré :

  • Testez si la requête Runtime 2.0 peut redémarrer à partir d’une copie du point de contrôle existant.
  • Valider les opérations avec état, les filigranes en temps d’événement, les déclencheurs, les options de source et de récepteur, ainsi que les schémas de sortie.
  • Gardez les données sources et le point de contrôle original disponibles jusqu’à ce que la validation soit terminée.
  • Si un point de contrôle est incompatible, planifiez un redémarrage contrôlé avec un nouveau point de contrôle. Prenez en compte les entrées rejouées ou sautées, et rendez le sink idempotent avant de recommencer.

Consultez le guide de migration Structured Streaming pour les changements de compatibilité en amont.

Tables Delta Lake

Delta Lake maintient la rétrocompatibilité pour les tables existantes, de sorte que Runtime 2.0 peut fonctionner avec des tables créées par Runtime 1.3. Cependant, activer une nouvelle fonctionnalité de table peut augmenter la version du protocole de lecture ou d’écriture de la table et empêcher les anciens moteurs ou autres expériences Fabric d’utiliser la table.

Lors de la migration initiale à l’exécution :

  • Ne mettez pas à jour les protocoles de table ni n’activez les fonctionnalités Delta Lake 4.2.
  • Inspectez les fonctionnalités et les versions de protocole des nouvelles tables créées ainsi que des tables existantes. Runtime 2.0 fixe spark.databricks.delta.properties.defaults.enableDeletionVectors à true; vérifier les métadonnées de table résultantes au lieu de supposer qu’éviter l’activation manuelle des fonctionnalités préserve la compatibilité.
  • lectures de test, écritures, fusions, évolution de schéma, opérations de maintenance et accès simultané.
  • Identifiez chaque moteur qui lit ou écrit chaque table, y compris le point de terminaison d’analyse SQL, Power BI, les pipelines, les flux de données, les flux d’événements et les moteurs externes.
  • Activez une nouvelle fonctionnalité Delta seulement après que tous les clients l’ont prise en charge.

Les fonctionnalités spécifiques à Delta Lake 4.2 sont expérimentales dans Fabric et limitées aux expériences Spark. Pour la matrice de prise en charge et les versions de protocole par défaut, voir Interopérabilité du format de table Delta Lake.

Migrer vos charges de travail

Utilisez une migration par étapes au lieu de modifier immédiatement le runtime d’un espace de travail de production.

1. Répertoriez vos charges de travail Runtime 1.3

Enregistrez les informations suivantes :

  • Notebooks, définitions de jobs Spark, pipelines, plannings et éléments dépendants.
  • Affectations d’environnement au niveau de l’espace de travail et au niveau des éléments.
  • Configurations de Spark, y compris les paramètres de compatibilité hérités.
  • Bibliothèques publiques, privées et personnalisées ainsi que leurs versions résolues.
  • Fichiers JAR personnalisés, wheels Python, paquets R, bibliothèques natives et logique d’initialisation.
  • Sources de données, destinations, secrets, connexions et besoins réseaux.
  • Les tables Delta et tous les consommateurs non-Spark de ces tables.
  • Checkpoints de streaming, schémas, offsets et exigences de récupération.
  • Schémas de sortie attendus, nombre de lignes, contrôles de qualité des données et références de performance.

Priorisez les charges de travail qui utilisent des bibliothèques personnalisées, du code natif, Scala, l’état de streaming ou des fonctionnalités avancées Delta.

2. Créer un environnement de test Runtime 2.0

Créez un élément d’environnement séparé et sélectionnez 2.0 (Spark 4.1, Delta 4.2) comme runtime. Ajoutez les bibliothèques nécessaires, sauvegardez l’environnement, et publiez-le. Attachez l’environnement à des copies de notebooks représentatifs et des définitions de tâches Spark dans un espace de travail de développement ou de test.

Si votre espace de travail de production utilise toujours Runtime 1.3, ne changez pas son runtime avant la fin des tests. Gardez sa configuration existante disponible pour un retour en arrière pendant la validation.

Pour valider les prochaines mises à jour Runtime 2.0 avant qu’elles n’atteignent le canal par défaut, utilisez le canal de publication en accès anticipé dans votre environnement de test. Pour plus d’informations, voir les canaux de publication du runtime Fabric.

3. Mettre à jour les bibliothèques et le code

Appliquez les changements identifiés dans la revue de compatibilité :

  1. Remplacer les paquets intégrés manquants par des dépendances explicites de l’environnement.
  2. Mettez à jour ou remplacez les paquets qui ne prennent pas en charge Python 3.13, Java 21, Scala 2.13 ou Azure Linux 3.0.
  3. Reconstruis des fichiers JAR personnalisés et des binaires natifs.
  4. La mise à jour a supprimé les appels à PySpark et à l’API pandas sur Spark.
  5. Remplacez-le EventHubConnector par le connecteur Kafka.
  6. Supprimez les paramètres Spark pour les configurations non disponibles dans Runtime 2.0, et examinez les redéfinitions explicites des configurations dont les paramètres par défaut ont changé.
  7. Résoudre les différences de comportement de Spark SQL dans le code au lieu de dépendre de façon permanente des paramètres hérités.
  8. Gardez inchangées les fonctionnalités et protocoles existants de la table Delta pendant cette phase.

4. Exécuter des tests de compatibilité et de régression

Exécutez les mêmes entrées représentatives sur Runtime 1.3 et Runtime 2.0. Comparer:

  • Statut de complétion, journaux, avertissements et nouvelles tentatives.
  • Schémas et types de données.
  • Résultats au niveau des lignes et agrégés.
  • Historique et protocole de la table Delta.
  • Avancement du streaming, état, latence et gestion des doublons.
  • Temps d’exécution, utilisation des ressources et coût.
  • Résultats en aval dans le point de terminaison d’analytique SQL, Power BI, les pipelines et d’autres consommateurs.

Incluez les tests d’échec et de récupération, pas seulement les essais réussis. Redémarrages de sessions de test, relances de tâches, récupération de points de contrôle et accès simultané à la table.

5. Déployez Runtime 2.0

Déplacer les charges de travail en lots contrôlés :

  1. Publiez l’environnement validé Runtime 2.0.
  2. Attachez-le à un petit ensemble de notebooks de production ou de définitions de tâches Spark.
  3. Exécutez le batch et surveillez les résultats ainsi que les consommateurs en aval.
  4. Continuez avec les charges de travail restantes après la période d’observation.
  5. Définissez Runtime 2.0 comme valeur par défaut de l’espace de travail seulement une fois la migration au niveau des éléments terminée.

Changer l’exécution de l’espace de travail affecte les nouvelles sessions Spark. Les sessions existantes continuent d’utiliser leur temps d’exécution actuel jusqu’à ce qu’elles s’arrêtent.

6. Maintenir une possibilité de retour arrière

Conservez l’environnement Runtime 1.3, les artefacts, les spécifications de bibliothèque et les checkpoints de streaming jusqu’à la fin de la période d’observation Runtime 2.0. Pour revenir en arrière, réattachez l’environnement Runtime 1.3 ou restaurez le runtime précédent de l’espace de travail et lancez une nouvelle session Spark.

Important

Une mise à jour du protocole Delta n’est généralement pas réversible. N’activez pas les fonctionnalités de table qui font passer la version du protocole à un niveau supérieur avant d’avoir terminé la validation Runtime 2.0 et confirmé la compatibilité avec chaque consommateur de table.

Liste des éléments à vérifier pour la migration

Avant de terminer la migration, confirmez que :

  • [ ] Tous les paquets Python et R requis sont explicitement disponibles et compatibles avec Python 3.13 ou R 4.5.
  • [ ] Les fichiers JAR personnalisés ciblent Java 21, Scala 2.13 et Spark 4.1.
  • [ ] Les dépendances natives fonctionnent sur Azure Linux 3.0.
  • [ ] Les paramètres de l’espace de travail, de l’environnement, du notebook et de la définition de tâche Spark n’utilisent pas les configurations Spark supprimées.
  • [ ] Les charges de travail sont testées par rapport aux paramètres par défaut modifiés de la configuration Spark Runtime 2.0.
  • [ ] Les tests de régression Spark SQL et PySpark réussissent.
  • [ ] Les charges de travail des Event Hubs utilisent le connecteur Kafka.
  • [ ] Les charges de travail en streaming structuré redémarrent et se récupèrent comme prévu.
  • [ ] Les protocoles et fonctionnalités de table Delta restent compatibles avec tous les consommateurs.
  • [ ] Les résultats de qualité des données, de performance et de coût répondent à vos critères d’acceptation.
  • [ ] Les procédures de déploiement, de surveillance et de retour arrière sont documentées et testées.

Contenu connexe

  • Dernière mise à jour :