Snowflake en 2026 : architecture, SQL et questions d'entretien data engineer

Les questions d'entretien sur Snowflake vérifient si un data engineer comprend l'architecture découplée de la plateforme, et pas seulement sa syntaxe SQL. La conception multi-cluster à données partagées que Snowflake a inventée sépare le stockage, le calcul et les services en trois couches indépendantes, et cette séparation explique presque chaque décision de performance et de coût qu'une équipe prend sur la plateforme. Ce guide couvre l'architecture Snowflake, les patterns SQL qui gardent les requêtes rapides et économiques en 2026, ainsi que les questions d'entretien qui révèlent une véritable expérience en production.

Architecture Snowflake : stockage, calcul et services cloud

Le trait caractéristique de l'architecture Snowflake est que le stockage et le calcul sont physiquement séparés. Les données résident une seule fois dans une couche de stockage centralisée, adossée à des object stores cloud tels qu'Amazon S3 ou Azure Blob Storage. Un nombre illimité de clusters de calcul peut lire ces mêmes données simultanément sans les copier, une approche que l'équipe d'ingénierie d'origine a baptisée multi-cluster shared data dans l'article SIGMOD de 2016 qui a introduit cette conception.

La couche de stockage conserve les données dans des fichiers immuables, compressés et colonnaires appelés micro-partitions. L'utilisateur ne gère jamais ces fichiers directement. Snowflake les écrit, suit leurs métadonnées et les recycle. La couche de calcul est constituée de virtual warehouses, chacun étant un cluster de serveurs que Snowflake provisionne à la demande. La couche de services cloud se situe au-dessus des deux et coordonne l'ensemble : elle parse le SQL, planifie les requêtes, applique le contrôle d'accès, gère les transactions et stocke les métadonnées qui rendent possibles des fonctionnalités comme le Time Travel et le zero-copy cloning.

Comme ces couches sont indépendantes, un warehouse peut être redimensionné ou supprimé sans toucher un seul octet de données, et le stockage peut atteindre plusieurs pétaoctets sans provisionner le moindre calcul.

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

Supprimer analytics_wh une fois ce script exécuté arrêterait toute la facturation du calcul, tandis que chaque table reste interrogeable dès qu'un nouveau warehouse est créé. Ce découplage est l'idée la plus importante à formuler lors d'un entretien.

Comment les virtual warehouses font évoluer le calcul Snowflake

Un virtual warehouse est un cluster de calcul nommé, dimensionné en unités de type taille de T-shirt : X-Small, Small, Medium, Large, et au-delà. Chaque palier supérieur double à la fois le nombre de serveurs et la consommation de crédits par heure, si bien qu'un warehouse Large coûte quatre fois plus qu'un Small mais termine aussi une requête gourmande en scan environ quatre fois plus vite. Ce compromis linéaire prix/performance signifie que l'option la moins chère est souvent un warehouse plus grand qui tourne moins longtemps.

Il existe deux dimensions de scaling, et les confondre est un piège fréquent en entretien. Le scaling vertical redimensionne un seul warehouse pour accélérer une requête. Le scaling horizontal ajoute des clusters à un warehouse multi-cluster afin de servir davantage de requêtes concurrentes. Un dashboard sollicité par 200 analystes à 9 h a besoin de plus de clusters, pas d'un plus gros ; un backfill nocturne d'un billion de lignes a besoin d'un plus gros, pas de plus de clusters.

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

AUTO_SUSPEND et AUTO_RESUME sont ce qui rend l'ensemble économique. Un warehouse suspendu ne coûte rien, et Snowflake facture à la seconde avec un minimum de 60 secondes. Définir un auto-suspend court sur les warehouses interactifs empêche les clusters inactifs de brûler des crédits entre les requêtes.

Micro-partitions et clustering keys pour un SQL rapide

