Maintenant que nous vous avons détaillé comment choisir votre data warehouse dans le cloud nous vous proposons la découverte de quelques unes du marché:
- Snowflake
- AWS Redshift
- Google Big Query
- Azure Data Warehouse
- Benchmark
Vous pouvez revenir aux critères de sélection des data warehouse dans le cloud.
Nous avons voulu tester nous-même ces data warehouses pour nous en faire notre propre idée.
Étant habitués aux entrepôts de données et aux bases de données en général nous voulions surtout nous rendre compte à quel point il était simple de se lancer dans un projet.
En guise d’introduction
Il n’échappe à personne à quel point les services de Google ont connu une adoption fulgurante sur les 20 dernières années qui se sont écoulées. Les employés de Google avaient alors besoin d’analyser toutes les métriques d’utilisation de tous ces services. C’est alors que leurs travaux de recherche aboutissent à Dremel.
Ce moteur de requêtes sait paralléliser les interrogations SQL sur des milliers de machines ! Dremel traitait en 2012, déjà, 35 milliards de lignes, sans index, en une petite dizaine de seconde.
Autant dire qu’aujourd’hui l’outil s’est grandement amélioré.
Scénario
Nous avons poussé des données dans Google Cloud Storage, créé une table alimentée par des fichiers qui en sont issus et exécuté des requêtes.
Chargement des données
La définition du chargement des données peut s’opérer soit via l’API (ici en lignes de commandes) ou encore via les interfaces web de GCP prévu à cet effet.
Les commandes qui suivent ont été réalisé via gcloud.
# création de la table
bq mk trips.taxi_trips
# association du schéma à la table
read -r -d '' SCHEMA <<- FINISHED \
vendor_id :string, \
pickup_datetime :timestamp, \
dropoff_datetime :timestamp, \
passenger_count :integer, \
trip_distance :float, \
pickup_longitude :float, \
pickup_latitude :float, \
rate_code :integer, \
store_and_fwd_flag :string, \
dropoff_longitude :float, \
dropoff_latitude :float, \
payment_type :string, \
fare_amount :float, \
surcharge :float, \
mta_tax :float, \
tip_amount :float, \
tolls_amount :float, \
total_amount :float \
FINISHED
#chargement des données
bq load \
--max_bad_records=10000 \
--field_delimiter="," \
--source_format=CSV \
skilful-elixir-431:trips.taxi_trips \
gs://<>/csv/yellow_tripdata_*.csv \
$SCHEMA
L’interface graphique rend l’outil plus accessible pour les novices.
Ce que l’on peut d’emblée noter c’est le type de Table, elle peut être native (à même BigQuery) et externe.
Exécution des requêtes
Troisième plateforme testée, toujours les mêmes requêtes ou type de requêtes…
Nous avons exécuté cette même requête deux fois dans un court laps de temps.
On peut constater que la deuxième exécution n’a pas de délais ! Là où la première avait mis 3 sec. 8, la deuxième en met 0 !
Bonus
Google BigQuery présente nombre d’avantages.
D’abord il est dans le riche écosystème de Google Cloud : de nombreux composants pour gérer la donnée de bout en bout, de la collecte à la présentation en passant par l’analyse et la diffusion. Et bien sûr tous interagissent avec BigQuery, on peut citer le petit dernier: Data Fusion, ou concevoir des tableaux de bord directement avec Data Studio.
Autre point, il va être possible de manipuler des types de données géographiques, appliquer des modèles de machine Learning…
Pour finir, nombre de sociétés font confiance à G Suite.
Et bien, elles peuvent bénéficier des données qu’elles poussent dans G Drive afin de les interroger via BigQuery. Ce peut être une manière de partager des jeux de données et en même temps de les interroger en masse !
Appréciation Générale
BigQuery a beaucoup progressé en usabilité au fur et à mesure des versions livrées.
Comme de nombreux services de GCP elle gagnerait à mieux se faire connaître. La solution reste très simple et facile d’emploi, et elle peut jouir de l’ensemble des composants de sécurité de GCP.