Bonnes pratiques de Unity Catalog

Ce document fournit des recommandations pour utiliser Unity Catalog afin de répondre le plus efficacement possible à vos besoins en matière de gouvernance des données. Pour une introduction à la gouvernance des données sur Databricks, consultez Gouvernance des données et de l'IA avec Unity Catalog. Pour une introduction à Unity Catalog, consultez Qu'est-ce qu'Unity Catalog ?.

Identités

Les principaux (utilisateurs, groupes et service principals) doivent être définis au niveau du compte Databricks afin de se voir attribuer des privilèges sur les objets sécurisables d’Unity Catalog. Databricks vous recommande d’utiliser SCIM pour provisionner des principaux dans votre compte Databricks à partir de votre IdP.

Bonnes pratiques :

• Évitez le provisionnement SCIM au niveau du Workspace (et désactivez ceux qui existent déjà). Le provisionnement des principaux directement vers un Workspace doit être réservé aux Workspaces hérités qui ne sont pas activés pour Unity Catalog. Vous devriez gérer le provisionnement entièrement au niveau du compte.

• Définissez et gérez les groupes dans votre IdP. Ils doivent être cohérents avec les définitions de votre groupe organisationnel.

  Les groupes se comportent différemment des utilisateurs et des Service Principals. Bien que les utilisateurs et les Service Principals que vous ajoutez à un workspace soient automatiquement synchronisés avec votre compte Databricks, les groupes au niveau du workspace ne le sont pas. Si vous avez des groupes locaux de Workspace, vous devez les migrer manuellement vers le compte, de préférence en les répliquant dans votre IdP (si nécessaire) et en les provisionnement sur le compte.

• Configurez des groupes afin de pouvoir les utiliser efficacement pour accorder l'accès aux données et à d'autres objets sécurisables de Unity Catalog. Évitez les octrois directs aux utilisateurs dans la mesure du possible.

• Utilisez des groupes pour attribuer la propriété à la plupart des objets sécurisables.

• Évitez d'ajouter des utilisateurs manuellement, soit au compte, soit au workspace. Évitez de modifier les groupes dans Databricks : utilisez votre IdP.

• Utilisez les Service Principal pour exécuter des Job. Les Service Principals permettent l'automatisation des Jobs. Si vous utilisez des utilisateurs pour exécuter des Jobs qui écrivent en production, vous risquez d'écraser des données de production par accident.

Pour plus d'informations, voir Gérer les utilisateurs, les Service Principal et les groupes et Synchroniser les utilisateurs et les groupes de votre fournisseur d'identité à l'aide de SCIM.

Rôles d'administrateur et privilèges puissants

L’attribution de rôles d’administrateur et de privilèges puissants comme ALL PRIVILEGES et MANAGE requiert de la prudence :

• Comprenez les privilèges des administrateurs de compte, des administrateurs de workspace et des administrateurs de metastore avant de les attribuer. Découvrez les privilèges d'administrateur dans Unity Catalog.
• Attribuez ces rôles à des groupes chaque fois que cela est possible.
• Les administrateurs du métastore sont facultatifs. Attribuez-les uniquement si vous en avez besoin. Pour plus d'informations, consultez les administrateurs du metastore.
• Attribuez la propriété des objets aux groupes, en particulier si les objets sont utilisés en production. Le créateur de tout objet est son premier propriétaire. Les créateurs devraient réattribuer la propriété aux groupes appropriés.
• Seuls les administrateurs de métastore, les propriétaires et les utilisateurs ayant le privilège MANAGE sur un objet peuvent accorder des privilèges sur cet objet. Les propriétaires des catalogues et schémas parents ont également la possibilité d'accorder des privilèges sur tous les objets du catalogue ou du schéma. Soyez parcimonieux dans l'attribution de la propriété et du privilège MANAGE.
• Soyez parcimonieux dans votre attribution de ALL PRIVILEGES, qui inclut tous les privilèges, à l'exception de MANAGE, EXTERNAL USE LOCATION et EXTERNAL USE SCHEMA.

Attribution de privilèges

Les objets sécurisables dans Unity Catalog sont hiérarchiques et les privilèges sont hérités vers le bas. Utilisez cette hiérarchie d'héritage pour développer un modèle de privilèges efficace.

Bonnes pratiques :