Snowflake stocke chaque table comme un ensemble de micro-partitions, chacune contenant de 50 à 500 Mo de données non compressées au format colonnaire. Pour chaque micro-partition, Snowflake enregistre dans ses métadonnées la valeur minimale et maximale de chaque colonne. Lorsqu'une requête filtre sur une colonne, l'optimiseur lit ces métadonnées et ignore toute partition dont la plage de valeurs ne peut pas correspondre, un processus appelé partition pruning. C'est pourquoi Snowflake n'a besoin d'aucun index manuel : le pruning s'applique automatiquement sur chaque colonne.

Le pruning fonctionne au mieux quand la colonne de filtre est corrélée à l'ordre dans lequel les données ont été chargées. Une table ingérée par date élague efficacement les requêtes par plage de dates. Quand une grande table est fréquemment filtrée sur une colonne sans lien avec l'ordre de chargement, une clustering key regroupe les lignes apparentées à travers les micro-partitions pour que le pruning reste efficace à mesure que la table grossit.

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

Les clustering keys ne sont pas gratuites : Snowflake exécute un service d'arrière-plan automatique pour les maintenir, et ce service consomme des crédits. La règle empirique consiste à n'ajouter une clustering key qu'aux tables de l'ordre du téraoctet où les query profiles montrent un pruning médiocre. Les tables plus petites élaguent bien d'elles-mêmes, et une clustering key prématurée gaspille de l'argent. Expliquer ce compromis fait souvent la différence entre une réponse de junior et une réponse de senior.

Charger et transformer les données : Snowpipe, Streams et Dynamic Tables

Trois patterns d'ingestion couvrent la plupart des charges de travail. Le COPY INTO en masse charge des fichiers en staging en une seule commande et convient aux jobs batch planifiés. Snowpipe charge les fichiers en continu par micro-batches serverless, déclenchés par des événements de stockage cloud, pour une arrivée en quasi temps réel. Snowpipe Streaming pousse des lignes individuelles via une API à faible latence quand une fraîcheur inférieure à la seconde est nécessaire. Choisir parmi ces options selon les exigences de latence et de taille de fichier est une question d'entretien fréquente, et la bonne réponse commence par « cela dépend de la fraîcheur dont le consommateur en aval a réellement besoin ».

La transformation à l'intérieur du warehouse s'appuyait historiquement sur les Streams et les Tasks. Un Stream capture les changements au niveau des lignes d'une table (change data capture), et une Task exécute du SQL selon un planning pour consommer ces changements et les fusionner en aval.

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

En 2026, les Dynamic Tables sont devenues la façon privilégiée d'exprimer des transformations incrémentales. Au lieu de câbler un Stream à une Task et d'écrire le merge à la main, une Dynamic Table déclare un target lag et une requête, et Snowflake détermine automatiquement le refresh incrémental. Cela supprime la majeure partie du boilerplate d'orchestration tout en gardant les résultats frais.

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

Pour les équipes qui construisent sur des formats ouverts, les tables Iceberg de Snowflake permettent au warehouse de lire et d'écrire des données Apache Iceberg stockées dans le propre bucket cloud du client, ce qui évite le lock-in tout en conservant le moteur de requête et la gouvernance de Snowflake. Beaucoup d'équipes associent Snowflake à dbt pour des transformations versionnées et testées, un workflow détaillé dans le guide des transformations et tests de données avec dbt.

Questions d'entretien Snowflake pour data engineers

Les questions ci-dessous reviennent régulièrement dans les entretiens de data engineering sur Snowflake. Les bonnes réponses rattachent une fonctionnalité à la séparation stockage/calcul plutôt que de réciter de la syntaxe.

Quel problème résout la séparation du stockage et du calcul ? Elle supprime la contention. Les analystes qui font tourner des dashboards, une équipe de data science qui entraîne des features et un job ELT qui charge des données peuvent chacun s'exécuter sur leur propre warehouse contre les mêmes tables sans se disputer les ressources ni copier les données. Le calcul monte en charge pour un job lourd et se suspend à l'inactivité, tandis que le coût du stockage reste stable quel que soit le calcul rattaché.

