Aller au contenu principal
Dernière mise à jour le

Utiliser Unity Catalog avec des pipelines

Databricks recommande de configurer les Lakeflow pipelines avec Unity Catalog. L'utilisation de Unity Catalog est le default pour les pipelines nouvellement créés.

Les pipelines configurés avec Unity Catalog publient toutes les vues matérialisées définies et les tables de streaming vers le catalogue et le schéma spécifiés. Les pipelines Unity Catalog peuvent lire à partir d’autres tables et volumes Unity Catalog.

Pour gérer les autorisations sur les tables créées par un pipeline Unity Catalog, utilisez GRANT et REVOKE.

remarque

Cet article aborde les fonctionnalités du mode de publication par default actuel pour les pipelines. Les pipelines créés avant le 5 février 2025, pourraient utiliser le mode de publication hérité et le schéma virtuel LIVE. Voir le schéma EN DIRECT (hérité).

Exigences​

Pour créer des tables de streaming et des vues matérialisées dans un schéma cible dans Unity Catalog, vous devez disposer des autorisations suivantes sur le schéma et le catalogue parent :

  • USE CATALOG privilèges sur le catalogue cible.
  • CREATE MATERIALIZED VIEW et USE SCHEMA privilèges sur le schéma cible si votre pipeline crée des vues matérialisées.
  • CREATE TABLE et USE SCHEMA privilèges sur le schéma cible si votre pipeline crée des tables de streaming.
  • Si votre pipeline crée de nouveaux schémas, vous devez disposer des privilèges USE CATALOG et CREATE SCHEMA sur le catalogue cible.

Exigences de compute pour exécuter un pipeline activé pour Unity Catalog :

  • Votre ressource de compute doit être configurée avec le mode d'accès Standard. Le compute dédié n'est pas pris en charge. Voir Modes d'accès.

