Snowflake, BigQuery, Databricks : comprendre les différences

En bref. Ces trois plateformes reviennent constamment dans les offres d'emploi data et dans les discussions techniques, mais elles ne répondent pas exactement au même besoin. Snowflake s'est construit sur la séparation stockage et calcul. BigQuery est le moteur analytique de Google Cloud, sans infrastructure à gérer. Databricks vient du monde Spark et couvre l'ingénierie de données et le machine learning. Cet article explique ce qui les distingue vraiment, sans présupposer de connaissances en architecture.

Le problème que ces outils résolvent

Quand un volume de données dépasse ce qu'un tableur peut traiter, on le stocke dans une base. Quand ce volume dépasse ce qu'une base classique traite confortablement pour de l'analyse, on passe à un entrepôt de données, aussi appelé data warehouse.

La différence tient à l'usage. Une base de données classique est optimisée pour écrire et lire des enregistrements un par un, très vite. Un entrepôt analytique est optimisé pour balayer des millions de lignes et calculer des agrégats. Ce sont deux métiers différents.

Ces trois plateformes répondent au second besoin, avec des approches distinctes qu'il est utile de comprendre quand on travaille dans la data.

Snowflake : la séparation stockage et calcul

Snowflake a popularisé une idée devenue standard : dissocier complètement le stockage des données de la puissance de calcul utilisée pour les interroger.

Concrètement, les données dorment à un endroit, et on allume de la puissance de calcul uniquement quand on en a besoin, dans la quantité voulue. Plusieurs personnes peuvent travailler simultanément sur les mêmes données sans se marcher dessus, chacune avec sa propre capacité.

Le démarrage à froid prend moins de cinq secondes et la montée en charge est automatique. C'est la plateforme la plus simple à prendre en main quand on vient du SQL. En contrepartie, le format de stockage est propriétaire.

BigQuery : le serverless de Google

BigQuery pousse la logique plus loin : il n'y a aucune infrastructure à dimensionner. On écrit une requête SQL, elle s'exécute, et la facturation porte sur les données lues.

Ce modèle a une conséquence pratique importante pour qui apprend : une requête mal écrite qui balaye toute une table coûte cher, alors qu'une requête bien filtrée coûte une fraction. Un SELECT étoile sur une table de plusieurs téraoctets facture le scan complet. Écrire du SQL économe devient une compétence directement mesurable.

L'intégration native avec l'écosystème Google (Analytics, Ads, Sheets, Looker Studio) en fait le point d'entrée naturel pour beaucoup d'analystes. BigQuery est aussi la seule des trois plateformes où l'on ne paie rien tant qu'on ne requête pas, ce qui en fait un bon terrain d'apprentissage.

Databricks : au-delà de l'analyse

Databricks vient d'un autre point de départ : Apache Spark, un moteur de traitement distribué conçu pour les gros volumes.

La plateforme couvre un périmètre plus large que l'analyse SQL : préparation de données à grande échelle, pipelines d'ingénierie, entraînement de modèles de machine learning avec notebooks, MLflow et feature stores intégrés. Le concept de lakehouse qu'elle promeut vise à réunir la souplesse d'un data lake et la rigueur d'un data warehouse.

C'est l'option la plus riche fonctionnellement, et aussi celle qui demande le plus de compétences techniques pour être exploitée correctement.

Trois modèles de facturation qui changent les réflexes

Comprendre comment chaque plateforme facture aide à comprendre comment elle fonctionne.

Snowflake facture des crédits de calcul à la seconde selon la taille de l'entrepôt, avec un minimum de 60 secondes à chaque reprise. Le réflexe associé : éviter de laisser un entrepôt tourner à vide entre deux requêtes.

BigQuery facture soit les téraoctets scannés, soit des créneaux de capacité réservés. Le réflexe associé : filtrer et partitionner pour ne lire que le nécessaire.

Databricks facture des unités de calcul auxquelles s'ajoute la facture du fournisseur cloud sous-jacent. Le réflexe associé : ne jamais raisonner sur le seul coût affiché par la plateforme.

Ce qu'il faut retenir quand on apprend la data

La bonne nouvelle est que le socle est commun : SQL fonctionne partout. Les trois plateformes s'interrogent en SQL, avec des variantes de syntaxe mineures.

Investir dans SQL rend opérationnel sur les trois, alors qu'apprendre les spécificités d'une plateforme ne transfère que partiellement aux autres. C'est l'ordre de priorité qui compte : le langage d'abord, la plateforme ensuite.

Deux compétences comptent partout : écrire du SQL qui ne scanne que ce dont il a besoin, et structurer ses transformations pour qu'elles soient reproductibles et testables.

La formation SQL de DataBird couvre ce socle, et la formation dbt apprend à structurer les modèles de façon versionnée et testée. Pour voir l'ensemble de la chaîne, de l'ingestion à l'orchestration, la formation Analytics Engineer va plus loin.

En résumé

Snowflake mise sur la simplicité d'exploitation et la séparation stockage/calcul. BigQuery supprime toute gestion d'infrastructure et récompense le SQL bien écrit. Databricks couvre un périmètre plus large qui va jusqu'au machine learning, au prix d'une complexité supérieure. Dans les trois cas, SQL reste le point d'entrée.