Comment fonctionnent le Time Travel et le zero-copy cloning ? Les deux reposent sur l'immuabilité des micro-partitions. Comme Snowflake ne réécrit jamais une micro-partition, les versions antérieures restent sur disque pendant la fenêtre de rétention (jusqu'à 90 jours en édition Enterprise). Le Time Travel interroge une table telle qu'elle était à un timestamp passé en pointant vers ces partitions plus anciennes, et CLONE crée une nouvelle table qui référence les mêmes partitions sans dupliquer le stockage tant qu'un des deux côtés n'est pas modifié. Le copy-on-write est ce qui rend le clone d'une table d'un pétaoctet instantané et quasi gratuit.

Quand faut-il définir une clustering key ? Uniquement sur de grandes tables (environ un téraoctet ou plus) fréquemment filtrées ou jointes sur une colonne sans lien avec leur ordre de chargement, et seulement après qu'un query profile a confirmé un pruning médiocre. Le clustering entraîne un coût de maintenance continu en crédits, c'est donc une optimisation délibérée, pas un réglage par défaut.

Comment contrôle-t-on le coût de Snowflake ? Par le dimensionnement des warehouses, un auto-suspend agressif, un nombre de clusters ajusté à la concurrence réelle, et des resource monitors qui plafonnent la dépense en crédits. Un resource monitor peut notifier ou suspendre automatiquement les warehouses une fois un quota atteint.

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

Streams et Tasks ou Dynamic Tables ? Les Dynamic Tables conviennent aux pipelines déclaratifs où l'exigence est une fraîcheur cible et où Snowflake peut gérer le refresh. Les Streams et Tasks restent le bon outil quand la transformation nécessite un contrôle impératif, des effets de bord ou une logique qu'une seule requête ne peut pas exprimer. Savoir où chacun s'inscrit, plutôt que de se rabattre systématiquement sur l'un, témoigne d'une expérience en production.

En quoi l'ELT sur Snowflake diffère-t-il de l'ETL traditionnel ? Le stockage bon marché et le calcul élastique de Snowflake rendent pratique le fait de charger les données brutes d'abord puis de les transformer sur place, le pattern exploré dans le guide d'architecture ETL vs ELT. Les candidats qui préparent la boucle complète peuvent s'entraîner sur le module des patterns ETL et ELT en parallèle du parcours plus large de data engineering.

Conclusion

• L'architecture Snowflake sépare le stockage, le calcul et les services cloud en trois couches indépendantes, et presque chaque réponse de conception se ramène à cette séparation
• Les virtual warehouses évoluent verticalement pour des requêtes uniques plus lourdes et horizontalement pour une concurrence plus élevée ; l'auto-suspend et la facturation à la seconde gardent le calcul inactif gratuit
• Les micro-partitions avec des métadonnées min/max par colonne offrent un partition pruning automatique, raison pour laquelle Snowflake n'a besoin d'aucun index manuel
• N'ajoutez des clustering keys qu'aux tables à l'échelle du téraoctet dont le pruning médiocre est avéré, car la maintenance consomme des crédits
• Adaptez le pattern d'ingestion à la fraîcheur requise : COPY en masse pour le batch, Snowpipe pour les micro-batches continus, Snowpipe Streaming pour une latence inférieure à la seconde
• Privilégiez les Dynamic Tables pour les transformations incrémentales déclaratives en 2026, et réservez les Streams et Tasks à la logique impérative
• Le Time Travel et le zero-copy cloning exploitent tous deux l'immuabilité des micro-partitions et le copy-on-write, rendant les requêtes point-in-time et les clones instantanés bon marché
• Maîtrisez le coût avec des warehouses correctement dimensionnés, un auto-suspend agressif, des clusters ajustés à la concurrence et des resource monitors