Meilleures pratiques Unity Catalog

Ce document fournit des recommandations sur l’utilisation du catalogue Unity pour répondre aux besoins de gouvernance des données le plus efficacement. Pour une présentation de la gouvernance des données sur Azure Databricks, consultez La gouvernance des données avec Azure Databricks. Pour une présentation du catalogue Unity, consultez Qu’est-ce que le catalogue Unity ?.

Identities

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

Meilleure pratique :

• Évitez l’approvisionnement SCIM au niveau de l’espace de travail (et désactivez tout approvisionnement SCIM existant). L'attribution de rôles principaux directement à un espace de travail doit être réservée aux espaces de travail hérités qui ne sont pas activés pour Unity Catalog. Vous devez gérer entièrement l’approvisionnement au niveau du compte.

• Définissez et gérez des groupes dans votre IdP. Elles doivent être cohérentes avec les définitions de votre groupe d’organisation.

  Les groupes se comportent différemment des utilisateurs et des principaux de service. Bien que les utilisateurs et les principaux de service que vous ajoutez à un espace de travail soient automatiquement synchronisés avec votre compte Azure Databricksaccount, les groupes au niveau de l’espace de travail ne le sont pas. Si vous avez des groupes locaux d’espace de travail, 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 approvisionnant sur le compte.

• Configurez des groupes pour pouvoir les utiliser efficacement pour accorder l’accès aux données et à d’autres éléments sécurisables du catalogue Unity. Évitez les subventions directes aux utilisateurs dans la mesure du possible.

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

• Évitez d’ajouter manuellement des utilisateurs au compte ou à l’espace de travail. Évitez de modifier des groupes dans Azure Databricks : utilisez votre IdP.

• Utilisez des principaux de service pour exécuter des tâches. Les principaux de service activent l’automatisation des tâches. Si vous faites appel à des utilisateurs pour exécuter des travaux qui écrivent dans l’environnement de production, vous risquez de remplacer les données de production par inadvertance.

Pour plus d’informations, consultez Gérer les utilisateurs, les principaux de service et les groupes etsynchroniser des utilisateurs et des groupes à partir de Microsoft Entra ID à 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 nécessite des soins :

• Comprendre les privilèges des administrateurs de compte, des administrateurs d’espace de travail et des administrateurs de metastore avant de les affecter. Consultez Privilèges d’administrateur dans Unity Catalog.
• Attribuez ces rôles à des groupes dans la mesure du possible.
• Les administrateurs de metastore sont facultatifs. Attribuez-les uniquement si vous en avez besoin. Pour obtenir des conseils, consultez (Facultatif) Attribuer le rôle d’administrateur du metastore.
• Affectez la propriété d’objet aux groupes, en particulier si les objets sont utilisés en production. Le créateur de n’importe quel objet est son premier propriétaire. Les créateurs doivent réaffecter la propriété à des groupes appropriés.
• Seuls les administrateurs de metastore, les propriétaires et les utilisateurs disposant du MANAGE privilège sur un objet peuvent accorder des privilèges sur cet objet. Les propriétaires de catalogues et de 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’affectation de la propriété et du privilège MANAGE.
• Soyez parcimonieux dans votre affectation de ALL PRIVILEGES, qui inclut tous les privilèges à l’exception de MANAGE.

Affectation 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ège efficace.

Meilleure pratique :

• Comprendre la différence entre USE CATALOG (ou USE SCHEMA) et BROWSE:

  • USE CATALOG | SCHEMA accorde la possibilité d’afficher les données dans le catalogue ou le schéma. Seuls, ces privilèges n’accordent pas SELECT ou READ aux objets du catalogue ou du schéma, mais ils sont requis pour accorder cet accès aux utilisateurs. Accordez ces privilèges uniquement aux utilisateurs qui doivent être en mesure d’afficher 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) aux utilisateurs qui ne doivent pas 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).
  • BROWSE peut être accordé largement au niveau du catalogue pour permettre aux utilisateurs d’afficher les métadonnées associées aux objets du catalogue.

• Comprendre la différence entre la propriété de l’objet et le MANAGE privilège :

  • 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é vers d’autres principaux.
  • Les propriétaires peuvent accorder le privilège MANAGE de déléguer des droits de propriété sur un objet à d’autres entités.
  • Les propriétaires de catalogue et de schéma 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 MANAGE privilège sur tous les objets à un groupe responsable de l’administration des subventions sur l’objet.

• Réservez un accès direct MODIFY aux tables de production pour les principaux de service.

Pour plus d’informations, consultez Gérer les privilèges dans le catalogue Unity.

Magasins de métadonnées

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