• Comprenez le rôle des privilèges USE CATALOG et USE SCHEMA :

  • USE CATALOG | SCHEMA permet d’afficher les données dans le catalogue ou le schéma. À eux seuls, ces privilèges n'accordent pas SELECT ou READ sur les objets au sein du catalogue ou du schéma, mais ils constituent une condition préalable à l'octroi de cet accès aux utilisateurs. N'accordez ces privilèges qu'aux utilisateurs qui devraient pouvoir consulter les données dans le catalogue ou le schéma.
  • USE CATALOG | SCHEMA, en limitant l'accès à un catalogue ou à un schéma, empêche les propriétaires d'objets (par exemple, un créateur de table) d'attribuer par inadvertance l'accès à cet objet (table) à des utilisateurs qui ne devraient pas y avoir accès. Il est courant de créer un schéma par équipe et d'accorder USE SCHEMA et CREATE TABLE uniquement à cette équipe (ainsi que USE CATALOG sur le catalogue parent).

• Comprenez le rôle du privilège BROWSE :

  • BROWSE permet aux utilisateurs de consulter les métadonnées des objets dans un catalogue à l'aide de Catalog Explorer, du navigateur de schémas, de la recherche, du graphe de traçabilité, information_schema et de l'API REST. Il n'accorde pas l'accès aux données.
  • BROWSE permet aux utilisateurs de découvrir des données et d'y demander l'accès, même s'ils ne disposent pas des privilèges USE CATALOG ou USE SCHEMA.
  • Databricks recommande d'accorder BROWSE sur les catalogues au groupe All account users au niveau du catalogue afin de rendre les données détectables et de prendre en charge les demandes d'accès.

• Configurez les destinations de demande d'accès pour prendre en charge l'accès en libre-service :

  • Lorsque les destinations de demande d'accès ne sont pas configurées, les utilisateurs ne peuvent pas demander l'accès aux objets, même s'ils peuvent les découvrir.
  • Databricks recommande d'activer les destinations d'e-mail par default afin que les requêtes soient automatiquement envoyées au propriétaire du catalogue ou de l'objet lorsqu'aucune autre destination n'est configurée.
  • Les destinations peuvent être configurées vers des adresses e-mail, Slack, Microsoft Teams, PagerDuty, des webhooks ou une URL de redirection vers le système de demande de votre organisation.

• Comprenez la différence entre la propriété d'objet et le privilège MANAGE :

  • Le propriétaire d'un objet dispose de tous les privilèges sur l'objet, tels que SELECT et MODIFY sur une table, ainsi que l'autorisation d'accorder des privilèges sur l'objet sécurisable à d'autres principaux et de transférer la propriété à d'autres principaux.
  • Les propriétaires peuvent accorder le privilège MANAGE pour déléguer les capacités de propriété sur un objet à d'autres principaux.
  • Les propriétaires de catalogues et de schémas peuvent transférer la propriété de n'importe quel objet dans le catalogue ou le schéma.
  • Il est préférable de configurer la propriété ou d'accorder le privilège MANAGE sur tous les objets à un groupe responsable de l'administration des octrois sur l'objet.

• Utilisez la propriété de groupe pour activer l'édition collaborative des vues et des vues de métriques :

  • default, seul le propriétaire d'une vue ou d'une vue de métriques peut modifier sa définition. Ceci empêche l'escalade de privilèges où un éditeur pourrait modifier la vue pour accéder à des données non autorisées.
  • Pour permettre à plusieurs utilisateurs de modifier en toute sécurité la même vue ou vue de métrique, transférez la propriété à un groupe et accordez à ce groupe l'accès aux tables source. Tous les membres du groupe peuvent ensuite modifier la définition, et l'accès aux données est limité à ce que le groupe est autorisé à voir.
  • Pour des conseils détaillés, consultez Activer la modification collaborative.

• Réservez l'accès direct MODIFY aux tables de production pour les Service Principals.

Pour plus d'informations, consultez Gérer les privilèges dans Unity Catalog.

Métastores

Voici les règles et les meilleures pratiques pour la création et la gestion des metastores :

• Vous ne pouvez avoir qu'un seul métastore par région. Tous les Workspaces de cette région partagent ce métastore. Pour partager des données entre les régions, consultez Le partage interrégional et interplateforme.

• Les metastores offrent une isolation régionale, mais ne sont pas destinés à être des unités default d'isolation des données. L'isolation des données commence généralement au niveau du catalogue. Cependant, si vous préférez un modèle de gouvernance plus centralisé, vous pouvez créer un stockage géré au niveau du metastore. Pour les recommandations, voir le stockage géré.

• Le rôle d'administrateur du métastore est facultatif. Pour des recommandations sur l’opportunité d’attribuer un administrateur de métastore facultatif, consultez Rôles d’administrateur et privilèges puissants.

