❄️ Snowflake – Cloud Data Warehouse (SQL, Scalabilité & Secure Sharing)

Qu'est-ce que Snowflake ?

Snowflake est une plateforme de données Cloud (Data Cloud), fournie en mode SaaS (Software-as-a-Service). C'est (principalement) un Data Warehouse (Entrepôt de Données) conçu pour le SQL Analytique (BI).

Il est multi-cloud, ce qui signifie qu'il tourne sur AWS, Azure, ou GCP (vous choisissez la région).

Philosophie (Focus SQL)

Contrairement à Databricks (focus Data Science/Python), Snowflake est "SQL-first". Il est conçu pour les Analystes de Données (BI) qui ont besoin d'exécuter des requêtes SQL (SELECT, JOIN, GROUP BY) très rapides sur des volumes massifs (Téraoctets/Pétaoctets) de données structurées et semi-structurées (JSON).

La Révolution : Séparation Stockage/Compute

L'innovation majeure de Snowflake (1.2) est la séparation complète (brevetée) du Stockage (Storage) et du Calcul (Compute). (Voir 1.2).

C'est le concept fondamental de Snowflake.

[ COUCHE 1 : STOCKAGE CENTRALISÉ ] (1 Seul)
(S3 / Blob Storage) (Données .parquet compressées)
    ▲                ▲
    │ (Lit)          │ (Lit/Écrit)
    │                │
[ COUCHE 2 : COMPUTE (CALCUL) ] (N Clusters)
    │                │
+----------------+ +------------------+
| Virtual (BI)   | | Virtual (ETL)    |
| Warehouse 1    | | Warehouse 2      |
| (Taille: S)    | | (Taille: XL)     |
| (Cluster 1)    | | (Cluster 2)      |
+----------------+ +------------------+

C'est la "fondation" (le "disque dur") de Snowflake. C'est là que les données (Tables) sont stockées.

Stockage Cloud (S3/Blob)

Snowflake n'utilise pas ses propres disques. Il utilise le stockage objet (Object Storage) du fournisseur Cloud (ex: AWS S3, Azure Blob).

Avantage : Scalabilité (illimitée), Durabilité (99.999...%), Coût (bon marché).

Format : Micro-Partitions (Floconné)

Snowflake ne stocke pas vos données en CSV ou JSON. Quand vous chargez (LOAD) des données, il les convertit dans son format interne optimisé (propriétaire) : les Micro-Partitions (voir 3.1).

(Fichier 'ventes.csv')
   │
   ▼ (Commande 'COPY INTO')
[ SNOWFLAKE (Ingestion) ]
   │
   ├─ (Compresse)
   ├─ (Convertit en Colonnes)
   ├─ (Chiffre)
   ├─ (Stocke les Métadonnées)
   │
   ▼
[ S3 / Blob (Stockage Snowflake) ]
  ├─ (Micro-Partition 1.parquet.gz.enc)
  ├─ (Micro-Partition 2.parquet.gz.enc)
  └─ ...

C'est le "muscle" (les "moteurs") de Snowflake. C'est la couche Compute (Calcul).

Virtual Warehouse (Entrepôt Virtuel)

Un "Warehouse" n'est pas un "Data Warehouse". C'est le nom (marketing) de Snowflake pour un Cluster de Calcul (VMs).

C'est un cluster (ex: EC2 sur AWS) dédié au traitement des requêtes (Query Processing). Il n'y a pas de stockage (il est 100% "stateless").

Fonctionnement (SQL)

1. (Utilisateur) SELECT * FROM table.
2. (Couche 3 : Cloud Services) Reçoit la requête.
3. (Couche 3) Démarre le Warehouse (ex: "BI_WH"). (Si éteint, 1-3 sec).
4. (Couche 2 : Warehouse) Exécute la requête :
   • (Lit les Micro-Partitions (données) depuis le Stockage (S3)).
   • (Traite les données en RAM/SSD local (Cache)).
