Partager via


Qu’est-ce que Unity Catalog ?

Cet article présente Unity Catalog, une solution de gouvernance unifiée pour les ressources de données et d’IA sur Azure Databricks.

Remarque

Unity Catalog est également disponible en tant qu’implémentation open source. Consultez le blog d’annonce et le référentiel public Unity Catalog sur GitHub.

Vue d’ensemble de Unity Catalog

Unity Catalog fournit des fonctionnalités centralisées de contrôle d’accès, d’audit, de traçabilité et de découverte des données dans les espaces de travail Azure Databricks.

Diagramme de Unity Catalog

Les principales fonctionnalités de Unity Catalog sont les suivantes :

  • Définir une fois, sécuriser partout : Unity Catalog offre un emplacement unique pour gérer les stratégies d’accès aux données qui s’appliquent à tous les espaces de travail.
  • Modèle de sécurité conforme aux standards : le modèle de sécurité de Unity Catalog est basé sur le langage SQL ANSI standard. Il permet aux administrateurs d’accorder des autorisations dans leur lac de données existant en employant une syntaxe bien connue, au niveau des catalogues, schémas (également appelés bases de données), tables et vues.
  • Audit et traçabilité intégrés : Unity Catalog capture automatiquement les journaux d’audit de niveau utilisateur qui enregistrent l’accès à vos données. Unity Catalog capture également les données de traçabilité qui effectuent le suivi de la création et de l’utilisation des ressources de données dans tous les langages.
  • Découverte des données : Unity Catalog vous permet d’étiqueter et de documenter les ressources de données, et fournit une interface de recherche permettant aux consommateurs de données de trouver des données.
  • Tables système (préversion publique) : Unity Catalog vous permet d’accéder et d’interroger facilement les données opérationnelles de votre compte, notamment les journaux d’audit, l’utilisation facturable et la traçabilité.

Modèle objet Unity Catalog

Dans Unity Catalog, toutes les métadonnées sont inscrites dans un metastore. Dans un metastore Unity Catalog, les objets de base de données sont hiérarchisés sur trois niveaux ; ils sont représentés par un espace de noms à trois niveaux (catalog.schema.table-etc) lorsque vous faites référence à des tables, vues, volumes, modèles et fonctions.

Diagramme de modèle objet Unity Catalog

Metastores

Le metastore est le conteneur de niveau supérieur des métadonnées dans Unity Catalog. Il inscrit les métadonnées sur les ressources de données et d’IA, ainsi que les autorisations qui régissent l’accès à celles-ci. Pour qu’un espace de travail utilise Unity Catalog, un metastore Unity Catalog doit lui être attaché.

Vous devez disposer d’un metastore pour chaque région où vous disposez d’espaces de travail. Comment un espace de travail est-il attaché à un metastore ? Consultez Comment faire configurer le catalogue Unity pour mon organisation ?.

Hiérarchie des objets dans le metastore

Dans un metastore Unity Catalog, la hiérarchie à trois niveaux des objets de base de données se compose de catalogues qui contiennent des schémas, qui eux-mêmes contiennent des données et des objets d’IA, comme des tables et des modèles.

Niveau 1 :

  • Les catalogues permettent d’organiser vos ressources de données ; ils constituent généralement le niveau supérieur dans votre schéma d’isolation des données. Les catalogues reflètent souvent des unités d’organisation ou des étendues de cycle de vie de développement logiciel. Consultez En quoi consistent les catalogues dans Azure Databricks ?
  • Les objets sécurisables non-données, tels que les informations d’identification de stockage et les emplacements externes, permettent de gérer votre modèle de gouvernance des données dans Unity Catalog. Ils se trouvent aussi directement sous le metastore. Une description plus détaillée de ceux-ci est fournie dans Autres objets sécurisables.

Niveau 2 :

  • Les schémas (également appelés bases de données) contiennent des tables, des vues, des volumes, des modèles d’IA et des fonctions. Les schémas organisent les données et les ressources d’IA en catégories logiques plus granulaires que les catalogues. En règle générale, un schéma représente un seul cas d’utilisation, projet ou bac à sable d’équipe. Consultez En quoi consistent les schémas dans Azure Databricks ?

Niveau 3 :

