Snowflake Data Engineering

 Au cours des dernières années, Snowflake a ajouté plusieurs fonctionnalités clés pour orchestrer des flux de transformation de données au sein même de la plateforme. Avec l’arrivée en 2019 des Tasks, et en 2022 des DAGs, il devient possible de créer des pipelines de commandes SQL orchestrées directement dans Snowflake. Plus besoin d’utiliser un orchestrateur externe, parfois coûteux et nécessitant une configuration supplémentaire pour accéder aux données dans Snowflake.

En 2022, Snowflake a également lancé Snowpark, une API permettant de traiter les données Snowflake à l’échelle depuis Python, Java et Scala. Avec une interface similaire à Spark, Snowpark dépasse les contraintes du SQL tout en profitant du calcul distribué sur les ressources Snowflake. Grâce aux Stored Procedures en Python, Java ou Scala, ces langages s’intègrent aussi aux DAGs Snowflake.

En 2023, l’arrivée du Logging et du Tracing depuis ces Stored Procedures a permis de monitorer les pipelines, une fonctionnalité essentielle pour garantir la stabilité d’un environnement de production.

Toutefois, développer un pipeline ETL nativement sur Snowflake présente certaines limitations, surtout en comparaison avec des outils ETL plus matures comme DBT ou Airflow.

• Maturité technique : l’API Snowpark est complexe à utiliser, évolue beaucoup, et la documentation reste limitée. Tester un ETL Snowflake de manière unitaire ou intégrale est difficile, et certains bugs dans une Stored Procedure peuvent être compliqués à investiguer.
• Contrôle de version et déploiement : bien que l’intégration Git soit désormais disponible pour le grand public, elle est récente. De plus, l’API Python pour la gestion des objets Snowflake, comme les Tasks et DAGs, est encore en phase de preview.
• Interfaçage externe : les ressources de calcul Snowflake ne sont pas directement connectées à Internet. Faire un appel API extérieur nécessite une configuration supplémentaire (Network Rule, Security Integration, External Access Integration). Ces requêtes passent par plusieurs éléments de réseau, rendant l’investigation des problèmes de latence complexe.

L’écosystème Snowflake est néanmoins en évolution rapide et pourrait devenir un service robuste pour le Data Engineering dans les années à venir.

Le point de vue Theodo

Aujourd’hui, notre recommandation est plutôt d’utiliser Snowflake comme un puissant moteur SQL et d’orchestrer ses transformations avec des services extérieurs plus matures (comme une stack DBT/Airflow). Dans les cas où l’industrialisation nécessaire est faible ou si l’on souhaite disposer d’une plateforme unique et cohérente, les outils ETL de Snowflake peuvent néanmoins être suffisants.