Activer le mode de publication par défaut dans un pipeline

Cet article explique comment migrer des pipelines qui utilisent le LIVE schéma virtuel (mode de publication hérité) vers le mode de publication par défaut.

Le mode de publication par défaut permet à un seul pipeline d’écrire dans plusieurs catalogues et schémas, et inclut une syntaxe simplifiée pour l’utilisation de tables et de vues dans le pipeline. Le mode de publication hérité est considéré comme déconseillé et Databricks recommande de migrer tous les pipelines vers le mode de publication par défaut.

La migration affecte les métadonnées du pipeline, mais ne lit pas, ne déplace pas et n’écrit pas sur des jeux de données.

Comment savoir si votre pipeline utilise le mode de publication hérité

Les pipelines en mode publication hérité sont indiqués dans le champ Résumé de l’interface utilisateur des paramètres de pipelines déclaratifs de Lakeflow Spark.

Considérations relatives à la migration vers le mode de publication par défaut

Les notes suivantes sont utiles pour garder à l’esprit pendant la migration :

• Une fois qu’un pipeline est migré vers le mode de publication par défaut, il ne peut pas être migré vers l’utilisation du LIVE schéma virtuel.
• Vous devrez peut-être préparer votre pipeline pour la migration en traitant les modifications de syntaxe entre les modes de publication hérités et par défaut. La plupart des pipelines ne nécessitent pas de modifications. Pour plus d’informations, consultez Préparation des pipelines pour la migration.
• La migration affecte uniquement les métadonnées. Il ne lit, ne déplace pas ou n’écrit dans aucun jeu de données.
• Dans le mode de publication par défaut, les vues matérialisées et les tables de diffusion en continu ne peuvent pas être déplacées entre les schémas après leur création.
• Le mode de publication par défaut nécessite databricks CLI version v0.230.0 ou ultérieure. Consultez Installer ou mettre à jour l’interface CLI Databricks.

Migrer vers le mode de publication par défaut

Procédez comme suit pour migrer vers le mode de publication par défaut.

1. Cliquez sur Travaux & Pipelines à partir de la barre latérale gauche de votre espace de travail.

2. Cliquez sur le nom du pipeline à migrer dans la liste.

3. Suspendez les mises à jour et laissez s’arrêter tout pipeline en cours d’exécution s’arrêter.

   Au moins une mise à jour doit être exécutée au cours des 60 derniers jours avant la fin de la migration. Si le pipeline est déclenché ou a déjà été suspendu, exécutez manuellement une seule mise à jour. Si le pipeline est continu, assurez-vous qu'il parvienne (ou soit déjà) à l’état RUNNING, puis suspendez.

4. Si vous le souhaitez, préparez tout code pouvant avoir besoin d’être migré.

   Le mode de publication par défaut est généralement rétrocompatible avec le mode de publication hérité, mais veillez à préparer correctement votre pipeline pour la migration afin que votre code de pipeline s’exécute correctement lors de la mise à niveau. La plupart des pipelines n’ont pas besoin de modifications.

5. Ajoutez une configuration dans les paramètres du pipeline : pipelines.enableDPMForExistingPipeline, défini sur true.

6. Démarrez une mise à jour manuelle et laissez la mise à jour terminée.

7. Si vous le souhaitez, dans les paramètres du pipeline, supprimez la configuration du pipeline pour pipelines.enableDPMForExistingPipeline. Ce paramètre est utilisé pour la migration et n’est pas nécessaire une fois la migration terminée.

8. Si nécessaire, mettez à jour la planification et activez les mises à jour du pipeline.

Le mode de publication par défaut est désormais activé sur le pipeline. Si vous rencontrez des problèmes, utilisez la section suivante pour vous aider à résoudre les problèmes. Si des problèmes persistent, contactez votre responsable de compte Databricks.

Préparation des pipelines pour la migration

Le mode de publication par défaut est généralement rétrocompatible avec le mode de publication hérité, mais certains pipelines pourraient devoir être modifiés pour pouvoir s'exécuter. Les notes suivantes peuvent vous aider à préparer vos pipelines pour la migration.

Mot clé LIVE

Le mot clé LIVE dans le mode de publication hérité définit le catalogue et le schéma de l’objet avec les valeurs par défaut du pipeline. Le mode de publication par défaut n’utilise plus le LIVE mot clé pour qualifier les tables ou les vues. Le LIVE mot clé est ignoré et remplacé par le catalogue et le schéma par défaut du pipeline. En règle générale, cela utilise le même catalogue et schéma par défaut que le mot-clé LIVE en mode de publication hérité, à moins que vous n'ajoutiez ultérieurement des commandes USE CATALOG ou USE SCHEMA à votre pipeline.

Dans le mode de publication hérité, les références de table et d’affichage partiellement qualifiées sans le LIVE mot clé (par exemple table1) utilisent les valeurs par défaut Spark. En mode de publication par défaut, les références partiellement qualifiées utilisent les valeurs par défaut du pipeline. Si vos valeurs par défaut spark et vos pipelines sont différentes, vous devez qualifier entièrement le nom d’une table ou d’une vue partiellement qualifiée avant la migration.

Références de colonne avec le LIVE mot clé

Vous ne pouvez pas utiliser le LIVE mot clé pour définir des colonnes en mode de publication par défaut. Par exemple, ce code :

CREATE OR REPLACE MATERIALIZED VIEW target AS SELECT LIVE.source.id FROM LIVE.source;

doit être remplacé par ce qui suit avant la migration :

CREATE OR REPLACE MATERIALIZED VIEW target AS SELECT source.id FROM LIVE.source;

Cette version fonctionne dans l'un ou l'autre mode de publication.

Modifications apportées à l’événement flow_progress

La migration de votre pipeline modifie le nom du jeu de données pour l’événement flow_progress dans le journal des événements. Si vous avez des requêtes sur le journal des événements pour ce pipeline, vous devrez peut-être mettre à jour votre requête.

Dans le mode de publication ancien, le nom du jeu de données est le nom table. En mode de publication par défaut, le nom de l'ensemble de données est le nom entièrement qualifié catalog.schema.table.

Pour plus d’informations sur l’utilisation du journal des événements, consultez le journal des événements de pipeline.

Avertissements et erreurs

Certains avertissements dans le mode de publication hérité ont été remplacés par des erreurs dans le mode de publication par défaut.

Auto-références Une auto-référence (ou référence circulaire) n’est pas autorisée dans le mode de publication par défaut (et avait des résultats indéfinis dans le mode de publication hérité). Par exemple:

CREATE OR REPLACE MATERIALIZED VIEW table1 AS SELECT * FROM target_catalog.target_schema.table1;

générerait un avertissement dans le mode de publication hérité (et aurait des résultats non définis). En mode de publication par défaut, il génère une erreur.

Noms à plusieurs parties Vous ne pouvez pas utiliser de points dans les noms en mode de publication par défaut (noms à plusieurs parties). Par exemple, le code Python suivant est valide en mode hérité, mais pas en mode par défaut :

@dlt.view(name=”a.b.c”)
def transform():
  return …

Avant de migrer, renommez la table en un nom qui n’inclut pas de caractère de point.

Résolution des problèmes

Le tableau suivant décrit les erreurs qui peuvent se produire lors de la migration à partir du mode de publication hérité.