Phase 2 : Concevoir la stratégie du Workspace

Dans cette phase, vous concevez l'architecture de votre Workspace afin de l'aligner sur la structure, les exigences de sécurité et les besoins d'Opérations de votre organisation.

Comprendre les Workspace

Un workspace Databricks est la limite opérationnelle dans une région cloud où les équipes développent et exécutent des charges de travail. Il contient des artefacts de collaboration (par exemple, des Notebooks, des Jobs, des tableaux de bord et des repositories) et des configurations à l'échelle du Workspace, telles que les autorisations du Workspace, les stratégies de cluster, les secrets et les configurations SQL. Le workspace est un environnement d'exécution et de collaboration. Les données persistantes sont généralement stockées dans des services cloud, tels que le stockage d'objets.

Les administrateurs des workspaces créent et configurent des workspaces en fonction des objectifs de leur organisation. Certains utilisent un seul workspace tandis que d'autres séparent par domaine, environnement (dev/test/prod), secteur d'activité, géographie ou limites réglementaires. Ces choix déterminent le rayon administratif, la séparation des tâches, l'attribution des coûts et la fréquence de réplication. Commencer modestement avec Databricks nécessite une configuration minimale, mais les déploiements plus importants doivent prendre en compte les exigences futures et la manière dont elles affectent votre capacité à protéger les données tout en responsabilisant les équipes.

Choisissez le modèle de déploiement du workspace

Il existe deux types de Databricks Workspace disponibles :

Workspaces Serverless

Un déploiement de Workspace dans votre compte Databricks, préconfiguré avec un compute serverless et un stockage default pour offrir une expérience entièrement serverless.

Caractéristiques du workspace Serverless

• default storage : Stockage cloud sur le compte cloud de Databricks, dans la même région que le Workspace.

  • Vous pouvez toujours vous connecter à votre stockage cloud à partir de workspaces serverless.

• Compute Serverless : préconfiguré et immédiatement disponible.

• Fast Startup : aucun provisionnement d'infrastructure n'est requis.

• Mise à l'échelle automatique : s'adapte à la demande de workload.

Classic Workspace

Un déploiement de Workspace dans votre compte Databricks qui provisionne des ressources de stockage et de compute dans votre compte cloud existant. Les services et le compute Serverless sont toujours disponibles dans les workspaces classiques.

Caractéristiques de Classic Workspace

• Stockage géré par le client : Stockage dans votre compte cloud.
• **Compute géré par le client** : infrastructure de compute dans votre compte cloud.
• Contrôle du réseau : contrôle total de la configuration du Virtual Private Cloud (VPC)/VNet.
• Flexibilité : le compute Serverless peut toujours être utilisé parallèlement au compute classique.

Recommandations de modèle de déploiement de Workspace

Utilisez ces recommandations pour décider de déployer un workspace Serverless ou classique pour votre scénario :

• Confirmez que la région que vous prévoyez d'utiliser prend en charge les Workspaces serverless et le compute serverless si vous avez l'intention d'utiliser Serverless.
• Examinez les limitations du workspace Serverless pour vérifier qu’elles répondent à vos exigences.
• Évaluez vos cas d'utilisation principaux (par exemple, l'autoscaling par rapport au contrôle précis des clusters) et choisissez des Workspace Serverless ou classiques en conséquence.
• **Recommendation** : start avec des Workspace Serverless pour une efficacité opérationnelle.
• Utilisez des Workspaces classiques lorsque : Vous avez besoin de configurations réseau personnalisées, d'une connectivité on-premise ou d'exigences de conformité spécifiques.

Conception de la stratégie de fractionnement de Workspace

Il y a plusieurs raisons de diviser une configuration Databricks en différents Workspaces. Examinez ces modèles lors de la conception de l'architecture de votre Workspace.

Raisons de fractionner les Workspaces

Isoler les workspaces en fonction des exigences de protection des données

