Phase 5 : conception de l'architecture de stockage

Dans cette phase, vous concevez l'infrastructure de stockage pour les Workspaces Databricks et Unity Catalog.

Pour traiter les données sur Databricks, le stockage cloud doit être configuré. Il existe deux types de stockage au sein de Databricks :

• Stockage géré par Databricks (stockage par default) : Stockage dans le compte cloud appartenant à Databricks. Utilisé par les workspaces Serverless pour le stockage racine du workspace et éventuellement pour les catalogues Unity Catalog.
• Stockage géré par le client : stockage dans le compte cloud du client. Utilisé par les workspaces classiques pour le stockage du workspace et le stockage Unity Catalog.

Les deux types de stockage utilisent les mêmes services cloud sous-jacents.

Concevoir l'architecture de stockage du workspace

Le compte/compartiment de stockage du Workspace est une partie obligatoire d'un Workspace Databricks et est utilisé à plusieurs fins :

• Stockage pour le catalogue Unity Catalog default créé pour ce Workspace.
• D’autres données générées en interne utilisées par différents services de la plateforme, tels que l’emplacement de stockage par default pour les Experimentation MLflow, les modèles de registre MLflow et LakeFlow Pipelines, ainsi que Cloud Fetch.

Modèles de stockage du Workspace

L’utilisation d’un réseau virtuel géré par le client vous donne plus de contrôle sur le compartiment système du Workspace. Vous créez d'abord le bucket racine, puis vous l'attribuez à un workspace Databricks, en conservant un contrôle total sur la stratégie du bucket tout en vous assurant que le workspace peut toujours y accéder.

Meilleures pratiques pour le stockage du workspace

• Utiliser les emplacements externes de Unity Catalog pour remplacer les emplacements de stockage par default du Workspace.
• Interdisez les uploads depuis l'application web, sauf en cas de nécessité absolue (configurez depuis la page admin).
• N'utilisez pas le compartiment racine du workspace (DBFS) pour les données client de production.
• Comprenez les risques et les solutions de contournement pour le compartiment racine.

Migration DBFS

DBFS (Databricks File System) ne doit pas être utilisé pour les nouvelles données de production. Pour les déploiements existants :

• Données structurées : migrez les tables DBFS vers des tables gérées par Unity Catalog.
• Données non structurées : migrez les fichiers de DBFS vers les volumes Unity Catalog pour un accès aux fichiers de style POSIX.
• Fichiers Workspace : Continuez d'utiliser le stockage Workspace (pas DBFS) pour les Notebooks, les bibliothèques et les logs de cluster.

Concevoir l’architecture de stockage de Unity Catalog

Les metastores Unity Catalog prennent en charge trois types d'objets qui déterminent comment et où les données sont stockées : gérés, externes et étrangers.

Types d'objet de stockage

Objets gérés

Pour les objets gérés, un emplacement de stockage géré spécifie un emplacement dans le stockage d'objets cloud pour le stockage des données des tables gérées et des volumes gérés. Vous pouvez associer un emplacement de stockage géré à un métastore, un catalogue ou un schéma. Les emplacements de stockage gérés situés à des niveaux inférieurs dans la hiérarchie remplacent les emplacements de stockage définis à des niveaux supérieurs lorsque des tables gérées ou des volumes gérés sont créés.

important

Se fier aux emplacements default n'est pas recommandé, car cela peut entraîner une colocation de données involontaire et compliquer le contrôle d'accès et la gestion du cycle de vie. Définir explicitement les emplacements de stockage au niveau du catalogue ou du schéma.

Objets externes

Les objets externes stockent leurs données dans des emplacements externes. Les emplacements externes associent les informations d'identification de stockage d'Unity Catalog aux conteneurs de stockage d'objets cloud (par exemple, les compartiments Amazon S3, les conteneurs Azure ou les compartiments Google Cloud Storage). Les emplacements externes sont utilisés pour :

• Définissez les emplacements de stockage gérés pour les catalogues et les schémas.
• Définir les emplacements pour les tables externes et les volumes externes.

Corps étrangers

Un catalogue externe spécifie une connexion à un système de données externe pour l'accès aux tables et schémas distants. Vous pouvez associer un catalogue étranger à des métadonnées provenant de sources externes telles que Hive Metastore, AWS Glue ou Snowflake Horizon. Les catalogues externes fournissent un accès en lecture seule aux objets de base de données du système distant, vous permettant de query des tables et des schémas externes via Unity Catalog sans répliquer les données.

Architecture de stockage cloud

Architecture de stockage AWS

Dans les comptes Databricks AWS, un metastore Unity Catalog possède :

• Zéro ou un bucket S3 pour le stockage default des tables gérées au niveau du métastore.
• Zéro ou plusieurs compartiments au niveau du catalogue ou du schéma pour les tables gérées.
• Zéro ou plusieurs compartiments S3 pour les tables externes.

