Ces deux dernières années, les principaux data warehouses cloud ont continué d’améliorer leurs solutions en fournissant aux clients des performances plus rapides, à un coût réduit. Contrairement aux croyances populaires, ces fournisseurs^] améliorent constamment leur efficacité pour permettre aux clients d’économiser de l’argent, malgré l’impact sur le chiffre d’affaires à court terme^[1]. Cependant, tous les fournisseurs offrent des performances similaires. Pour les différencier, les clients doivent donc se concentrer sur l’expérience utilisateur.

Fivetran est un pipeline de data qui synchronise les données d’applications, de databases et de fichiers dans les data warehouses de nos clients. On nous pose souvent la question suivante : « Quel data warehouse choisir ? » Afin d'y répondre, nous nous sommes associés à Brooklyn Data Co. pour comparer la vitesse et le coût de cinq solutions de data warehouse très populaires :

• Amazon Redshift
• Snowflake
• Google BigQuery
• Databricks
• Azure Synapse

Les analyses comparatives reposent sur des choix : quels types de data utiliser ? En quelle quantité ? Quels types de requêtes envoyer ? La manière dont vous prenez ces décisions est cruciale : modifier la forme de vos data ou la structure de vos requêtes peut dramatiquement ralentir même les warehouses les plus rapides. Nos choix se rapprochent de ceux d'un utilisateur type de Fivetran, pour que les résultats soient profitables aux entreprises qui utilisent nos services.

Un utilisateur type de Fivetran peut synchroniser Salesforce, JIRA, Marketo, Adwords et sa database de production Oracle avec un data warehouse. Ces sources de data ne sont pas volumineuses : une source contient généralement entre des dizaines et des centaines de gigaoctets. Elles sont cependant complexes : elles contiennent des centaines de tables suivant un schéma normalisé. Nos clients écrivent des requêtes SQL complexes pour résumer ces data.

Le code source de cette analyse est disponible à l’adresse https://github.com/fivetran/benchmark et il est possible de consulter les data brutes ici.

[CTA_MODULE]

Quelles data avons-nous interrogées?

Nous avons généré l’ensemble de data TPC-DS^[2] à une échelle de 1 To. TPC-DS comporte 24 tables dans un schéma Snowflake. La table représente les ventes Web, en catalogue et en magasin d’un détaillant fictif. La plus grande table de faits comporte 4 millions de lignes^[3].

Quelles requêtes avons-nous exécutées?

Nous avons exécuté 99 requêtes TPC-DS^[4] entre mai et octobre 2022. Ces requêtes sont complexes : elles comportent beaucoup de liaisons, d’agrégations et de sous-requêtes. Nous avons exécuté chaque requête une seule fois, afin d’éviter que le warehouse ne mette en cache les résultats précédents. Les requêtes ont été envoyées de manière séquentielle, une à la fois, ce qui diffère d’un cas d’utilisation typique du monde réel, où de nombreux utilisateurs lancent des requêtes simultanément.

Comment avons-nous configuré les warehouses?

Nous avons exécuté chaque warehouse dans trois configurations, afin d’étudier le rapport prix/performance.

Il est assez difficile de comparer les coûts des systèmes, car chacun d’entre eux présente des fonctionnalités différentes qui permettent de réduire les coûts. Ces chiffres ne tiennent pas compte des avantages suivants :

• Tarification par instance de points de Databricks.
• Évolutivité multi-clusters automatique de Snowflake.
• Tarification à la demande BigQuery.

Ces fonctionnalités, ainsi que celles spécifiques aux plateformes, peuvent être utilisées pour réduire les coûts de nombreuses charges de travail.

Comment avons-nous personnalisé les paramètres des warehouses?

Ces data warehouses offrent chacun des fonctionnalités avancées comme des clés de tri, des clés de cluster et la séparation des dates. Nous avons choisi de ne pas tenir compte de ces fonctionnalités dans notre analyse comparative^[7]. Nous avons appliqué l’encodage de la compression des colonnes dans Redshift et l’indexation du magasin de colonnes dans Synapse. Quant à Snowflake, Databricks et BigQuery, ils appliquent la compression automatiquement.

