Snowflake Gen2 Warehouses : la vitesse vaut-elle vraiment son prix ?

Les warehouses Gen2 tirent parti d'un matériel plus rapide proposé par les fournisseurs cloud sous-jacents (AWS, GCP). En complément, l'équipe Snowflake a développé des optimisations logicielles spécifiques aux warehouses Gen2 qui apportent des gains supplémentaires en performance et en coût. Quasiment toutes les requêtes bénéficient des améliorations matérielles, et certains workloads profitent en plus des optimisations logicielles.

Les warehouses Gen2 ne sont aujourd'hui disponibles que dans un nombre limité de régions, mais un déploiement plus large devrait suivre rapidement. Consultez cette page pour vérifier si Gen2 est disponible dans votre région.

Améliorations matérielles

Les Virtual Warehouses Gen2 de Snowflake s'exécutent sur l'infrastructure de calcul de votre fournisseur cloud, par exemple des instances EC2 ou des machines virtuelles. Avec le temps, ces fournisseurs renouvellent leurs instances avec du matériel plus récent. AWS, par exemple, a récemment lancé les processeurs ARM Graviton4. Bien que Snowflake ne précise pas le matériel exact utilisé, on peut raisonnablement supposer qu'il s'appuie sur les dernières offres de chaque fournisseur. Ces évolutions matérielles incluent des lectures disque local plus rapides, des performances CPU accrues et un débit réseau supérieur, autant d'éléments qui se traduisent par de meilleures performances de requête dès le départ.

Améliorations logicielles