Utilisation d’objets de base de données dans Unity Catalog

L’utilisation d’objets de base de données dans Unity Catalog est très similaire à l’utilisation d’objets de base de données inscrits dans un metastore Hive, sauf qu’un metastore Hive ne comporte pas de catalogues dans l’espace de noms d’objet. Vous pouvez utiliser la syntaxe ANSI bien connue pour créer des objets de base de données, gérer les objets de base de données, gérer les autorisations et utiliser les données dans Unity Catalog. Vous pouvez également créer des objets de base de données, gérer les objets de base de données et gérer les autorisations sur les objets de base de données à l’aide de l’interface utilisateur de Catalog Explorer.

Pour plus d’informations, consultez Objets de base de données dans Azure Databricks et Utiliser Unity Catalog et le metastore Hive hérité.

Autres objets sécurisables

Outre les objets de base de données et les ressources d’IA contenus dans les schémas, Unity Catalog régit également l’accès aux données à l’aide des objets sécurisables suivants :

Pour plus d’informations sur les objets sécurisables Delta Sharing, consultez Qu’est-ce que le Delta Sharing ?.

Octroi et révocation d’accès à des objets de base de données et autres objets sécurisables dans Unity Catalog

Vous pouvez accorder et révoquer l’accès aux objets sécurisables à n’importe quel niveau de la hiérarchie, y compris le metastore lui-même. L’accès à un objet accorde implicitement le même accès à tous les enfants de cet objet, sauf si l’accès est révoqué.

Vous pouvez utiliser les commandes SQL ANSI classiques pour accorder et révoquer l’accès aux objets dans Unity Catalog. Par exemple :

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

Vous pouvez également utiliser Catalog Explorer, l’interface CLI Databricks et les API REST pour gérer les autorisations d’objets.

Accorder des privilèges à l’aide de Catalog Explorer

Pour savoir comment gérer les privilèges dans Unity Catalog, consultez Gérer les privilèges dans Unity Catalog.

Accès par défaut aux objets de base de données dans Unity Catalog

Unity Catalog opère selon principe du privilège minimum, à savoir que les utilisateurs disposent de l’accès minimum nécessaire pour effectuer leurs tâches requises. Lorsqu’un espace de travail est créé, les utilisateurs non administrateurs n’ont accès qu’au catalogue d’espace de travail approvisionné automatiquement, ce qui fait de ce catalogue est emplacement pratique pour les utilisateurs souhaitant essayer le processus de création et d’accès aux objets de base de données dans Unity Catalog. Consultez Privilèges de catalogue d’espace de travail.

Rôles d’administrateur

Par défaut, les administrateurs d’espace de travail et les administrateurs de compte disposent de privilèges supplémentaires. Administrateur de metastore est un rôle facultatif. Il est nécessaire si vous souhaitez gérer le stockage de tables et de volumes au niveau du metastore. Pratique, il vous permet de gérer les données de manière centralisée sur les différents espaces de travail d’une région. Pour plus d’informations, consultez Privilèges d’administrateur dans Unity Catalog et (Facultatif) Attribuer le rôle d’administrateur de metastore.

Comparaison entre les tables et les volumes managés et externes

Les tables et les volumes peuvent être managés ou externes.

  • Les tables managées sont complètement managées par Unity Catalog, ce qui signifie que Unity Catalog manage à la fois la gouvernance et les fichiers de données sous-jacents pour chaque table managée. Les tables managées sont stockées à un emplacement managé par Unity Catalog dans votre stockage cloud. Les tables managées utilisent toujours le format Delta Lake. Vous pouvez stocker les tables managées au niveau du metastore, du catalogue ou du schéma.
  • Les tables externes sont des tables dont l’accès depuis Azure Databricks est managé par Unity Catalog, mais dont le cycle de vie des données et la disposition des fichiers sont gérés par l’intermédiaire de votre fournisseur de cloud et d’autres plateformes de données. En règle générale, les tables externes servent à inscrire de grandes quantités de données existantes dans Azure Databricks. Elles sont également si vous avez besoin d’un accès en écriture aux données à l’aide d’outils extérieurs à Azure Databricks. Les tables externes sont prises en charge dans plusieurs formats de données. Une fois qu’une table externe est inscrite dans un metastore Unity Catalog, vous pouvez gérer et auditer l’accès d’Azure Databricks à celle-ci (et l’utiliser) comme vous le feriez avec des tables managées.
  • Les volumes managés sont complètement managés par Unity Catalog, ce qui signifie que Unity Catalog manage l’accès à l’emplacement de stockage des volumes dans le compte de votre fournisseur de cloud. Lorsque vous créez un volume managé, il est automatiquement stocké à l’emplacement de stockage managé affecté au schéma conteneur.
  • Les volumes externes représentent les données existantes à des emplacements de stockage gérés en dehors d’Azure Databricks, mais inscrits dans Unity Catalog pour le contrôle et l’audit de l’accès depuis Azure Databricks. Lorsque vous créez un volume externe dans Azure Databricks, vous spécifiez son emplacement, qui doit se trouver sur un chemin défini à un emplacement externe Unity Catalog.

