Migrer du calcul classique vers le calcul sans serveur

Migrez vos charges de travail du calcul classique vers le calcul serverless. Le calcul serverless gère automatiquement l’approvisionnement, la mise à l’échelle, les mises à niveau du runtime et l’optimisation.

La plupart des charges de travail classiques peuvent migrer avec un minimum ou aucun changement de code. Cette page se concentre sur ces charges de travail. Certaines fonctionnalités, telles que df.cache, ne sont pas encore prises en charge sur serverless, mais ne nécessitent pas de modifications de code une fois disponibles. Certaines charges de travail qui dépendent de notebooks R ou Scala nécessitent un calcul classique et ne pourront pas migrer vers serverless. Pour obtenir la liste complète des limitations actuelles, consultez les limitations de calcul sans serveur.

Migrer avec l’agent de migration

Important

Cette fonctionnalité est en version bêta. Les administrateurs de l’espace de travail peuvent l’activer depuis la page Aperçu en s’inscrivant à l’aperçu de l’Agent de calcul . Consultez Gérer les préversions d’Azure Databricks.

Vous pouvez utiliser un agent de migration pour migrer un seul notebook ou une tâche vers un calcul sans serveur. L’agent examine l’environnement de la charge de travail, les bibliothèques, les configurations Spark, les tags et le code, puis propose chaque modification comme une suggestion individuelle à accepter ou rejeter. Les changements acceptés sont appliqués en place et peuvent être annulés.

Ce que l’agent évalue et modifie

Area Ce que fait l’agent
Environnement et bibliothèques Traduit les installations de bibliothèques en une spécification d’environnement sans serveur, y compris les installations %pip, les scripts d’initialisation du cluster, les bibliothèques de cluster utilisées dans les jobs et les références à un index privé de paquets.
Variables d’environnement Traduit les variables d’environnement du cluster vers leurs équivalents serverless, préservant les références secrètes de l’espace de travail et omettant les valeurs gérées par la plateforme.
Accès aux données et au stockage Réécrit les chemins incompatibles avec Serverless, tels que le disque local, dbfs:/, et les chemins de montage, en volumes Unity Catalog. L’agent applique automatiquement des réécritures non ambiguës et vous demande de choisir un volume lorsque la cible est ambiguë.
Configurations de Spark Classe chaque configuration Spark, commente celles qui peuvent être supprimées sans risque, et signale et supprime les configurations qui ne sont pas prises en charge par le mode serverless. Couvre à la fois les configurations associées au cluster et celles dans le notebook.
Code de charge de travail Réécrit du code que le serverless ne supporte pas en équivalents compatibles, comme les opérations RDD réécrites en opérations DataFrame, et ajuste le code pour le comportement SQL en mode ANSI sur serverless.
Balises Traduit les balises de cluster personnalisées, telles qu’une balise de centre de coûts, vers leurs équivalents sans serveur.
Mode performance Il suggère un mode performance basé sur la configuration du cluster. Voir Choisir un mode de performances.

Exigences

  • L’accès administrateur de l’espace de travail est recommandé pour garantir une migration complète. Cela s’explique par le fait que l’agent inspecte également les scripts d’init globaux au niveau de l’espace de travail au-delà de la charge de travail cible. Vous pourrez peut-être effectuer la migration si vous disposez de l’autorisation CAN MANAGE pour la charge de travail, mais sans autorisations d’administrateur, cela peut entraîner l’absence de bibliothèques, de paramètres d’environnement ou de balises.

  • Confirmez que vous avez accès à l’agent. Tapez /compute dans Genie Code. /compute Devrait apparaître dans le menu d’autocomplétion. Si elle n’apparaît pas, un administrateur de l’espace de travail doit activer l’aperçu dans votre espace de travail.

    Le panneau Genie Code avec /compute saisi, affichant la commande /compute dans le menu de saisie semi-automatique avec la description Migrer des jobs vers le calcul sans serveur

Migrer un bloc-notes

  1. Ouvrez le notebook que vous souhaitez migrer.
  2. Ouvre le code Genie et lance /compute migrate to serverless depuis la / palette de commandes.
  3. Examinez les conclusions de l’agent. L’agent analyse l’environnement, les bibliothèques et le code du carnet, et propose une modification pour chaque élément qui en nécessite une, par exemple en déplaçant l’installation d’une bibliothèque dans une spécification d’environnement ou en réécrivant une cellule de code pour qu’elle s’exécute en mode serverless.
  4. Accepter ou rejeter chaque changement proposé.
  5. Appliquez les modifications que vous avez acceptées. Ils sont écrits directement dans le notebook.
  6. Associez le notebook à Serverless et exécutez-le pour vérifier qu’il se comporte comme prévu. Voir Vérification d’une charge de travail migrée.

