Phase 8 : conception de la configuration de compute

Dans cette phase, vous concevez les ressources de compute et les paramètres de Workspace pour optimiser les performances, les coûts et la sécurité.

Databricks recommande d'utiliser le compute serverless comme option principale. Le Serverless ne nécessite aucune configuration, est toujours disponible et s'adapte automatiquement aux charges de travail en quelques secondes. Ne configurez le compute classique manuellement que si le Serverless ne prend pas en charge votre cas d'utilisation.

Concevoir une stratégie de dimensionnement des clusters

Pour les charges de travail compute classiques, suivez les meilleures pratiques de dimensionnement des clusters afin de trouver un point de départ raisonnable pour vos charges de travail.

Considérations relatives à la taille des clusters

• Type de Workload : le traitement par batch nécessite de plus grands clusters. Les Workloads interactifs bénéficient de l'autoscaling.
• Volume de données : Dimensionnez les clusters en fonction du volume de données prévu et des exigences de parallélisme.
• Exigences de performance : Équilibre entre le coût et la latence des query.
• Autoscaling : Activer l'autoscaling pour les charges de travail à demande variable.
• Types d'instances : choisissez les types d'instances en fonction des exigences de CPU, de mémoire et d'E/S.

Modèles de dimensionnement de cluster

• Petits clusters (de 2 à 8 nœuds) : Développement, tests et petits datasets.
• Clusters moyens (8-32 nœuds) : Charges de travail ETL et analytiques de production.
• Clusters volumineux (plus de 32 nœuds) : traitement par lots à grande échelle et entraînement du Machine Learning.

Meilleures pratiques pour le dimensionnement des clusters

• start par une configuration de référence et itérez en fonction des métriques de performance.
• Utilisez le dimensionnement automatique pour gérer efficacement les charges de travail variables.
• Surveiller les métriques d'utilisation des clusters (par exemple, processeur, mémoire, E/S) afin d'ajuster leur taille.
• Utilisez des instances spot/préemptives pour les charges de travail tolérantes aux pannes afin de réduire les coûts.
• Documentez les décisions de dimensionnement des clusters et les références de performances.

Pour des guides détaillés sur le dimensionnement des clusters, consultez les meilleures pratiques de configuration du compute classique.

Concevez une stratégie de dimensionnement de SQL Warehouse

Alors que les équipes Data Science sont généralement petites, les cas d'utilisation de Business Intelligence (BI) impliquent souvent des milliers d'analystes. Pour prendre en charge autant d'utilisateurs, Databricks SQL utilise un mécanisme de mise à l'échelle automatique qui ajoute ou supprime des clusters en fonction de trois facteurs principaux :

• Throughput des queries : Combien de queries sont en cours d'exécution ?
• Taille de la file d’attente : Combien de query sont en attente d’un emplacement ?
• Demande prédite : charge de travail estimée pour les deux prochaines minutes.

Essentiellement, Databricks ajoute des clusters lorsqu'il calcule que le matériel actuel ne peut pas traiter assez rapidement les queries existantes et futures.

Choisissez la bonne configuration SQL Warehouse

Le choix de la bonne configuration implique d'équilibrer la taille de compute (puissance) et le nombre de compute (concurrence).

Sélection de la taille (XS à XL)

La « taille de T-shirt » de votre cluster détermine la quantité de compute disponible par query.

• Petits niveaux (XS, S) : Idéal pour les queries simples et rapides. Le plus rentable pour les tableaux de bord de base.
• Grands tiers (L, XL) : Nécessaires pour les query complexes et lourdes qui traitent de vastes datasets afin de prévenir les goulots d'étranglement de performances.

Sélection du nombre (simultanéité)

Le nombre de ressources de compute détermine le nombre d’utilisateurs simultanés que vous pouvez prendre en charge.

• En règle générale : Prévoyez environ 10 requêtes simultanées par cluster.
• high concurrency : si vous avez de nombreux utilisateurs exécutant de petites queries, utilisez de nombreux petits clusters.
• Faible simultanéité : Si vous avez peu d'utilisateurs exécutant des queries massives, utilisez quelques grands clusters.

**Résumé** : Augmentez la taille pour accélérer les queries uniques. Augmentez le nombre pour gérer plus d'utilisateurs simultanément.

Meilleures pratiques pour le dimensionnement du SQL Warehouse

• Démarrez avec les SQL warehouses serverless (aucun dimensionnement requis).
• Pour les SQL Warehouse classiques, commencez par une taille moyenne et ajustez en fonction des modèles de query.
• Surveillez les performances des requêtes et les métriques de mise en file d'attente.
• Utilisez plusieurs warehouse pour différents cas d'usage (ad hoc ou de reporting).
• Documentez les SLA de performance pour différents groupes d'utilisateurs.

