BDC sizing et capacité
À jour au 2026-08-16
Dimensionner BDC = assez de capacité pour la charge sans payer de marge inutilisée; en modèle consommation (M032) le mauvais sizing coûte dans les deux sens (sous = lent/SLA-raté/méfiance, sur = gras permanent). Piloté par la charge, pas les sièges : trois classes passent à l'échelle sur des axes différents — pipelines planifiés (batchables), requêtes/stories interactives (concurrence/latence), eng/ML Databricks (en pointe, M034); un seul nombre pour les trois est l'erreur classique. Estimation T-shirt d'abord, puis right-sizing sur télémétrie réelle (M045) après 4-6 semaines — ne pas traiter l'estimation initiale comme finale. Concevoir pour l'élasticité (monter pour la clôture de fin de mois, descendre après) pas une capacité de pointe permanente. Le sizing stockage suit le tiering d'historique (M071) — dimensionner l'ensemble chaud+tiède, pas l'archive 12 ans. Honnête : le sizing est une estimation raffinée par la réalité + un point de contrôle, pas de fausse précision. Contrôle facture + UX simultanément.
Ce que vous apprendrez
- Séparer les trois classes de charge BDC — pipelines planifiés, requêtes interactives, ML Databricks — et dimensionner chacune sur son propre axe plutôt qu'avec un chiffre unique
- Construire un plan de sizing T-shirt conservateur avec un point de contrôle de right-sizing défini sur la télémétrie réelle (M045)
- Concevoir la capacité pour l'élasticité autour des fenêtres de pointe (clôture mensuelle/trimestrielle) plutôt que payer une capacité de pointe permanente toute l'année
- Cadrer le sizing du stockage sur l'ensemble de travail chaud+tiède (M071) et défendre une recommandation de sizing devant un platform owner sans fausse précision
Aperçu du module
Dimensionner un environnement BDC est la discipline de provisionner assez de capacité pour répondre à la charge sans payer pour de la marge que personne n'utilise — et dans une plateforme à tarification consommation (module compagnon M032), se tromper est coûteux dans les deux sens. Sous-dimensionner et les requêtes rampent, les pipelines ratent les SLA, les utilisateurs perdent confiance; sur-dimensionner et la facture porte un gras permanent. L'approche senior est un right-sizing fondé sur les preuves qui démarre conservateur et se raffine sur la télémétrie réelle, pas une estimation en un coup.
Piloté par la charge, pas par les sièges. L'ancienne question de sizing SAC/BW était « combien d'utilisateurs ? » La question BDC est « quelles charges, à quelle concurrence, à quel volume de données ? » Trois classes de charge pilotent la capacité : les pipelines planifiés (prévisibles, batchables), les requêtes/stories interactives (sensibles à la concurrence, bornées par la latence), et l'ingénierie/ML Databricks (en pointe, lourd en compute — module compagnon M034). Chacune passe à l'échelle sur un axe différent; dimensionner un seul nombre pour les trois est l'erreur classique.
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.