Transférer un emploi

  1. Ouvre le poste que tu veux migrer.
  2. Ouvre le code Genie et lance /compute migrate to serverless depuis la / palette de commandes.
  3. L’agent clone votre tâche et tente ensuite de migrer la tâche clonée vers un environnement serverless.
  4. Examinez les conclusions de l’agent. Pour une tâche multitâche, l’agent énumère chaque tâche ainsi que sa configuration de cluster par tâche, et propose des modifications pour chacune tout en préservant le planning du travail.
  5. Accepter ou rejeter chaque modification proposée sur la surface de migration : environnement et bibliothèques, configurations Spark, et tout code de charge de travail devant changer.
  6. Appliquez les modifications que vous avez acceptées. Les ressources de calcul de la tâche passent en mode serverless.
  7. Exécutez la tâche sur une infrastructure serverless et confirmez les résultats. Voir Vérification d’une charge de travail migrée.
  8. Optionnellement, en dernière étape, l’agent promeut le clone migré. Il copie la configuration et les carnets du clone sur votre job original en place (en gardant le même ID de job, le même planning et les permissions), puis supprime le clone. Si vous ignorez la promotion et conservez les deux tâches, mettez en pause la planification de celle que vous n’exécutez pas ; sinon, le même déclencheur activera les deux tâches et pourra entraîner des écritures en double ou d’autres effets secondaires.

Vérifier une charge de travail migrée

L’agent propose et applique des modifications, mais n’exécute pas votre charge de travail et n’en vérifie pas le résultat. Exécutez toujours une charge de travail migrée sur serverless et confirmez les résultats avant de vous y fier, surtout pour les charges qui écrivent dans des tables de production. Si l’agent propose un changement qui semble erroné, rejetez-le et envoyez-nous un retour afin que nous puissions améliorer l’agent. Consultez Envoyer des commentaires sur le produit.

Tip

Pendant que vous validez une charge de travail migrée, exécutez-la en mode optimisé en termes de performance. Il démarre plus vite que le mode standard, donc vous obtenez un retour plus rapide en confirmant les résultats. Passe au mode qui correspond le mieux à la charge de travail avant de le lancer en production. Voir Choisir un mode de performances.

Lorsque l’agent trouve quelque chose qu’il ne peut pas migrer en toute sécurité, il signale un bloqueur et s’arrête par défaut. Vous pouvez explicitement demander de passer outre certains bloqueurs de compatibilité ou de dépendances, mais cela implique d’accepter le risque que ces dépendances, l’attribution des coûts ou le comportement à l’exécution ne soient pas conservés, et que la charge de travail puisse échouer dans un environnement serverless.

Annuler les changements de migration

Les modifications appliquées par l’agent sont réversibles.

Pour un carnet, ouvrez-le et restaurez la révision juste avant la migration. Consultez l’historique des versions dans les notebooks Databricks.

Pour un poste, si vous n’avez pas promu le clone migré, votre job original n’a jamais été modifié : exécutez-le comme avant et supprimez le clone. Si vous avez promu le clone, restaurez à partir de la sauvegarde que l’agent a créée avant d’apporter la moindre modification :

  1. Ouvrez le dossier de sauvegarde dans votre espace de travail principal : /Workspace/Users/<your-username>/serverless-migration/backups/job-<job-id>/<timestamp>/. L’agent a montré ce chemin pendant la migration. S’il y a plusieurs horodatages, choisissez celui juste avant la migration.
  2. Ouvrez job.yaml, qui contient les paramètres de votre tâche avant la migration, puis réappliquez ces paramètres à la même tâche au moyen d’une requête POST /api/2.2/jobs/reset, qui remplace les paramètres de la tâche par ceux que vous fournissez. Vous pouvez aussi les coller dans la définition JSON du poste dans l’interface utilisateur. Cela ramène la tâche au calcul classique.
  3. Ouvre mapping.yaml, qui liste chaque fichier sauvegardé et le chemin d’origine d’où il provienne. Copiez chaque fichier de sauvegarde sur son chemin d’origine pour annuler les réécritures de code.
  4. Exécutez la tâche pour confirmer qu’elle fonctionne comme avant la migration.

La migration ne supprime jamais cette sauvegarde. Les tâches que l’agent n’a pas modifiées, comme les tâches issues de Git, SQL ou dbt, sont enregistrées dans job.yaml, mais leurs fichiers ne sont pas copiés dans la sauvegarde ; restaurez-les donc depuis votre source de référence si nécessaire.

