BigQuery — Les bases

Bonjour à tous, je commence une série d’articles sur BigQuery, l’objectif de ces derniers sera de présenter BigQuery, son fonctionnement, ses particularités, de faire des retours d’expérience et de le mettre en situation.

Voilà maintenant 10 ans que je travaille dans la data, je suis passé d’écosystèmes basés sur des infrastructures internes à des plateformes dans le cloud ( puis hybrid / multi cloud ) en général et sur GCP en particulier, d’écosystèmes basés sur Hadoop à des plateformes plus ouvertes avec une plus grande souplesse. Et au milieu de tout cela, de mes premières plateformes data GCP à celles d’aujourd’hui, il y a un composant qui est central dans toute architecture DATA, il s’agit de BigQuery.

De l’analyse rapide de haut volume de données en SQL à la possibilité de générer des modèles ML, l’outil a su se développer et s’enrichir pour devenir aujourd’hui un composant indispensable pour toute architecture Data GCP.

PREMIERS PAS AVEC BIGQUERY

Mais avant de parcourir toutes ces évolutions, voyons déjà ce qu’est BigQuery à la base.

Le plus simple pour commencer est déjà de mettre BigQuery en action, je vais prendre cette requête de base que j’utilise habituellement en démo d’introduction :

SELECT
  language,
  title,
  SUM(views) AS views
FROM
  `bigquery-samples.wikipedia_benchmark.Wiki10M`
WHERE
  title LIKE '%Google%'
GROUP BY
  language,
  title
ORDER BY
  views DESC;

Cette requête est simple, je recherche tout simplement les articles dont le titre contient google dans une base fournie par wikipedia. Comme on peut le voir sur l’image suivante, la requête a mis 1,3 secondes pour une quantité de données processées de 529,8 Mb.

Je vais à présent exécuter la même requête mais cette fois ci sur une table beaucoup plus importante :

Cette fois-ci, notre requête à mis 11,6 secondes pour processer 415 Gb. Et nous voyons dans ce petit exemple, ce qui va constituer une des grandes forces de BigQuery : la capacité de processer une importante volumétrie de donnée en un temps se comptant en secondes dans un langage simple : le SQL.

Comme vous pouvez le voir avec mes captures d’écran, j‘ai demandé à ne pas utiliser le cache, en l’utilisant ma requête met à présent 0,1 seconde pour me fournir le résultat, le cache a une durée de 24 heures par requête et par utilisateur et s’annule en cas de modification des tables concernées.

Continuons un peu avec notre requête, nous avons utilisé les données Wikipedia, voyons le FROM :

`bigquery-samples.wikipedia_benchmark.Wiki10B`

il se construit de la manière suivante :

`ProjectId.dataset.table`

Ce qui nous permet de voir l’organisation logique des données dans BigQuery, chaque donnée se retrouve stockée au sein de tables qui se retrouvent elles-mêmes au sein d’un dataset qui appartient à un projet. Voyons cela en détail :

Le projet est le projet GCP qui est responsable de définir les droits pour les utilisateurs qui pourront exploiter BigQuery mais aussi les règles générales d’exploitation (mise en place de quota par exemple ).

Le dataset est l’équivalent de la collection ou des databases dans d’autres systèmes ( MongoDB, elastic, mysql … ), il regroupe un ensemble de données cohérent qui sera réparti dans différentes tables ou vues. C’est au niveau du dataset que nous allons fournir les droits d’accès aux données aux utilisateurs, qu’ils appartiennent à notre projet ou non.

Les tables sont l’organisation physique de nos données, elles sont réparties en colonnes et c’est sur ces dernières que nous allons exécuter nos requêtes.

Dans notre requête de démo nous avons exploité les données wikipedia qui sont mises à disposition, si on reprend ce que l’on vient d’expliquer, cela signifie que dans le projet : bigquery-samples, on a mis à disposition les données du dataset wikipedia_benchmark à l’ensemble des utilisateurs quelques soient leurs projets. A l’heure ou j’écris cet article, il y a 134 datasets publics référencés dans des secteurs aussi divers que le sport avec les statistiques des championnats de NCAA ou que des données climatiques avec les relevés GSOD du National Oceanic and Atmospheric Administration

Ceci permet aussi de montrer que BigQuery est composé en fait de deux services, un service de stockage et un service de requêtage.

Le reste de la requête est du SQL standard, il répond aux normes du SQL 2011. Pour être complet, il existe deux langages SQL disponibles, le legacy sorti en 2010 et le standard sorti quelques années plus tard, le standard est plus performant et propose un plus grand nombre de fonctionnalités.

