24 août 2026/Lecture : 9 minData engineering
Snowpipe Streaming : la solution pour diffuser vos données facilement vers Apache Iceberg
Testez le streaming à grande échelle sans infrastructure supplémentaire
Pour savoir si Snowpipe Streaming tient la cadence à plus d’un million de TPS, votre équipe doit pouvoir obtenir rapidement une réponse concrète. Le streaming à grande échelle a la réputation d’être complexe. C’est le workload que les équipes repoussent, car sa mise en place exige des buckets S3, un cluster EKS, des topics Kafka, des politiques IAM, un examen de sécurité et la validation de trois équipes plateforme, chacune ayant déjà son propre backlog. Cette configuration peut nécessiter le provisionnement d’infrastructures supplémentaires et une coordination étroite avant même le début des tests. Démontrer que ces pipelines fonctionnent à grande échelle et absorbent les volumes de production devient généralement un projet à part entière.
Dans notre environnement de démo, un après-midi nous a suffi pour configurer et réaliser cette évaluation. Notre architecture haute performance Snowpipe Streaming vous permet de diffuser des données au format Apache Iceberg™ à plus d’un million de TPS, entièrement au sein de l’infrastructure Snowflake. Un conteneur exécuté dans Snowpark Container Services (SPCS) génère la charge, diffuse les données via le SDK et les écrit dans une table Iceberg gérée par Snowflake. Les données peuvent ainsi être interrogées immédiatement dans Snowflake, avec le contrôle d’accès basé sur les rôles (RBAC), la traçabilité et le masquage appliqués dès leur arrivée. Dans notre environnement de test, un après-midi nous a suffi pour déployer la démo, la tester de bout en bout, mesurer le débit, puis supprimer l’ensemble.
Cet article vous explique concrètement comment créer une démo de streaming de bout en bout vers Iceberg à l’aide de ce dépôt GitHub. Cet exemple utilise Python, mais vous pouvez tester les différentes options du SDK (Java, Python, Node et REST). Vous disposerez ainsi de résultats concrets pour recommander cette solution à votre organisation en toute confiance.
Schéma d’architecture : Le modèle
Notre objectif était de créer une démo entièrement exécutée au sein de l’infrastructure Snowflake. Plusieurs conteneurs Docker exécutés dans Snowpark Container Services (SPCS) génèrent des données de test synthétiques au nombre de transactions par seconde que vous ciblez, puis les diffusent à l’aide du SDK Snowpipe Streaming. Elles sont écrites dans une table Iceberg gérée par Snowflake : un format ouvert, interrogeable quelques secondes après leur arrivée et gouverné dans Snowflake. L’authentification est simple : SPCS injecte dans le conteneur un token OAuth à courte durée de vie que le Streaming SDK utilise automatiquement. Vous n’avez aucun secret à gérer.
Pourquoi utiliser SPCS pour générer la charge ?
Soyons clairs : Snowpipe Streaming n’a pas besoin de SPCS. Le SDK s’exécute partout : sur votre ordinateur portable, une instance EC2 ou un pod Kubernetes.
Son déploiement dans SPCS accélère simplement les tests : le service s’exécute entièrement sur une infrastructure déjà gérée par Snowflake, sans nouveau provisionnement ni validation supplémentaire pour le test.
Écrire directement dans Iceberg
La cible est une table Iceberg gérée par Snowflake. Les lignes sont diffusées via le SDK, puis écrites au format Parquet avec des métadonnées Iceberg gérées par Snowflake. Vous pourrez ensuite la connecter à votre propre volume externe S3 ou la laisser sous gestion Snowflake après l’évaluation. Dans les deux cas, le code reste identique.
Pour l’évaluation, cela réduit la configuration nécessaire. Une table utilisant le stockage géré par Snowflake vous dispense de configurer au préalable un volume externe, une intégration de stockage et les autorisations de stockage cloud.
Lorsque vous serez prêt à passer en production, trois options s’offriront à vous :
- Iceberg géré par Snowflake avec un volume externe : Les fichiers Parquet sont stockés dans votre bucket S3. Un moteur externe lit directement les fichiers Parquet dans S3 et utilise Horizon REST Catalog pour les métadonnées.
- Iceberg géré par Snowflake sur le stockage Snowflake : Les fichiers sont conservés dans le stockage interne de Snowflake. Cette option évite de configurer un volume externe et le stockage cloud associé. Elle exploite les fonctionnalités d’Iceberg pour assurer la compatibilité à l’avenir.
- Table Snowflake native : Cette configuration ne nécessite aucune infrastructure de stockage externe gérée séparément.
Démo : Regardez-la tourner
Lorsque vous exécutez le script de démo, vous voyez le service SPCS démarrer, le producteur générer la charge et le consommateur diffuser les données vers la table Iceberg.
Dans Snowsight, vous pouvez également voir le nombre de lignes grimper, jusqu’à plusieurs millions, et les interroger dès leur arrivée.
Le code : À vous de jouer
Pour mieux comprendre le fonctionnement de l’ensemble, voici un pseudocode qui permet de visualiser les différentes étapes. Le code complet se trouve dans le dépôt, qui contient également des liens vers plusieurs autres démos.
Commencez par créer une table Iceberg gérée par Snowflake et un pipe :
-- 1. The target table
CREATE OR REPLACE ICEBERG TABLE events (
event_id STRING,
event_ts TIMESTAMP_NTZ,
payload VARIANT
)
CATALOG = 'SNOWFLAKE'
BASE_LOCATION = 'events/'
ICEBERG_VERSION = 3;
-- 2. The streaming pipe (extracts typed fields from the SDK's VARIANT payload)
CREATE OR REPLACE PIPE events_pipe
AS COPY INTO events (event_id, event_ts, payload)
FROM (
SELECT $1:event_id::STRING,
$1:event_ts::TIMESTAMP_NTZ,
$1:payload::VARIANT
FROM TABLE(DATA_SOURCE(TYPE => 'STREAMING'))
);
L’architecture haute performance de Snowpipe Streaming prend en charge les versions v2 et v3. Si vous omettez le paramètre, la table utilise la version v2 par défaut.
Passez ensuite au consommateur :
from snowflake.ingest.streaming import StreamingIngestClient
# SPCS injects credentials automatically - no keys, no secrets
props = {
"account": "YOUR_ACCOUNT",
"user": "YOUR_USER",
"role": "STREAMING_SERVICE_ROLE",
"url": "https://YOUR_ACCOUNT.snowflakecomputing.com",
"authorization_type": "SPCS",
"spcs_token_path": "/snowflake/session/token",
}
# Connect to the pipe
client = StreamingIngestClient(
client_name="my_consumer",
db_name="STREAMING_DEMO",
schema_name="PUBLIC",
pipe_name="events_pipe",
properties=props,
)
# Open a channel and stream rows
channel, status = client.open_channel("ch_1")
for i, row in enumerate(generate_load()):
channel.append_row(row, offset_token=str(i))
# Close cleanly
channel.close()
client.close()
Déployez le consommateur dans SPCS à l’aide d’une courte spécification de service. Puis observez l’arrivée des données :
SELECT
COUNT(*) AS rows_landed,
MAX(event_ts) AS latest_event
FROM
streaming_demo.public.events;Java, Node et l’interface REST suivent le même principe : ouvrir un canal, insérer des lignes, puis les envoyer. Le dépôt contient un exemple fonctionnel pour chaque option. Vous pouvez donc tester celle qui correspond à votre stack.
Pour l’essayer, consultez le dépôt.
Attention toutefois : le Streaming SDK utilise un endpoint d’ingestion distinct via HTTPS. Même si vous l’exécutez dans Snowflake, vous devez donc accorder une intégration d’accès externe autorisant le trafic sortant vers *.snowflakecomputing.com.
Bonnes pratiques
Snowpipe Streaming gère les batchs pour vous
Snowpipe Streaming ne crée pas un fichier par ligne. Le SDK envoie les lignes dès que vous appelez appendRows, mais une couche de mise en mémoire tampon côté serveur les absorbe et détermine elle-même le moment du commit. Elle les regroupe automatiquement afin d’éviter l’envoi d’un fichier par ligne.
En complément, Snowflake exécute automatiquement une compaction en arrière-plan pour les Iceberg Tables gérées par Snowflake dont Snowflake est l’unique moteur d’écriture : Les petits fichiers Parquet sont fusionnés en fichiers plus volumineux, tandis que les petits manifests sont également compactés. Vous n’avez rien à planifier ni à exécuter : cette opération fait partie du fonctionnement normal.
Ce que vous pouvez faire :
- Regrouper les lignes en batch côté client avant d’appeler
appendRows: envoyer les lignes une par une implique toujours un aller-retour par ligne. Les regrouper dans un même appel répartit ces frais opérationnels, selon le même principe que la recommandation de Snowflake consistant à compresser et à envoyer davantage de données par requête. - Conserver les canaux ouverts : ouvrez un canal une seule fois par partition source et laissez-le ouvert pendant toute la durée de la tâche, au lieu de l’ouvrir et de le fermer à chaque micro-batch. Il s’agit de la bonne pratique pour Snowpipe Streaming recommandée dans la documentation Snowflake. Elle réduit les frais opérationnels sans perturber le regroupement déjà effectué en arrière-plan.
- Définir
TARGET_FILE_SIZEsur la table : Cette propriété définie au niveau de la table, indépendamment du SDK, indique à Snowflake la taille cible pour les nouvelles écritures et la compaction en arrière-plan, quelle que soit la méthode d’ingestion des données. - Laisser le débit faire son travail : Plus votre nombre de TPS soutenu est élevé, plus la mémoire tampon côté serveur se remplit et se vide rapidement. Pour une taille de fichier donnée, il faut donc trouver le bon compromis entre débit et latence.
Prochaine étape : Iceberg v4
Snowpipe Streaming et la compaction automatique résolvent le problème physique des petits fichiers. Toutefois, des commits fréquents peuvent encore générer des frais opérationnels dans l’arborescence des métadonnées Iceberg. Aujourd’hui, chaque commit écrit un nouveau fichier JSON de métadonnées, une nouvelle liste de manifests et un nouveau manifest, même s’il ne contient qu’un petit fichier. Pour les workloads qui effectuent un commit toutes les quelques secondes, ce traitement répété des métadonnées peut devenir un goulot d’étranglement.
La proposition Iceberg v4 introduit une arborescence adaptative des métadonnées (Adaptive Metadata Tree) afin de réduire cette amplification des écritures. Au lieu de créer un manifest pour chaque petit commit, le manifest racine peut intégrer directement ces commits. Une seule écriture Parquet et un remplacement atomique du pointeur remplacent la chaîne actuelle. Les E/S de métadonnées par commit restent ainsi constantes au lieu d’augmenter avec le nombre de manifests. Pour les workloads de streaming à haute fréquence, cette évolution peut considérablement réduire la latence du streaming.
Le streaming est l’un des cas d’usage phares d’Iceberg v4 : Les workloads qui effectuent un commit toutes les quelques secondes mettent directement en évidence l’amplification des écritures de métadonnées. Les avantages de l’Adaptive Metadata Tree sont donc particulièrement pertinents dans ce contexte. La spécification v4 continue d’évoluer, mais mérite votre attention si le streaming Iceberg figure sur votre feuille de route. Snowflake est fier de contribuer activement à façonner l’avenir de ce format.
Ce que cela change pour votre architecture
Dans cet article, nous avons démontré toute l’efficacité de Snowpipe Streaming pour diffuser des données vers Iceberg. Avec une charge comparable à celle d’une grande plateforme média ou télécom, le workload s’est exécuté dans Snowflake, sans bucket S3, cluster EKS, topic Kafka ni rôle IAM pour cet environnement de test. Nous avons ensuite pu le supprimer à la fin de l’évaluation.
L’infrastructure qui freine habituellement le lancement d’un test de streaming, notamment les buckets, les clusters, l’authentification et les validations, n’est plus un prérequis. Vous pouvez ainsi répondre rapidement à la question : « Cette solution répond-elle à nos exigences ? »
Si vous travaillez dans le Site Reliability Engineering (SRE) ou le data engineering pour une grande plateforme média ou télécom et que le streaming Iceberg figure sur votre feuille de route, commencez par le test, pas par le cycle d’achat. Clonez le dépôt, déployez-le dans SPCS et regardez-le tourner.
- Essayez-le dès maintenant avec le dépôt GitHub
- Pour aller plus loin, consultez la documentation sur l’architecture haute performance de Snowpipe Streaming