À l'instar des workspaces, les compartiments S3 pour le stockage sous Unity Catalog peuvent appartenir à différents comptes AWS. Pour tous les compartiments (emplacements de stockage), vous devez configurer un rôle IAM inter-comptes (identifiant de stockage) avec une relation de confiance afin que Unity Catalog puisse endosser le rôle pour accéder aux données dans le compartiment au nom des utilisateurs Databricks.

Modèles d'isolement du stockage

Séparez le stockage par environnement

Utilisez des conteneurs de stockage différents pour les environnements de développement, de préproduction et de production. Ceci fournit des limites claires et empêche l'accès accidentel aux données de production depuis des environnements inférieurs.

Séparer le stockage par unité commerciale

Lorsque les unités commerciales exigent une ségrégation complète des données à des fins de gouvernance ou de facturation, utilisez des conteneurs de stockage séparés avec des informations d'identification de stockage séparées pour chaque unité commerciale.

Séparer le stockage par domaine de données

Dans les architectures data mesh, chaque domaine devrait avoir ses propres conteneurs de stockage gérés par des identifiants de stockage spécifiques au domaine.

Conception de stockage multirégional

Si plusieurs régions utilisent Databricks, l'architecture de stockage doit tenir compte de la localité des données et des modèles d'accès inter-régions :

• Déployer les conteneurs de stockage dans la même région que le métastore pour les performances.
• Utilisez OpenSharing géré par Databricks (D2D) pour partager des données entre les régions.
• Évaluez la fréquence et le volume d'accès aux données entre les régions pour déterminer si des pipelines de réplication de données sont nécessaires.
• Tenez compte des coûts de transfert de données lorsque vous accédez aux données entre les régions.

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.

Concevoir une stratégie d'accès et d'authentification

Databricks recommande d'utiliser Unity Catalog pour gérer l'accès à toutes les données, et recommande en particulier d'utiliser des tables gérées dans la mesure du possible. Unity Catalog gère entièrement le layout de stockage, les métadonnées et la gouvernance des tables gérées.

Pour gérer l'accès au stockage cloud externe qui contient des tables et des volumes, Unity Catalog utilise des emplacements externes, qui définissent un chemin vers le stockage cloud et les informations d'identification requises pour accéder à cet emplacement. Au-delà du stockage cloud, Unity Catalog gère également les autorisations pour les tables, les modèles et les autres assets, et peut fédérer vers des catalogues externes.

Méthodes d'authentification par cloud

Architecture d'authentification AWS

Dans AWS, utilisez des rôles IAM inter-comptes pour Unity Catalog afin d'accéder au stockage des clients :

1. Créez un rôle IAM avec une politique de confiance qui permet à Databricks d'endosser le rôle
2. Joignez des stratégies IAM accordant des autorisations S3 à des compartiments S3 ou des préfixes spécifiques.
3. Enregistrer l'ARN du rôle IAM en tant qu'identifiant de stockage dans Unity Catalog
4. Créez des emplacements externes qui utilisent l'identifiant de stockage

Bonnes pratiques pour l'authentification 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 de chiffrement

Le stockage géré par le client peut être chiffré à l'aide des pratiques cloud standard. Par default, les données sont chiffrées au repos à l'aide du chiffrement du fournisseur cloud et d'une clé gérée par Databricks.

Options de chiffrement

Clés gérées par Databricks (default)

Par default, vos données sont chiffrées au repos à l'aide du chiffrement du fournisseur cloud et d'une clé gérée par Databricks. Cela fournit un chiffrement de base sans configuration supplémentaire requise.

Clés gérées par les clients

Pour les organisations qui exigent des clés gérées par le client, chaque cloud les prend en charge. Les clés gérées par le client sont généralement utilisées à deux fins :

Objectif 1 : Chiffrement du plan de contrôle et des services gérés

Chiffrer les données client dans le plan de contrôle Databricks, le stockage default et les services Serverless pris en charge qui stockent les données client au repos (tels que AI Search, les résultats de query, le code et les secrets) avec une clé sous le contrôle du client. Si le client supprime la clé ou supprime l'accès à la clé, toutes les données liées à ce Workspace sur le plan de contrôle deviennent inaccessibles.

Objectif 2 : chiffrement du compute et du plan de données

Chiffrez les données client sur les plans de compute et de données client pour des services spécifiques. Définissez une clé gérée par le client à des fins de chiffrement du stockage afin que Databricks l'utilise pour chiffrer le compartiment racine et les volumes de stockage connectés aux clusters.

remarque

Sur AWS, S3 chiffre toujours les données de manière transparente à l'aide d'une clé KMS gérée par S3. Une clé gérée par le client n'est nécessaire que pour chiffrer explicitement les données avec une clé gérée par le client, fournissant une couche de sécurité supplémentaire liée à l'accès à la clé elle-même.

