Snowflake : Spark natif et Virtual Warehouses, deux évolutions clés à connaître
Chez Keyrus, nos experts suivent de près les évolutions des technologies data & cloud pour en décrypter les impacts concrets. Dans cet article, Arnaud Col, Tech Advisory Director et Snowflake Data Superhero, revient sur deux nouveautés majeures de Snowflake :
le support du code Spark natif via Snowpark Connect,
et l’évolution des Virtual Warehouses, cœur du moteur de calcul Snowflake.
Deux avancées stratégiques pour optimiser coûts, performances et simplifier la gestion des workloads.
Spark natif dans Snowflake grâce à Snowpark Connect
Pourquoi Snowflake supporte désormais le code Spark
Snowflake propose désormais le support du code Spark natif (en public preview), une avancée attendue par de nombreux utilisateurs. Jusqu’à présent, il fallait passer par Snowpark, impliquant souvent des réécritures de code et des tests de non-régression.
SparkSQL, DataFrame et UDF sans passer par Snowpark
Avec Snowpark Connect, il est possible d’exécuter du SparkSQL, des DataFrames et des UDF directement sur Snowflake.
La soumission d’un job batch Spark se fait via la commande
.snowpark-submitLa récupération d’une session Spark se réalise simplement avec
.snowpark_connect.get_session()
Les prérequis techniques pour utiliser Snowpark Connect (PySpark, Python, Spark)
Pour l’instant, seul PySpark est supporté, avec :
une version Spark supérieure à 3.5,
une version Python supérieure à 3.10.
Le support de Scala et Java est prévu prochainement.
Quels bénéfices pour les clients Snowflake utilisant Spark
Cette nouveauté permet de migrer du code Spark existant vers Snowflake sans réécriture. Les workloads Spark batch peuvent donc être exécutés directement dans l’environnement Snowflake, réduisant ainsi la complexité et la dette technique.
Virtual Warehouses Snowflake : le cœur du moteur de calcul
Virtual Warehouse vs Data Warehouse : comprendre la différence
Contrairement à leur nom, les Virtual Warehouses ne stockent pas de données et ne sont pas des data warehouses. Il s’agit en réalité de clusters de machines virtuelles qui exécutent vos traitements.
Workloads et bonnes pratiques de configuration des Virtual Warehouses
En pratique, on crée souvent un warehouse par workload (catégorie de traitements) afin d’éviter les interférences. Exemple d’organisation :
WH_LOAD pour les chargements,
WH_COMPUTE pour les transformations,
WH_QUERY pour l’exposition des données.
Les trois types actuels de Virtual Warehouses (Gen 1, Gen 2, Snowpark-optimized)
Historiquement, la configuration d’un warehouse reposait sur trois critères :
sa puissance (taille « t-shirt »),
la scalabilité horizontale automatique (1 à 10 nœuds),
le délai avant arrêt/redémarrage automatique.
Aujourd’hui, Snowflake propose trois types de Virtual Warehouses :
Standard (Gen 1)
Standard (Gen 2) : jusqu’à 4x plus rapide sur DELETE, MERGE, UPDATE. Particulièrement adapté à dbt, avec une consommation de crédits légèrement supérieure (20–25 %).
Snowpark-Optimized : avec plus de RAM, idéal pour Snowpark.
Vers les Adaptive Warehouses : performances et optimisation automatique
Demain, Snowflake proposera les Adaptive Warehouses (actuellement en Private Preview). Leur particularité : plus besoin de configurer manuellement la taille. Snowflake ajuste automatiquement le dimensionnement du warehouse selon les requêtes.
Les seules options définies par l’utilisateur :
un plafond de crédits par heure,
une taille maximale par requête.
👉 Exemple concret : Un warehouse LOAD peut gérer des chargements complets de gros fichiers la nuit et de petits incréments en journée. Avec un warehouse classique, il faudrait jongler entre deux configurations. Avec un Adaptive Warehouse, la plateforme s’ajuste automatiquement, optimisant coûts et performances.
Pourquoi ces évolutions Snowflake sont stratégiques
Optimiser les coûts et les performances de vos traitements data
Le support du Spark natif et les nouvelles générations de warehouses permettent de mieux équilibrer consommation de crédits et rapidité d’exécution.
Simplifier la migration et réduire la dette technique
Avec Snowpark Connect, les workloads Spark existants peuvent être déplacés vers Snowflake sans réécriture lourde.
Se concentrer sur la valeur business des workloads
Les Adaptive Warehouses simplifient la configuration technique. Les équipes data peuvent ainsi se concentrer sur leurs workloads, véritables générateurs de valeur métier.
Rendez-vous au Snowflake World Tour Paris
Échanger avec nos experts Keyrus sur Spark et les Virtual Warehouses
Ces nouveautés Snowflake seront au cœur des échanges de la communauté.
Découvrir en avant-première les évolutions Snowflake
📅 Rejoignez nos experts Keyrus lors du Snowflake World Tour Paris, le 7 octobre.
F.A.Q
Qu’est-ce qu’un Virtual Warehouse Snowflake ?
Un Virtual Warehouse dans Snowflake est un cluster de machines virtuelles utilisé pour exécuter les traitements (requêtes, transformations, chargements). Contrairement à son nom, il ne stocke aucune donnée. Les données restent centralisées dans Snowflake, tandis que les Virtual Warehouses apportent la puissance de calcul nécessaire.
Quelle est la différence entre un Virtual Warehouse et un Data Warehouse ?
Un Data Warehouse est une base de données dédiée au stockage et à l’analyse des données. Un Virtual Warehouse Snowflake, lui, est uniquement un moteur de calcul. Il ne contient pas les données, mais exécute les requêtes sur celles stockées dans Snowflake.
Quels sont les types de Virtual Warehouses disponibles dans Snowflake ?
Snowflake propose aujourd’hui trois types de Virtual Warehouses : Standard (Gen 1) Standard (Gen 2), plus rapide (DELETE, MERGE, UPDATE) Snowpark-Optimized, offrant davantage de mémoire pour les traitements Snowpark. Une quatrième génération est en préparation : les Adaptive Warehouses, capables de s’ajuster automatiquement.
Qu’est-ce que Snowpark Connect ?
Snowpark Connect est une fonctionnalité Snowflake qui permet d’exécuter du code Spark natif (PySpark, SparkSQL, DataFrame, UDF) sans passer par Snowpark. Elle simplifie la migration des workloads Spark existants vers Snowflake.
Quels sont les avantages d’exécuter Spark natif dans Snowflake ?
Le principal avantage est de réutiliser du code Spark existant sans réécriture. Cela réduit les coûts de migration, évite des tests de non-régression complexes et accélère le passage vers un environnement Snowflake entièrement intégré.
Quand seront disponibles les Adaptive Warehouses Snowflake ?
Les Adaptive Warehouses sont actuellement en Private Preview. Leur objectif est de supprimer la configuration manuelle des warehouses en ajustant automatiquement leur taille et leur consommation de crédits en fonction des requêtes.