Résultats

Tous les warehouses présentent une excellente vitesse d’exécution, ce qui est adapté aux requêtes interactives et ad hoc^[8]. Pour calculer le coût, nous avons multiplié le temps d’exécution par le coût par seconde de la configuration.

Dans quelle mesure les performances ont-elles été améliorées?

Nous avons effectué la même analyse comparative en 2020. Les performances de tous les systèmes se sont améliorées au cours des deux dernières années^[9] :

Databricks est la solution qui a le plus évolué, ce qui n’est pas surprenant puisqu'ils ont complètement réécrit leur moteur d’exécution SQL.

Pourquoi nos résultats diffèrent de ceux des précédentes analyses comparatives?

Analyse TPC-DS de Databricks

En novembre 2021, Databricks a publié une analyse TPC-DS officielle présentant les performances de son nouveau moteur d’exécution SQL « Photon ». L’entreprise a également publié une comparaison entre Databricks et Snowflake, qui révèle que son système est 2,7 fois plus rapide et 12 fois moins cher. Il existe de nombreuses différences entre l’analyse de Databricks et la nôtre :

• Databricks a utilisé un ensemble de data de 100 To. Nous avons utilisé un ensemble de 1 To.
• L'entreprise s'est servie d'un point de terminaison 4XL, alors que nous avons préféré un point L.
• Elle a aussi opté pour la séparation des dates dans certaines tables pour leurs données et pour se comparer à Snowflake.
• L'exécution de la commande d’analyse s'est faite immédiatement après le chargement pour mettre à jour les statistiques de colonne.
• Enfin, Databricks a fourni un temps d’exécution total alors que nous avons relevé une moyenne géométrique. Le temps d’exécution total est dominé par les requêtes les plus longues, tandis que la moyenne géométrique pondère de manière équivalente toutes les requêtes.

Databricks a publié le code permettant de reproduire son analyse sur le site Web TPC-DS, ce qui est très utile pour comprendre les principales différences entre notre analyse et celle-ci.

Analyse des performances du data warehouse cloud de Gigaom

En avril 2019, Gigaom a exécuté une version des requêtes TPC-DS sur BigQuery, Redshift, Snowflake et Azure SQL Data Warehouse. Cette analyse comparative était sponsorisée par Microsoft. Une quantité de data 30 fois plus importante a été utilisée (30 To vs 1 To). Différentes tailles de cluster ont été configurées pour plusieurs systèmes. Ils ont présenté des temps d’exécution bien plus lents que ceux de notre analyse :

Il est curieux que Gigaom ait constaté des performances aussi lentes, étant donné que ses clusters étaient 5 à 10 fois plus grands, mais que son volume de data était seulement 3 fois plus important que le nôtre.

Analyse Redshift vs BigQuery d’Amazon

En octobre 2016, Amazon a exécuté une version des requêtes TPC-DS à la fois dans BigQuery et Redshift. Amazon a indiqué que Redshift était 6 fois plus rapide et que les temps d’exécution de BigQuery étaient généralement supérieurs à une minute. Les principales différences entre cette analyse et la nôtre sont les suivantes :

• Amazon a utilisé un ensemble de data 10 fois plus volumineux (10 To vs 1 To) et un cluster Redshift 2 fois plus grand (38,40 $/heure vs 19,20 $/heure).
• Ils ont aussi personnalisé le warehouse avec des clés de tri et de distribution, contrairement à nous.
• Par ailleurs, BigQuery Standard-SQL était toujours en version bêta en octobre 2016. Il est possible que la solution soit devenue plus rapide fin 2018, lorsque nous avons effectué cette analyse.