Pour les secteurs d'activité fortement réglementés avec une application stricte de la séparation des données, isolez les workspaces pour simplifier la mise en œuvre des contrôles pour les données sensibles sans interférer avec les flux de travail à moindre risque.

Isoler différentes unités commerciales

Assurez-vous qu'aucun asset de Workspace dans Databricks n'est partagé entre les unités commerciales lorsque les limites organisationnelles exigent une isolation complète.

Isoler les équipes ayant des besoins de plateforme différents

Si différentes équipes requièrent un accès à différents ensembles de fonctionnalités de plateforme (par exemple, un accès complet à toutes les fonctionnalités pour une équipe d'administration centrale, mais pas pour d'autres équipes ou pour les tests de plateforme), alors ces équipes devraient être séparées par des Workspaces.

Isoler les environnements de cycle de vie du développement logiciel (SDLC)

Séparez les environnements de développement, de préproduction et de production si vous avez des exigences d'isolation strictes. Par exemple :

• Certaines organisations déploient des environnements Dev/Staging/Prod dans différents réseaux virtuels, de sorte que des workspaces séparés sont nécessaires pour chaque environnement.
• Pour tester de nouveaux paramètres de Workspace avant de les appliquer à Prod (comme l'activation ou la restriction de fonctionnalités), Prod doit être un Workspace différent de Dev ou Staging.
• De nombreuses entreprises isolent également ces environnements du point de vue du stockage et du compute en utilisant différents conteneurs de stockage, réseaux virtuels et workspaces Databricks.

Opérer dans plusieurs régions cloud

Lorsqu'une organisation sert des utilisateurs ou collecte des données dans plusieurs pays ou zones géographiques, les réglementations ou les politiques internes peuvent exiger que des données spécifiques restent dans la région, ce qui génère le besoin de workspaces séparés déployés dans chaque région cloud qui traitent ou stockent ces données. La répartition des Workspace par région permet aux équipes d'aligner les déploiements Databricks avec des comptes de stockage locaux et des réseaux virtuels, tout en respectant les normes d'entreprise communes en matière de gouvernance et de sécurité.

Les Workspaces régionaux contribuent également à réduire la latence pour l'analytique interactive et les applications de données en plaçant le compute plus près des utilisateurs locaux et des sources de données, ce qui améliore l'expérience utilisateur et les performances des queries.

Diviser pour dépasser les limites de ressources

Les comptes cloud (ou abonnements) ont des limites de Ressources. Le déploiement des workspaces sur différents comptes est un moyen de garantir que des Ressources suffisantes sont disponibles pour chaque workspace. Il existe également des limites dans chaque workspace Databricks, telles que le nombre de tâches pouvant s'exécuter simultanément ou le nombre maximal de Databricks Apps. La division des workspaces garantit que les charges de travail de chaque workspace ont accès à davantage de Ressources.

Limites de ressources du fournisseur de services cloud

Limites de Workspace AWS

Nombre maximal de Workspace par compte Databricks sur AWS :

• Limites default : 10 pour le niveau Premium, 50 pour le niveau Enterprise.
• Limites strictes
  • Niveau Premium : 50 (autorisé avec des batchs incrémentiels de 20).
  • Niveau Entreprise : 1 000 pour les workspaces classiques, 2 000 pour les workspaces serverless (autorisés avec des batches incrémentiels de 50).

L'augmentation des limites du Workspace requiert l'intervention de l'équipe de compte Databricks.

Limites importantes de l'infrastructure cloud

Parce que chaque Workspace est déployé sur un Virtual Private Cloud (VPC) dans votre compte AWS, gardez à l'esprit les limites sous-jacentes, en particulier :

• Nombre de comptes AWS.
• Nombre de VPC par région.

Considérations pour les Workspace fractionnés

Limitations de la collaboration

Il n'y a pas de partage de notebooks (collaboration) entre les workspaces. Utilisez Unity Catalog dans tous les workspaces pour promouvoir le Data Sharing lorsque cela est possible. Le code peut être partagé à l'aide de GitHub entre les workspaces.

Charge administrative

Les frais administratifs pour un grand nombre de Workspaces peuvent devenir substantiels. Souvent, avoir plus de 100 Workspaces peut, par inadvertance, entraîner des Workspaces orphelins ou non gérés, ce qui peut poser un risque de coût et/ou d'exfiltration.

Exigence d'automatisation

Pour plusieurs Workspaces, la configuration et la maintenance doivent être entièrement automatisées (en utilisant des outils tels que Terraform, des outils spécifiques au cloud ou l'API REST). Ceci est particulièrement important pour les besoins de mobilité et les scénarios de récupération d'urgence (DR), où le provisionnement rapide des Workspace, le basculement et la réplication de la configuration entre les régions ou les clouds sont des exigences opérationnelles critiques.

Coûts d'infrastructure réseau

Si chaque Workspace doit être sécurisé au niveau du réseau (comme pour la protection contre l'exfiltration des données), l'infrastructure réseau nécessaire peut devenir très coûteuse si vous avez des centaines de Workspaces.

Limites des fonctionnalités

Certaines fonctionnalités ont un support inter-Workspace limité, comme le compute Serverless avec des contrôles de sortie Serverless, qui accèdent aux services gérés de Unity Catalog. Certaines fonctionnalités, telles que les fonctionnalités d'IA, AWS Private Link et les clés de chiffrement, sont définies au niveau du Workspace. Si l'entreprise exige des configurations de sécurité différentes pour d'autres équipes, l'approbation de ces fonctionnalités définit la répartition du Workspace.

SDLC et matrice d'unité commerciale

Si vous souhaitez séparer les Workspace pour le développement/la mise en scène/la production, et que vous souhaitez également isoler les unités commerciales par Workspace, veuillez prendre en compte les limites de Workspace des différents fournisseurs de cloud. La matrice peut rapidement entraîner un grand nombre de Workspace.

Comprendre les modes de sécurité du Workspace

Les Workspaces qui sont affectés à Unity Catalog prennent en charge les modes d'accès suivants pour les clusters :

Mode de sécurité	Caractéristiques
Standard	Plusieurs utilisateurs peuvent travailler sur le même cluster. Convient aux charges de travail générales (par exemple, ETL, exploration de données). Prend en charge SQL, Python et Scala uniquement. Prend en charge le contrôle d'accès granulaire (FGAC), y compris les autorisations basées sur les vues et le contrôle d'accès basé sur les attributs/tables (ABAC). Aucun support pour le DBR ML de Machine Learning (mais de nombreuses bibliothèques ML peuvent être installées sur le DBR standard).
Dédié	Prend en charge DBR ML et toutes les langues. Dédié à un seul utilisateur : le cluster n'est accessible que par un seul utilisateur (attribué lors de la création du cluster). Dédié à un seul groupe : plusieurs utilisateurs du même groupe peuvent travailler sur le même cluster (le groupe est attribué lors de la création du cluster).

Mode de sécurité	Caractéristiques
Standard	Plusieurs utilisateurs peuvent travailler sur le même cluster. Convient aux charges de travail générales (par exemple, ETL, exploration de données). Prend en charge SQL, Python et Scala uniquement. Prend en charge le contrôle d'accès granulaire (FGAC), y compris les autorisations basées sur les vues et le contrôle d'accès basé sur les attributs/tables (ABAC). Aucun support pour le DBR ML de Machine Learning (mais de nombreuses bibliothèques ML peuvent être installées sur le DBR standard).
Dédié	Prend en charge DBR ML et toutes les langues. Dédié à un seul utilisateur : le cluster n'est accessible que par un seul utilisateur (attribué lors de la création du cluster). Dédié à un seul groupe : plusieurs utilisateurs du même groupe peuvent travailler sur le même cluster (le groupe est attribué lors de la création du cluster).

Exemples de déploiements de Workspace

Lorsque vous getting start avec Databricks, la plupart des organisations exécutent un déploiement Databricks mono-tenant dans une seule région de cloud. Toutefois, à mesure que votre organisation se développe, les administrateurs peuvent adapter leurs déploiements pour répondre à leurs cas d'utilisation complexes.

Déploiement monotenant, monorégion

• Un Workspace de production.
• Un Workspace de développement.
• Toutes les ressources dans une seule région cloud.

Déploiement multirégional

• Workspace de production dans la région des États-Unis.
• Workspace de production dans la région de l'UE (pour la conformité GDPR).
• Workspace de développement partagé.
• Métastore Unity Catalog par région avec OpenSharing D2D pour l'accès aux données interrégionales.

Déploiement multi-unités commerciales

• Un Workspace par unité commerciale (par exemple, Ventes, Marketing, Data Engineering).
• Workspace de développement partagé pour toutes les équipes.
• Metastore central Unity Catalog avec ségrégation au niveau du catalogue.

Déploiement par environnement

• Workspace de production (toutes les unités commerciales).
• Workspace de pré-production (tests de pré-production).
• Workspace de développement (développement partagé).
• Séparez les réseaux et le stockage pour chaque environnement.

Définir les conventions de nommage du Workspace

Établissez une convention de nommage cohérente pour les workspaces afin d'améliorer la découvrabilité et la gestion.

Modèle de nommage recommandé

{organization}-{environment}-{region}-{purpose}

Exemples

• acme-prod-us-west-analytics
• acme-dev-shared
• acme-prod-eu-west-gdpr
• acme-staging-us-east-dataeng

Bonnes pratiques pour le nommage des Workspace

• Utilisez des lettres minuscules et des tirets.
• Incluez la désignation de l’environnement (par exemple, prod, staging, dev).
• Incluez la région pour les déploiements multirégions.
• Incluez l'unité commerciale ou l'objectif, le cas échéant.
• Limitez les noms à moins de 50 caractères.
• Conventions de dénomination des documents dans votre runbook.

Recommandations relatives à la stratégie de Workspace

Recommandations

• Diviser les environnements SDLC en workspaces séparés (au moins Dev et Prod, mais potentiellement plus selon les exigences).
• Utilisez des outils d'automatisation tels que Terraform chaque fois que possible pour minimiser les erreurs humaines et établir des modèles de déploiement reproductibles.
• Start with serverless workspaces and switch to classic workspaces only when you have specific network or conformité requirements.
• Documenter la stratégie de division du Workspace et les conventions de nommage.
• Créez un Workspace administratif par région pour la gestion des Ressources Unity Catalog.

Évitez ces modèles

• Ne créez pas de Workspace séparés pour des équipes individuelles ou de petits projets (utilisez plutôt les catalogues et schémas Unity Catalog pour l'isolation).
• Ne déployez pas plus de 50 à 100 workspaces sans justification solide et automatisation robuste.
• Ne divisez pas les Workspace inutilement (équilibre des besoins d'isolation et de la complexité opérationnelle).
• Évitez la création ad-hoc de Workspace sans suivre les conventions de nommage.

Résultats de la phase 2

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

• Modèle de déploiement du Workspace sélectionné (Serverless vs espaces de travail classiques).
• Stratégie de fractionnement du Workspace conçue en fonction des besoins organisationnels (par exemple, environnement, unité commerciale, région, conformité).
• Compréhension des limites de ressources et des stratégies d'atténuation.
• Convention de nommage du Workspace définie.
• Modes de sécurité compris (standard ou dédié).
• Architecture de déploiement documentée.
• Stratégie d'automatisation prévue pour le provisionnement des Workspace.

Phase suivante : Phase 3 : Concevoir l'architecture Unity Catalog