ARCHITECTURE

Comment BigQuery fait-il pour obtenir ces résultats ? BigQuery est dans la catégorie de ce que l’on appelle une base colonne, l’avantage de ce type de stockage à l’inverse d’un stockage orienté ligne, est qu’il permet de requêter directement les colonnes qui nous intéressent sans avoir à récupérer la totalité de la ligne et de devoir filtrer ensuite. Ce type de stockage va aussi permettre un niveau de compression supérieur. La contrepartie étant que les opérations de modification d’une ligne deviennent plus coûteuses et nous avons moins de fonctionnalités que dans une RDMBS classique, nous sommes bien en face d’une base analytique.

Ok BigQuery est une base analytique orientée colonne, mais ces performances vont s’expliquer par l’architecture mise en place qui est le résultat des différentes recherches faites depuis plusieurs années. Cette architecture va s’appuyer sur les quatre principaux composants suivants :

• Colossus : Evolution de GFS qui assure le stockage, la réplication et la distribution des données
• Jupiter : Réseau pétabit / s permettant la récupération et la circulation des données
• Borg : Organisation, gestion et mise à disposition des ressources machines nécessaires
• Dremel : le moteur de requêtage qui va organiser l’exécution de nos requêtes

Pour illustrer cela nous allons reprendre notre requête du début, lorsque nous exécutons, la requête est prise en charge par dremel et nous allons pouvoir récupérer les données : title, langage et views au sein de Collosus qui seront transmises via jupiter à l’ensemble des machines mises à disposition, de là, Dremel appliquera son plan d’exécution et le “découpage” de la requête en différentes étapes et répartira la charge entre les différentes machines mises à disposition, entre deux étapes, si une opération de Shuffle est nécessaire elle sera mise en place automatiquement pour optimiser les performances.`

(Image source: Google Dremel Paper)

UTILISER BIGQUERY

Pour utiliser BigQuery, que ce soit pour créer des datasets, tables ou vues ou bien pour exécuter une query, vous avez différentes solutions à votre disposition :

• Par la console : Comme vu lors de mes exemples précédents, une interface est mise à disposition au sein de la console GCP. Très utile par exemple pour explorer les données ou travailler sur une requête.
• Par le Cli de google : gcloud embarque l’outil bq qui va vous permettre d’interagir en ligne de commande avec BigQuery, très utile pour scripter nos actions et offre souvent des options supplémentaires à la console ou accessibles en alpha ou béta.
• Par appel API : Comme tout service sur GCP, vous pouvez manipuler BigQuery par des APIs, ce sera très utile pour appeler BigQuery à partir d’autres applications. A noter qu’il existe un grand nombre de client qui sont disponibles dans de nombreux langages de programmation (C#, Go, Java, Python, PHP, Ruby, Node.js … )

PRICING

Nous sommes dans le cloud et forcément le modèle de pricing va avoir son importance dans le design et les choix que nous ferons. Concernant BigQuery, nous ne payons pas de serveur mais nous payons selon l’utilisation que nous faisons du service :

• Le stockage de données ( exemple en multi-région EU : 0,20 $ du Gb puis 0,10 $ du Gb si il n’y a pas eu de modification de la table depuis 90 jours )
• L’insertion de données en streaming : 0,010 $ pour 200 Mb
• Requête : 5$ par To ( le premier To du mois est gratuit )
• BigQuery ML et la Storage API ont un coup particulier que nous verrons dans d’autres articles.

L’ensemble des autres fonctionnalités sont gratuites telles que :

• Le chargement de données
• L’export de données
• La copie de données
• La création / Suppression de table / Dataset
• etc …

CONCLUSION

BigQuery nous permet d’interroger facilement, en SQL, d’importants volumes de données en quelques secondes, c’est à partir de ce constat que nous allons pouvoir exploiter la technologie dans de nombreux use cases :

• Datawarehouse / Base Analytique principale ou de complément
• Service ETL / ELT
• Analyse de données en streaming avec Dataflow SQL
• Pré processing des données en Machine Learning
• Service de machine learning avec BQML
• Service de stockage de données

Nous verrons au cours des prochains articles comment bien utiliser et designer bigquery et les différentes fonctionnalités disponibles.

Liens Utiles

BigQuery : https://cloud.google.com/bigquery/

BigQuery Under the hood : https://cloud.google.com/blog/products/gcp/bigquery-under-the-hood

Dremel : https://research.google/pubs/pub36632/

Why Analytic workloads are faster on columnar Databases https://loonytek.com/2017/05/04/why-analytic-workloads-are-faster-on-columnar-databases/