Data engineering avec Snowflake : de la source à l'usage, sur une seule plateforme
Ingestion, transformation, orchestration, IA, consommation, gouvernance : le parcours complet d'une donnée dans Snowflake, et les choix qui font une plateforme fiable.
Il y a quelques années, une plateforme data ressemblait à un assemblage : un outil pour extraire, un autre pour charger, un ordonnanceur à part, une base pour stocker, un catalogue ajouté après coup, et autant de contrats, de droits et de points de panne. Snowflake a progressivement rapatrié chacune de ces étapes dans la plateforme elle-même. Le data engineering n'y disparaît pas, il change de nature : on passe moins de temps à faire tenir les tuyaux ensemble, et plus de temps sur ce qui compte, la qualité et le sens des données.
Cet article suit le parcours d'une donnée de bout en bout, de la source jusqu'à celui qui l'utilise, et décrit à chaque étape les briques disponibles et les choix à faire.
Étape 1 : des sources de plus en plus variées
Une entreprise ne manque pas de données, elle en a trop d'origines différentes. On peut les ranger en quatre familles, qui ne se chargent pas de la même façon.
La nouveauté de ces dernières années tient à la dernière partie de la troisième famille : les documents non structurés. Contrats, rapports d'intervention, fiches techniques ou photos n'étaient pas l'affaire de l'entrepôt de données. Avec l'IA générative, ils deviennent une source comme une autre, à condition de les faire entrer dans la plateforme avec les mêmes règles que le reste.
Étape 2 : l'ingestion, choisir le bon tuyau
Snowflake propose trois manières principales de faire entrer les données. Le bon choix dépend d'une seule question : à quelle vitesse la donnée doit-elle être disponible, et sous quelle forme arrive-t-elle ?
Openflow est le service d'intégration géré de Snowflake, bâti sur Apache NiFi. Il fournit des connecteurs prêts à l'emploi vers les applications et les bases de données courantes, en batch comme en continu, pour des données structurées ou non. C'est la réponse à la question qui imposait autrefois un outil tiers : « comment récupérer les données de cette application ? ».
Snowpipe charge automatiquement les fichiers dès qu'ils arrivent dans un espace de stockage (S3, Azure Blob, Google Cloud Storage). Le système qui produit les fichiers n'a rien à savoir de Snowflake : il dépose, Snowpipe charge.
Snowpipe Streaming insère les données ligne par ligne, sans passer par un fichier intermédiaire. C'est le choix pour les flux d'événements et les capteurs, quand quelques secondes de latence comptent.
- Les données arrivent sous forme de fichiers
- Chargement déclenché par l'arrivée du fichier
- Latence de l'ordre de la minute
- Idéal pour les exports réguliers et les dépôts de partenaires
- Les données arrivent ligne par ligne
- Pas de fichier intermédiaire à gérer
- Latence de l'ordre de la seconde
- Idéal pour Kafka, l'IoT et les journaux applicatifs
Openflow se place au-dessus : il fournit les connecteurs vers les sources et s'appuie sur ces mécanismes de chargement.
Un conseil de terrain : quel que soit le tuyau, la donnée doit atterrir telle que la source l'a envoyée, sans transformation. Cette copie fidèle sert de preuve et permet de tout recalculer si une règle métier change.
Étape 3 : transformer avec les Dynamic Tables
Une fois chargées, les données doivent être nettoyées, reliées entre elles et mises en forme pour les usages. La pratique la plus répandue les fait passer par trois couches, nommées d'après leur rôle : Raw, Integration et Presentation. On croise souvent une autre nomenclature, bronze, argent, or, dite « architecture médaillon » : elle a été popularisée par Databricks et ne doit pas être confondue avec les conventions du monde Snowflake, même si l'idée d'un affinage progressif est proche.
Les Dynamic Tables changent la manière de construire ces couches. Au lieu d'écrire le traitement (« chaque nuit, supprimer telles lignes, insérer celles-ci, mettre à jour celles-là »), on écrit le résultat attendu sous forme d'une requête, et on indique la fraîcheur souhaitée, par exemple « pas plus de quinze minutes de retard ». Snowflake se charge du reste : il détecte ce qui a changé en amont et rafraîchit la table, de façon incrémentale quand c'est possible.
- On écrit chaque étape de mise à jour
- On planifie les traitements dans un ordonnanceur
- On gère soi-même les dépendances entre tables
- Une table en retard bloque la chaîne en silence
- On écrit la requête du résultat attendu
- On fixe une fraîcheur cible
- Snowflake déduit les dépendances
- Le rafraîchissement est incrémental quand c'est possible
Les transformations s'écrivent en SQL, en Python avec Snowpark, ou avec dbt, qui peut désormais s'exécuter directement dans Snowflake. dbt apporte ce qui manque souvent à une plateforme : chaque modèle est versionné, testé et documenté, et le même code passe du développement à la qualification puis à la production sans retouche manuelle.
Étape 4 : orchestrer avec Tasks et Streams
Toutes les transformations ne se décrivent pas par une simple requête : appel à une API, envoi d'une alerte, traitement en plusieurs étapes conditionnelles. C'est le rôle des Tasks, qui exécutent du SQL ou des procédures selon un calendrier ou en chaîne, sous forme de graphe de dépendances.
Les Streams les complètent. Un stream mémorise les changements survenus sur une table depuis sa dernière lecture : lignes ajoutées, modifiées, supprimées. Une task peut alors ne s'exécuter que si le stream contient quelque chose. Le pipeline devient déclenché par les données plutôt que par l'horloge : il ne tourne pas, et ne coûte rien, quand rien n'a changé.
- Un stream capte les lignes ajoutées ou modifiées
- Aucun traitement si rien n'a changé
- Une task applique les règles et les contrôles
- Les données rejetées sont isolées et signalées
- Les tables métier sont mises à jour
- Les consommateurs voient une donnée fraîche et contrôlée
En pratique, la règle est simple : Dynamic Tables pour tout ce qui se décrit comme un résultat, Tasks et Streams pour ce qui relève de l'action ou de la logique conditionnelle. Beaucoup de plateformes combinent les deux.
Étape 5 : l'IA au service du data engineer
L'IA intervient à deux niveaux dans le travail de data engineering.
Le premier concerne les données elles-mêmes. Les fonctions IA de Cortex s'appellent directement en SQL : classer un texte, en extraire des informations, résumer, traduire, analyser un document. Un pipeline peut ainsi transformer un rapport d'intervention en PDF en lignes structurées (équipement, panne, action) dans la même chaîne que le reste, sans sortir les données de la plateforme.
Le second concerne le travail de l'ingénieur. Cortex Code est un assistant qui aide à écrire, expliquer et déboguer les requêtes et les pipelines, en connaissant le contexte du compte Snowflake. Il accélère, mais ne remplace pas la revue : un modèle généré se teste et se relit comme un autre.
Pour ce qui demande plus que du SQL, Snowpark permet d'exécuter du Python, du Java ou du Scala au plus près des données, dans des notebooks ou dans des conteneurs (Snowpark Container Services) pour les besoins les plus spécifiques.
Étape 6 : servir tous les consommateurs
Une donnée bien préparée n'a de valeur que si elle est utilisée. La force d'une plateforme unique est de servir des usages très différents à partir de la même couche métier.
Le partage mérite une mention particulière. Avec Secure Data Sharing, un partenaire ou une filiale accède aux données sans qu'aucun fichier ne soit exporté : il lit la donnée vivante, sous les droits définis par le fournisseur, et l'accès se révoque en un instant.
Pour les agents IA, une condition est décisive : qu'ils s'appuient sur des définitions métier explicites, par exemple des vues sémantiques, plutôt que de deviner le sens des colonnes. Un agent n'est jamais plus fiable que la couche de données sur laquelle il répond.
La gouvernance, à chaque étape
La gouvernance n'est pas une étape de plus en fin de chaîne : elle accompagne la donnée du début à la fin. Dans Snowflake, elle est regroupée sous Horizon Catalog.
| Ingestion | Transformation | Consommation | |
|---|---|---|---|
| Lignage | ✓ | ✓ | ✓ |
| Contrôle d'accès | ✓ | ✓ | ✓ |
| Qualité des données | ◐ | ✓ | ◐ |
| Masquage | ✕ | ✓ | ✓ |
| Audit et suivi des coûts | ✓ | ✓ | ✓ |
✓ accès complet ◐ accès restreint ou masqué ✕ pas d'accès
Le lignage montre d'où vient chaque colonne et ce qui en dépend, ce qui permet de mesurer l'impact d'une modification avant de la faire. Les rôles et les politiques de masquage ou de filtrage des lignes garantissent que chacun ne voit que ce qu'il doit voir, y compris un agent IA. Les contrôles de qualité alertent avant qu'une donnée incohérente n'atteigne un indicateur. L'audit et le suivi des coûts répondent aux deux questions qu'une direction finit toujours par poser : qui a fait quoi, et combien cela coûte.
Un stockage ouvert
Dernier point, souvent décisif dans le choix d'une plateforme : la crainte d'enfermement. Snowflake stocke ses tables dans son format natif, mais prend aussi en charge Apache Iceberg, un format de table ouvert reposant sur des fichiers Parquet. Les tables Iceberg peuvent être lues et écrites par d'autres moteurs (Spark, Trino, etc.), et cataloguées via Snowflake Open Catalog, issu du projet open source Apache Polaris.
- Format géré entièrement par Snowflake
- Toutes les optimisations de la plateforme
- Aucune administration du stockage
- Le choix par défaut pour un usage interne à Snowflake
- Format ouvert, fichiers Parquet
- Lisibles par d'autres moteurs
- Stockage dans le compte cloud de l'entreprise
- Le choix quand plusieurs moteurs partagent les données
Le choix n'est pas binaire : une même plateforme peut garder ses tables internes au format natif et exposer en Iceberg celles que d'autres outils doivent lire.
Ce qui ne change pas
Une plateforme qui intègre tout ne dispense pas de méthode, au contraire. Les erreurs classiques restent possibles, simplement plus vite : un entrepôt trop grand qui ne s'éteint jamais, des droits accordés « temporairement » qui ne sont jamais retirés, des modèles modifiés directement en production. Les bonnes pratiques restent les mêmes : des couches claires, trois environnements séparés, des transformations versionnées et testées, des droits construits avec les métiers et un suivi régulier des coûts.
La différence, c'est que ces pratiques s'appliquent désormais à un seul endroit. C'est là que se trouve le vrai gain du data engineering sur Snowflake : moins d'outils à faire tenir ensemble, une seule gouvernance, et plus de temps pour comprendre les données que l'on sert.
À retenir
- Snowflake couvre aujourd'hui tout le parcours de la donnée : ingestion, transformation, orchestration, IA, consommation et gouvernance.
- L'ingestion se choisit selon le rythme et la forme des données : Openflow pour les connecteurs, Snowpipe pour les fichiers, Snowpipe Streaming pour les flux.
- Les Dynamic Tables décrivent le résultat attendu et une fraîcheur cible ; Snowflake gère les dépendances et les rafraîchissements.
- Tasks et Streams orchestrent ce qui relève de l'action et rendent les pipelines déclenchés par les données.
- Cortex met l'IA dans les requêtes SQL et aide l'ingénieur à écrire ses pipelines, sans sortir les données de la plateforme.
- Horizon Catalog gouverne chaque étape, et Apache Iceberg garde le stockage ouvert à d'autres moteurs.
Checklist
- Chaque source a un mode d'ingestion choisi selon son rythme : connecteur, fichier ou flux.
- Les données atterrissent d'abord telles que la source les envoie, sans transformation.
- Les transformations sont organisées en couches et décrites en Dynamic Tables ou en modèles dbt versionnés.
- Chaque Dynamic Table a une fraîcheur cible justifiée par un usage réel.
- Les pipelines conditionnels utilisent Tasks et Streams et ne tournent que si les données ont changé.
- Le lignage, les droits, le masquage et le suivi des coûts sont en place avant l'ouverture aux utilisateurs.
- Les tables partagées avec d'autres moteurs sont identifiées et stockées au format Iceberg.