Snowflake a également annoncé plusieurs optimisations logicielles spécifiques qui accélèrent les workloads DML (c'est-à-dire les jobs qui fusionnent ou mettent à jour des données dans les tables) ainsi que certaines requêtes complexes.

Comme nous le verrons dans les résultats de notre analyse, ces améliorations logicielles sont vraisemblablement à l'origine des gains de performance les plus marqués.

Comme les warehouses Gen2 fonctionnent sur du matériel plus récent et plus performant, ils sont plus chers. Comme le montre la grille tarifaire ci-dessous (source), les warehouses Gen2 sont 35 % plus chers sur AWS et GCP, et 25 % plus chers sur Azure.

Cela a des implications majeures à peser avant tout basculement. Même si les requêtes s'exécutent plus vite, encore faut-il que la réduction du temps de calcul compense la hausse du tarif. Pour compliquer encore les choses, la plupart des praticiens configurent leurs warehouses pour qu'ils se suspendent après 60 secondes d'inactivité. Vous paierez donc le tarif plus élevé pendant ce temps d'inactivité — un facteur à intégrer à votre analyse.

Calcul du seuil de rentabilité

Puisque les requêtes s'exécutent plus vite sur Gen2 et que vous êtes facturé au tarif supérieur pendant moins de temps, le calcul du seuil de rentabilité est le suivant :

Réduction de temps requise (%) = 1 - (1 / Facteur d'augmentation du prix)

Sur Azure, une réduction de 20 % du temps d'activité du warehouse est nécessaire pour atteindre l'équilibre.

• 1 - (1 / 1,25) = 0,20

Sur AWS, une réduction de 25,9 % du temps d'activité du warehouse est nécessaire pour atteindre l'équilibre.

• 1 - (1 / 1,35) = 0,259

J'ai réalisé les benchmarks sur AWS. Par conséquent, pour rester neutre en termes de coût, il faut que les performances progressent d'au moins 25,9 %.

N'oubliez pas la période de facturation minimum d'une minute

Gardez en tête qu'à chaque reprise d'un warehouse, vous êtes facturé pour 60 secondes. Si une requête passe de 30 secondes en Gen1 à 15 secondes en Gen2, vous ne réalisez aucune économie : vous payez plus. À vous de juger si les gains de performance justifient le surcoût.

Le scénario d'économie idéal : des workloads qui durent plus d'une minute ET dont la réduction de temps dépasse le seuil de rentabilité indiqué ci-dessus.

Le tableau ci-dessous résume ce concept.

Créer un nouveau warehouse Gen2, ou convertir un warehouse existant en Gen2, est très simple : il suffit de passer le paramètre resource_constraint à l'instruction create ou alter. Voici un exemple de chaque :

-- create new
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alter existing
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Snowflake est livré avec une base d'exemple contenant le dataset TCP-H. TCP-H est un jeu de données défini par le Transaction Processing Performance Council pour benchmarker les workloads analytiques.

Dans Snowflake, vous trouverez ces schémas dans la base snowflake_sample_data :

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SF signifie Scale Factor. SF10 est 10 fois plus volumineux que SF1, et ainsi de suite. Nous avons testé différents types de workloads sur SF10, SF100 et SF1000.

Nous avons couvert trois scénarios principaux pour nos benchmarks :

1. dbt : construction d'un projet dbt composé entièrement de modèles de tables et de tests. L'objectif : déterminer si les projets dbt, très largement utilisés sur Snowflake, sont de bons candidats pour les warehouses Gen2.
2. Requêtes select : nous simulons ici ce qui se produit dans un outil de BI ou d'autres applications côté utilisateur.
3. Workloads DML : la mise à jour et la fusion de nouvelles données dans Snowflake est un workload courant pour les équipes data engineering. Nous avons testé différents scénarios DML (updates, merges, etc.) pour en mesurer l'impact.

dbt

Configuration

Nous avons forké et mis à jour un projet dbt existant qui fonctionne avec les datasets TCPH de Snowflake. Notre dépôt est disponible ici.

Nous avons exécuté le projet dbt en pleine charge sur chaque dataset, avec des warehouses de différentes tailles, et comparé Gen1 et Gen2. Nous avons utilisé des warehouses plus petits sur les petits datasets et des plus grands sur les plus volumineux, afin de simuler un scénario réaliste.

Chaque itération a été construite dans un schéma vierge pour éviter le cache et conserver séparément les résultats de chaque test. Chaque build exécute 16 modèles de tables et 43 tests de données (dbt build --exclude tag:merge-test).

Résultats

Voici les résultats :

Le travail effectué dans ce projet dbt correspond à environ 97 % de requêtes CTAS (modèles de tables) et 3 % de tests dbt (requêtes select simples).

Sur cette base, pour les modèles de tables dbt de ce projet précis, le gain de performance ne suffit pas toujours à justifier le surcoût de 35 %.

Il est également intéressant de noter que le warehouse 4XL Gen2 a affiché un temps de démarrage à froid très long, supérieur à 5 minutes, alors que le 4XL Gen1 démarrait immédiatement. Comme le temps de reprise du warehouse n'est pas facturé, nous l'avons exclu du résultat en pré-démarrant le warehouse avant l'exécution de dbt. Les délais de provisionnement des warehouses ne posent généralement pas problème pour les jobs ETL exécutés de nuit, mais cela mérite d'être souligné.

Instructions select simples

Nous avons exécuté un échantillon de requêtes select issues des datasets TPCH pour simuler ce qui se produit dans un outil de BI ou d'autres applications côté utilisateur. Les requêtes exactes utilisées sont liées dans le tableau. Voici les résultats :

La requête Select, Aggregate est disponible ici.

La requête Select, join, aggregate est disponible ici.

Ces instructions select affichent d'excellents gains de performance et toutes permettent d'économiser sur Gen2 à la seconde près. À noter : puisque ces requêtes côté utilisateur doivent être rapides, on se heurte à la subtilité de la période de facturation minimum de Snowflake. Si les requêtes durent moins de 60 secondes et/ou que le warehouse reste inactif sur de longues périodes (ce qui est fréquent dans les outils de BI), Gen1 reste recommandé, sauf si vous cherchez à optimiser spécifiquement la vitesse et pouvez absorber le surcoût.

Il faut aussi mentionner que les warehouses Gen2 ouvrent la voie à une réduction de taille. Par exemple, si vous divisez par deux le temps des requêtes avec Gen2 mais que les coûts grimpent à cause d'un temps d'inactivité plus onéreux, vous pouvez très bien diviser la taille de votre warehouse par deux, conserver les mêmes performances à moindre coût et réaliser des économies significatives.

DML : mise à jour de grandes tables

Les mises à jour de cette section sont toutes des updates simples de type update table <tbl> set column <col> = value. Notez que même si l'on ne met à jour qu'une seule colonne, Snowflake doit réécrire l'intégralité de la micro-partition pour la ligne concernée. Concrètement, ces deux commandes demandent la même quantité de travail à Snowflake :

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

Nous avons exécuté trois scénarios :

• Un update sans clause where sur 6 milliards de lignes.
• Un update sélectif sur la même table, où seulement 2,4 millions de lignes (0,04 % de la table) sont mises à jour.
• La mise à jour d'une seule ligne.
• Les instructions SQL sont disponibles ici.

Les résultats me paraissent assez concluants : les warehouses Gen2 excellent sur les updates filtrés, probablement grâce aux optimisations logicielles spécifiques publiées par Snowflake.

Analysons plus en détail la requête qui affiche un delta de coût de -79 % pour comprendre l'origine d'une telle amélioration.

La capture d'écran montre une réduction de 99 % des octets écrits !

(0,16 Go – 16,56 Go) / 16,56 Go = -99 %

DML : requêtes merge

Configuration

Contrairement aux updates simples ci-dessus, les requêtes Merge mettent à jour les enregistrements de la cible en fonction d'enregistrements provenant d'une source. Dans ce cas, une jointure est utilisée pour mettre à jour les enregistrements correspondants et insérer les nouveaux.

Les requêtes merge avec n % de lignes mises à jour sont des modèles incrémentaux dbt. Elles s'exécutent via dbt run -s pre_merge+ en modifiant le filtre de limite de lignes à la ligne 22. Cela reproduit une situation incrémentale réelle, où seule une fraction des données est nouvelle ou mise à jour. Pour modifier le pourcentage de données mises à jour, on change cette ligne puis on exécute le modèle ainsi que le modèle incrémental aval.

Les tâches Merge, toutes les lignes mises à jour proviennent de cette requête, qui met à jour chaque ligne du dataset.

Gardez à l'esprit que le dataset SF10 contient environ 60 millions de lignes et SF100 environ 600 millions de lignes.

Résultats

Les résultats ci-dessus démontrent clairement que les requêtes merge mettant à jour un petit nombre d'enregistrements bénéficient d'une amélioration de performance bien supérieure à celle des merges en pleine charge.

La preuve se trouve dans le profil de requête, qui révèle plusieurs détails notables. D'abord, la communication réseau a chuté significativement, passant de 41 % à 13 %. Ce changement s'explique probablement par la réduction spectaculaire des octets écrits — de 1,6 Go à seulement 4,65 Mo. Cela suggère que Snowflake a peut-être amélioré la compression ou optimisé la manière dont les données transitent sur le réseau. Puisque les deux requêtes ne mettent à jour que 100 lignes, cela conforte l'idée que Gen2 intègre des optimisations spécifiques pour écrire les données plus efficacement.

Une anomalie

La seule anomalie (à l'avant-dernière ligne, avec seulement 1 % d'économies) est particulièrement intéressante car Snowflake indique que 99,5 % d'octets en moins ont été écrits. Plusieurs explications sont possibles, notamment le throttling S3 et la vitesse réseau.

Tous les résultats précédents sont présentés à la seconde près. Mais comme indiqué plus haut, le temps d'inactivité après l'exécution des requêtes est un élément à intégrer. Prenons un scénario simple. Dans le tableau ci-dessous, nous supposons que Gen2 exécute une requête en 50 % de temps en moins par rapport à Gen1. Hypothèse très généreuse, mais restons simples. Supposons également qu'une auto-suspension de 60 secondes soit configurée. Cela nous donnerait :

Bien sûr, plus le workload tourne longtemps, moins cet impact pèse. Le tableau ci-dessous illustre la diminution de cet impact à mesure que la durée des requêtes augmente :

Ce phénomène peut s'exprimer sous forme de fonction :

% temps d'inactivité = [secondes d'auto-suspension] / ([Temps de requête] + [secondes d'auto-suspension])

Pour les clients Snowflake qui cherchent à optimiser la performance, l'impact du temps d'inactivité est négligeable comparé au coût de mobiliser un data engineer pour affiner les requêtes — et consommer des crédits supplémentaires durant cet exercice ! Mais le temps d'inactivité reste un élément à considérer.

Examen des résultats agrégés

L'examen des résultats agrégés peut être trompeur car il est fortement influencé par le nombre de requêtes exécutées dans chaque catégorie et chaque taille de warehouse. Il masque aussi le fait que certaines requêtes au sein d'une catégorie peuvent afficher des résultats très différents de l'agrégat.

Malgré cela, observer les données agrégées reste utile car cela permet de constater que l'évolution des coûts et des performances varie fortement.

Vous trouverez ci-dessous les résultats des tests précédents, consolidés pour une lecture rapide.

La leçon à retenir : expérimentez toujours avec votre propre dataset pour voir comment Gen2 se comporte sur vos cas d'usage. Comme pour la plupart des sujets cloud, il est très difficile de dire quel outillage est universellement moins cher ou meilleur. Tout dépend du cas d'usage.

Mais quelques enseignements clés se dégagent :

• Nous disposons désormais d'un levier sans effort pour accélérer les requêtes et, le plus souvent, réduire les coûts.
• Les requêtes select simples figurent parmi les meilleures performances de nos tests, avec 26 % d'économies.
  • En revanche, elles peuvent finir par coûter plus cher si elles s'exécutent sur des warehouses non saturés pendant moins que la période de facturation minimum.
  • Gardez à l'esprit qu'il peut être tout à fait acceptable de payer 10 % de plus (mettons 10 000 $ supplémentaires par an) pour une amélioration de 20 % sans effort destinée à tous vos utilisateurs métier. Mettez cela en regard du temps qu'il vous faudrait pour réaliser ces optimisations vous-même.
• Gen2 surclasse nettement Gen1 sur les updates ciblés et les requêtes select simples impliquant des scans complets de tables.
• Gen2 n'est pas nécessairement moins cher pour vos modèles de tables dbt classiques. Cela s'explique probablement par la réécriture de toutes les partitions de données via create or replace table as. En revanche, il peut être moins cher et plus rapide sur les modèles incrémentaux qui s'appuient sur des instructions merge.

À mon sens, un excellent cas d'usage pour les warehouses Gen2, c'est lorsque votre warehouse actuel est saturé et que vous envisagez de l'agrandir, par exemple de Medium à Large. Au lieu de passer à Large où chaque crédit coûte 100 % plus cher, essayez plutôt un Medium Gen2 : vous ne payez que 35 % de plus par crédit. Personnellement, je commence à voir Gen2 comme un demi-palier entre chaque taille de warehouse.

• Les économies totales s'élèvent à 2 % — mais ce chiffre est fortement tiré vers le bas par les deux workloads les plus volumineux.
• En excluant les deux plus gros consommateurs de crédits, les économies totales atteignent 7 %.

En discutant de nos résultats de benchmark avec un interlocuteur de chez Snowflake, ce dernier a fait une remarque qui nous a marqués : la seule chose qu'un benchmark vous dit, c'est à quelle vitesse le benchmark s'est exécuté. De nombreux facteurs entrent en jeu dans l'impact réel sur votre workload de production.

• Absence de concurrence : la plupart des benchmarks tournent sur des warehouses non saturés, où la concurrence n'est pas un enjeu.
• Bruit transitoire : la même requête exécutée dans les mêmes conditions peut varier d'environ 10 % en plus ou en moins si elle est rejouée à un autre moment, en raison de la variabilité naturelle de l'infrastructure cloud sous-jacente (incidents transitoires, throttling du service AWS S3, etc.).

Nous vous suggérons d'exécuter Gen2 sur des workloads ciblés pendant une certaine durée — environ une semaine — afin de mesurer l'impact réel sur les coûts dans votre environnement.

Chez SELECT, nous voulons bâtir une approche plus robuste et scientifique du benchmarking. Nous imaginons un scénario où Python exécute la même requête plusieurs fois sur le même dataset, avec différents warehouses. Cela nous permettra d'obtenir un échantillon plus large, où chaque résultat individuel pèse moins sur la moyenne. À suivre !

Nous sommes impatients de recueillir vos retours d'expérience sur les warehouses Gen2 ! N'hésitez pas à nous contacter pour partager vos découvertes ou vos histoires d'économies !

Jeff est consultant Data & Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des insights et l'utilisation des données pour piloter les processus métier. Côté technologie, il est spécialisé sur Snowflake + dbt + Tableau. Côté métier, il a de l'expérience dans les services publics, les essais cliniques, l'édition, les biens de grande consommation et l'industrie. N'hésitez pas à le contacter à tout moment : [email protected].

Ian Whitestone · Co-fondateur & CEO de SELECT

Ian est co-fondateur et CEO de SELECT, plateforme SaaS de gestion et d'optimisation des coûts Snowflake. Avant de lancer SELECT, Ian a passé 6 ans à diriger des équipes full stack data science et engineering chez Shopify et Capital One. Chez Shopify, Ian a piloté les efforts d'optimisation du data warehouse et d'amélioration de l'observabilité des coûts.