Concevoir une stratégie de règles de cluster

Avec les politiques de cluster, les administrateurs Databricks peuvent contrôler de nombreux aspects des clusters qui sont lancés. Les politiques de clusters sont recommandées pour toutes les organisations. Les modèles courants incluent :

Cas d'usage des règles de cluster

• Limiter les utilisateurs aux paramètres prescrits : incluant les types d'instance disponibles, les versions Databricks et les tailles d'instance.
• Simplifier l'interface utilisateur : en corrigeant et en masquant certaines valeurs.
• Contrôle des coûts : en limitant le coût maximal par cluster.
• Appliquer la conformité : En exigeant des metastores externes ou des Cluster Tags spécifiques pour se conformer aux politiques d'entreprise.

Modèles de politique de cluster

• Politique de développement : Petits clusters rentables pour le développement et les tests.
• Politique de production : clusters plus grands et plus puissants avec des types d'instances et des tags spécifiques.
• ML policy : clusters compatibles GPU avec des runtimes ML.
• Politique des instances Spot/préemptables : utilisez des instances Spot pour les workloads tolérants aux pannes.

Bonnes pratiques pour les règles de cluster

• Créez des stratégies distinctes pour différentes équipes ou cas d'utilisation.
• Utilisez les politiques de cluster pour appliquer des contrôles de coûts et des limites de ressources.
• Exigez des tags sur tous les clusters pour l'attribution des coûts.
• Simplifiez l'interface utilisateur en masquant les options de configuration inutiles.
• Documentez les objectifs et restrictions des politiques de cluster.

Pour une configuration détaillée des politiques de clusters, consultez Créer et gérer les politiques de compute.

Concevoir une stratégie de politique d'utilisation

Les politiques d'utilisation se composent de tags qui sont appliqués à toute activité de compute serverless engagée par un utilisateur affecté à la politique. Les tags sont enregistrés dans vos relevés de facturation, vous permettant d'attribuer une utilisation serverless sélectionnée à des budgets spécifiques.

Cas d’utilisation de la politique d’utilisation

• Attribuer les coûts du compute serverless à des services ou des projets spécifiques.
• Suivez les coûts pour différents environnements (par exemple, dev, staging, production).
• Surveillez les dépenses par rapport aux limites budgétaires.
• Générez des rapports de coûts par unité commerciale ou centre de coûts.

Meilleures pratiques pour les politiques d'utilisation

• Créez des politiques d’utilisation pour chaque département ou projet.
• Utilisez des schémas de balisage cohérents sur toutes les ressources de compute.
• Surveiller l'utilisation du budget par l'intermédiaire des tables système et des tableaux de bord.
• Configurez des alertes pour les seuils de budget.
• Révisez et ajustez trimestriellement les affectations budgétaires.

Après avoir appliqué une politique à un Notebook, un Job ou un pipeline, Databricks propage tous les tags de la politique à votre table système system.billing.usage dans la colonne custom_tags.

Superviser l'utilisation et les coûts

Importez les tableaux de bord d'utilisation prédéfinis dans vos workspaces pour surveiller l'utilisation au niveau du compte et du workspace.

Bonnes pratiques de monitoring de l’utilisation

• Importez et personnalisez les tableaux de bord d'utilisation prédéfinis.
• Surveiller les tendances d'utilisation par workspace, utilisateur et type de compute.
• Configurez des alertes pour les modèles de dépenses inhabituels.
• Passez en revue les rapports d'utilisation mensuels avec les équipes financières.
• Utilisez les tables système pour une analyse personnalisée de l'utilisation.

Pour les Template de tableaux de bord d'utilisation, consultez la référence des tables système.

Concevez une stratégie de contrôle d'accès

Pour une installation Databricks par default, tous les utilisateurs peuvent créer et modifier des objets d'Workspace à moins qu'un administrateur n'active le contrôle d'accès à l'Workspace. Les organisations qui souhaitent implémenter une ségrégation du contrôle d'accès au sein d'un Workspace peuvent activer le contrôle d'accès au Workspace.

Modèles de contrôle d'accès

• **Permissif (default)** : Tous les utilisateurs peuvent créer des clusters, des Jobs et des Notebook.
• Restreint : les utilisateurs ont besoin d'autorisations explicites pour créer des objets de Workspace.
• Séparé : Différentes équipes ont accès à différentes ressources de workspace.

Bonnes pratiques pour le contrôle d'accès au Workspace

• Activez le contrôle d'accès Workspace pour les environnements de production.
• Utilisez des groupes pour gérer les autorisations plutôt que des utilisateurs individuels.
• Mettez en œuvre l'accès au moindre privilège (n'accordez que les autorisations nécessaires).
• Révisez et auditez régulièrement les autorisations du workspace.
• Documentez les politiques de contrôle d'accès dans votre runbook.