Modèles de chiffrement

Environnements fortement réglementés

Utilisez des clés gérées par les clients pour le chiffrement du plan de contrôle et du plan de compute/données afin de garder un contrôle total sur les clés de chiffrement et de satisfaire aux exigences de conformité.

Déploiements d’entreprise standard

Utilisez les clés gérées par Databricks pour la plupart des charges de travail, en réservant les clés gérées par le client aux Workspaces de production contenant des données sensibles.

Déploiements multilocataires

Envisagez d'utiliser des clés distinctes gérées par le client pour différentes unités commerciales ou environnements afin d'assurer l'isolation du chiffrement.

Concevoir la sécurité du réseau de stockage

L'accès réseau au stockage cloud peut être limité comme couche de sécurité supplémentaire. Si les identifiants sont divulgués, les contrôles d'accès réseau empêchent leur utilisation.

Modèles de sécurité réseau

• Utilisez les stratégies de bucket S3 pour restreindre l'accès à des Virtual Private Cloud (VPC) ou des Endpoints VPC spécifiques.

Bonnes pratiques pour la sécurité du réseau de stockage

• Limitez l'accès au stockage à des réseaux virtuels ou sous-réseaux spécifiques.

• Utilisez des Endpoint Virtual Private Cloud (VPC) pour une connectivité privée.

• Activer la journalisation du service de stockage pour auditer les tentatives d'accès.

• Configurez les règles réseau avant d'accorder des autorisations de stockage étendues.

Conception de stockage en étoile

Le modèle de conception de stockage en étoile est une architecture courante pour les déploiements Unity Catalog d'entreprise. Ce modèle centralise les actifs de données partagés dans le stockage centralisé tout en permettant des données spécifiques au domaine dans le stockage en étoile.

caractéristiques de stockage de type Hub-and-Spoke

• Stockage centralisé : Contient des assets de données partagés à l'échelle de l'organisation (par exemple, les données de référence des clients, les données de référence, les datasets gérés de manière centralisée).
• Stockage spoke : contient des données spécifiques au domaine, détenues et gérées par les unités commerciales (par exemple, analytique des ventes, campagnes 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).

Bonnes pratiques pour la conception de stockage hub-and-spoke.

• Utilisez le stockage centralisé pour les données partagées à l'échelle de l'organisation que plusieurs domaines consomment.
• Utilisez le stockage satellite pour les données spécifiques au 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.
• Documentez la propriété et la traçabilité des données pour le stockage en étoile.
• Remarque : Le stockage du métastore est désormais facultatif et il est recommandé de ne pas l'utiliser.

Recommandations d'architecture de stockage

Recommandations

• Utilisez les tables gérées par Unity Catalog et ne fournissez pas d'accès au niveau du stockage aux compartiments.
• Définissez explicitement les emplacements de stockage au niveau du catalogue ou du schéma plutôt que de vous fier aux default au niveau du metastore.
• Séparez le stockage par environnement (par exemple, développement, préproduction, production) en utilisant différents conteneurs de stockage.
• 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.
• Utilisez OpenSharing géré par Databricks pour partager des tables entre les clouds et les régions.

Éviter

• N'utilisez pas le compartiment racine (DBFS) pour le stockage des données client.
• 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).
• Ne fournissez pas d'accès au niveau du stockage (par exemple, l'accès aux buckets S3, l'accès aux conteneurs ADLS) directement aux utilisateurs.
• Ne vous fiez pas aux emplacements de stockage par default au niveau du métastore pour les données de production.

Résultats de la phase 5

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

• Architecture de stockage conçue pour les Workspace (gérée par le client ou gérée par Databricks).
• Architecture de stockage Unity Catalog conçue (objets gérés, externes ou étrangers).
• Stratégie d'isolation du stockage définie (par environnement, unité commerciale ou domaine de données).
• Stratégie d'authentification conçue (par exemple, rôles IAM, connecteurs d'accès ou comptes de service).
• Stratégie de chiffrement sélectionnée (clés gérées par Databricks ou clés gérées par le client).
• Modèles de sécurité réseau de stockage définis (par exemple, politiques de compartiment, pare-feu de stockage, Endpoint Virtual Private Cloud (VPC)).
• Considérations relatives au stockage multirégion documentées (le cas échéant).
• Conception de stockage en étoile évaluée (pour les déploiements d’entreprise).
• Stratégie de migration DBFS planifiée (pour les déploiements existants avec des données DBFS).

Phase suivante : Phase 6 : Conception de l'architecture Delta Lake

Directives de mise en œuvre : pour des instructions détaillées sur la mise en œuvre de votre conception de stockage, consultez Se connecter au stockage d’objets cloud à l’aide de Unity Catalog.