BigQuery vs Redshift : quelques critères pour les différencier
Google BigQuery et Amazon Redshift sont aujourd’hui deux technologies à considérer pour qui s’intéresse aux entrepôts de données dans le cloud. Mais, pour choisir, il convient de connaître les principales différences de chaque technologie. Les coûts et les capacités d’administration en font partie.
Si l’on considère le cloud comme un réceptacle propice aux traitements du Big Data, Google BigQuery et AWS Redshift sont deux technologies incontournables, que l’on se doit de comparer.
Ces services d'entrepôt de données présentent certes de grandes similitudes – notamment en matière de fonctions qui en général séduisent les entreprises. Mais c’est bien leurs différences, en particulier en ce qui concerne les coûts et la gestion, qui détermineront le choix final de la technologie. L’autre critère est interne : le personnel IT est-il en mesure ou non de gérer ce type d’infrastructure et les ressources nécessaires à ces services de données ?
Coûts et administration : les différences
Le débat BigQuery vs Redshift n'est pas vraiment nouveau, confirme Mike Leone, analyste senior chez Enterprise Strategy Group. Redshift reste en tête en termes d'adoption, mais BigQuery rattrape son retard. Les coûts et l’administration ont été deux facteurs clés dans la capacité de Google à combler l'écart.
Une explication : Redshift et BigQuery sont deux composants du Paas, mais l'architecture serverless de BigQuery élimine de l'équation l'infrastructure, affirme l’analyste. Les administrateurs n'ont pas à se soucier du choix des instances ou du provisioning pour supporter les pics d’utilisation, car avec BigQuery, ces tâches n’ont plus lieu d’être. Cela peut également permettre de réduire les coûts : l’IT peut se concentrer sur d’autres projets à plus de valeur métier et commerciale.
« La simplicité d’usage, mis en avant par BigQuery, est un double avantage : le service est perçu comme étant plus facile à utiliser par les administrateurs et les utilisateurs finaux,[et] il permet de réaliser potentiellement des économies plus importantes en matière d’OPEX », ajoute-t-il.
Redshift, de son côté, nécessite l’intervention d'administrateurs qualifiés et formés pour gérer l'infrastructure, pour comprendre les besoins en ressources – et les maintenir - et répondre aux utilisateurs en cas de problème.
Mais c’est aussi sa force. Redshift permet d’avoir un contrôle plus granulaire de l'infrastructure, et de configurer le service au plus près des exigences et des workloads, explique Mike Leone. « Si les compétences tant en matière d’entrepôt de données que de workloads métier sont présentes en interne, l’entreprise bénéficiera de la flexibilité nécessaire pour optimiser l'infrastructure et mieux répondre aux exigences de performances », commente-t-il.
Bien configuré, Redshift peut donc surpasser BigQuery dans certains cas d'utilisation - bien que ces différences de performance soient généralement mineures. « Cela ne veut pas dire que Redshift prend quelques minutes pour retourner les résultats d’une requête et que BigQuery des heures ; il s'agit surtout d'une comparaison secondes vs minutes », ajoute-t-il encore.
Ce que confirme Michael Fauscette, directeur de recherche chez G2 Crowd, une société qui compile les avis des utilisateurs sur toute une gamme de produits informatiques : les DSI qui ont l’habitude de gérer leurs propres ressources CPU et de stockage pour un entrepôt de données seront davantage attirés par Redshift. A cela s’ajoute le fait que les prix de Redshift paraissent souvent plus prévisibles, soutient-il. Par exemple, Redshift utilise une tarification horaire plus cohérente et plus attrayante pour les grandes entreprises. De son côté, BigQuery vous permet de basculer entre la tarification fixe et le paiement à l'utilisation. En fin de compte, le coût de chaque service variera bien en fonction de la façon dont l'entreprise l'utilise.
« Ma théorie est que Redshift doit être un peu plus cher, mais cela dépend des spécificités », poursuit le spécialiste.
BigQuery vs. Redshift : d’autres critères à prendre en compte
En plus de la gestion des coûts et des ressources, Redshift et BigQuery diffèrent aussi par leurs processus de chargement des données.
Dans Redshift, vous pouvez copier des données directement depuis S3, et aussi streamer des données avec Amazon Kinesis. BigQuery, de son côté, supporte les chargements brutes à partir de fichiers CSB ou JSON, avec certaines limites toutefois. Le service prend également en charge le streaming de données, mais cela a tendance à augmenter vos coûts, rapporte Michael Fauscette.
Sans oublier le fait qu’AWS domine le marché du cloud public, ce qui pourrait lui donner un petit avantage dans le débat Redshift vs BigQuery.
« Amazon a définitivement développer son écosystème plus rapidement et reste le chef de file », commente-t-il. Pour les nombreuses entreprises qui hébergent déjà leurs applications sur l'infrastructure AWS , l'adoption de Redshift comme entrepôt de données serait naturel.
Un marché qui se développe
Evidemment, en matière d’entrepôts de données, BigQuery et Redshift sont loin d’être les seules solutions du marché. Il convient également d’évaluer les autres options disponibles.
Il ne s'agit pas seulement d'une course de deux chevaux, lance Greg Schulz, analyste conseil senior chez StorageIO. Microsoft, par exemple, propose Azure SQL Data Warehouse. Et, comme les utilisateurs qui ont déjà investi dans AWS pourraient se diriger vers Redshift, ceux ayant un pied dans Azure pourraient faire de même avec SQL Data Warehouse.
Mais il convient aussi de ne pas oublier certains pure-players des entrepôts de données dans le cloud. Snowflake, par exemple, a de quoi séduire les entreprises qui ne souhaitent pas placer leur œufs dans le même panier en matière de fournisseurs cloud. Initialement bâti sur une infrastructure AWS, la société a travaillé à porter sa technologie sur Azure. Snowflake est officiellement disponible sur Azure depuis cet été. Autre avantage de cet éditeur : celui de pouvoir bénéficier d’une architecture qui exploite les spécificités premières du cloud, à savoir l’élasticité et la consommation à la demande. Snowflake a en effet choisi de séparer la couche de stockage de données de leur traitement, rendant possible des cas d’usages plus étendus (comme celui du data sharing - partage de données -, fortement mis en avant par la société).