Limitations connues

  • Les éléments suivants sont signalés comme des éléments bloquants : images personnalisées, variantes de ML Runtime, versions de Databricks Runtime antérieures à 13, configurations Spark qui ne peuvent pas être ignorées en toute sécurité dans un environnement serverless, et dépendances telles que les eggs, les fichiers JAR et les bibliothèques Maven. Un blocage signifie que l’agent s’arrête au lieu de migrer cet élément. Vous pouvez soit résoudre vous-même et relancer la migration, soit dire à l’agent de migrer quand même, ce qui laisse cet élément non résolu et peut entraîner l’échec de la charge de travail en serverless.
  • L’agent lit les scripts d’init stockés dans des fichiers workspace ou des volumes du catalogue Unity. Les scripts d’initiation stockés dans ABFSS ou DBFS ne peuvent pas être lus et sont signalés comme des bloqueurs.
  • L’agent n’inspecte pas tous les attributs classiques de calcul. La livraison de logs de cluster et les clés SSH ne sont pas modélisées, et bien qu’il détecte de nombreuses dépendances de montage DBFS à partir du code de charge de travail, il n’énumère ni ne résout chaque montage.
  • Les API de cache et de points de contrôle, les vues temporaires globales, les appels de gestion de montage DBFS, ainsi que le code Scala ou R sont des blocages durs par défaut. Vous pouvez demander à l’agent de continuer, mais la fonctionnalité non résolue reste inchangée et peut échouer en serverless.
  • Les emplois comportant plus de 10 tâches migrables ne peuvent actuellement pas être transférés.
  • L’agent migre une charge de travail à la fois. Il n’existe pas de processus de découverte à l’échelle de la flotte, de migration en masse ou d’approbation administrative.
  • L’agent propose des modifications et applique celles que vous acceptez, mais il n’exécute pas vos tâches et ne vérifie pas l’exactitude du résultat. Vérifiez une charge de travail migrée avant de vous y fier pour les données de production.
  • Si la source de vérité de votre charge de travail est un Databricks Asset Bundle ou un dossier Git, l’agent applique des modifications à l’objet workspace en place. Réconciliez ces modifications avec votre bundle ou dépôt afin qu’un déploiement ultérieur ne remplace pas la migration.

Migrer manuellement vers une architecture serverless

Pour migrer vos charges de travail du calcul classique vers le calcul serverless, procédez comme suit :

  1. Vérifiez les conditions préalables : vérifiez que votre espace de travail, votre réseau et votre accès au stockage cloud répondent aux exigences. Voir Avant de commencer.
  2. Code de mise à jour : apportez les modifications nécessaires au code et à la configuration. Consultez Mettre à jour votre code.
  3. Testez vos charges de travail : vérifiez la compatibilité et l’exactitude avant de passer à la nouvelle configuration. Consultez Tester vos charges de travail.
  4. Choisissez un mode de performance : sélectionnez le mode de performance qui correspond le mieux à vos besoins en charge de travail. Voir Choisir un mode de performances.
  5. Migrer en phases : Déployer serverless de manière incrémentielle, en commençant par de nouvelles charges de travail à faible risque. Consultez Migrer en phases.
  6. Surveiller les coûts : effectuez le suivi de la consommation DBU serverless et configurez des alertes. Consultez Surveiller les coûts.

Avant de commencer

Avant de commencer la migration, vous devrez peut-être mettre à jour certaines configurations héritées dans votre espace de travail.

Conditions préalables Action Détails
L’espace de travail est activé pour le catalogue Unity Migrer à partir du metastore Hive si nécessaire Upgrader un espace de travail Azure Databricks vers le catalogue Unity
Mise en réseau configurée Remplacer le peering VPC par des NCC (Network Connectivity Centers), des Private Links ou des règles de pare-feu Mise en réseau du plan de calcul serverless
Accès au stockage cloud Remplacer les modèles d’accès aux données héritées par les emplacements externes du Catalogue Unity Se connecter au stockage d'objets cloud à l'aide d'Unity Catalog

Vérifiez que votre espace de travail se trouve dans une région prise en charge.

Mettre à jour votre code

Les sections suivantes répertorient les modifications de code et de configuration requises pour rendre vos charges de travail compatibles avec serverless.

Accès aux données

Les modèles d’accès aux données hérités ne sont pas pris en charge sur serverless. Mettez à jour votre code pour utiliser le catalogue Unity à la place.

