La plus grande entrée en bourse de l’année 2020 a eu lieu le 16 Septembre dernier, celle de la licorne californienne, fondée par deux français ; Snowflake, une étape pourtant logique lorsqu’on se penche sur la croissance vertigineuse de l’entreprise ces deux dernières années (cf. graphique ci-dessous).
Afin de mieux comprendre la popularité de cette solution je propose dans ce premier article de présenter rapidement Snowflake :
- Nous expliciterons un des concepts phares de Snowflake : les virtual warehouses ;
- Puis nous nous pencherons sur la tarification ;
- Enfin, nous regarderons la performance de Snowflake par rapport aux autres principaux acteurs du marché.
#1 Présentation et architecture
Snowflake est une solution Software-as-a-Service qui propose un Data Warehouse reposant entièrement sur une infrastructure cloud. Pour rappel, une solution SaaS ne nécessite en outre aucune installation physique ou virtuelle de matériel ni de logiciel. Tout est installé, configuré et mis à jour dans le cloud, et aucun frais de maintenance n’est à prévoir : cette partie est entièrement gérée par Snowflake. Aussi, une interface très simple à prendre en main est proposée clé en main par l’éditeur, comme illustré ci-dessous.
La principale force de Snowflake repose sur son architecture hybride qui combine deux éléments :
- La simplicité d’utilisation des bases de données traditionnelles à disques partagés (shared-disks), où toute la donnée est centralisée sur un disque et partagée entre tous les noeuds. Néanmoins cette architecture est difficilement scalable car le serveur aura tendance a vite être saturé dès que les données seront requêtées simultanément par plusieurs noeuds ;
- La performance des architectures dites « shared-nothing » qui s’appuient sur des traitements massivement parallèles. Les calculs sont partagés sur plusieurs noeuds qui appliquent les requêtes sur différents sous-ensembles de données.
En outre, la donnée, entièrement stockée de manière optimisée dans le cloud, n’est disponible que par des requêtes SQL spécifiques à Snowflake, comme résumé dans le schéma ci-dessous. L’analyse et le traitement de ces requêtes se font via des objets appelés Virtual Warehouses (ou Entrepôts Virtuels en français) qui représentent la partie calculatoire de Snowflake.
Ces virtual warehouses sont des « clusters de calculs » propres à Snowflake, constitués eux-mêmes de plusieurs noeuds et sont redimensionnables à volonté. Ainsi, il est possible de (re)configurer très simplement et à la volée ces unités de calcul directement via l’interface web de snowflake :
Plusieurs paramètres sont donc disponibles :
- La taille du virtual warehouse, c’est-à-dire le nombre de serveurs qui composent chaque cluster dans un entrepôt qui va établir le coût d’utilisation en crédit, la facturation sera mise en avant ci-dessous ;
- Le nombre minimum/maximum de clusters qui sont des paramètres de scale-in : au fur et à mesure que l’on reçoit des requêtes, Snowflake va allouer dynamiquement des ressources (clusters) pour les traiter le plus efficacement et le plus économiquement possible ;
- Le choix de la politique de mise à l’échelle : l’un va favoriser la performance, l’autre va minimiser les coûts d’utilisations ;
- La politique de mise à l’arrêt automatique : la durée après laquelle le warehouse s’arrête si elle n’a pas reçu de requête à traiter entre temps, et donc aucun crédit n’est consommé.
Il est à noter qu’il est possible de modifier les paramètres d’un virtual warehouse alors même qu’il est en train d’effectuer des calculs. Il est aussi possible de les configurer, comme d’ailleurs tout objet sur Snowflake, via des requêtes SQL, sans même avoir à passer par l’interface.
#2 Facturation
Dans les technologies cloud, il est parfois difficile de s’y retrouver dans les systèmes de facturation tant ils varient d’un éditeur à un autre, d’un service à un autre, et il est rapide de se retrouver avec de mauvaises surprises dans ses coûts finaux. Les frais de Snowflake se décomposent seulement en coûts de stockage et en coûts de calculs.
Le coût de stockage est fixe et déterminé par le package de Snowflake choisi (à partir de 23$ par TB par mois). Le coût de calcul correspond à la durée d’utilisation (à la minute près) et à la taille des Virtual Warehouses utilisés, ces deux notions sont résumées sous la forme de “crédits”. Ainsi, l’utilisateur n’est facturé que pour ce qu’il consomme.
Snowflake propose ainsi différentes tailles de warehouses, qui se découpent en huit paliers et décrivent le nombre de serveurs qui composent un cluster (sachant que l’on peut paramétrer le nombre minimal et maximal de clusters qui composent un virtual warehouse).
Ainsi, si avec mon virtual warehouse XL j’effectue un traitement mobilisant 1 cluster pendant 1 heure, puis 2 clusters l’heure qui suit, j’aurais alors dépensé 1×16+2×16=48 crédits sur ces 2 heures.
Remarque : Augmenter la taille d’un cluster permet d’effectuer plus de requêtes en parallèle, cette solution de scale-out est donc plutôt à privilégier dans des cas où l’on ingère beaucoup de fichiers en parallèle ou pour effectuer des requêtes complexes sur une multitude de tables. A l’inverse, augmenter la taille d’un Virtual Warehouse pour effectuer des requêtes SQL de base aura peu d’influence sur sa rapidité d’exécution.
Remarque 2 : Snowflake a un système de cache ; les résultats des requêtes sont gardés en mémoire pendant 24h. Il est donc possible de réexécuter des requêtes onéreuses à moindres coûts.
#3 Performances et positionnement sur le marché
Pour comparer Snowflake à ses concurrents, je vais dans cette section m’appuyer sur les résultats de l’étude de Fivetran publiée en septembre 2020. Ce benchmark s‘inspire de l’analyse comparative standard TPC-DS, qui consiste à utiliser des requêtes SQL complexes (beaucoup de jointures, d’aggregations, de sous-requêtes etc…) sur des bases de données de retail plus ou moins larges. Ici, ces requêtes sont appliquées à un schéma de 24 tables, pour un total d’1TB — ce qui peut paraître peu en termes de volume mais l’idée est avant tout de tester la performance du traitement de bases de données à la structure complexe.
Ces requêtes sont testées sur des warehouses équivalents chez quatre grands acteurs de datawarehousing : Snowflake, Presto, Redshift d’AWS, et BigQuery de GCP. En particulier, le temps d’exécution et le coût associé pour chacun d’eux sont comparés.
Nous constatons trois choses :
- Quel que soit la datawarehouse utilisée, les temps d’execution sont excellents et peuvent notamment convenir à du requêtage interactif ;
- Les prix des requêtes sont à peu près équivalents d’un datawarehouse à une autre ;
- Snowflake a un avantage minime sur ses concurrents au niveau du temps d’execution et du prix.
La principale différence réside dans la façon dont les calculs sont effectués ; Snowflake et Redshift sont similaires puisqu’ils proposent dans les 2 cas de configurer en détails des clusters de calculs. Redshift permet de paramétrer la mémoire, le stockage et la puissance de chaque cluster, tandis que, de par son architecture qui sépare stockage et calculs, Snowflake gère la mémoire et la puissance comme indiqué dans les parties précédentes.
BigQuery quant à lui ne laisse pas le choix dans la configuration d’un cluster de calcul : l’utilisateur envoie les requêtes une par une directement sur le serveur. Il a néanmoins le choix dans la tarification : soit “à la demande” qui s’adaptera mieux aux requêtes gourmandes mais ponctuelles. Soit en taux-fixe pour une utilisation continue du service de GCP.
Conclusion
Nous avons passé en revue les principaux atouts de Snowflake : cette solution se détache de la concurrence par la simplicité qu’offre le SaaS et sa flexibilité. En effet, nous avons vu qu’il était très facile de configurer des clusters de calculs de manière instantanée.
Snowflake offre en outre une plus grande lisibilité sur sa tarification, qui ne dépend que de la puissance de calcul déployée plus le stockage utilisé. L’utilisateur pourra donc très simplement adapter ses paramètres pour répondre au mieux, et à moindres coûts, à son besoin.
Enfin, Snowflake présente d’autres concepts clés, comme le time travel, le clustering de données, snowpipe etc… qui feront l’objet de futurs articles, auxquels il faudra bientôt ajouter les grandes évolutions prévues lors de son dernier Data Cloud Summit 2020.
Rédigé par Simon Coulet, Consultant Data Driven Business.