Snowflake Adaptive Compute : laissez Snowflake dimensionner vos warehouses ❄️

J'ai perdu un compte du nombre de fois où j'ai vu ce pattern : un LOADING_WH en X-Small pour Snowpipe, un TRANSFORM_WH en Large pour dbt, un REPORTING_WH en X-Large pour PowerBI, et un ADHOC_WH en Medium pour les analystes. Quatre warehouses, quatre tailles figées, quatre budgets qui tournent 24/7. Et quand un analyste lance une requête légère sur le REPORTING_WH X-Large, Snowflake facture 40 crédits/heure pour un scan qui aurait pu tenir sur un Small.

La question qui revient toujours : faut-il vraiment choisir la taille de son warehouse ?

Snowflake a lancé Adaptive Compute en private preview au Summit 2025, puis en public preview en avril 2026. La promesse est radicale : Snowflake choisit automatiquement la taille des clusters, leur nombre, et la politique de suspend/resume. Vous n'avez plus à penser à WAREHOUSE_SIZE, MAX_CLUSTER_COUNT, AUTO_SUSPEND ou au dimensionnement manuel.

Le problème : pourquoi le dimensionnement manuel échoue

Le modèle classique des warehouses Snowflake demande à l'architecte de deviner la charge :

CREATE WAREHOUSE REPORTING_WH
  WAREHOUSE_SIZE = 'X-LARGE'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'STANDARD';

Ça paraît raisonnable. En pratique, c'est un cauchemar opérationnel :

• Sous-dimensionnement : vos utilisateurs se plaignent que c'est lent. Vous passez en X-Large pour "être tranquille".
• Sur-dimensionnement : la facture explose. Un X-Large à 40 crédits/heure qui tourne 4h par jour coûte 4 800€/mois, même pour des requêtes qui scannent 2 Go.
• Workloads mixtes : le même warehouse gère des dashboards PowerBI (légers) et des rechargements dbt (lourds). Aucune taille fixe ne convient.
• Consolidation impossible : regrouper 4 warehouses en 1 nécessite de changer les noms codés en dur dans les pipelines, les scripts, les connexions BI. Risqué.

Le résultat : la plupart des plateformes que j'audite ont 8 à 15 warehouses, dont 60% sont surdimensionnés.

Adaptive Compute : le changement de paradigme

Adaptive Compute transforme le warehouse d'un objet à dimensionner en un service qui s'autorégule.

Ce que Snowflake gère pour vous

La conversion : une seule commande

-- Convertir un warehouse standard en Adaptive Warehouse
ALTER WAREHOUSE REPORTING_WH SET WAREHOUSE_TYPE = 'ADAPTIVE';

C'est tout. Pas de downtime, pas de renommage, pas de changement dans vos pipelines. Les noms, les politiques, les autorisations et la structure de refacturation restent identiques.

Le pool de ressources partagées

La différence fondamentale : dans un warehouse classique, chaque cluster est isolé. Un X-Large avec une seule requête légère gaspille 39 slots de calcul. Avec Adaptive Compute, toutes les requêtes sur tous les Adaptive Warehouses d'un compte sont routées vers un pool de ressources partagées. Snowflake alloue dynamiquement la bonne taille de cluster à chaque requête.

┌─────────────────────────────────────────────────────┐
│              Pool de ressources partagées             │
│                                                      │
│   ┌────────┐  ┌────────────┐  ┌──────────┐         │
│   │ Small  │  │  X-Large   │  │  Medium  │         │
│   │ (léger)│  │  (lourd)   │  │ (moyen)  │         │
│   └────────┘  └────────────┘  └──────────┘         │
│                                                      │
│   → Routage intelligent par query                    │
│   → Pas de cluster isolé qui gaspille                │
└─────────────────────────────────────────────────────┘

Ce que ça change en pratique

1. Fini le débat sur la taille du warehouse

Avant, chaque nouveau workload déclenchait une discussion :

"On met ça sur quel warehouse ? Le Large ou le X-Large ?"

Avec Adaptive Compute, la réponse est : peu importe. Snowflake va ajuster. Vous créez un Adaptive Warehouse par contexte métier (reporting, transformation, adhoc), et Snowflake dimensionne chaque requête individuellement.

2. La consolidation devient safe

Le frein principal à la consolidation des warehouses, c'était le risque de casser les pipelines. Avec Adaptive Compute, vous convertissez vos warehouses existants un par un :

-- Étape 1 : convertir le warehouse de reporting
ALTER WAREHOUSE REPORTING_WH SET WAREHOUSE_TYPE = 'ADAPTIVE';