• Vous ne pouvez avoir qu’un seul metastore par région. Tous les espaces de travail de cette région partagent ce metastore. Pour partager des données entre des régions, consultez le partage interrégion et multiplateforme.

• Les metastores fournissent une isolation régionale, mais ne sont pas prévus comme unités par défaut d’isolation des données. L’isolation des données commence généralement au niveau du catalogue. Toutefois, si vous préférez un modèle de gouvernance plus centralisé, vous pouvez créer un stockage managé au niveau du metastore. Pour obtenir des recommandations, consultez Stockage managé.

• Le rôle d’administrateur du metastore est facultatif. Pour obtenir des recommandations sur l’affectation d’un administrateur de metastore facultatif, consultez les rôles d’administrateur et les privilèges puissants.

Importante

N’inscrivez pas les tables fréquemment sollicitées en tant que tables externes dans plusieurs metastores. Si vous le faites, les modifications apportées au schéma, aux propriétés de table, aux commentaires et à d’autres métadonnées qui se produisent à la suite d’écritures dans le metastore A ne s’inscrivent pas du tout auprès du metastore B. Vous pouvez également provoquer des problèmes de cohérence avec le service de validation Azure 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 classique. Les schémas ajoutent une couche supplémentaire d’organisation.

Bonnes pratiques pour l’utilisation du catalogue et du schéma :

• Organisez les données et les objets IA dans des catalogues et des schémas qui reflètent les divisions et projets organisationnels. Cela signifie souvent que les catalogues correspondent à une étendue d’environnement, une équipe, une unité commerciale ou une combinaison de celles-ci. Cela facilite l’utilisation de la hiérarchie de privilèges pour gérer efficacement l’accès.
• Lorsque les environnements de travail et les données ont les mêmes exigences d’isolation, vous pouvez lier un catalogue à un espace de travail spécifique. Lorsque cela est nécessaire, créez des catalogues qui peuvent être étendus à un ensemble limité d’espaces de travail.
• Attribuez toujours la propriété des catalogues de production et des schémas à des groupes, et non à des utilisateurs individuels.
• Accordez USE CATALOG et USE SCHEMA uniquement aux utilisateurs qui doivent être en mesure de voir ou d’interroger les données contenues dans ces données.

Pour plus d’informations sur l’octroi de privilèges sur les catalogues et les schémas, consultez Affectation de privilèges.

Stockage managé

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

Bonnes pratiques pour les emplacements de stockage managé :

• 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 a été requis dans les environnements de catalogue Unity précoces, mais il n’est plus nécessaire.

• Si vous choisissez de créer un emplacement managé au niveau du metastore, utilisez un conteneur dédié.

• N’utilisez pas de conteneur accessible en dehors du catalogue Unity.

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

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

• Si vous avez des charges de travail gourmandes en stockage, n’utilisez pas de compte de stockage et de conteneur unique pour le stockage managé et d’autres emplacements externes.

  re :[ADLS] comptes prennent en charge 20 000 requêtes par seconde par défaut. Cela peut entraîner une limitation et un ralentissement de la charge de travail. L’utilisation de plusieurs conteneurs dans le même compte de stockage ne modifie pas cette limite à l’échelle du compte. Vous devez donc répartir le stockage entre plusieurs comptes de stockage.

  Ces bandes seraient invisibles pour les utilisateurs finaux d’Unity Catalog.

Tables managées et externes

Les tables managées sont entièrement géré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 managée. Elles sont systématiquement au format Delta ou Apache Iceberg.

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. Lorsque vous créez une table externe dans Azure Databricks, vous spécifiez son emplacement, qui doit se trouver sur un chemin défini dans un emplacement externe du catalogue Unity.

Utilisez des tables managées :

• Pour la plupart des cas d’utilisation. Databricks recommande des tables et des volumes managés, car elles vous permettent de tirer pleinement parti des fonctionnalités de gouvernance du catalogue Unity et des optimisations des performances, notamment :

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

  La nouvelle fonctionnalité Azure Databricks donne priorité aux tables managées.

• Pour toutes les nouvelles tables.

Utilisez des tables externes :

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

  • L’utilisation de tables externes peut fournir une mise à niveau rapide et transparente sans déplacer de données.
  • Databricks recommande de migrer des tables externes vers des tables managées.

• Si vous avez des exigences de récupération d’urgence pour ces données qui ne peuvent pas être remplies par des tables managées.

  Les tables managées ne peuvent pas être inscrites sur plusieurs metastores dans le même cloud.

• Si des lecteurs ou des enregistreurs externes doivent être en mesure d’interagir avec les données en dehors de Databricks.

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

• Vous devez prendre en charge des tables non Delta ou non Iceberg, telles que Parquet, Avro, ORC, etc.

Autres recommandations pour l’utilisation de tables externes :