Modèle classique Remplacement sans serveur Détails
Chemins DBFS (dbfs:/...) Volumes de Catalogue Unity Présentation des volumes Unity Catalog
Tables Hive Metastore Tables du catalogue Unity (ou HMS Federation) Upgrader un espace de travail Azure Databricks vers le catalogue Unity
Informations d’identification du compte de stockage Emplacements externes du catalogue Unity Se connecter au stockage d'objets cloud à l'aide d'Unity Catalog
JARs JDBC personnalisés Fédération de Lakehouse Qu’est-ce que la fédération de requêtes ?

Avertissement

L’accès DBFS est limité sur serverless. Mettez à jour tous les dbfs:/ chemins d’accès aux volumes catalogue Unity avant de migrer. Pour plus d’informations, consultez Migrer des fichiers stockés dans DBFS.

Exemple : Remplacer les chemins DBFS et les références de metastore Hive 
# Classic
df = spark.read.csv("dbfs:/mnt/datalake/data.csv", header=True)
df.write.parquet("dbfs:/mnt/output/results")
df = spark.table("my_database.my_table")

# Serverless
df = spark.read.csv("/Volumes/main/sales/raw_data/data.csv", header=True)
df.write.parquet("/Volumes/main/analytics/output/results")
df = spark.table("main.my_database.my_table")  # three-level namespace

API et code

Certaines API et modèles de code ne sont pas pris en charge sur serverless. Référencez ce tableau pour voir si votre code doit être mis à jour.

Modèle classique Remplacement sans serveur Détails
API RDD (sc.parallelize, rdd.map) API DataFrame Comparer Spark Connect à Spark Classic
df.cache(), df.persist() Supprimer les appels de mise en cache Limitations du calcul sans serveur
spark.sparkContext, sqlContext Utiliser spark (SparkSession) directement Comparer Spark Connect à Spark Classic
Variables Hive (${var}) SQL DECLARE VARIABLE ou Python f-strings DECLARE VARIABLE
Configurations Spark non prises en charge Supprimez les configurations non prises en charge. La configuration serverless ajuste automatiquement la plupart des paramètres. Configurer les propriétés Spark pour les notebooks serverless et les travaux.
Exemple : Remplacer les opérations RDD par des DataFrames 
from pyspark.sql import functions as F

# sc.parallelize + rdd.map
# Classic:  rdd = sc.parallelize([1, 2, 3]); rdd.map(lambda x: x * 2).collect()
df = spark.createDataFrame([(1,), (2,), (3,)], ["value"])
result = df.select((F.col("value") * 2).alias("value")).collect()

# rdd.flatMap
# Classic:  sc.parallelize(["hello world"]).flatMap(lambda l: l.split(" ")).collect()
df = spark.createDataFrame([("hello world",)], ["line"])
words = df.select(F.explode(F.split("line", " ")).alias("word")).collect()

# rdd.groupByKey
# Classic:  rdd.groupByKey().mapValues(list).collect()
df = spark.createDataFrame([("a", 1), ("b", 2), ("a", 3)], ["key", "value"])
grouped = df.groupBy("key").agg(F.collect_list("value").alias("values")).collect()

# rdd.mapPartitions → applyInPandas
import pandas as pd
def process_group(pdf: pd.DataFrame) -> pd.DataFrame:
    return pd.DataFrame({"total": [pdf["id"].sum()]})
result = (spark.range(100).repartition(4)
    .groupBy(F.spark_partition_id())
    .applyInPandas(process_group, schema="total long").collect())

# sc.textFile → spark.read.text
df = spark.read.text("/Volumes/catalog/schema/volume/file.txt")
Exemple : Remplacer SparkContext et la mise en cache 
from pyspark.sql.functions import broadcast

# sc.broadcast → broadcast join
result = main_df.join(broadcast(lookup_df), "key")

# sc.accumulator → DataFrame aggregation
total = df.agg(F.sum("amount")).collect()[0][0]

# sqlContext.sql → spark.sql
result = spark.sql("SELECT * FROM main.db.table")

# df.cache() → remove caching calls
# Materialize expensive intermediate results to Delta as a workaround:
df = spark.read.parquet(path)
result = df.filter("status = 'active'")
expensive_df.write.format("delta").mode("overwrite").saveAsTable("main.scratch.temp")
result = spark.table("main.scratch.temp")

Bibliothèques et environnements

Vous pouvez gérer des bibliothèques et des environnements au niveau de l’espace de travail à l’aide d’environnements de base et au niveau du notebook à l’aide de l’environnement serverless du notebook.