Databricks recommande les tables et les volumes managés pour tirer pleinement parti des fonctionnalités de gouvernance et des optimisations de performances de Unity Catalog.

Consultez Utiliser des tables managées, Utiliser des tables externeset Comparaison entre volumes managés et volumes externes.

Isolation des données avec un stockage managé

Votre organisation peut demander à ce que les données de certains types soient stockées dans des comptes ou des compartiments spécifiques dans votre locataire cloud.

Unity Catalog permet de configurer des emplacements de stockage au niveau du metastore, du catalogue ou du schéma pour répondre à ces exigences. Le système évalue la hiérarchie des emplacements de stockage du schéma au catalogue, puis au metastore.

Par exemple, supposons que la stratégie de conformité d’entreprise de votre organisation nécessite que les données de production relatives aux ressources humaines résident dans le conteneur abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. Dans Unity Catalog, vous pouvez répondre à cette exigence en définissant un emplacement au niveau du catalogue, en créant un catalogue appelé par exemple hr_prod, et en lui attribuant l’emplacement abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Cela signifie que les tables ou volumes managés créés dans le catalogue hr_prod (en utilisant CREATE TABLE hr_prod.default.table …, par exemple) stockent leurs données dans abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Si vous le souhaitez, vous pouvez choisir de fournir des emplacements au niveau du schéma pour organiser les données dans hr_prod catalog à un niveau plus granulaire.

Si l’isolation du stockage n’est pas exigée pour certains catalogues, vous pouvez éventuellement définir un emplacement de stockage au niveau du metastore. Cet emplacement sert d’emplacement par défaut pour les tables et les volumes managés dans les catalogues et les schémas qui n’ont pas de stockage attribué. Cependant, Databricks vous recommande généralement d’attribuer des emplacements de stockage managés distincts pour chaque catalogue.

Pour plus d’informations, consultez Spécifier un emplacement de stockage managé dans Unity Catalog et Données physiquement séparées dans le stockage.

Liaison espace de travail-catalogue

Par défaut, les propriétaires de catalogue (et les administrateurs de metastore, s’ils sont définis pour le compte) peuvent rendre un catalogue accessible aux utilisateurs dans plusieurs espaces de travail attachés au même metastore Unity Catalog. Cependant, si vous utilisez des espaces de travail pour isoler l’accès aux données utilisateur, vous avez peut-être intérêt à limiter l’accès au catalogue à des espaces de travail spécifiques dans votre compte, afin de garantir que certains types de données ne soient traités que dans ces espaces de travail. Vous pouvez souhaiter disposer d’espaces de travail de production et de développement distincts, par exemple, ou d’un espace de travail distinct pour le traitement des données sensibles. C’est ce que l’on appelle une liaison espace de travail-catalogue. Consultez Limiter l’accès au catalogue à des espaces de travail spécifiques.

Remarque

Pour une isolation accrue des données, vous pouvez également lier l’accès au stockage cloud et l’accès au service cloud à des espaces de travail spécifiques. Voir (Facultatif) Affecter des informations d’identification de stockage à des espaces de travail spécifiques, (Facultatif) Affecter un emplacement externe à des espaces de travail spécifiques et (Facultatif) Affecter des informations d’identification de service à des espaces de travail spécifiques.