Le Compute requis pour query les tables créées par des pipelines utilisant Unity Catalog (y compris les tables de streaming et les vues matérialisées) comprend les éléments suivants :

  • SQL Warehouse
  • compute en mode d'accès standard sur Databricks Runtime 13.3 LTS ou version ultérieure.
  • Le compute en mode d'accès dédié, si le contrôle d'accès granulaire est activé sur le compute dédié (c'est-à-dire qu'il s'exécute sur Databricks Runtime 15.4 ou version ultérieure et que le compute Serverless est activé pour le Workspace). Pour de plus amples informations, veuillez consulter le contrôle d'accès précis sur un compute dédié.
  • Compute en mode d'accès dédié sur les versions 13.3 LTS à 15.3, seulement si le propriétaire de la table exécute la query.

Des limitations de compute supplémentaires s’appliquent. Consultez la section suivante.

Limitations​

Voici les limites liées à l'utilisation de Unity Catalog avec les pipelines :

  • Par default, seuls le propriétaire du pipeline et les administrateurs de workspace peuvent consulter les logs du driver du compute qui exécute un pipeline compatible Unity Catalog. Pour permettre à d'autres utilisateurs d'accéder aux logs du driver, voir Autoriser les utilisateurs non-administrateurs à consulter les logs du driver d'un pipeline compatible Unity Catalog.

  • Les pipelines existants qui utilisent le Hive metastore ne peuvent pas être mis à niveau pour utiliser Unity Catalog. Pour migrer un pipeline existant qui écrit vers Hive metastore, vous devez créer un nouveau pipeline et réingérer les données à partir des source de données. Voir Créer un pipeline Unity Catalog en clonant un pipeline Hive metastore.

  • Vous ne pouvez pas créer un pipeline compatible Unity Catalog dans un workspace attaché à un metastore qui a été créé pendant la préversion publique de Unity Catalog. Consultez Mise à niveau vers l'héritage des privilèges.

  • Les JAR ne sont pas pris en charge. Seules les bibliothèques Python tierces sont prises en charge. Consultez Gérer les dépendances Python pour les pipelines.

  • Les requêtes de langage de manipulation de données (LMD) qui modifient le schéma d'une table de streaming ne sont pas prises en charge.

  • Une vue matérialisée créée dans un pipeline ne peut pas être utilisée comme source de streaming en dehors de ce pipeline, par exemple, dans un autre pipeline ou un notebook en aval.

  • Les données pour les vues matérialisées et les tables de streaming sont stockées dans l'emplacement de stockage du schéma conteneur. Si un emplacement de stockage de schéma n'est pas spécifié, les tables sont stockées dans l'emplacement de stockage du catalogue. Si les emplacements de stockage du schéma et du catalogue ne sont pas spécifiés, les tables sont stockées dans l'emplacement de stockage racine du métastore.

  • Le Catalog Explorer History tab does not show history for materialized views.

  • La propriété LOCATION n'est pas prise en charge lors de la définition d'une table.

  • Les pipelines compatibles avec Unity Catalog ne peuvent pas publier dans le Hive metastore.

  • Les scripts d'initialisation globaux ne sont pas pris en charge. Databricks recommande d'utiliser les paramètres d' environnement du pipeline pour installer les dépendances. Sur le compute classique, vous pouvez utiliser des scripts d'initialisation à l'échelle du cluster, mais Databricks recommande plutôt les paramètres **Environnement**. Les pipelines Serverless ne prennent pas en charge les scripts d'initialisation. Voir Gérer les dépendances Python pour les pipelines.

  • La prise en charge de Python UDF est en aperçu public.

remarque

Les fichiers sous-jacents qui supportent les vues matérialisées peuvent inclure des données provenant de tables en amont (y compris des informations personnelles identifiables possibles) qui n'apparaissent pas dans la définition de la vue matérialisée. Ces données sont automatiquement ajoutées au stockage sous-jacent pour prendre en charge le refresh incrémentiel des vues matérialisées.

Parce que les fichiers sous-jacents d'une vue matérialisée pourraient risquer d'exposer des données provenant de tables en amont ne faisant pas partie du schéma de la vue matérialisée, Databricks recommande de ne pas partager le stockage sous-jacent avec des consommateurs en aval non fiables.

Par exemple, supposons qu'une définition de vue matérialisée inclue une clause COUNT(DISTINCT field_a). Même si la définition de la vue matérialisée n'inclut que la clause d'agrégation COUNT DISTINCT, les fichiers sous-jacents contiennent une liste des valeurs réelles de field_a.

Utilisez Hive metastore et les pipelines Unity Catalog ensemble​

Votre Workspace peut contenir des pipelines qui utilisent Unity Catalog et le Hive metastore hérité. Cependant, un seul pipeline ne peut pas écrire dans le Hive metastore et le Unity Catalog. Les pipelines existants qui écrivent dans le Hive metastore ne peuvent pas être mis à niveau pour utiliser Unity Catalog. Pour migrer un pipeline existant qui écrit vers Hive metastore, vous devez créer un nouveau pipeline et réingérer les données à partir de la ou des sources de données. Voir Créer un pipeline Unity Catalog en clonant un pipeline Hive metastore.

Les pipelines existants qui n'utilisent pas Unity Catalog ne sont pas affectés par la création de nouveaux pipelines configurés avec Unity Catalog. Ces pipelines continuent à persister les données dans le Hive metastore à l'aide de l'emplacement de stockage configuré.

Sauf indication contraire dans ce document, toutes les sources de données existantes et les fonctionnalités de pipeline sont prises en charge avec les pipelines qui utilisent Unity Catalog. Les interfaces Python et SQL sont prises en charge avec les pipelines qui utilisent Unity Catalog.

Tables inactives​

Lorsqu’un pipeline est configuré pour conserver les données dans Unity Catalog, le pipeline gère le cycle de vie et les autorisations de la table.

Les tables peuvent devenir inactives si leur définition est supprimée d’un pipeline. La prochaine mise à jour du pipeline marque l’entrée de la vue matérialisée ou de la table de streaming correspondante comme inactive.

Si vous modifiez le catalogue ou le schéma default du pipeline et que vous n’utilisez pas de noms de table entièrement qualifiés dans le code source du pipeline, la prochaine exécution du pipeline crée la vue matérialisée ou la table de streaming dans le nouveau catalogue ou schéma, et la vue matérialisée ou la table de streaming précédente à l’ancien emplacement est marquée comme inactive.

Vous pouvez toujours query les tables inactives, mais le pipeline ne les met plus à jour. Pour nettoyer les vues matérialisées ou les tables de streaming, DROP la table explicitement. Les tables inactives sont supprimées lorsque le pipeline est supprimé.

  • Vous pouvez récupérer les tables supprimées dans les 7 jours en utilisant la commande UNDROP.
  • Pour conserver le comportement hérité où l'entrée de la vue matérialisée ou de la table de streaming est supprimée d'Unity Catalog lors de la prochaine mise à jour du pipeline, définissez la configuration du pipeline "pipelines.dropInactiveTables": "true". Les données réelles sont conservées pendant une période afin qu'elles puissent être récupérées si elles sont supprimées par erreur. Les données peuvent être récupérées dans les 7 jours en ajoutant la vue matérialisée ou la table de streaming à nouveau dans la définition du pipeline.

La suppression complète du **pipeline** (par opposition à la suppression d’une définition de table de la source du **pipeline**) supprime également toutes les tables définies dans ce **pipeline**. L’interface utilisateur vous invite à confirmer la suppression d’un pipeline.

Supprimer un pipeline​

Lorsque vous supprimez un pipeline Unity Catalog, les vues matérialisées, les tables de streaming et les vues associées sont également supprimées.

Pour supprimer un pipeline et conserver ses tables, utilisez le champ cascade dans l'API. Les tables conservées sont inactives, mais peuvent être query. Vous pouvez déplacer les tables inactives vers un nouveau pipeline, et si elles sont attachées à un flux, elles sont réactivées. Voir Déplacer des tables entre les pipelines.

DELETE /api/2.0/pipelines/{pipeline_id}?cascade=false

Consultez Supprimer un pipeline dans la documentation de l'API REST Databricks.

Écrire des tables dans Unity Catalog à partir d'un pipeline​

Pour écrire vos tables dans Unity Catalog, vous devez configurer votre pipeline pour qu’il fonctionne avec celui-ci via votre Workspace. Lorsque vous créez un pipeline, sélectionnez Unity Catalog sous Options de stockage , sélectionnez un catalogue dans le menu déroulant Catalogue et sélectionnez un schéma existant ou entrez le nom d'un nouveau schéma dans le menu déroulant Schéma cible . Pour en savoir plus sur les catalogues Unity Catalog, consultez Que sont les catalogues dans Databricks ?. Pour en savoir plus sur les schémas dans Unity Catalog, consultez Que sont les schémas dans Databricks ?.

remarque

Lorsqu'un pipeline publie dans Unity Catalog, Databricks stocke certaines données de support dans le catalogue __databricks_internal réservé. C'est attendu. Consultez le catalogue __databricks_internal.

Ingérer des données dans un pipeline Unity Catalog​

Votre pipeline configuré pour utiliser Unity Catalog peut lire les données des éléments suivants :

  • Tables Unity Catalog gérées et externes, vues, vues matérialisées et tables de streaming.
  • Tables et vues du Hive metastore.
  • Auto Loader utilisant la fonction read_files() pour lire à partir des emplacements externes de Unity Catalog.
  • Apache Kafka et Amazon Kinesis.

Voici des exemples de lecture depuis les tables Unity Catalog et Hive metastore.

Ingestion par batch depuis une table Unity Catalog​

SQL
CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  my_catalog.my_schema.table1;

Stream des modifications d'une table Unity Catalog​

SQL
CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  STREAM(my_catalog.my_schema.table1);

Ingérer des données à partir de Hive metastore​

Un pipeline qui utilise Unity Catalog peut lire les données des tables du Hive metastore en utilisant le catalogue hive_metastore :

SQL
CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  <hms_federation_catalog>.some_schema.table;

Ingérer des données depuis Auto Loader​

SQL
CREATE OR REFRESH STREAMING TABLE table_name
AS SELECT *
FROM STREAM read_files(
  "/path/to/uc/external/location",
  format => "json"
)

Partager les vues matérialisées​

Par default, seul le propriétaire du pipeline dispose de l'autorisation de query les datasets créés par le pipeline. Vous pouvez donner aux autres utilisateurs la possibilité de query une table en utilisant les instructions GRANT et vous pouvez révoquer l'accès à la query en utilisant les instructions REVOKE. Pour plus d'information sur les privilèges dans Unity Catalog, consultez Gérer les privilèges dans Unity Catalog.

Accorder la sélection sur une table​

SQL
GRANT SELECT ON TABLE
  my_catalog.my_schema.table_name
TO
  `user@databricks.com`

Révoquer la sélection sur une table​

SQL
REVOKE SELECT ON TABLE
  my_catalog.my_schema.table_name
FROM
  `user@databricks.com`

Accorder les privilèges de création de table ou de vue matérialisée​

SQL
GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
  my_catalog.my_schema
TO
  { principal | user }

Afficher la traçabilité pour un pipeline​

La traçabilité des tables définies dans les pipelines est visible dans l'explorateur de catalogues. L'interface utilisateur de traçabilité de Catalog Explorer affiche les tables en amont et en aval pour les vues matérialisées ou les tables de streaming dans un pipeline compatible avec Unity Catalog. Pour en savoir plus sur la traçabilité dans Unity Catalog, consultez Traçabilité dans Unity Catalog.

Pour une vue matérialisée ou une table de streaming dans un pipeline compatible avec Unity Catalog, l'interface utilisateur de lignage de l'Explorateur de catalogues renvoie également au pipeline qui a produit la vue matérialisée ou la table de streaming si le pipeline est accessible depuis le workspace actuel.

Ajouter, modifier ou supprimer des données dans une table de streaming​

Vous pouvez utiliser des instructions de langage de manipulation de données (LMD), y compris des instructions d'insertion, de mise à jour, de suppression et de Merge, pour modifier les tables de streaming publiées dans Unity Catalog. La prise en charge des requêtes LMD sur les tables de streaming permet des cas d'utilisation tels que la mise à jour des tables pour la conformité avec le Règlement général sur la protection des données (GDPR).

remarque
  • Les instructions DML qui modifient le schéma de table d'une table en streaming ne sont pas prises en charge. Assurez-vous que vos instructions DML ne tentent pas de faire évoluer le schéma de la table.
  • Les instructions DML qui mettent à jour une table de streaming peuvent être exécutées uniquement dans un cluster Unity Catalog partagé ou un SQL Warehouse utilisant Databricks Runtime 13.3 LTS et versions ultérieures.
  • Étant donné que le streaming nécessite des sources de données d'ajout uniquement, si votre traitement nécessite de lire en streaming une table de streaming source avec des modifications (par exemple, par des instructions DML), définissez l'indicateur skipChangeCommits lors de la lecture de la table de streaming source. Lorsque skipChangeCommits est défini, les transactions qui suppriment ou modifient des enregistrements sur la table source sont ignorées. Si votre traitement ne nécessite pas de table de streaming, vous pouvez utiliser une vue matérialisée (qui n'a pas la restriction d'ajout uniquement) comme table cible.

Voici des exemples d'instructions DML pour modifier des enregistrements dans une table de streaming.

Supprimer les enregistrements avec un ID spécifique :​

SQL
DELETE FROM my_streaming_table WHERE id = 123;

Mettre à jour les enregistrements avec un ID spécifique :​

SQL
UPDATE my_streaming_table SET name = 'Jane Doe' WHERE id = 123;

Publiez des tables avec des filtres de lignes et des masques de colonnes​

Les filtres de lignes vous permettent de spécifier une fonction qui s'applique comme un filtre chaque fois qu'une analyse de table récupère des lignes. Ces filtres garantissent que les queries suivantes ne renvoient que les lignes pour lesquelles le prédicat du filtre est vrai.

Les masques de colonne vous permettent de masquer les valeurs d'une colonne chaque fois qu'une analyse de table récupère des lignes. Les requêtes futures pour cette colonne renvoient le résultat de la fonction évaluée au lieu de la valeur d'origine de la colonne. Pour plus d'informations sur l'utilisation des filtres de ligne et des masques de colonne, consultez Filtres de ligne et masques de colonne.

Gérer les filtres de lignes et les masques de colonne​

Les filtres de lignes et les masques de colonnes sur les vues matérialisées et les tables de streaming doivent être ajoutés, mis à jour ou supprimés via l'instruction CREATE OR REFRESH.

Pour une syntaxe détaillée sur la définition de tables avec des filtres de lignes et des masques de colonnes, consultez la référence du langage SQL de Pipeline et la référence du langage Python de LakeFlow Pipelines.

Comportement du filtre de ligne et du masque de colonne​

Voici d'importants détails concernant l'utilisation de filtres de ligne ou de masques de colonne dans un pipeline :

  • Refresh as owner : Lorsqu’une mise à jour de pipeline refresh une vue matérialisée ou une table de streaming, les fonctions de filtre de ligne et de masque de colonne s’exécutent avec les droits du propriétaire du pipeline. Cela signifie que le table refresh utilise le contexte de sécurité de l'utilisateur qui a créé le pipeline. Les fonctions qui vérifient le contexte utilisateur (telles que CURRENT_USER et IS_MEMBER) sont évaluées à l'aide du contexte utilisateur du propriétaire du pipeline.
  • Query : Lors de l'interrogation d'une vue matérialisée ou d'une table de streaming, les fonctions qui vérifient le contexte utilisateur (telles que CURRENT_USER et IS_MEMBER) sont évaluées à l'aide du contexte utilisateur de l'appelant. Cette approche applique des contrôles d'accès et de sécurité des données spécifiques à l'utilisateur en fonction du contexte de l'utilisateur actuel.
  • Lors de la création de vues matérialisées sur des tables sources qui contiennent des filtres de lignes et des masques de colonnes, le refresh de la vue matérialisée est toujours un refresh complet. Une full refresh retraite toutes les données disponibles dans la source avec les dernières définitions. Ce processus vérifie que les politiques de sécurité sur les tables sources sont évaluées et appliquées avec les données et définitions les plus récentes.

Audit des filtres de lignes et des masques de colonne​

Utilisez DESCRIBE EXTENDED, INFORMATION_SCHEMA ou l'Explorateur de catalogues pour examiner les filtres de lignes et les masques de colonnes existants qui s'appliquent à une vue matérialisée ou une table de streaming donnée. Cette fonctionnalité permet aux utilisateurs d'auditer et de réviser les mesures d'accès et de protection des données sur les vues matérialisées et les tables de streaming.

Sur cette page