Pour une configuration détaillée du contrôle d'accès, consultez les listes de contrôle d'accès.

Examiner les paramètres du workspace

La page des paramètres du Workspace au sein de la console d'administration contient un grand nombre de paramètres importants, dont beaucoup ne sont pas couverts par les APIs (et ne peuvent donc pas être automatisés). Veuillez examiner tous ces paramètres avant qu'un Workspace ne soit prêt pour la production.

Download le guide des Bonnes pratiques de sécurité à partir de https://www.databricks.com/trust/security-features/best-practices et de mettre en œuvre les suggestions en conséquence.

Paramètres critiques du Workspace à examiner

• **Contrôle d'accès/de visibilité** : Activé par default. Contrôle la visibilité du Workspace, des clusters, des Pool et des Job.

• Table Access Control : Disabled by default. Envisagez de laisser cette option désactivée et d'utiliser Unity Catalog lorsque des ACL de table à grain fin sont requises.

• Appliquer l’isolation des utilisateurs : Désactivé par default. Activer pour éviter d’utiliser les clusters « Sans isolation ».

• Services de conteneurs : Désactivé par default. Activer pour autoriser les conteneurs Docker personnalisés.

• Listes d'autorisation Git de Repos : Désactivées par default. Envisagez d'activer cette option pour limiter les repository auxquels les utilisateurs peuvent accéder.

• **Protections contre l'exfiltration** : envisagez de désactiver les fonctionnalités pour éviter l'exfiltration de données :

  • Bouton de download pour les résultats du Notebook
  • upload Data using UI
  • Exportation de Notebook
  • Fonction du presse-papiers de table Notebook
  • MLflow Run Artifact download

• Stockage des résultats des Notebooks interactifs : activez le stockage des résultats dans le compte client.

Meilleures pratiques pour les paramètres de Workspace

• Examinez tous les paramètres du Workspace avant le déploiement en production.
• Activez les fonctionnalités basées sur les exigences de sécurité et de conformité.
• Désactiver les fonctionnalités qui pourraient permettre l'exfiltration de données pour les workspaces sensibles.
• Documentez les paramètres du workspace et la justification dans votre runbook.
• Utilisez l'IaC (Terraform) pour gérer les paramètres du Workspace dans la mesure du possible.

Recommandations de compute Workspace

Recommandations

• Utilisez le compute Serverless comme option principale pour SQL, les Notebook, les Job et les LakeFlow Pipelines.
• Créer la configuration initiale pour les clusters et les SQL Warehouses, puis l'affiner en fonction des charges réalistes.
• Gardez le compromis coût/performance à l'esprit lors de la conception de la capacité.
• Utilisez les politiques de cluster pour restreindre les autorisations et appliquer des tailles de clusters raisonnables.
• Utilisez les politiques d'utilisation pour attribuer les coûts Serverless aux départements ou aux projets.
• Surveillez l'utilisation par le biais des tables système et des tableaux de bord prédéfinis.
• Activez le contrôle d'accès Workspace pour les environnements de production.
• Examinez attentivement les paramètres du workspace avant le déploiement en production.

Évitez ces modèles

• Ne créez pas manuellement de clusters sans politiques de cluster en production.
• Ne pas autoriser les tailles de clusters ou les types d'instance illimités sans contrôles.
• Ne sautez pas les tests avec des charges de travail réalistes avant de finaliser la taille des clusters.
• Évitez d'activer des fonctionnalités qui pourraient permettre l'exfiltration de données sans examen de sécurité.
• Ne déployez pas en production sans revoir tous les paramètres du workspace.

Résultats de la phase 8

Après avoir terminé la Phase 8, vous devriez avoir :

• Stratégie de compute définie (compute serverless vs classique pour différentes charges de travail).
• Stratégie de dimensionnement des clusters conçue pour les charges de travail de compute classiques.
• Stratégie de dimensionnement de SQL Warehouse conçue pour les charges de travail BI et analytiques.
• Stratégie de règle de cluster conçue avec des règles pour différentes équipes ou cas d'utilisation.
• Stratégie de politique d'utilisation conçue pour l'attribution des coûts Serverless.
• Approche de monitoring de l'utilisation définie avec des tableaux de bord et des alertes.
• Stratégie de contrôle d’accès conçue pour les objets Workspace.
• Paramètres de Workspace examinés et documentés pour le déploiement en production.
• Stratégie d'optimisation des coûts définie (par exemple, instances Spot, autoscaling, dimensionnement adéquat).

Phase suivante : Phase 9 : Conception de la stratégie d'observabilité

Conseils de mise en œuvre : Pour obtenir des instructions étape par étape sur l'implémentation de votre configuration de compute, consultez Compute.