Audit de l’accès aux données

Unity Catalog capture un journal d’audit des actions effectuées au niveau du metastore, ce qui permet aux administrateurs d’accéder à des détails très fins sur les personnes ayant accédé à un jeu de données déterminé et les actions qu’ils ont effectuées.

Vous pouvez accéder aux journaux d’audit de votre compte en utilisant les tables système managées par Unity Catalog.

Consultez Auditer les événements Unity Catalog, Événements Unity Cataloget Surveiller l’utilisation avec les tables système.

Suivi de la traçabilité des données

Vous pouvez utiliser le Catalogue Unity pour capturer la traçabilité des données de runtime entre les requêtes dans n’importe quel langage exécuté sur un cluster Azure Databricks ou un entrepôt SQL. La traçabilité est capturée jusqu’au niveau de la colonne, et inclut les notebooks, les travaux et les tableaux de bord liés à la requête. Pour en savoir plus, consultez Capturer et afficher la traçabilité des données en utilisant Unity Catalog.

Lakehouse Federation et Unity Catalog

Lakehouse Federation est la plateforme de fédération de requêtes pour Azure Databricks. Le terme fédération de requêtes décrit une collection de fonctionnalités qui permettent aux utilisateurs et aux systèmes d’exécuter des requêtes sur plusieurs sources de données en silo sans devoir migrer toutes les données vers un système unifié.

Azure Databricks utilise Unity Catalog pour gérer la fédération des requêtes. Vous utilisez Unity Catalog pour configurer desconnexions en lecture seule à des systèmes de base de données externes populaires et créer des catalogues étrangers qui reflètent des bases de données externes. Les outils de gouvernance et de traçabilité des données d’Unity Catalog garantissent que l’accès aux données est géré et audité pour toutes les requêtes fédérées effectuées par les utilisateurs de vos espaces de travail Azure Databricks.

Consultez Qu’est-ce que Lakehouse Federation ?.

Delta Sharing, Databricks Marketplace et Unity Catalog

Delta Sharing est une plateforme de partage de données sécurisée qui vous permet de partager des données et des ressources d’IA avec des utilisateurs extérieurs à votre organisation, que ces utilisateurs utilisent ou non Databricks. Bien que Delta Sharing soit disponible en tant qu’implémentation open source, dans Databricks, Unity Catalog est nécessaire pour tirer pleinement parti des fonctionnalités étendues. Consultez Qu’est-ce que le Delta Sharing ?.

Databricks Marketplace est un forum ouvert dédié à l’échange de produits de données, qui repose sur Delta Sharing. À ce titre, vous devez disposer d’un espace de travail compatible avec Unity Catalog pour pouvoir être fournisseur de la Marketplace. Consultez Qu’est-ce que la Place de marché Databricks ?.

Comment faire configurer le catalogue Unity pour mon organisation ?

Pour utiliser Unity Catalog, votre espace de travail Azure Databricks doit être activé pour Unity Catalog, ce qui signifie que l’espace de travail est attaché à un metastore Unity Catalog.

Comment un espace de travail est-il attaché à un metastore ? Cela dépend du compte et de l’espace de travail :

  • En règle générale, lorsque vous créez un espace de travail Azure Databricks dans une région pour la première fois, le metastore est créé automatiquement et attaché à l’espace de travail.
  • Pour certains comptes anciens, un administrateur de compte doit créer le metastore et affecter les espaces de travail de cette région au metastore. Pour obtenir des instructions, consultez Créer un metastore Unity Catalog.
  • Si un compte dispose déjà d’un metastore affecté pour une région, un administrateur de compte peut décider s’il faut attacher automatiquement le metastore à tous les nouveaux espaces de travail de cette région. Consultez Activer l’attribution automatique d’un metastore à de nouveaux espaces de travail.

Que votre espace de travail ait été activé automatiquement ou non pour Unity Catalog, les étapes suivantes sont également nécessaires pour commencer à utiliser Unity Catalog :

  • Création de catalogues et de schémas en vue d’accueillir les objets de base de données comme les tables et les volumes.
  • Création d’emplacements de stockage managés pour stocker les tables et les volumes managés dans ces catalogues et schémas.
  • Octroi d’un accès utilisateur aux catalogues, schémas et objets de base de données.

