Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit une vue d’ensemble de la syntaxe et du comportement hérités pour le schéma virtuel LIVE.
Le LIVE schéma virtuel est une fonctionnalité héritée de Lakeflow Spark Declarative Pipelines et est considéré comme déconseillé. Vous pouvez toujours utiliser le mode de publication hérité et le schéma virtuel LIVE pour les pipelines créés avec ce mode.
Databricks recommande de migrer tous les pipelines vers le nouveau mode de publication. Vous avez deux choix pour la migration :
- Déplacez des tables (y compris des vues matérialisées et des tables de streaming) d’un pipeline hérité vers un pipeline qui utilise le mode de publication par défaut. Pour savoir comment déplacer des tables entre des pipelines, consultez Déplacer des tables entre des pipelines.
- Activez le mode de publication par défaut dans un pipeline qui utilise actuellement le mode de publication hérité. Consultez Activer le mode de publication par défaut dans un pipeline.
Ces deux méthodes sont des migrations unidirectionnelles. Vous ne pouvez pas migrer les tables de retour vers le mode hérité.
La prise en charge du schéma virtuel hérité LIVE et du mode de publication hérité sera supprimée dans une prochaine version d’Azure Databricks.
Note
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. Vous pouvez également confirmer qu’un pipeline utilise le mode de publication hérité si le target champ est défini dans la spécification JSON du pipeline.
Vous ne pouvez pas utiliser l’interface utilisateur de configuration du pipeline pour créer de nouveaux pipelines avec le mode de publication hérité. Si vous devez déployer de nouveaux pipelines à l’aide de l'ancienne syntaxe de LIVE, contactez le représentant de votre compte Databricks.
Qu’est-ce que le schéma virtuel LIVE ?
Note
Le LIVE schéma virtuel n’est plus nécessaire pour analyser la dépendance des ensembles de données dans le mode de publication par défaut des pipelines déclaratifs de Lakeflow Spark.
Le LIVE schéma est un concept de programmation dans les pipelines déclaratifs Spark Lakeflow qui définit une limite virtuelle pour tous les jeux de données créés ou mis à jour dans un pipeline. Par conception, le schéma LIVE n’est pas lié directement aux jeux de données d’un schéma publié. Au lieu de cela, le schéma LIVE permet à une logique dans un pipeline d’être planifiée et exécutée même si un utilisateur ne souhaite pas publier de jeux de données dans un schéma.
Dans les pipelines en mode de publication hérité, vous pouvez utiliser le mot clé LIVE pour référencer d’autres jeux de données dans le pipeline actuel pour les lectures, par exemple SELECT * FROM LIVE.bronze_table. Dans le mode de publication par défaut pour les nouveaux pipelines déclaratifs Spark Lakeflow, cette syntaxe est silencieusement ignorée, ce qui signifie que les identificateurs non qualifiés utilisent le schéma actuel. Voir Définir le catalogue cible et le schéma.
Mode de publication hérité pour les pipelines
Le LIVE schéma virtuel est utilisé avec l'ancien mode de publication pour les pipelines déclaratifs Spark Lakeflow. Toutes les tables créées avant le 5 février 2025 utilisent le mode de publication hérité par défaut.
Le tableau suivant décrit le comportement de toutes les vues matérialisées et tables de streaming créées ou mises à jour dans un pipeline en mode de publication hérité :
| Option de stockage | Emplacement de stockage ou catalogue | Schéma cible | Comportement |
|---|---|---|---|
| Hive metastore | Aucun spécifié | Aucun spécifié | Les métadonnées et les données du jeu de données sont stockées à la racine DBFS. Aucun objet de base de données n’est inscrit dans le metastore Hive. |
| Hive metastore | URI ou chemin de fichier d'accès vers le stockage d'objets cloud. | Aucun spécifié | Les métadonnées et données du jeu de données sont stockées à l’emplacement de stockage spécifié. Aucun objet de base de données n’est inscrit dans le metastore Hive. |
| Hive metastore | Aucun spécifié | Schéma existant ou nouveau dans le metastore Hive. | Les métadonnées et les données du jeu de données sont stockées à la racine DBFS. Toutes les vues matérialisées et tables de streaming du pipeline sont publiées dans le schéma spécifié du metastore Hive. |
| Hive metastore | URI ou chemin de fichier d'accès vers le stockage d'objets cloud. | Schéma existant ou nouveau dans le metastore Hive. | Les métadonnées et données du jeu de données sont stockées à l’emplacement de stockage spécifié. Toutes les vues matérialisées et tables de streaming du pipeline sont publiées dans le schéma spécifié du metastore Hive. |
| Unity Catalog | Catalogue Unity Catalog existant. | Aucun spécifié | Les métadonnées et données du jeu de données sont stockées dans l’emplacement de stockage par défaut associé au catalogue cible. Aucun objet de base de données n’est inscrit dans le catalogue Unity. |
| Unity Catalog | Catalogue Unity Catalog existant. | Schéma existant ou nouveau dans le catalogue Unity. | Les métadonnées et données du jeu de données sont stockées dans l’emplacement de stockage par défaut associé au schéma ou au catalogue cible. Toutes les vues matérialisées et les tables de streaming du pipeline sont publiées dans le schéma spécifié dans le catalogue Unity. |
Mettre à jour le code source à partir du schéma LIVE
Les pipelines configurés pour s’exécuter avec le nouveau mode de publication par défaut ignorent silencieusement la syntaxe de schéma LIVE. Par défaut, toutes les lectures de table utilisent le catalogue et le schéma spécifiés dans la configuration du pipeline.
Pour la plupart des pipelines existants, ce changement de comportement n’a aucun impact, car le comportement de schéma virtuel hérité LIVE dirige également les lectures vers le catalogue et le schéma spécifiés dans la configuration du pipeline.
Important
Le code hérité avec des lectures qui tirent parti du catalogue et du schéma par défaut de l’espace de travail nécessitent des mises à jour de code. Considérez la définition de vue matérialisée suivante :
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data
En mode de publication hérité, une lecture non qualifiée à partir de la table raw_data utilise le catalogue et le schéma par défaut de l’espace de travail, par exemple, main.default.raw_data. Dans le nouveau mode de pipeline par défaut, le catalogue et le schéma utilisés par défaut sont ceux configurés dans la configuration du pipeline. Pour vous assurer que ce code continue de fonctionner comme prévu, mettez à jour la référence pour utiliser l’identificateur complet de la table, comme dans l’exemple suivant :
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data
Utiliser le journal des événements pour les pipelines en mode de publication hérité Unity Catalog
Important
La TVF event_log est disponible pour les pipelines en mode de publication hérité qui publient des tables dans Unity Catalog. Le comportement par défaut pour les nouveaux pipelines publie le journal des événements dans le catalogue cible et le schéma configurés pour le pipeline. Consultez Vérifiez le journal des événements.
Les tables configurées avec le metastore Hive disposent également d’une prise en charge et d’un comportement différents du journal des événements. Consultez Utiliser le journal des événements pour les pipelines de metastore Hive.
Si votre pipeline publie des tables dans Unity Catalog avec le mode de publication hérité, vous devez utiliser la event_log (TVF) pour extraire le journal des événements du pipeline. Vous récupérez le journal des événements d’un pipeline en passant l’ID de pipeline ou un nom de table à la fonction table (TVF). Par exemple, pour récupérer les enregistrements du journal des événements pour le pipeline avec l’ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b :
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
Pour récupérer les enregistrements du journal des événements pour le pipeline qui a créé ou possède la table my_catalog.my_schema.table1 :
SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))
Pour appeler la TVF, vous devez utiliser un cluster partagé ou un entrepôt SQL. Par exemple, vous pouvez utiliser l’éditeur SQL connecté à un entrepôt SQL.
Pour simplifier les requêtes sur les événements d’un pipeline, le propriétaire du pipeline peut créer une vue sur la TVF event_log. L’exemple suivant crée une vue sur le journal des événements d’un pipeline. Cette vue est utilisée dans les exemples de requêtes de journal des événements compris dans cet article.
Note
- La
event_logfonction TVF ne peut être appelée que par le propriétaire du pipeline. - Vous ne pouvez pas utiliser la
event_logfonction de valeur de table dans un pipeline ou dans une requête pour accéder aux journaux d’événements de plusieurs pipelines. - Vous ne pouvez pas partager une vue créée sur la fonction table
event_logavec d’autres utilisateurs.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Remplacez <pipeline-ID> par l’identificateur unique du pipeline. Vous trouverez l’ID dans le panneau Détails du pipeline de l’interface utilisateur des pipelines déclaratifs Lakeflow Spark.
Chaque instance d’une exécution de pipeline est appelée mise à jour. Vous souhaitez souvent extraire des informations pour la mise à jour la plus récente. Exécutez la requête suivante pour rechercher l’identificateur de la dernière mise à jour et l’enregistrer dans la vue temporaire latest_update_id. Cette vue est utilisée dans les exemples de requêtes de journal des événements compris dans cet article :
CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;