5. (Couche 2) Renvoie le résultat à l'utilisateur.
6. (Après X min d'inactivité) Le Warehouse s'éteint (Suspend) automatiquement (Auto-Suspend).

Facturation : Vous ne payez que lorsque le Warehouse est RUNNING (facturation à la seconde).

C'est le "Cerveau" (Control Plane) de Snowflake. C'est une collection de services (SaaS) gérés par Snowflake.

Responsabilités

• Query Optimizer (Optimiseur) : (Le plus important) Le "cerveau" SQL. Il parse la requête SQL de l'utilisateur, lit les métadonnées (3.2), et génère le plan d'exécution (ex: "Ignorer 99% des partitions, lire 1%").
• Metadata Manager (Métadonnées) : (Le "catalogue") Gère les métadonnées sur les Micro-Partitions (Min/Max, Nb Lignes...).
• Security Manager : Gère l'authentification (MFA) et les autorisations (RBAC, GRANT).
• Transaction Manager : Gère les transactions (ACID).
• Coordinator : Coordonne le démarrage/arrêt des Virtual Warehouses (2.2).

C'est le cœur du stockage Snowflake. Snowflake ne stocke pas les "fichiers" (comme Parquet), il stocke des Micro-Partitions.

Caractéristiques

• Taille : Petites (50-500 Mo, non compressé). (Plus petit que Parquet (128Mo+)).
• Format : Hybride (PAX). Stocke les données en format colonnaire (comme Parquet/ORC) -> (Très rapide pour les scans analytiques SELECT SUM(col)).
• Immuables (Immutable) : Une micro-partition n'est jamais modifiée. (Un UPDATE crée une nouvelle micro-partition (copie) et marque l'ancienne comme "morte"). C'est ce qui permet Time Travel (5.1).
• Métadonnées : Snowflake stocke des métadonnées (Min/Max, Nb Lignes...) sur chaque micro-partition. (Permet le Pruning (3.2)).

Le "Pruning" (Élagage de partitions) est la principale technique d'optimisation (automatique) de Snowflake. C'est ce qui rend les requêtes rapides.

Fonctionnement (Métadonnées MIN/MAX)

Pour chaque micro-partition (3.1), Snowflake stocke (dans la couche Cloud Services) les valeurs Min/Max de chaque colonne de cette partition.

Exemple (Requête)

SELECT SUM(montant)
FROM ventes
WHERE date_commande = '2025-11-10'

Flux (Optimiseur Snowflake) :

1. L'Optimiseur (2.3) lit le WHERE ('2025-11-10').
2. Il scanne uniquement les métadonnées (très rapide) de 10 000 micro-partitions.
3. Partition 1 : (MinDate: '2024-01-01', MaxDate: '2024-01-31') -> Ignoré (Pruned).
4. Partition 2 : (MinDate: '2025-11-09', MaxDate: '2025-11-11') -> Lu (Scanned).
5. Partition 3 : (MinDate: '2025-11-10', MaxDate: '2025-11-10') -> Lu (Scanned).
6. ... (etc.)

Résultat : Au lieu de scanner 10 000 partitions (1 To), le Warehouse (Compute) ne lit que 2 partitions (500 Mo). (Extrêmement rapide).

Problème : Le "Pruning" (3.2) fonctionne mal si les données (ex: date_commande) sont désordonnées (spread) sur toutes les partitions.

La Solution : CLUSTER BY (Tri)

Définir une Clé de Clustering (Clustering Key) (ex: CLUSTER BY (date_commande)) demande à Snowflake de ré-écrire (réorganiser) physiquement les données (en arrière-plan) pour que les valeurs similaires (ex: '2025-11-10') soient colocalisées dans les mêmes micro-partitions.

Résultat : La requête WHERE date_commande = '...' devient encore plus rapide (le Pruning est plus efficace).

-- (Définir la clé de tri (Clustering)
--  sur une table (Grosse)
--  sur la colonne la plus filtrée)
ALTER TABLE ventes CLUSTER BY (date_commande);

-- (Snowflake gère le re-clustering automatiquement
--  en arrière-plan (coût de compute))

(Similaire à Z-ORDER BY dans Databricks/Delta Lake).

La scalabilité verticale (Scale Up/Down) du Compute (2.2) est instantanée (via les "T-Shirt Sizes").

T-Shirt Sizes (Tailles)

Vous choisissez la "taille" (puissance) de votre Warehouse. Chaque taille (au-dessus de XS) double le nombre de VMs (serveurs) dans le cluster (et double le coût/heure).