Un espace de travail automatiquement activé pour Unity Catalog approvisionne un catalogue d’espace de travail en octroyant des privilèges étendus à tous les utilisateurs de l’espace de travail. Ce catalogue est un point de départ pratique pour essayer Unity Catalog.

Pour obtenir des instructions de configuration détaillées, consultez Configurer et gérer Unity Catalog.

Migration d’un espace de travail existant vers Unity Catalog

Si vous disposez d’un ancien espace de travail et que vous l’avez récemment activé pour Unity Catalog, il est probable que vos données sont managées par le metastore Hive hérité. Vous pouvez utiliser ces données en même temps que les données inscrites dans Unity Catalog, mais le metastore Hive hérité est déconseillé, et vous avez tout intérêt à migrer les données de votre metastore Hive vers Unity Catalog dès que possible pour tirer parti des fonctionnalités de gouvernance et des performances supérieures de Unity Catalog.

La migration passe par les étapes suivantes :

  1. Conversion des éventuels groupes locaux d’espace de travail en groupes au niveau du compte. Unity Catalog centralise la gestion des identités au niveau du compte.
  2. Migration des tables et des vues managées du metastore Hive vers Unity Catalog.
  3. Mise à jour des requêtes et des travaux pour faire référence aux nouvelles tables Unity Catalog à la place des anciennes tables du metastore Hive.

Les recommandations suivantes peuvent vous aider à gérer une migration :

Exigences et restrictions de Unity Catalog

Unity Catalog exige certains types de calcul et de formats de fichiers, dont vous trouverez la description ci-dessous. De même, vous trouverez ensuite mention de certaines fonctionnalités Azure Databricks qui ne sont pas entièrement prises en charge dans Unity Catalog sur toutes les versions de Databricks Runtime.

Prise en charge des régions

Toutes les régions prennent en charge Unity Catalog. Pour plus d’informations, consultez Régions Azure Databricks.

Exigences de calcul

Unity Catalog est pris en charge sur les clusters qui exécutent Databricks Runtime 11.3 LTS ou version ultérieure. Unity Catalog est pris en charge par défaut sur toutes les versions de calcul de l’entrepôt SQL .

Les clusters s’exécutant sur des versions antérieures de Databricks Runtime ne prennent pas en charge toutes les fonctionnalités et fonctionnalités d’Unity Catalog GA.

Pour accéder aux données dans Unity Catalog, les clusters doivent être configurés avec le mode d’accès correct. Unity Catalog est sécurisé par défaut. Si un cluster n’est pas configuré avec un mode d’accès partagé ou utilisateur unique, le cluster ne peut pas accéder aux données dans le catalogue Unity. Voir Modes d’accès aux fichiers.

Pour plus d’informations sur les modifications apportées aux fonctionnalités de Unity Catalog dans chaque version de Databricks Runtime, consultez les notes de publication.

Les limitations de Unity Catalog varient selon le mode d’accès et la version de Databricks Runtime. Consulter Limitations des mode d’accès au calcul pour Unity Catalog.

Prise en charge des formats de fichiers

Unity Catalog prend en charge les formats de tableau suivants :

Limites

Unity Catalog présente les limitations suivantes. Certaines d’entre elles sont propres aux anciennes versions de Databricks Runtime et aux modes d’accès au calcul.

Les charges de travail Structured Streaming présentent d’autres limitations, qui dépendent de Databricks Runtime et du mode d’accès. Consulter Limitations des mode d’accès au calcul pour Unity Catalog.

