Phase 3 : Conception de l'architecture Unity Catalog

Dans cette phase, vous concevez l'infrastructure Unity Catalog pour prendre en charge la gouvernance des données, le contrôle d'accès et l'organisation des données.

Unity Catalog est activé automatiquement sur les workspaces des comptes Databricks créés après le 8 novembre 2023. Pour ces comptes, un metastore est automatiquement créé et attribué aux espaces de travail.

Pour des directives exhaustives sur Unity Catalog, y compris les étapes de mise en œuvre et les fonctionnalités avancées, consultez Qu'est-ce que Unity Catalog ?

Choisissez un modèle opérationnel de gouvernance

Avant de concevoir votre architecture Unity Catalog, sélectionnez un modèle opérationnel de gouvernance qui correspond à votre structure organisationnelle et à votre culture des données. Le modèle de gouvernance détermine comment la propriété des données, le contrôle d'accès et l'application des politiques sont gérés au sein de votre organisation.

Options du modèle de gouvernance

• Gouvernance centralisée : Chaque unité commerciale ou domaine opère dans une limite commerciale différente, mais toutes les unités relèvent de la même limite opérationnelle qui régit tous les assets de données et d'IA (multi-location). Une plateforme unique ou une équipe de gouvernance des données contrôle tous les assets de données, les politiques et les accès.

  

