Schéma LIVE (hérité)
Le schéma virtuel LIVE est une fonctionnalité de pipeline dépréciée utilisée par le mode de publication hérité pour référencer des datasets au sein d’un pipeline.
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 les tables (y compris les vues matérialisées et les tables de streaming) d'un pipeline hérité vers un pipeline qui utilise le mode de publication default. Pour savoir comment déplacer des tables entre les pipelines, consultez Déplacer des tables entre les pipelines.
- Activez le mode de publication default dans un pipeline qui utilise actuellement le mode de publication hérité. Voir Activer le mode de publication default dans un pipeline.
Ces deux méthodes sont des migrations unidirectionnelles. Vous ne pouvez pas migrer les tables vers le mode hérité.
La prise en charge du schéma virtuel LIVE hérité et du mode de publication hérité devrait être supprimée dans une future version de Databricks.
Les pipelines en mode de publication hérité sont indiqués dans le champ **Récapitulatif** de l'interface utilisateur des paramètres du pipeline.
Vous ne pouvez pas utiliser l'interface utilisateur de configuration de 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 la syntaxe héritée LIVE, veuillez contacter votre représentant Databricks.
Qu'est-ce que le schéma virtuel LIVE ?
Le schéma virtuel LIVE n'est plus nécessaire pour analyser la dépendance des datasets dans le mode de publication par default pour les pipelines.
Le schéma LIVE est un concept de programmation dans les pipelines qui définit une limite virtuelle pour tous les datasets créés ou mis à jour dans un pipeline. Par conception, le schéma LIVE n'est pas lié directement aux datasets dans un schéma publié. Le schéma LIVE permet plutôt de planifier et d'exécuter la logique d'un pipeline, même si un utilisateur ne souhaite pas publier de datasets vers 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 datasets dans le pipeline actuel pour les lectures, par exemple, SELECT * FROM LIVE.bronze_table. Dans le mode de publication default pour les nouveaux pipelines, cette syntaxe est ignorée en silence, ce qui signifie que les identificateurs non qualifiés utilisent le schéma actuel. Voir Définir le catalogue et le schéma cibles.
Mode de publication hérité pour les pipelines
Le schéma virtuel LIVE est utilisé avec le mode de publication hérité pour les pipelines. Toutes les tables créées avant le 5 février 2025 utilisent le mode de publication hérité default.
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 dataset sont stockées dans la racine DBFS. Aucun objet de base de données n'est enregistré dans le Hive metastore. |
Hive metastore | Un URI ou un chemin de fichier vers le stockage d'objets cloud. | Aucun spécifié | Les métadonnées et les données du dataset sont stockées à l'emplacement de stockage spécifié. Aucun objet de base de données n'est enregistré dans le Hive metastore. |
Hive metastore | Aucun spécifié | Un schéma existant ou nouveau dans le Hive metastore. | Les métadonnées et les données du dataset sont stockées dans la racine DBFS. Toutes les vues matérialisées et les tables de streaming du pipeline sont publiées dans le schéma spécifié dans le Hive metastore. |
Hive metastore | Un URI ou un chemin de fichier vers le stockage d'objets cloud. | Un schéma existant ou nouveau dans le Hive metastore. | Les métadonnées et les données du dataset sont stockées à l'emplacement de stockage spécifié. Toutes les vues matérialisées et les tables de streaming du pipeline sont publiées dans le schéma spécifié dans le Hive metastore. |
Unity Catalog | Un catalogue Unity Catalog existant. | Aucun spécifié | Les métadonnées et les données du dataset sont stockées dans l'emplacement de stockage default associé au catalogue cible. Aucun objet de base de données n'est enregistré dans Unity Catalog. |
Unity Catalog | Un catalogue Unity Catalog existant. | Un schéma existant ou nouveau dans Unity Catalog. | Les métadonnées et les données du dataset sont stockées dans l'emplacement de stockage default associé au schéma ou au catalogue cible. Toutes les vues matérialisées et tables de streaming dans le pipeline sont publiées dans le schéma spécifié dans Unity Catalog. |
Mettre à jour le code source depuis le schéma LIVE
Les pipelines configurés pour s'exécuter avec le nouveau mode de publication default ignorent silencieusement la syntaxe du schéma LIVE. Par default, toutes les lectures de tables utilisent le catalogue et le schéma définis dans la configuration du pipeline.
Pour la plupart des pipelines existants, cette modification de comportement n'a aucun impact, car le comportement du 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.
Le code hérité avec des lectures qui exploitent le catalogue et le schéma par default du Workspace nécessite des mises à jour du 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 de la table raw_data utilise le catalogue et le schéma default de l’espace de travail, par exemple main.default.raw_data. Dans le nouveau mode de pipeline par default, le catalogue et le schéma utilisés par default sont ceux configurés dans la configuration du pipeline. Pour que ce code continue de fonctionner comme prévu, mettez à jour la référence afin d’utiliser l’identifiant entièrement qualifié de la table, comme dans l’exemple suivant :
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data
Utiliser le log des événements pour les pipelines en mode de publication hérité de Unity Catalog
La TVF event_log est disponible pour les pipelines en mode de publication hérité qui publient des tables dans Unity Catalog. Le comportement Default des nouveaux pipelines publie le log d'événements vers le catalogue cible et le schéma configuré pour le pipeline. Consultez Interroger le log des événements.
Les tables configurées avec Hive metastore ont également un support et un comportement de journal d'événements différents. Voir Utiliser le journal d'événements pour les pipelines Hive metastore.
Si votre pipeline publie des tables dans Unity Catalog en mode de publication hérité, vous devez utiliser la event_log fonction à valeurs de table (TVF) pour récupérer le log d'événements du pipeline. Vous récupérez le Log des événements d'un pipeline en transmettant l'ID de pipeline ou un nom de table au TVF. Par exemple, pour récupérer les enregistrements du log d'événements du pipeline avec l'ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b:
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
Pour récupérer les enregistrements des Logs d'é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 SQL warehouse. Par exemple, vous pouvez utiliser l'éditeur SQL connecté à un SQL warehouse.
Pour simplifier l'interrogation des événements d'un pipeline, le propriétaire du pipeline peut créer une vue sur la fonction de valeur de table event_log. L'exemple suivant crée une vue sur le log d'événements pour un pipeline. Cette vue est utilisée dans les exemples de requêtes du log d'événements inclus dans cet article.
- La fonction TVF
event_logpeut être appelée uniquement par le propriétaire du pipeline. - Vous ne pouvez pas utiliser la fonction table à valeurs
event_logdans un pipeline ou une query pour accéder aux logs d'événements de plusieurs pipelines. - Vous ne pouvez pas partager une vue créée sur la fonction à valeur de table
event_logavec d'autres utilisateurs.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Remplacez <pipeline-ID> par l'identifiant unique du pipeline. Vous pouvez trouver l'ID dans le volet Détails du pipeline de l'interface utilisateur du pipeline.
Chaque instance d’exécution de pipeline est appelée une mise à jour . Vous souhaitez souvent extraire des informations pour la mise à jour la plus récente. Exécutez la query suivante pour trouver l’identifiant de la mise à jour la plus récente et enregistrez-la dans la vue temporaire latest_update_id. Cette vue est utilisée dans les exemples de queries de log d’événements inclus 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;