-- Étape 2 : convertir le warehouse de transformation
ALTER WAREHOUSE TRANSFORM_WH SET WAREHOUSE_TYPE = 'ADAPTIVE';

-- Étape 3 : consolider les workloads adhoc vers le reporting
-- (les noms restent, les pipelines ne cassent pas)
GRANT USAGE ON WAREHOUSE REPORTING_WH TO ROLE ADHOC_ROLE;

Les noms ne changent pas. Les permissions restent. Les outils BI et les scripts qui référencent REPORTING_WH continuent de fonctionner.

3. Le FinOps reste pilotable

C'est la peur numéro 1 : "si Snowflake dimensionne tout seul, comment je contrôle mes coûts ?"

Adaptive Compute est compatible avec les outils FinOps existants :

-- Les Budgets fonctionnent sur les Adaptive Warehouses
CREATE BUDGET ADAPTIVE_BUDGET
  CREDIT_QUOTA = 2000
  FREQUENCY = MONTHLY
  NOTIFY_AT = (75, 90, 100);

-- Les Resource Monitors aussi
CREATE RESOURCE MONITOR ADAPTIVE_MONITOR
  CREDIT_QUOTA = 5000
  FREQUENCY = MONTHLY
  NOTIFY_AT = (75, 90, 100);

-- Les vues ACCOUNT_USAGE donnent la granularité habituelle
SELECT warehouse_name, credits_used, queries_executed
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_type = 'ADAPTIVE'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP());

Les 5 pièges à éviter

Piège 1 — Convertir tous les warehouses d'un coup

Commencez par le warehouse le moins critique. Convertissez, observez 48h via WAREHOUSE_METERING_HISTORY, vérifiez les performances et les coûts, puis convertisez le suivant.

Piège 2 — Ignorer les workloads Snowpark

Les workloads Snowpark (Python, Java) ont des patterns de mémoire différents. Si vous avez un SNOWPARK-OPTIMIZED warehouse, testez la conversion sur un workload de dev avant la prod.

Piège 3 — Ne pas monitorer le Query Acceleration Service

Adaptive Compute s'appuie sur le Query Acceleration Service (QAS). Surveillez QUERY_ACCELERATION_HISTORY pour comprendre quelles requêtes sont accélérées et lesquelles ne le sont pas :

SELECT query_id, credits_used, files_scanned, query_text
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY credits_used DESC
LIMIT 20;

Piège 4 — Garder les anciens Resource Monitors inactifs

Quand vous consolidez des warehouses, les anciens Resource Monitors attachés aux warehouses supprimés deviennent orphelins. Nettoyez-les :

SHOW RESOURCE MONITORS;
-- Vérifiez ceux qui ne sont plus attachés à aucun warehouse actif
DROP RESOURCE MONITOR OLD_ADHOC_MONITOR;

Piège 5 — Ne pas communiquer avec les équipes

Le passage en Adaptive Compute change la façon dont les équipes raisonnent sur les performances. Une requête qui prenait 30 secondes sur un X-Large peut maintenant prendre 45 secondes sur un Small adapté — c'est normal et c'est moins cher. Formez vos équipes à regarder le coût par requête plutôt que le temps d'exécution brut.

Le bilan : avant vs après

Sur une plateforme que j'ai migrée récemment (6 warehouses, dont 4 surdimensionnés) :

Quand NE PAS utiliser Adaptive Compute

Adaptive Compute n'est pas une réponse universelle. Trois cas où je recommande de rester en warehouse standard :

1. Workloads batch nocturnes avec SLA strict : si votre recharge dbt doit finir avant 6h, un warehouse standard en X-Large avec AUTO_SUSPEND = 60 donne plus de prévisibilité.
2. Coûts très maîtrisés sur un workload homogène : si un warehouse ne fait qu'une seule chose (ex: un seul dashboard PowerBI), un Small standard bien calibré peut être moins cher qu'un Adaptive qui sur-provisionne par sécurité.
3. Conformité et isolation : certains contextes réglementaires exigent que les workloads soient strictement isolés. Le pool partagé d'Adaptive Compute peut poser question.

Conclusion

Le dimensionnement des warehouses est l'une des tâches les plus chronophages et les moins valorisantes du métier de Data Architect. Adaptive Compute ne supprime pas le besoin d'expertise — il le déplace vers où il compte vraiment : la gouvernance, le monitoring, et le FinOps stratégique.

Si vous avez déjà corrigé les 5 erreurs de costing de mon article précédent, Adaptive Compute est le prochain levier. Si ce n'est pas le cas, commencez par là : on ne dimensionne pas intelligemment ce qui est mal configuré à la base.