Modèle classique Remplacement sans serveur Détails
Scripts d’initialisation Environnements sans serveur Configuration de l'environnement serverless
Bibliothèques au niveau d'un cluster Bibliothèques spécifiques au notebook ou d’environnement Configuration de l'environnement serverless
Bibliothèques Maven/JAR Prise en charge des tâches JAR pour les travaux ; PyPI pour les notebooks Tâche JAR pour les travaux
Conteneurs Docker Environnements serverless pour les besoins de la bibliothèque Configuration de l'environnement serverless

Épinglez des packages Python dans requirements.txt pour les environnements reproductibles. Consultez Spécifier les versions des packages Python.

Diffusion en continu

Les charges de travail de streaming sont prises en charge sur les infrastructures serverless, mais certains déclencheurs ne le sont pas. Mettez à jour votre code pour utiliser les déclencheurs pris en charge.

Déclencheur Spark Soutenu Remarques
Trigger.AvailableNow() Oui Recommandé
Trigger.Once() Oui Cet élément est obsolète. Utilisez Trigger.AvailableNow() à la place.
Trigger.ProcessingTime(interval) Non Retourne INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED.
Trigger.Continuous(interval) Non Utiliser le mode continu des pipelines Lakeflow à la place
Valeur par défaut (non paramétré .trigger()) Non Omettre .trigger() revient à utiliser ProcessingTime("0 seconds"), ce qui n'est pas pris en charge en mode sans serveur. Toujours défini .trigger(availableNow=True) explicitement.

Pour le streaming en continu, migrez vers les pipelines déclaratifs Spark en mode continu ou utilisez des tâches à horaire continu avec AvailableNow. Pour les sources volumineuses, définissez maxFilesPerTrigger ou maxBytesPerTrigger, pour empêcher les erreurs de mémoire insuffisante.

Exemple : Corriger les déclencheurs de diffusion en continu 
# Classic (not supported on serverless — default trigger is ProcessingTime)
query = df.writeStream.format("delta").outputMode("append").start()

# Serverless (explicit AvailableNow trigger)
query = (df.writeStream.format("delta").outputMode("append")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))
query.awaitTermination()

# With OOM prevention for large sources
query = (spark.readStream.format("delta")
    .option("maxFilesPerTrigger", 100)
    .option("maxBytesPerTrigger", "10g")
    .load(input_path)
    .writeStream.format("delta")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))

Tester vos charges de travail

  1. Test de compatibilité rapide : exécutez la charge de travail sur le calcul classique avec le mode d’accès Standard et Databricks Runtime 14.3 ou version ultérieure. Si l’exécution réussit, la charge de travail peut migrer vers serverless sans aucune modification du code.
  2. Comparaison A/B (recommandée pour la production) : exécutez la même charge de travail sur classique (contrôle) et serverless (expérience). Comparer les tableaux de résultats et vérifier l'exactitude. Itérer jusqu’à ce que les sorties correspondent.
  3. Configurations temporaires : vous pouvez définir temporairement les configurations Spark prises en charge pendant le test. Supprimez-les lorsque les conditions sont stables.

Choisir un mode de performance

Les travaux et pipelines serverless prennent en charge deux modes de performance : standard et optimisé pour les performances. Le mode de performances que vous choisissez dépend des besoins de votre charge de travail.

Mode Disponibilité Jeune entreprise Idéal pour
Norme Travaux, pipelines Lakeflow 4 à 6 minutes Lot sensible aux coûts
Optimisé pour les performances Notebooks, Travaux, Pipelines Lakeflow Secondes Interactive, sensible à la latence

Migrer en phases

  1. Nouvelles charges de travail : démarrez tous les nouveaux blocs-notes et travaux sur serverless.
  2. Charges de travail à faible risque : migrez des charges de travail PySpark/SQL déjà en mode d’accès standard et Databricks Runtime 14.3 ou version ultérieure.
  3. Charges de travail complexes : migrez les charges de travail nécessitant des modifications de code (réécritures RDD, mises à jour DBFS, correctifs de déclencheur).
  4. Charges de travail restantes : passez en revue régulièrement à mesure que les fonctionnalités s’étendent.

Superviser les coûts

La facturation serverless est basée sur la consommation DBU, et non sur le temps d’activité du cluster. Validez les attentes en matière de coûts avec les charges de travail représentatives avant de migrer à grande échelle. Pour connaître les outils et stratégies permettant de surveiller les coûts liés au serverless, voir Surveiller le coût du calcul serverless.

Ressources additionnelles

Vous pouvez également consulter les billets de blog suivants pour plus d’informations :

  • Last updated on