Snowflake sépare trois couches que vous dimensionnez et facturez presque indépendamment : les services cloud (plan de contrôle), le calcul (virtual warehouses) et le stockage (fichiers colonnaires sur le stockage objet du cloud). C’est l’architecture dite multi-cluster shared data : une seule copie des tables, plusieurs entrepôts qui les lisent en parallèle sans se répliquer.
Services cloud. Authentification, sessions, parsing et optimisation des requêtes, transactions, contrôle d’accès, et surtout les métadonnées des micro-partitions (minima, maxima, nombre de valeurs distinctes). Cette couche tourne en continu, gérée par Snowflake. Une part de son coût est absorbée tant qu’elle reste sous un seuil lié à votre calcul ; au-delà, elle apparaît en crédits de cloud services. En entretien, le signal est de ne pas la confondre avec le warehouse : une requête servie uniquement par le result cache n’allume pas de calcul, mais elle passe quand même par les services.
Calcul. Un virtual warehouse est un cluster éphémère que vous dimensionnez (tailles de t-shirt, éventuellement multi-cluster). Il exécute scans, jointures et agrégations. Il ne détient pas la vérité des données : il les lit depuis le stockage, éventuellement depuis son cache SSD local. Deux warehouses du même compte ne partagent pas ce cache, mais ils voient les mêmes tables. C’est ainsi qu’on isole la BI de l’ETL.
Stockage. Les tables sont découpées en micro-partitions compressées, colonnaires, posées sur S3, Azure Blob ou GCS selon le cloud du compte. Vous ne gérez ni nœuds HDFS ni disques. Le stockage se facture au téraoctet compressé, que les warehouses soient allumés ou non.
Que vous tirez la conséquence opérationnelle : grossir le warehouse n’agrandit pas le stockage, et suspendre le calcul n’efface pas les tables. Beaucoup de candidats récitent « compute et storage découplés » sans savoir dire où vivent les métadonnées, ni pourquoi un second warehouse ne crée pas une seconde copie.
La relance classique : « Où s’exécute l’optimiseur ? » Dans les services cloud, avant que le warehouse ne lise quoi que ce soit. Si le plan décide qu’aucune micro-partition n’est utile, le calcul peut rester presque inactif — et c’est précisément ce que valent les métadonnées.
Snowflake n’est pas « une base sur une VM que l’on scale ». Vous ne choisissez pas d’image machine, vous ne posez pas de replica de lecture. Le partage des données entre warehouses n’est pas de la réplication : c’est la même couche de stockage, adressée par les services cloud.