important

N'enregistrez pas les tables fréquemment consultées en tant que tables externes dans plus d'un metastore. Si vous le faites, les modifications apportées au schéma, aux propriétés de la table, aux commentaires et aux autres métadonnées résultant des écritures dans le metastore A ne seront pas du tout enregistrées auprès du metastore B. Vous pouvez également causer des problèmes de cohérence avec le service de commit Databricks.

Catalogues et schémas

Les catalogues sont l'unité principale d'isolation des données dans le modèle de gouvernance des données Unity Catalog typique. Les schémas ajoutent une couche supplémentaire d'organisation.

Meilleures pratiques pour l'utilisation du catalogue et du schéma :

• Organisez les objets de données et d’IA en catalogues et schémas qui reflètent les divisions organisationnelles et les projets. Souvent, cela signifie que les catalogues correspondent à une portée d’environnement, une équipe, une unité commerciale ou une combinaison de ceux-ci. Cela facilite l'utilisation de la hiérarchie des privilèges pour gérer efficacement l'accès.
• Lorsque les environnements de travail et les données ont tous deux les mêmes exigences d'isolation, vous pouvez lier un catalogue à un workspace spécifique. Lorsque cela est requis, créez des catalogues qui peuvent être limités à un ensemble restreint de workspaces.
• Attribuez toujours la propriété des catalogues et schémas de production à des groupes, et non à des utilisateurs individuels.
• Accordez USE CATALOG et USE SCHEMA uniquement aux utilisateurs qui devraient pouvoir voir ou query les données qu'ils contiennent.

Pour plus de conseils sur l'octroi de privilèges sur les catalogues et les schémas, consultez l'attribution de privilèges.

Stockage géré

Les tables et volumes gérés, objets dont le cycle de vie est entièrement managé par Unity Catalog, sont stockés dans des emplacements de stockage default, appelés *stockage géré*. Vous pouvez configurer le stockage géré au niveau du métastore, du catalogue ou du schéma. Les données sont stockées à l’emplacement disponible le plus bas dans la hiérarchie. Pour plus de détails, consultez Spécifier un emplacement de stockage géré dans Unity Catalog.

Bonnes pratiques pour les emplacements de stockage gérés :

• Donnez la préférence au stockage au niveau du catalogue comme unité principale d'isolation des données.

  Le stockage au niveau du metastore était requis dans les premiers environnements Unity Catalog, mais il ne l'est plus.

• Si vous choisissez de créer un emplacement géré au niveau du métastore, utilisez un compartiment dédié.

• N'utilisez pas un compartiment accessible depuis l'extérieur de Unity Catalog.

  Si un service externe ou un principal accède aux données dans l'emplacement de stockage géré, en contournant Unity Catalog, le contrôle d'accès et l'auditabilité sur les tables et volumes gérés sont compromis.

• Ne réutilisez pas un compartiment qui est ou a été utilisé pour votre système de fichiers racine DBFS.

Tables gérées et externes

Les tables gérées sont entièrement managées par Unity Catalog, ce qui signifie que Unity Catalog gère à la fois la gouvernance et les fichiers de données sous-jacents pour chaque table gérée. Ils sont toujours au format Delta ou Apache Iceberg.

Les tables externes sont des tables dont l'accès depuis Databricks est géré par Unity Catalog, mais dont le cycle de vie des données et le layout des fichiers sont gérés à l'aide de votre fournisseur cloud et d'autres plateformes de données. Lorsque vous créez une table externe dans Databricks, vous spécifiez son emplacement, qui doit se trouver sur un chemin défini dans un emplacement externe Unity Catalog.

Utilisez des tables gérées :

• Pour la plupart des cas d'usage. Databricks recommande les tables et les volumes gérés, car ils vous permettent de tirer pleinement parti des capacités de gouvernance et des optimisations des performances d’Unity Catalog, y compris :

  • Compactage automatique
  • Optimisation automatique
  • Lectures plus rapides des métadonnées (mise en cache des métadonnées)
  • Optimisations intelligentes de la taille des fichiers

  La nouvelle fonctionnalité Databricks donne la priorité aux tables gérées.

• Pour toutes les nouvelles tables.

Utiliser des tables externes :

• Lorsque vous les utilisez déjà et que vous effectuez une mise à niveau de Hive metastore vers Unity Catalog.

  • L'utilisation de tables externes peut fournir une mise à niveau rapide et transparente « en un seul clic » sans déplacer de données.
  • Databricks vous recommande de migrer à terme les tables externes vers des tables gérées.