• Databricks vous recommande de créer des tables externes en utilisant un emplacement externe par schéma.
• Databricks recommande vivement de ne pas inscrire de tables courantes en tant que tables externes dans plusieurs metastores au risque d'entraîner des problèmes de cohérence. Par exemple, une modification du schéma dans un metastore ne s’inscrit pas dans le deuxième metastore. Utilisez Delta Sharing pour partager des données entre des metastores. Consultez le partage interrégion et multiplateforme.

Consultez également Présentation des tables Azure Databricks.

Volumes managés et externes

Les volumes managés sont entièrement géré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 de cloud. Les volumes externes représentent des données existantes dans des emplacements de stockage gérés en dehors d’Azure Databricks, mais inscrits dans Unity Catalog pour contrôler et auditer l’accès à partir d’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 dans un emplacement externe du catalogue Unity.

Utilisez des volumes managés :

• Pour la plupart des cas d’usage, tirez pleinement parti des fonctionnalités de gouvernance du catalogue Unity.
• Si vous souhaitez créer des tables à partir de fichiers d’un volume sans exécuter COPY INTO ou exécuter des instructions CTAS (CREATE TABLE AS).

Utilisez des volumes externes :

• Pour enregistrer des zones d’atterrissage pour les données brutes produites par des systèmes externes afin de faciliter leur traitement dans les premières phases des pipelines ETL et d'autres activités d'ingénierie des données.
• Pour inscrire des emplacements intermédiaires pour l’ingestion, par exemple, à l’aide d’un chargeur automatique, de COPY INTO ou d’instructions CTAS.
• Fournissez aux scientifiques des données, aux analystes de données et aux ingénieurs d’apprentissage automatique des emplacements de stockage de fichiers à utiliser dans le cadre de leurs analyses exploratoires des données et d’autres tâches de science des données, lorsque les volumes gérés ne sont pas disponibles.
• Pour permettre aux utilisateurs d’Azure Databricks d’accéder à des 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 roue Python) exportées à partir de systèmes de gestion des dépendances locaux ou de pipelines CI/CD.
• Pour stocker des données opérationnelles, comme la journalisation des fichiers ou les points de contrôle, lorsque les volumes gérés ne sont pas disponibles.

Autres recommandations pour l’utilisation de volumes externes :

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

Conseil

Pour les cas d’usage d’ingestion dans lesquels les données sont copiées vers un autre emplacement (par exemple, à l’aide du chargeur automatique ou COPY INTO), utilisez des volumes externes. Utilisez des tables externes lorsque vous souhaitez interroger des données en place sous forme table, sans aucune copie.

Consultez également Volumes managés vs. volumes externes et Emplacements externes.

Emplacements externes

Les objets sécurisables de localisation externe, en combinant les informations d’identification de stockage et les chemins de stockage, assurent un contrôle strict et une auditabilité de l’accès au stockage. Il est important d’empêcher les utilisateurs d’accéder directement aux conteneurs inscrits en tant qu’emplacements externes, en contournant le contrôle d’accès fourni par le catalogue Unity.

Pour utiliser efficacement des emplacements externes :

• Veillez à limiter le nombre d’utilisateurs disposant d’un accès direct à n’importe quel conteneur utilisé comme emplacement externe.

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

• Accordez la possibilité de créer des emplacements externes uniquement aux administrateurs qui sont chargés de configurer des connexions entre le catalogue Unity et le stockage cloud, ou aux ingénieurs de données approuvés.

  Les emplacements externes fournissent un accès à partir du catalogue Unity à un emplacement largement englobant dans le stockage cloud, par exemple, un compartiment ou un conteneur entier (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net) ou un sous-chemin large (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog). L’objectif est qu’un administrateur cloud puisse être impliqué dans la configuration de quelques emplacements externes, puis délègue la responsabilité de la gestion de ces emplacements à un administrateur Azure Databricks au sein de votre organisation. L’administrateur Azure Databricks peut ensuite organiser l’emplacement externe en zones disposant d’autorisations plus précises en inscrivant des volumes externes ou des tables externes avec des préfixes spécifiques sous l’emplacement externe.

  Étant donné que les emplacements externes sont très englobants, Databricks recommande d’accorder l’autorisation CREATE EXTERNAL LOCATION uniquement à un administrateur chargé de configurer les connexions entre Unity Catalog et le stockage cloud, ou à des ingénieurs données de confiance. Pour fournir à d’autres utilisateurs un accès plus granulaire, Databricks recommande d’inscrire 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 les enfants d’un catalogue et d’un schéma, les administrateurs de catalogues ou de schémas ont le contrôle total sur les autorisations d’accès.

  Vous pouvez également contrôler l’accès à un emplacement externe en le liant à des espaces de travail spécifiques. Voir (Facultatif) Affecter un emplacement externe à des espaces de travail spécifiques.