• Gouvernance décentralisée : Chaque unité commerciale ou domaine possède une frontière commerciale et opérationnelle indépendante (ce qui signifie qu'il a son propre tenant). La gouvernance est déléguée à chaque unité commerciale afin qu'elle définisse et applique ses propres politiques de manière indépendante avec une supervision centrale minimale.

  

• Gouvernance fédérée : chaque unité commerciale ou domaine a une frontière commerciale et opérationnelle indépendante. Cependant, les politiques de gouvernance sont définies par un bureau de gouvernance centralisé et appliquées par chaque unité commerciale. Les assets critiques sont régis par le bureau de la gouvernance (par exemple, les produits de données partagés).

  

• Gouvernance hybride : un modèle entre centralisé et décentralisé, permettant à chaque unité commerciale ou domaine de gouverner ses propres données (décentralisé). Cependant, les données commerciales critiques sont collectées et régies en un seul endroit pour être utilisées par tous (centralisées).

  

Bonnes pratiques pour les modèles de gouvernance

• Start par la gouvernance fédérée pour la plupart des organisations (équilibre entre contrôle et agilité).
• Utilisez une gouvernance centralisée pour les secteurs d'activité fortement réglementés (par exemple, la finance, la santé, le gouvernement).
• Documentez clairement les rôles et les responsabilités pour chaque modèle de gouvernance.
• Alignez le modèle de gouvernance avec les structures organisationnelles existantes.
• Examinez et ajustez le modèle de gouvernance à mesure que votre plateforme de données évolue.

	Gouvernance centralisée	Gouvernance décentralisée	Gouvernance fédérée	Gouvernance hybride
Définition	Une seule autorité centrale contrôle toutes les politiques de données et d'IA au sein de l'organisation.	Chaque unité commerciale gère de manière indépendante ses propres politiques de données et d'IA.	Les équipes centrales définissent des directives et des normes, tandis que les équipes locales ont l'autonomie de les mettre en œuvre.	Les données et politiques essentielles sont gérées de manière centralisée, tandis que les unités commerciales contrôlent leurs données et politiques spécifiques à leur domaine.
Prise de décision	Toutes les décisions passent par une équipe centrale en utilisant une approche descendante.	Les unités commerciales prennent des décisions de manière indépendante sans coordination centrale.	Les équipes centrales établissent des lignes directrices, et les équipes locales prennent des décisions dans ces limites.	Les équipes centrales prennent des décisions pour les données et l'infrastructure essentielles. Les unités commerciales prennent leurs propres décisions pour les besoins spécifiques au domaine.
Propriété des données	Une équipe centrale détient et gère tous les assets de données.	Les équipes ou les unités commerciales individuelles possèdent leurs données sans gouvernance partagée.	Plusieurs équipes partagent les responsabilités de propriété au sein de l'organisation.	Les équipes centrales possèdent les données partagées essentielles. Les unités commerciales sont propriétaires de leurs données spécifiques au domaine.
Évolutivité	La mise à l'échelle dépend de la capacité de l'équipe centrale et peut devenir un goulot d'étranglement à mesure que l'organisation se développe.	Les unités commerciales peuvent monter en charge indépendamment, mais la coordination entre les équipes peut être difficile.	Les organisations peuvent monter en charge tout en maintenant la coordination grâce à des structures de gouvernance établies.	Les données principales montent en charge avec les ressources centrales. Les unités commerciales montent en charge de manière indépendante pour leurs domaines.
Conformité et sécurité	Les politiques sont appliquées de manière cohérente dans toute l'organisation avec une surveillance centrale rigoureuse.	L'application varie selon les équipes, ce qui peut entraîner des lacunes de sécurité et des pratiques incohérentes.	Les équipes centrales définissent les normes de sécurité et les équipes locales les appliquent au sein de leurs domaines.	Les données de base suivent des règles de conformité strictes. Les unités commerciales disposent d'une flexibilité pour les exigences spécifiques au domaine.
Efficacité opérationnelle	Les opérations sont efficaces, mais peuvent être ralenties par les processus bureaucratiques et les chaînes d'approbation.	Les équipes travaillent rapidement et s'adaptent facilement, mais les efforts peuvent être dupliqués et des silos peuvent se former.	Les organisations équilibrent l'efficacité et la flexibilité, bien qu'une coordination excessive puisse ralentir la prise de décision.	Les opérations principales peuvent présenter des goulets d'étranglement. Les unités commerciales fonctionnent efficacement dans leurs domaines.
Pertinence des cas d'usage	Idéal pour les secteurs d’activité hautement réglementés comme la finance et la santé, qui nécessitent une surveillance stricte.	Idéal pour les entreprises agiles, les startups et les organisations axées sur l'innovation qui privilégient la vitesse.	Idéal pour les grandes entreprises et les sociétés multinationales qui ont besoin à la fois de normes centrales et de flexibilité locale.	Idéal pour les organisations ayant des besoins variés, telles que les entreprises de technologie financière qui équilibrent les exigences de conformité et l'innovation.

	Gouvernance centralisée	Gouvernance décentralisée	Gouvernance fédérée	Gouvernance hybride
Définition	Une seule autorité centrale contrôle toutes les politiques de données et d'IA au sein de l'organisation.	Chaque unité commerciale gère de manière indépendante ses propres politiques de données et d'IA.	Les équipes centrales définissent des directives et des normes, tandis que les équipes locales ont l'autonomie de les mettre en œuvre.	Les données et politiques essentielles sont gérées de manière centralisée, tandis que les unités commerciales contrôlent leurs données et politiques spécifiques à leur domaine.
Prise de décision	Toutes les décisions passent par une équipe centrale en utilisant une approche descendante.	Les unités commerciales prennent des décisions de manière indépendante sans coordination centrale.	Les équipes centrales établissent des lignes directrices, et les équipes locales prennent des décisions dans ces limites.	Les équipes centrales prennent des décisions pour les données et l'infrastructure essentielles. Les unités commerciales prennent leurs propres décisions pour les besoins spécifiques au domaine.
Propriété des données	Une équipe centrale détient et gère tous les assets de données.	Les équipes ou les unités commerciales individuelles possèdent leurs données sans gouvernance partagée.	Plusieurs équipes partagent les responsabilités de propriété au sein de l'organisation.	Les équipes centrales possèdent les données partagées essentielles. Les unités commerciales sont propriétaires de leurs données spécifiques au domaine.
Évolutivité	La mise à l'échelle dépend de la capacité de l'équipe centrale et peut devenir un goulot d'étranglement à mesure que l'organisation se développe.	Les unités commerciales peuvent monter en charge indépendamment, mais la coordination entre les équipes peut être difficile.	Les organisations peuvent monter en charge tout en maintenant la coordination grâce à des structures de gouvernance établies.	Les données principales montent en charge avec les ressources centrales. Les unités commerciales montent en charge de manière indépendante pour leurs domaines.
Conformité et sécurité	Les politiques sont appliquées de manière cohérente dans toute l'organisation avec une surveillance centrale rigoureuse.	L'application varie selon les équipes, ce qui peut entraîner des lacunes de sécurité et des pratiques incohérentes.	Les équipes centrales définissent les normes de sécurité et les équipes locales les appliquent au sein de leurs domaines.	Les données de base suivent des règles de conformité strictes. Les unités commerciales disposent d'une flexibilité pour les exigences spécifiques au domaine.
Efficacité opérationnelle	Les opérations sont efficaces, mais peuvent être ralenties par les processus bureaucratiques et les chaînes d'approbation.	Les équipes travaillent rapidement et s'adaptent facilement, mais les efforts peuvent être dupliqués et des silos peuvent se former.	Les organisations équilibrent l'efficacité et la flexibilité, bien qu'une coordination excessive puisse ralentir la prise de décision.	Les opérations principales peuvent présenter des goulets d'étranglement. Les unités commerciales fonctionnent efficacement dans leurs domaines.
Pertinence des cas d'usage	Idéal pour les secteurs d’activité hautement réglementés comme la finance et la santé, qui nécessitent une surveillance stricte.	Idéal pour les entreprises agiles, les startups et les organisations axées sur l'innovation qui privilégient la vitesse.	Idéal pour les grandes entreprises et les sociétés multinationales qui ont besoin à la fois de normes centrales et de flexibilité locale.	Idéal pour les organisations ayant des besoins variés, telles que les entreprises de technologie financière qui équilibrent les exigences de conformité et l'innovation.

Votre choix de modèle opérationnel de gouvernance a une incidence sur la conception de votre métastore. Dans un modèle centralisé, vous pouvez attribuer un administrateur de métastore unique. Dans un modèle décentralisé, gérez les autorisations par le biais de pipelines de déploiement automatisés (à l'aide d'outils CI/CD tels que Terraform) plutôt que de déléguer à des administrateurs d'unités commerciales ou d'environnements individuels.

Concevoir l'architecture du metastore

Un métastore Unity Catalog est le conteneur régional de niveau supérieur pour les métadonnées et la gouvernance. Chaque métastore stocke les métadonnées des objets sécurisables (par exemple, les tables, les vues, les volumes, les emplacements externes, les partages) et les autorisations qui régissent leur accès. Le métastore est hébergé en tant que service multi-tenant dans le plan de contrôle Databricks.

Unity Catalog n'autorise qu'un seul métastore par région et vous permet de l'utiliser uniquement dans sa région assignée. Chaque workspace doit être affecté à un seul métastore.

Rôle d’administrateur du metastore

Un metastore peut être configuré en option avec un administrateur de metastore, selon votre modèle de gouvernance. Ce rôle n'est pas défini en cas d'activation automatique de Unity Catalog. Le rôle d'administrateur du métastore est requis si vous souhaitez gérer le stockage des objets Unity Catalog au niveau du métastore, et il est pratique si vous souhaitez gérer les données de manière centralisée sur plusieurs workspaces dans une région.

• Dans un **modèle centralisé**, attribuez un administrateur de métastore unique ou un groupe désigné.
• Dans un modèle décentralisé , gérez les autorisations via des pipelines de déploiement automatisés plutôt que de déléguer à des administrateurs individuels.

Si vous utilisez un administrateur de metastore, il est fortement recommandé d'attribuer le rôle à un groupe désigné plutôt qu'à un utilisateur unique.

Mécanismes d’isolement

Pour prendre en charge la ségrégation de niveau entreprise pour des raisons de sécurité ou d'organisation, Unity Catalog prend en charge l'isolation à plusieurs niveaux :

• Isolation administrative (délégation de la gestion) : Les données doivent être gérées par des personnes ou des équipes désignées, en fonction de l'objectif ou de la propriété de ces données.

• Liaison de workspace : les données ne doivent être consultées que dans des environnements désignés, en fonction de l’objectif de ces données.

  • Un catalogue (ou un autre objet Unity Catalog) peut être lié à plusieurs Workspace.
  • Un Workspace peut être lié à plusieurs catalogues, identifiants et emplacements externes du même métastore.

• Isolation du stockage : Les données doivent être physiquement séparées dans le stockage.

• Contrôle d'accès Unity Catalog : les utilisateurs ne devraient avoir accès aux données ou aux métadonnées que sur la base des règles d'accès convenues.

Utilisez ces mécanismes d'isolation pour séparer les workloads, les équipes ou les unités commerciales dans un seul métastore par région.

Modèles de conception de Metastore

Déploiement en un seul cloud, une seule région.

Pour les organisations opérant dans une seule région cloud, déployez un métastore dans cette région. Tous les workspaces de la région sont attribués à ce métastore.

Déploiement mono-cloud, multi-région

Pour les organisations opérant dans plusieurs régions du même cloud, déployez un métastore par région. Chaque workspace est attribué au métastore de sa région. Utilisez OpenSharing géré par Databricks (D2D) pour partager des données entre métastores dans différentes régions.

Déploiement multi-cloud et multi-régions

Pour les organisations opérant sur plusieurs fournisseurs et régions de cloud, déployez un métastore par région dans chaque cloud. Utilisez OpenSharing géré par Databricks (D2D) pour partager des données entre les metastores dans les clouds et les régions.

Modèles alternatifs

• Un metastore par unité commerciale : Approprié lorsque les unités commerciales nécessitent une isolation complète sans Data Sharing.
• Un métastore par environnement : Modèle moins courant où les environnements de développement, de préproduction et de production utilisent des métastores distincts pour une isolation stricte de l'environnement.

Considérations relatives à la conception multirégionale

Si plusieurs régions utilisent Databricks, un seul métastore Unity Catalog doit être déployé dans chaque région. Les utilisateurs peuvent travailler avec le métastore dans la même région que le workspace auquel ils sont connectés. Pour accéder aux données définies dans un métastore d'une autre région, OpenSharing géré par Databricks (D2D) est recommandé.

attention

N'enregistrez pas les tables partagées en tant que tables externes dans plusieurs metastores. Le risque est que toute modification apportée au schéma, aux propriétés de table et aux commentaires résultant d'écritures dans le metastore A ne soit pas du tout enregistrée dans le metastore B. Les tables du metastore B devraient être recréées pour avoir le bon schéma, et les propriétés de table ainsi que les commentaires seraient entièrement déconnectés. Cela peut également entraîner des problèmes de cohérence avec le service Delta Commit. Utilisez D2D OpenSharing pour le partage de données entre les metastores.

Bonnes pratiques pour la conception multirégion

• Déployez un métastore par région comme modèle default.
• Utilisez OpenSharing géré par Databricks pour partager des tables entre les régions.
• Évaluez la fréquence et le volume d'accès aux données dans les régions cloud. Si le coût devient trop élevé, envisagez de configurer un pipeline pour synchroniser les tables entre les régions.
• Pour les configurations interrégionales, stockez le stockage racine du métastore dans la même région que le métastore pour des raisons de performance.

Meilleures pratiques pour la conception de metastores

• Utilisez un métastore par région comme modèle par default pour la simplicité opérationnelle.
• Attribuez les Workspace de la même région au même métastore.
• Utilisez les catalogues au sein d'un métastore pour séparer les données par environnement ou par domaine.
• Créez un Workspace administratif par région pour la gestion des Ressources Unity Catalog.
• Documentez les attributions de metastore et les limites régionales dans votre runbook.

Pour les nouveaux comptes créés après le 8 novembre 2023, les metastores sont automatiquement créés et attribués.

Pour des informations détaillées sur l’architecture de stockage de Unity Catalog, y compris les objets gérés, externes et étrangers, consultez Phase 4 : Concevoir l’architecture de stockage.

Concevoir la structure du catalogue

Les catalogues constituent la première couche d'organisation au sein d'un métastore. Ils contiennent des schémas, qui contiennent des tables, des vues, des volumes et des fonctions. La conception de votre catalogue détermine la manière dont les assets de données sont organisés et accessibles.

Modèles de conception de catalogue

Catalogues basés sur l'environnement

Catalogues distincts pour les environnements de cycle de vie du développement logiciel (SDLC) tels que le développement, la préproduction et la production (par exemple, dev, staging, prod). Ce modèle prend en charge les flux de travail de promotion d'environnement et empêche les modifications accidentelles en production.

Isolez les environnements au niveau du catalogue de l'espace de noms à 3 niveaux que fournit Unity Catalog :

• dev Le catalogue couvre les emplacements des données de développement.
• prod Le catalogue couvre les emplacements des données de production.
• Les catalogues peuvent être des combinaisons de noms d'unités SDLC et commerciales ou organisationnelles, par exemple : sales_dev, sales_prod, engineering_dev

Catalogues par domaine

Des catalogues distincts pour les domaines d'activité ou les unités organisationnelles (par exemple, sales, marketing, finance, engineering). Ce modèle s'aligne avec les architectures data mesh et la propriété de domaine.

Catalogues hybrides

Combine des modèles d'environnement et de domaine (par exemple, sales_prod, sales_dev, finance_prod, finance_dev). Cela garantit à la fois l'isolation et une propriété claire.

Catalogues du cycle de vie des données

Catalogues distincts pour différentes étapes de maturité des données (par exemple, raw, curated, analytics). Ce modèle suit les principes de l'Architecture en médaillon au niveau du catalogue.

Zones de sandbox et de développement

De nombreuses équipes ont besoin de zones de sandbox pour créer des datasets temporaires pour une utilisation interne. Fournissez aux individus ou aux équipes leurs propres schémas de sandbox où ils peuvent ajouter des tables, mais ne peuvent pas partager avec quiconque en dehors de leur équipe car ils ne possèdent pas le schéma et le catalogue conteneurs.

Conventions de nommage du catalogue

Choisissez une convention de nommage pour vos catalogues qui s'aligne sur certaines configurations, par exemple, par environnement de cycle de vie de développement logiciel (Dev, Test, Prod), par couche médaillon (Bronze, Silver, Gold) ou par unité commerciale (Billing, Customer, Ventes). Les conventions de nommage exactes doivent être définies par votre équipe d'architecture.

Bonnes pratiques pour la conception de catalogues

• Utilisez les catalogues basés sur l’environnement default pour la plupart des organisations.
• Utilisez des catalogues basés sur des domaines pour les modèles de data mesh ou de gouvernance fédérée.
• Limitez le nombre de catalogues afin de réduire la surcharge administrative (généralement de 3 à 10 par métastore).
• Utilisez des conventions de nommage cohérentes dans tous les catalogues.
• Documentez les objectifs du catalogue et la propriété des données dans les commentaires du catalogue.
• Utilisez les octrois de catalogue pour contrôler qui peut créer des schémas et des tables au sein de chaque catalogue.
• Évitez de créer des catalogues distincts pour des équipes ou des projets individuels (utilisez plutôt des schémas).

Concevez une stratégie de gestion des informations d'identification de stockage

Les informations d'identification de stockage sont des objets d'authentification qui permettent à Unity Catalog d'accéder au stockage cloud au nom des utilisateurs. Elles constituent un moyen sécurisé d'accorder à Databricks l'accès au stockage cloud géré par le client sans partager les identifiants à long terme avec les utilisateurs finaux.

Lorsque des identifiants de stockage sont requis

• Création d'emplacements externes qui pointent vers le stockage cloud (par exemple, S3, ADLS Gen2, GCS).
• Accès au stockage géré par le client pour les tables externes et les volumes.
• Lecture de données à partir du stockage cloud qui n'est pas géré par Unity Catalog.

Lorsque les identifiants de stockage ne sont pas requis.

• Accès aux tables et volumes gérés par Unity Catalog (stockage géré par Databricks).
• Utilisation du stockage par default dans les Workspaces Serverless.

Architecture des identifiants de stockage AWS

Les informations d'identification de stockage AWS utilisent des rôles IAM inter-comptes avec des politiques d'approbation qui permettent à Databricks d'assumer le rôle. Le rôle IAM doit avoir des stratégies accordant des autorisations S3 (par exemple, s3:GetObject, s3:PutObject, s3:ListBucket) à des compartiments ou préfixes S3 spécifiques.

Le flux d'authentification :

1. Unity Catalog assume le rôle IAM à l'aide de la relation d'approbation
2. AWS valide la politique de confiance et renvoie des identifiants temporaires
3. Unity Catalog utilise des identifiants temporaires pour accéder à S3 au nom de l'utilisateur.
4. L'accès est accordé ou refusé en fonction des politiques IAM attachées au rôle.

Modèles de conception d'identifiants de stockage

• Utilisez des rôles IAM distincts pour différents compartiments de stockage ou domaines de données (par exemple, uc-prod-sales-role, uc-dev-engineering-role).
• Appliquer les autorisations du moindre privilège (n'accorder l'accès qu'à des préfixes S3 spécifiques).
• Créez un identifiant de stockage par environnement (par exemple, dev, staging, production).
• Créez un identifiant de stockage par unité commerciale lorsque la ségrégation des données est requise.

Bonnes pratiques pour les identifiants de stockage AWS

• Utilisez des rôles IAM distincts pour différents compartiments de stockage ou domaines de données.
• Appliquer les autorisations du moindre privilège (n'accorder l'accès qu'à des préfixes S3 spécifiques).
• Activez AWS CloudTrail pour auditer l'accès aux compartiments S3.
• Utilisez les politiques de compartiment comme couche de sécurité supplémentaire.

Concevoir une stratégie d'emplacement externe

Les emplacements externes mappent les informations d'identification de stockage à des chemins de stockage cloud spécifiques, ce qui permet à Unity Catalog de gouverner l'accès aux données stockées en dehors du stockage géré par Unity Catalog. Chaque emplacement externe combine une information d'identification de stockage avec un préfixe d'URL de stockage cloud.

Cas d'utilisation d'emplacement externe

• Accéder aux données existantes dans le stockage cloud qui précèdent l'adoption de Unity Catalog.
• Création de tables externes qui référencent des fichiers de données gérés par d'autres systèmes.
• Partage de données avec des systèmes externes qui nécessitent un accès direct aux fichiers.
• Stockage de grandes quantités de données non structurées (par exemple, vidéos, images, PDF) dans des volumes Unity Catalog.

Modèles de conception d'emplacement externe

• Créez des emplacements externes au préfixe de chemin commun le plus élevé afin de minimiser le nombre d'emplacements.
• Utilisez des emplacements externes qui s'alignent avec les limites du catalogue ou du schéma (par exemple, un emplacement externe par catalogue).
• Séparer les emplacements externes par environnement (par exemple, dev, staging, production).
• Séparez les emplacements externes par unité commerciale ou par domaine de données, si nécessaire.

Bonnes pratiques pour les emplacements externes

• Utilisez les emplacements externes pour les données qui doivent rester dans des chemins de stockage cloud spécifiques.
• Utilisez les tables gérées de Unity Catalog au lieu des emplacements externes lorsque cela est possible (gouvernance et optimisation simplifiées).
• Utilisez des noms descriptifs qui indiquent le chemin de stockage et l'objectif (par exemple, s3-sales-data-prod, adls-finance-reports-dev).
• Accordez l'accès aux emplacements externes uniquement aux utilisateurs qui ont besoin de créer des tables externes.
• Documenter les finalités de l'emplacement externe et la propriété des données.

Concevoir le modèle d'autorisations

Chaque organisation a des exigences différentes en matière de contrôle d'accès aux données. Un modèle d'autorisations courant implique de définir des rôles clairs avec des privilèges spécifiques.

Exemple de modèle d'autorisation

• Gestionnaires de données : Gèrent tous les assets de données (par exemple, la propriété, les privilèges de création, de modification, de suppression).
• **Consommateurs de données** : Accès en lecture seule à la plupart des assets de données (privilèges sélectionnés).
• Data engineers : Accès en lecture-écriture aux environnements de développement et de préproduction.
• Analystes : Accès en lecture seule aux données analytiques de production.

Délégation d'autorisations

L'administrateur du metastore établit et applique les politiques d’autorisation en assignant et en déléguant des droits d'accès aux utilisateurs ou aux groupes en fonction de leurs responsabilités. Par exemple :

• Les responsables des données peuvent se voir accorder des privilèges de propriété ou d'écriture pour la gestion des datasets.
• Les consommateurs reçoivent des autorisations de niveau lecture via l’adhésion au groupe.
• Cette structure assure une gouvernance cohérente, simplifie la maintenance et prend en charge la conformité aux politiques de données de l'organisation.

Bonnes pratiques pour les modèles d'autorisation

• Accordez des privilèges aux groupes plutôt qu'aux utilisateurs individuels pour faciliter la gestion.
• Utilisez l'accès au moindre privilège (accordez uniquement les autorisations minimales requises).
• Documentez les politiques de contrôle d'accès et examinez-les régulièrement avec les équipes de sécurité.
• Utilisez les octrois de catalogue et de schéma pour un contrôle d'accès à grain grossier.
• Utilisez les autorisations de table et de vue pour un contrôle d'accès précis.
• Utilisez des vues dynamiques et des filtres de lignes/colonnes pour les données sensibles.
• Auditer l'accès à l'aide de tables système (system.access.audit).

Modèle de conception en étoile

Le modèle de conception en étoile est une architecture courante pour les déploiements Unity Catalog en entreprise. Ce modèle centralise les assets de données partagés dans un catalogue central tout en permettant des données spécifiques au domaine dans des catalogues satellites.

Caractéristiques en étoile

• Catalogue central : Contient des assets de données partagés à l'échelle de l'organisation (par exemple, des données de base client, des données de référence, des datasets gérés de manière centralisée).
• Catalogues secondaires : contiennent des données spécifiques au domaine, détenues et gérées par des unités commerciales (par exemple, l'analytique des ventes, les campagnes de marketing).
• Séparation du stockage : les catalogues de hub et de domaine utilisent un stockage dédié avec des identifiants de stockage distincts.
• **Préférence pour les tables gérées** : pour les données structurées dans le lakehouse, utilisez les tables gérées.
• Volumes pour les données brutes : Utilisez les volumes pour accéder aux données d'atterrissage, brutes ou non structurées (qui peuvent se trouver en dehors du lakehouse, car des tiers nécessitent généralement un accès direct à ces emplacements de stockage).
• Tables externes pour le partage : Utilisez des tables externes pour partager des données en dehors du lakehouse (vers d’autres systèmes ne pouvant pas utiliser OpenSharing ou nécessitant un accès direct à l’emplacement de stockage).

Exemple de conception en étoile

Metastore (region: us-east-1)
├── Hub Catalog (prod_hub)
│   ├── Storage credential: hub-prod-credential
│   ├── External location: s3://company-hub-prod/
│   └── Schemas: customers, products, reference_data
│
├── Sales Domain Catalog (sales_prod)
│   ├── Storage credential: sales-prod-credential
│   ├── External location: s3://company-sales-prod/
│   └── Schemas: transactions, forecasts, reports
│
└── Engineering Domain Catalog (engineering_prod)
    ├── Storage credential: engineering-prod-credential
    ├── External location: s3://company-engineering-prod/
    └── Schemas: telemetry, monitoring, logs

Bonnes pratiques pour la conception en étoile.

• Utilisez le catalogue central pour les données partagées à l'échelle de l'organisation que plusieurs domaines consomment.
• Utilisez des catalogues rayons pour les données spécifiques à un domaine appartenant aux unités commerciales.
• Séparez les identifiants de stockage et les emplacements externes pour le hub et chaque spoke.
• Utilisez OpenSharing géré par Databricks pour partager des données du hub aux rayons.
• Documenter la propriété et la lignée des données pour les catalogues en étoile.
• Remarque : Le stockage du métastore est désormais facultatif et il est recommandé de ne pas l'utiliser.

Recommandations pour l'architecture de Unity Catalog

Recommandations

• Séparez les environnements SDLC dans le metastore Unity Catalog au niveau du catalogue de l'espace de noms à 3 niveaux.
• Utilisez les niveaux d'isolation de Unity Catalog pour séparer les charges de travail, les équipes et les unités commerciales.
• Utilisez OpenSharing géré par Databricks pour partager des tables entre les clouds et les régions.
• Pour les configurations interrégionales, évaluez la fréquence et le volume d’accès aux données entre les régions cloud. Si le coût devient trop élevé, envisagez de configurer un pipeline pour synchroniser les tables entre les régions.
• Utilisez les tables gérées par Unity Catalog et ne fournissez pas d'accès au niveau du stockage aux compartiments.
• Utilisez des volumes pour les chemins de fichiers de style Portable Operating System Interface (POSIX) sécurisés par Unity Catalog.
• Évitez les anciens modèles d'accès aux données, tels que le montage du stockage cloud et les profils d'instance, dans la mesure du possible.
• Évaluez si des clés de chiffrement gérées par le client (pour les services gérés et le stockage) sont nécessaires pour un contrôle accru des données au repos.

Éviter

• N'utilisez pas de modes d'accès autres que standard ou dédiés pour les Workspaces activés pour Unity Catalog.
• Ne stockez pas les données de production sur DBFS (Databricks File System).
• N'enregistrez pas de tables externes à travers les régions (métastores).
• N'utilisez pas le bucket racine (DBFS) pour le stockage des données client. Assurez-vous de comprendre les risques et les solutions de contournement pour le compartiment racine.

Résultats de la phase 3

Après avoir terminé la phase 3, vous devriez avoir :

• Modèle de gouvernance sélectionné en fonction de la structure organisationnelle (centralisée, décentralisée, fédérée ou hybride).
• Architecture du métastore conçue (généralement un par région).
• Architecture de stockage Unity Catalog conçue (objets gérés, externes ou étrangers).
• Structure de catalogue définie à l'aide de modèles basés sur l'environnement, basés sur le domaine ou hybrides.
• Stratégie d'identifiants de stockage conçue avec des identifiants distincts pour différents environnements ou domaines.
• Stratégie d'emplacement externe conçue pour le stockage cloud existant qui nécessite la gouvernance de Unity Catalog.
• Modèle d’autorisations conçu avec des rôles clairs (par exemple, curateurs, consommateurs, ingénieurs, analystes).
• Conception en étoile évaluée pour les déploiements d'entreprise avec des données partagées et spécifiques au domaine.

**Phase suivante** : Phase 4 : Conception de l'architecture réseau

Directives d'implémentation : pour des instructions pas à pas sur l'implémentation de votre conception de Unity Catalog, consultez Qu'est-ce que Unity Catalog ?.