Databricks publie régulièrement de nouvelles fonctionnalités qui réduisent cette liste.

  • Les groupes créés antérieurement dans un espace de travail (c’est-à-dire, des groupes au niveau de l’espace de travail) ne peuvent pas être utilisés dans les instructions GRANT de Unity Catalog. Cela permet d’obtenir une vue cohérente des groupes qui peuvent s’étendre sur plusieurs espaces de travail. Pour utiliser des groupes dans les instructions GRANT, créez vos groupes au niveau du compte et mettez à jour toute automatisation dédiée à la gestion des principaux ou des groupes (comme les connecteurs SCIM, Okta et Microsoft Entra ID, et Terraform) afin de référencer les points de terminaison du compte au lieu des points de terminaison de l’espace de travail. Consultez Différence entre les groupes de comptes et les groupes locaux d’espace de travail.

  • Les charges de travail en langage R ne prennent pas en charge les vues dynamiques dans le cadre de la sécurité au niveau des lignes ou des colonnes sur un calcul exécutant Databricks Runtime 15.3 et les versions antérieures.

    Utilisez une ressource de calcul utilisateur unique exécutant Databricks Runtime 15.4 LTS ou version ultérieure pour les charges de travail dans R qui interrogent des vues dynamiques. Ces charges de travail nécessitent également un espace de travail activé pour le calcul serverless. Pour plus d’informations, consultez Contrôle d’accès affiné sur le calcul d’un seul utilisateur.

  • Les clones superficiels ne sont pas pris en charge dans Unity Catalog sur le cluster de calcul exécutant Databricks Runtime 12.2 LTS et versions inférieures. Vous pouvez utiliser les clones superficiels pour créer des tables managées sur Databricks Runtime 13.3 LTS et versions supérieures. Vous ne pouvez pas les utiliser pour créer des tables externes, quelle que soit la version de Databricks Runtime. Consultez Clone superficiel pour les tables Unity Catalog.

  • Le compartimentage n’est pas pris en charge pour les tables Unity Catalog. Si vous exécutez des commandes qui tentent de créer une table compartimentée dans Unity Catalog, une exception sera levée.

  • L’écriture dans le même chemin d’accès ou dans la même table Delta Lake à partir d’espaces de travail dans plusieurs régions peut entraîner des performances peu fiables si certains clusters accèdent à Unity Catalog et d’autres pas.

  • Les schémas de partition personnalisés créés à l’aide de commandes telles que ALTER TABLE ADD PARTITION ne sont pas pris en charge pour les tables dans Unity Catalog. Unity Catalog peut accéder aux tables qui utilisent le partitionnement de type répertoire.

  • Le mode de remplacement des opérations d’écriture DataFrame dans Unity Catalog est pris en charge pour les tables Delta, mais pas pour les autres formats de fichier. L’utilisateur doit disposer du privilège CREATE sur le schéma parent et doit être le propriétaire de l’objet existant ou avoir le privilège MODIFY sur l’objet.

  • Les fonctions définies par l’utilisateur (UDF) Python ne sont pas prises en charge dans Databricks Runtime 12.2 LTS et versions inférieures. Cela englobe les fonctions UDAF, UDTF et Pandas sur Spark (applyInPandas et mapInPandas). Les fonctions UDF scalaires Python sont prises en charge dans Databricks Runtime 13.3 LTS et versions supérieures.

  • Les fonctions UDF Scala ne sont pas prises en charge dans Databricks Runtime 14.1 et les versions inférieures sur les clusters partagés. Les fonctions UDF scalaires Scala sont prises en charge dans Databricks Runtime 14.2 et les versions supérieures sur les clusters partagés.

  • Les pools de threads Scala standard ne sont pas pris en charge. En lieu et place, utilisez les pools de threads spéciaux dans org.apache.spark.util.ThreadUtils, par exemple, org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Toutefois, les pools de threads suivants dans ThreadUtils ne sont pas pris en charge : ThreadUtils.newForkJoinPool et tout pool de threads ScheduledExecutorService.

  • La journalisation d’audit est prise en charge pour les événements Unity Catalog au niveau de l’espace de travail uniquement. Les événements qui se produisent au niveau du compte sans référence à un espace de travail, tels que la création d’un metastore, ne sont pas journalisés.

Les modèles inscrits dans Unity Catalog présentent d’autres limitations. Voir Limitations.

Quotas de ressources

Unity Catalog applique des quotas de ressources sur tous les objets sécurisables. Ces quotas sont répertoriés dans les limites de ressources. Si vous prévoyez de dépasser ces limites de ressources, contactez l’équipe de votre compte Azure Databricks.

Vous pouvez surveiller l’utilisation de vos quotas à l’aide des API de quotas de ressources d’Unity Catalog. Consultez Surveiller l’utilisation de vos quotas de ressources Unity Catalog.