• Si vous avez des exigences de reprise après sinistre pour ces données qui ne peuvent pas être satisfaites par des tables gérées.

  Les tables gérées ne peuvent pas être enregistrées dans plusieurs métastores dans le même cloud.

• Si des lecteurs ou rédacteurs externes doivent pouvoir interagir avec les données depuis l’extérieur de Databricks.

  En règle générale, vous devriez éviter d’autoriser l’accès externe, même aux tables externes enregistrées dans Unity Catalog. Cela contourne le contrôle d'accès, l'audit et la traçabilité de Unity Catalog. Il est préférable d'utiliser des tables gérées et de partager des données entre les régions ou les fournisseurs cloud à l'aide d'OpenSharing. Si vous devez autoriser l’accès externe aux tables externes, limitez-le aux lectures, toutes les écritures s’effectuant via Databricks et Unity Catalog.

• Vous devez prendre en charge les tables non-Delta ou non-Iceberg, telles que Parquet, Avro, ORC, et ainsi de suite.

Autres recommandations pour l'utilisation de tables externes :

• Databricks vous recommande de créer des tables externes à l'aide d'un emplacement externe par schéma.
• Databricks recommande fortement de ne pas enregistrer une table en tant que table externe dans plus d'un métastore en raison du risque de problèmes de cohérence. Par exemple, une modification du schéma dans un métastore ne sera pas enregistrée dans le second métastore. Utilisez OpenSharing pour le partage de données entre les metastores. Voir Partage interrégional et multiplateforme.

Voir aussi les tables Databricks.

Volumes gérés et externes

Les *volumes gérés* sont entièrement managés par Unity Catalog, ce qui signifie que Unity Catalog gère l'accès à l'emplacement de stockage du volume dans votre compte de fournisseur cloud. Les volumes externes représentent des données existantes dans des emplacements de stockage qui sont gérés en dehors de Databricks, mais enregistrés dans Unity Catalog pour contrôler et auditer l'accès depuis Databricks. Lorsque vous créez un volume externe dans Databricks, vous spécifiez son emplacement, qui doit se trouver sur un chemin défini dans un emplacement externe Unity Catalog.

Utilisez des volumes gérés :

• Pour la plupart des cas d'utilisation, pour tirer pleinement parti des capacités de gouvernance d'Unity Catalog.
• Si vous souhaitez créer des tables à partir de fichiers dans un volume sans exécuter les instructions COPY INTO ou CTAS (CREATE TABLE AS).

Utiliser des volumes externes :

• Enregistrer les zones d’atterrissage des données brutes produites par des systèmes externes pour prendre en charge leur traitement aux premiers stades des pipelines ETL et d’autres activités de data engineering.
• Pour enregistrer les emplacements de transit pour l'ingestion, par exemple, à l'aide d'Auto Loader, COPY INTO, ou des instructions CTAS.
• Fournir des emplacements de stockage de fichiers que les data scientists, les data analysts et les ingénieurs en Machine Learning pourront utiliser pour leurs analyses exploratoires de données et d'autres tâches de Data Science, lorsque les volumes gérés ne sont pas une option.
• Pour donner aux utilisateurs de Databricks accès aux fichiers arbitraires produits et déposés dans le stockage cloud par d'autres systèmes, par exemple, de grandes collections de données non structurées (telles que des fichiers image, audio, vidéo et PDF) capturées par des systèmes de surveillance ou des appareils IoT, ou des fichiers de bibliothèque (JARs et fichiers Python wheel) exportés depuis des systèmes de gestion de dépendances locaux ou des pipelines CI/CD.
• Pour stocker des données opérationnelles, par exemple des fichiers de journalisation ou de point de contrôle, lorsque les volumes gérés ne sont pas une option.

Plus de recommandations pour l'utilisation de volumes externes :

• Databricks vous recommande de créer des volumes externes à partir d'un emplacement externe unique au sein d'un schéma unique.

astuce

Pour les cas d'utilisation d'ingestion où les données sont copiées vers un autre emplacement (par exemple, en utilisant Auto Loader ou COPY INTO), utilisez des volumes externes. Utilisez des tables externes lorsque vous souhaitez query les données sur place en tant que table, sans aucune copie.

Voir aussi Volumes gérés et volumes externes et Emplacements externes.

Emplacements externes