X-Small (XS) = 1 Serveur
Small (S)    = 2 Serveurs
Medium (M)   = 4 Serveurs
Large (L)    = 8 Serveurs
X-Large (XL) = 16 Serveurs
...
6X-Large     = 512 Serveurs

Usage (Scale Up)

Problème : Ma grosse requête ETL (Job) prend 60 minutes sur un Medium (4 serveurs).

Solution :

-- (Changer la taille (instantané))
ALTER WAREHOUSE ETL_WH SET WAREHOUSE_SIZE = 'Large';

-- (Relancer le Job)
(Le Job prend maintenant ~30 minutes)

-- (Rétrécir)
ALTER WAREHOUSE ETL_WH SET WAREHOUSE_SIZE = 'Medium';

La scalabilité horizontale (Scale Out) (Multi-Cluster) est conçue pour gérer la charge (concurrence).

Le Problème (Concurrence)

Vous avez 1 Warehouse "BI" (Taille Medium). 100 utilisateurs (PDG, Finance...) se connectent en même temps (Lundi 9h00). Le Warehouse (4 serveurs) est saturé. Les requêtes 50 à 100 sont mises en file d'attente (Queued).

Solution (Multi-Cluster)

Vous configurez le Warehouse en mode "Auto-scale" (Multi-Cluster).

CREATE WAREHOUSE BI_WH
  WAREHOUSE_SIZE = 'Medium'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 5
  SCALING_POLICY = 'ECONOMY';

Flux (Lundi 9h00)