Les analyses comparatives de fournisseurs qui prétendent que leur produit surpasse les autres doivent être prises avec des pincettes. De nombreux détails ne sont pas précisés dans l’article de blog d’Amazon. Par exemple, un cluster Redshift considérable a été utilisé. L’ensemble de la mémoire a-t-il été alloué à un seul utilisateur pour obtenir des résultats très rapides, même si cette configuration n'est pas réaliste ? Cette information n'est pas connue. Pour que cette analyse soit pertinente, AWS doit publier le code nécessaire à sa reproduction. Son réalisme pourra ainsi être évalué.

Analyse Redshift vs Snowflake vs BigQuery d’Amazon

Toujours en octobre 2016, Periscope Data a comparé Redshift, Snowflake et BigQuery en utilisant trois variations d’une requête d’agrégation envoyée toutes les heures, qui rassemblait une table de 1 milliard de lignes en une petite table de dimensions. Les résultats ont démontré que Redshift était globalement aussi rapide que BigQuery, mais que Snowflake était 2 fois plus lent. Les principales différences entre cette analyse et la nôtre sont les suivantes :

• L'exécution des mêmes requêtes s'est faite en plusieurs fois, ce qui a éliminé les temps de compilation lents de Redshift.
• Leurs requêtes étaient beaucoup plus simples que nos requêtes TPC-DS.

Le problème des analyses comparatives effectuées avec des requêtes « simples » réside dans le fait que chaque warehouse présente de bonnes performances dans ce test. Il n’est pas très pertinent d'apprendre que Snowflake exécute rapidement une requête simple, et que Redshift le fait encore plus vite. En revanche, l’exécution rapide de requêtes complexes constitue l’élément clé à évaluer.

Periscope a également comparé les coûts, en utilisant une approche quelque peu différente pour calculer le coût par requête. Comme nous, l’analyse évalue les data d’utilisation réelle des clients. En revanche, au lieu d’examiner le pourcentage de temps d’inactivité, le nombre de requêtes par heure est pris en compte. Periscope a déterminé que la plupart de ses clients (mais pas tous) pensent que Redshift est moins cher, alors que la différence est négligeable.

Les analyses à 1,1 milliard de lignes de Mark Litwintschik

Mark Litwintshik a effectué une analyse de BigQuery en avril 2016 et de Redshift en juin 2016. Il a exécuté quatre requêtes simples dans une table unique contenant 1,1 milliard de lignes. Il a déterminé que BigQuery opérait à une vitesse équivalente à un cluster Redshift environ 2 fois plus grand que le nôtre (41 $/heure). Les deux warehouses ont réalisé les requêtes en 1 à 3 secondes. Cela représente donc probablement le « plancher de performance » : il existe un temps d’exécution minimum, même pour les requêtes les plus simples.

Conclusion

Ces warehouses présentent d’excellentes performances et un prix attractif. Leur similarité n’est pas surprenante. Les techniques de base de création d’un data warehouse rapide à colonnes sont bien connues depuis la publication de l’article C-Store en 2005. Ces data warehouses utilisent incontestablement les astuces de performances standard : stockage en colonnes, planification des requêtes basée sur les coûts, exécution en pipeline et compilation en temps opportun. Nous devrions nous méfier des analyses comparatives qui affirment qu’un data warehouse est beaucoup plus rapide qu’un autre.

Les écarts les plus significatifs entre les warehouses sont des différences qualitatives résultant des choix de conception : certains warehouses mettent l’accent sur la personnalisation, d’autres sur la facilité d’utilisation. Si vous évaluez des data warehouses, nous vous conseillons d'essayer plusieurs systèmes avant de faire votre choix.

Corrections‍

20 décembre 2022 : nous avons clarifié certaines descriptions selon les commentaires des fournisseurs.

22 décembre 2022 : nous avons corrigé nos calculs de tarification pour Databricks et modifié notre configuration afin qu’elle corresponde mieux aux autres systèmes.

24 décembre 2022 : nous avons remplacé la tarification fixe de BigQuery et effectué une nouvelle fois l’analyse de Redshift et BigQuery.

4 janvier 2023 : nous avons ajouté un lien vers les data brutes et une note de bas de page concernant les performances de Redshift.

[CTA_MODULE]