Les objets sécurisables d'emplacement externe, en combinant les identifiants de stockage et les chemins de stockage, offrent un contrôle et une auditabilité renforcés de l'accès au stockage. Il est important d'empêcher les utilisateurs d'accéder directement aux buckets enregistrés en tant qu'emplacements externes, en contournant le contrôle d'accès fourni par Unity Catalog.

Pour utiliser efficacement les emplacements externes :

• Assurez-vous de limiter le nombre d'utilisateurs ayant un accès direct à tout compartiment utilisé comme emplacement externe.

• Ne montez pas de comptes de stockage sur DBFS s’ils sont également utilisés comme emplacements externes. Databricks vous recommande de migrer les montages sur les emplacements de stockage cloud vers des emplacements externes dans Unity Catalog à l’aide de l’ Explorateur de catalogues.

• Accordez la possibilité de créer des emplacements externes uniquement aux administrateurs chargés de configurer les connexions entre Unity Catalog et le stockage cloud, ou aux data engineers de confiance.

  Les emplacements externes offrent un accès depuis Unity Catalog à un emplacement de stockage cloud très étendu, par exemple, un compartiment ou un conteneur entier (s3://mycompany-hr-prod) ou un sous-chemin étendu (s3://mycompany-hr-prod/unity-catalog). L'objectif est qu'un administrateur cloud puisse être impliqué dans la configuration de quelques emplacements externes, puis déléguer la responsabilité de la gestion de ces emplacements à un administrateur Databricks au sein de votre organisation. L'administrateur Databricks peut ensuite organiser davantage l'emplacement externe en zones avec des autorisations plus granulaires en enregistrant des volumes externes ou des tables externes à des préfixes spécifiques sous l'emplacement externe.

  Étant donné que les emplacements externes sont très englobants, Databricks recommande de n'accorder la permission CREATE EXTERNAL LOCATION qu'à un administrateur chargé de configurer les connexions entre Unity Catalog et le stockage cloud, ou à des data engineers de confiance. Pour offrir aux autres utilisateurs un accès plus granulaire, Databricks recommande d'enregistrer des tables ou des volumes externes au-dessus des emplacements externes et d'accorder aux utilisateurs l'accès aux données à l'aide de volumes ou de tables. Étant donné que les tables et les volumes sont des dépendances d'un catalogue et d'un schéma, les administrateurs de catalogue ou de schéma ont le contrôle ultime sur les autorisations d'accès.

  Vous pouvez également contrôler l'accès à un emplacement externe en le liant à des Workspaces spécifiques. Consultez Attribuer un emplacement externe à des Workspaces spécifiques.

• N'accordez pas de permissions générales READ FILES ou WRITE FILES sur des emplacements externes aux utilisateurs finaux.

  Les utilisateurs ne doivent utiliser les emplacements externes que pour la création de tables, de volumes ou d'emplacements gérés. Ils ne devraient pas utiliser les emplacements externes pour l'accès basé sur le chemin d'accès pour la Data Science ou d'autres cas d'utilisation des données non tabulaires.

  Pour l'accès basé sur le chemin d'accès aux données non tabulaires, utilisez des volumes. L'accès URI cloud aux données sous le chemin du volume est régi par les privilèges accordés sur le volume, et non par les privilèges accordés sur l'emplacement externe où le volume est stocké.

  Les volumes vous permettent de travailler avec des fichiers à l'aide de commandes SQL, de dbutils, d'API Spark, d'API REST, de Terraform, et d'une interface utilisateur pour la navigation, l'upload et le download de fichiers. De plus, les volumes offrent un montage FUSE qui est accessible sur le système de fichiers local sous /Volumes/<catalog_name>/<schema_name>/<volume_name>/. Le montage FUSE permet aux data scientists et aux ingénieurs ML d'accéder aux fichiers comme s'ils se trouvaient dans un système de fichiers local, comme l'exigent de nombreuses bibliothèques de machine learning ou de systèmes d'exploitation.

  Si vous devez accorder un accès direct aux fichiers d'un emplacement externe (pour explorer les fichiers dans le stockage cloud avant qu'un utilisateur ne crée une table ou un volume externe, par exemple), vous pouvez accorder READ FILES. Les cas d'utilisation pour accorder WRITE FILES sont rares.

• Évitez les conflits de chevauchement de chemins : ne créez jamais de volumes externes ou de tables à la racine d'un emplacement externe.

  Si vous créez des volumes externes ou des tables à la racine de l'emplacement externe, vous ne pouvez pas créer de volumes ou de tables externes supplémentaires sur l'emplacement externe. Créez plutôt des volumes externes ou des tables dans un sous-répertoire de l'emplacement externe.

  Si vous rencontrez des conflits de stockage entre les emplacements externes et le stockage Unity Catalog default du Workspace, consultez Résoudre les conflits de chemin de stockage.