1. Les 30 premiers utilisateurs saturent le Cluster 1 (M).
2. Snowflake (Cloud Services) le détecte.
3. Snowflake démarre automatiquement le Cluster 2 (M).
4. Les utilisateurs 31-60 sont routés vers le Cluster 2.
5. Snowflake démarre Cluster 3 (M)... (Jusqu'à MAX_CLUSTER_COUNT = 5).
6. (Quand la charge baisse) Snowflake arrête automatiquement les clusters 5, 4, 3, 2.

L'architecture de séparation (1.2) permet une isolation totale des charges de travail (Workload Isolation).

La "Bonne Pratique" est de créer plusieurs Virtual Warehouses (Compute), chacun dédié à une "persona" (cas d'usage), qui lisent tous les mêmes données (Stockage).

Exemple (Isolation)

[ STOCKAGE (S3) - Tables Ventes ]
    ▲
    ├──────────────── (Lit) ────────────────┐
    │                                        │
+----------------+ +------------------+ +-----------------+
| Warehouse "ETL"| | Warehouse "BI"   | | Warehouse "ML"  |
| (Taille: XL)   | | (Taille: M)      | | (Taille: L)     |
| (Multi-Cluster)  | | (Multi-Cluster)  | | (Single-Cluster)|
+----------------+ +------------------+ +-----------------+
    ▲                ▲                    ▲
    │                │                    │
[ Job ETL (Écrit)] [ Analyste (BI) ]      [ Data Scientist ]

Résultat : Le Job ETL (lourd) sur le Warehouse "ETL" (XL) n'a strictement aucun impact (zéro contention) sur la performance du Dashboard (BI) ou du script (ML).

Le Time Travel est une fonctionnalité (permise par le stockage Immuable (3.1)) qui permet d'interroger (SELECT) l'état d'une table tel qu'il était dans le passé.

La "fenêtre" de rétention (configurable) est de 1 jour (Standard) à 90 jours (Enterprise).

Usage (SELECT ... AT)

-- (Scénario : Un stagiaire vient de 'TRUNCATE' la table...)

-- 1. Requêter les données... il y a 15 minutes
SELECT * FROM users
AT (TIMESTAMP => '2025-11-10 14:00:00'::timestamp_tz);

-- 2. (ou) (Requêter 5 minutes avant l'ID de la requête 'TRUNCATE')
SELECT * FROM users
BEFORE (STATEMENT => '8e5d0c67-05c0-11eb-a1f9-000000000001');

Usage (UNDROP)

Permet d'annuler des erreurs destructrices.

-- (Oups...)
DROP TABLE users;

-- (Pas de panique)
UNDROP TABLE users;

Le Clonage Zéro-Copie (Zero-Copy Cloning) est la capacité de créer une copie (clone) complète d'une base de données ou d'une table (de Pétaoctets) instantanément (quelques secondes) et sans coût de stockage.

Fonctionnement (Métadonnées)

Snowflake ne copie pas les données (les micro-partitions, qui sont immuables). Il copie uniquement les métadonnées (le "pointeur" vers les partitions).

[Table PROD] ── (Pointe vers) ──► [Partition 1, 2, 3]

-- Exécution (instantanée)
CREATE TABLE DEV.users_clone CLONE PROD.users;

[Table PROD] ── (Pointe vers) ──► [Partition 1, 2, 3]
[Table CLONE] ─ (Pointe vers) ──► [Partition 1, 2, 3]

Les deux tables partagent les mêmes données (immuables). Si vous UPDATE le Clone, il crée une nouvelle partition (que seul lui voit).

Usage

Dev/Staging : Créer un environnement de DEV (db_dev) (clone de db_prod) instantanément, avec 100% des données de production, sans doubler les coûts de stockage.

Le Partage Sécurisé est la capacité de "partager" (en lecture seule) une table de votre compte (Provider) avec un autre compte Snowflake (Consumer), sans copier (ETL) les données.

Fonctionnement (Métadonnées)

Le Provider (ex: Météo France) crée un SHARE (Partage). Il GRANT (autorise) SELECT sur sa table "meteo_prod" à ce SHARE. Il autorise le compte du Consumer (ex: IDEO-Lab) à lire ce SHARE.

Le Consumer (IDEO-Lab) "monte" ce SHARE comme une base de données (lecture seule) dans son propre compte.

Usage (Marketplace)

C'est la base du Snowflake Marketplace. Les entreprises (Providers) vendent l'accès (Data Sharing) à leurs datasets (Météo, Finance, Démographie).

Facturation : Le Provider paie le Stockage. Le Consumer paie le Compute (son propre Warehouse) pour requêter les données partagées.

Problème : L'ingestion "classique" (COPY INTO table) nécessite un Warehouse (Compute) actif (coûteux) et est "Batch" (ex: toutes les heures).

Solution (Snowpipe)

Snowpipe est le service d'ingestion "micro-batch" (streaming) et Serverless.

Flux (Événementiel)

1. (Setup) Vous créez un objet PIPE (ex: mypipe) dans Snowflake.
2. (Setup) Vous configurez une notification d'événement (Event) sur S3/Blob (ex: "S3:ObjectCreated").
3. (Runtime) Un nouveau fichier (log_1.json) arrive dans S3.
4. S3 envoie un événement (SNS/SQS) à Snowpipe.
5. Snowpipe (Compute Serverless, géré par Snowflake) "se réveille", lit log_1.json, et l'insère (COPY) dans la table.

Avantage : Serverless (pay-per-file), temps réel (latence < 1 min), pas de Warehouse à gérer.

SnowSQL est le client en ligne de commande (CLI) (similaire à psql ou mysql) pour se connecter à Snowflake et exécuter des requêtes SQL.

Connexion (~/.snowsql/config)

[connections.my_conn]
accountname = abc12345.eu-west-1
username = ideo_user
password = ...
dbname = PROD_DB
warehousename = BI_WH

Usage

# 1. Se connecter (interactivement)
$ snowsql -c my_conn
ideo_user#(BI_WH)@(PROD_DB.PUBLIC)> SELECT ...;

# 2. Exécuter un script (non-interactif)
$ snowsql -c my_conn -f /path/to/script.sql

# 3. Exécuter une commande (-q)
$ snowsql -c my_conn -q "SELECT COUNT(*) FROM users"

Utilisé pour l'administration, les scripts (CI/CD) et l'ingestion (PUT / COPY).

Snowsight (l'interface web "moderne", remplaçant "Classic Console") est l'interface (GUI) principale pour interagir avec Snowflake.

Fonctionnalités

• Worksheets (Feuilles de travail) : L'éditeur SQL (similaire à DBeaver/DataGrip) dans le navigateur.
• Dashboards : Outil de BI (léger) pour créer des graphiques/tableaux (basés sur les Worksheets).
• Data : Explorateur de BDD (Catalogs, Schemas, Tables).
• Admin :
  • Warehouses : Créer/Gérer/Monitorer les Warehouses (Compute).
  • Account : Gérer les utilisateurs, Rôles (RBAC), Sécurité.
  • Activity : Historique des requêtes (Query History). (Indispensable pour le débogage de performance).

Problème : Snowflake est "SQL-first". Les Data Scientists (qui utilisent Python/Scala) ne peuvent pas l'utiliser (ils utilisent Databricks/Spark).

Solution : Snowpark. C'est le "concurrent" de Spark DataFrames. C'est une API (bibliothèque) qui permet aux développeurs d'écrire de la logique (ETL, ML) en Python, Scala, ou Java (au lieu de SQL).

Fonctionnement (Lazy Evaluation)

Le code Python (Snowpark) n'est pas exécuté en Python. Il est traduit (transpilé) en SQL, puis exécuté (côté serveur) par le moteur SQL (Warehouse).

# Code Python (Snowpark)
# (Ressemble à PySpark)
session.table("ventes") \
    .filter(col("montant") > 100) \
    .group_by(col("region")) \
    .agg(sum("montant")) \
    .show()

# SQL (Généré par Snowpark)
SELECT region, SUM(montant)
FROM ventes
WHERE montant > 100
GROUP BY region

Avantage : Permet aux Data Engineers/Scientists de travailler dans leur langage (Python), tout en utilisant le moteur SQL optimisé (Photon) de Snowflake.

Problème : Que faire si la logique ne peut pas être traduite en SQL (ex: appeler un modèle ML (Scikit-learn), une librairie Python complexe) ?

Solution : Code Python Côté Serveur (Server-Side)

Snowpark permet d'envoyer (push) et d'exécuter du code Python (avec ses dépendances pip) côté serveur (sur le Warehouse).

Types

• UDF (User-Defined Function) : Une fonction (Python) qui s'exécute "par ligne" (ex: ma_fonction_python(colonne)).
• Stored Procedure (Procédure Stockée) : Un script Python complet (ex: pour entraîner un modèle ML) exécuté comme une tâche.

-- (Gestion du Contexte)
USE WAREHOUSE BI_WH;
USE DATABASE PROD_DB;
USE SCHEMA SALES;

-- --- Gestion du Compute (Warehouse) ---
CREATE WAREHOUSE ETL_WH
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 600 -- (S'éteint après 10 min)
  AUTO_RESUME = TRUE;

ALTER WAREHOUSE ETL_WH SET WAREHOUSE_SIZE = 'XLARGE';
ALTER WAREHOUSE ETL_WH RESUME; -- (Allumer)
ALTER WAREHOUSE ETL_WH SUSPEND; -- (Éteindre)

-- --- Gestion du Stockage (Tables) ---

-- (Créer une table (Transitoire : 1 jour de Time Travel))
CREATE TRANSIENT TABLE users (
  id INT,
  email STRING,
  ville STRING,
  created_at TIMESTAMP_TZ
);

-- (Clustering Key)
ALTER TABLE users CLUSTER BY (ville, date(created_at));

-- (Ingestion)
COPY INTO users
  FROM @my_s3_stage/users.csv
  FILE_FORMAT = (TYPE = CSV FIELD_DELIMITER = ',');

-- --- Time Travel ---

-- (Requête dans le passé)
SELECT * FROM users
AT (OFFSET => -60*10); -- (Il y a 10 minutes)

SELECT * FROM users
BEFORE (STATEMENT => '8e5d0c67-...'); -- (Avant l'UPDATE)

-- (Annuler un 'DROP')
UNDROP TABLE users;

-- --- Clonage ---

-- (Clone instantané)
CREATE TABLE users_dev CLONE users;

-- --- Data Sharing ---

-- (Provider)
CREATE SHARE sales_share;
GRANT USAGE ON DATABASE PROD_DB TO SHARE sales_share;
GRANT SELECT ON TABLE prod_db.sales.invoices TO SHARE sales_share;
ALTER SHARE sales_share ADD ACCOUNTS = 'consumer_account_id';

-- (Consumer)
CREATE DATABASE db_from_share FROM SHARE provider_account.sales_share;