• N’accordez pas d’autorisations générales READ FILES ou WRITE FILES sur des emplacements externes aux utilisateurs finaux.

  Les utilisateurs ne doivent pas utiliser d’emplacements externes pour quoi que ce soit, mais créer des tables, des volumes ou des emplacements managés. Les emplacements externes ne doivent pas être utilisés pour l’accès basé sur le chemin d’accès en science des données ou dans d’autres cas d’utilisation de données non tabulaires.

  Pour l’accès basé sur le chemin à des données non tabulaires, utilisez des volumes. L’accès aux données Cloud URI sous le chemin du volume est régi par les privilèges accordés sur le volume, plutôt que par les privilèges accordés sur l’emplacement externe où le volume est stocké.

  Les volumes vous permettent d’utiliser 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, le chargement et le téléchargement de fichiers. En outre, les volumes offrent un montage FUSE accessible sur le système de fichiers local sous /Volumes/<catalog_name>/<schema_name>/<volume_name>/. Le montage FUSE permet aux scientifiques des données et aux ingénieurs ML d’accéder aux fichiers comme s’ils se trouvaient dans un système de fichiers local, comme exigé par de nombreuses bibliothèques d’apprentissage automatique ou de système d’exploitation.

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

• Évitez les conflits de chevauchement de chemin d’accès : ne créez jamais de volumes ou de tables externes à 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 d’autres volumes externes ou tables sur l’emplacement externe. Au lieu de cela, créez des volumes ou des tables externes dans un sous-répertoire situé à l’intérieur de l’emplacement externe.

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

• Inscrivez des tables et des volumes externes à l’aide des commandes CREATE EXTERNAL VOLUME ou CREATE TABLE.
• Inscrivez un emplacement en tant que stockage managé. Le privilège CREATE MANAGED STORAGE est une condition préalable.
• Explorez les fichiers existants dans le stockage cloud avant de créer une table ou un volume externe avec un préfixe spécifique. Le privilège READ FILES est une condition préalable. Attribuez ce privilège de manière éparse. Pour plus d’informations, consultez la recommandation de la liste précédente.

Emplacements externes et volumes externes

Avant la publication des volumes, certaines implémentations de Unity Catalog ont affecté l’accès READ FILES directement aux emplacements externes pour l’exploration des données. Avec la disponibilité des volumes qui inscrivent des fichiers dans n’importe quel format, y compris les données structurées, semi-structurées et non structurées, il n’existe aucune raison réelle d’utiliser des emplacements externes pour tout ce qui concerne la création de tables, de volumes ou d’emplacements managés. Pour plus d’informations sur le moment où utiliser des emplacements externes et quand utiliser des volumes, consultez Les volumes managés et externes et les emplacements externes.

Partage entre régions et entre plateformes

Vous ne pouvez avoir qu’un seul metastore par région. Si vous souhaitez partager des données entre des espaces de travail sur différentes régions, utilisez databricks-to-Databricks Delta Sharing.

Meilleure pratique :

• Utilisez votre metastore à région unique pour toutes les étendues de cycle de vie de développement de logiciels et toutes les unités commerciales, par exemple, dev, test, prod, sales et marketing. Vérifiez que les espaces de travail qui nécessitent un accès fréquent aux données partagées se trouvent dans la même région.
• Utilisez Databricks-to-Databricks Delta Sharing entre les régions cloud ou les fournisseurs de cloud.
• Utilisez le partage Delta pour les tables rarement sollicitées, car vous êtes responsable des frais de sortie de région cloud en région cloud. Si vous devez partager des données fréquemment sollicitées entre des régions ou des fournisseurs de cloud, consultez : Surveiller et gérer les coûts de sortie des données Delta Sharing (pour les fournisseurs).

Tenez compte 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 de région ou de plateforme. 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 metastore et ne dépasse pas les limites de région ou de plateforme. Si une ressource a des privilèges qui lui sont attribués et que cette ressource est partagée avec un autre metastore dans le compte, les privilèges de 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 calcul

Databricks recommande d’utiliser des stratégies de calcul pour limiter la possibilité de configurer des clusters en fonction d’un ensemble de règles. Les stratégies de calcul vous permettent de limiter les utilisateurs à la création de clusters avec catalogue Unity, en particulier 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 mono-utilisateur ou mode d’accès affecté).

Seuls les clusters qui utilisent l’un de ces modes d’accès peuvent accéder aux données dans Le catalogue Unity. Tous les calculs serverless et le calcul 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 vos fonctionnalités requises ne sont pas prises en charge par le mode d’accès standard. Consultez les modes d’accès.