• Activez les événements de fichier pour des performances optimales de traitement des fichiers.

  Lorsque les événements de fichier sont activés pour un emplacement externe, Databricks assure le suivi des métadonnées d'ingestion en traitant les notifications de modification des fournisseurs de cloud. Ceci améliore les performances et la fiabilité des fonctionnalités en aval, telles que les file arrival Trigger et l'Auto Loader.

Vous devez utiliser les emplacements externes uniquement pour effectuer les opérations suivantes :

• Enregistrer des tables et des volumes externes à l'aide des commandes CREATE EXTERNAL VOLUME ou CREATE TABLE.
• Enregistrer un emplacement comme espace de stockage géré. Le privilège CREATE MANAGED STORAGE est une précondition.
• Explorez les fichiers existants dans le stockage cloud avant de créer une table ou un volume externe à un préfixe spécifique. Le privilège READ FILES est une condition préalable. Attribuez ce privilège avec parcimonie. Consultez la recommandation dans la liste précédente pour plus de détails.

Emplacements externes vs. volumes externes

Avant la publication des volumes, certaines implémentations de Unity Catalog ont attribué un accès READ FILES directement aux emplacements externes pour l'exploration des données. Avec la disponibilité de volumes qui enregistrent des fichiers dans n'importe quel format, y compris des données structurées, semi-structurées et non structurées, il n'y a pas de véritable raison d'utiliser des emplacements externes pour autre chose que la création de tables, de volumes ou d'emplacements gérés. Pour des informations détaillées sur quand utiliser les emplacements externes et quand utiliser les volumes, consultez Volumes gérés et externes et Emplacements externes.

Partage interrégional et multiplateforme

Vous ne pouvez avoir qu'un seul métastore par région. Si vous souhaitez partager des données entre des Workspace situés dans différentes régions, utilisez OpenSharing Databricks-to-Databricks.

Bonnes pratiques :

• Utilisez votre métastore à région unique pour tous les périmètres du cycle de vie du développement logiciel et toutes les unités commerciales, par exemple, dev, test, prod, Ventes et Marketing. Assurez-vous que le Workspace qui nécessite un accès fréquent aux données partagées est situé dans la même région.
• Utilisez Databricks-to-Databricks OpenSharing entre les régions cloud ou les fournisseurs cloud.
• Utilisez OpenSharing pour les tables rarement consultées, car vous êtes responsable des frais de sortie de données d'une région cloud à l'autre. Si vous devez partager des données fréquemment consultées entre les régions ou les fournisseurs de cloud, voir : Surveiller et gérer les coûts d'extraction OpenSharing (pour les fournisseurs).

Soyez conscient des limitations suivantes lorsque vous utilisez le partage Databricks-to-Databricks :

• Les graphes de lignage sont créés au niveau du metastore et ne dépassent pas les limites des régions ou des plateformes. Cela s'applique même si une ressource est partagée entre les metastores au sein du même compte Databricks : les informations de traçabilité de la source ne sont pas visibles dans la destination, et vice versa.
• Le contrôle d'accès est défini au niveau du métastore et ne franchit pas les limites régionales ou de plate-forme. Si des privilèges sont attribués à une ressource et que cette ressource est partagée avec un autre métastore dans le compte, les privilèges sur cette ressource ne s'appliquent pas au partage de destination. Vous devez accorder des privilèges sur le partage de destination dans la destination.

Configurations de compute

Databricks recommande d'utiliser les stratégies de compute pour limiter la possibilité de configurer des clusters basées sur un ensemble de règles. Les stratégies de compute vous permettent de limiter les utilisateurs à la création de clusters compatibles Unity Catalog, spécifiquement les clusters qui utilisent le mode d'accès standard (anciennement mode d'accès partagé) ou le mode d'accès dédié (anciennement mode d'accès mono-utilisateur ou affecté).

Seuls les clusters qui utilisent l'un de ces modes d'accès peuvent accéder aux données dans Unity Catalog. Tous les computes Serverless et DBSQL prennent en charge Unity Catalog.

Databricks recommande le mode d'accès standard pour toutes les charges de travail. Utilisez le mode d'accès dédié uniquement si la fonctionnalité requise n'est pas prise en charge par le mode d'accès standard. Voir Modes d'accès.