Introduction

Le 14 Mars dernier Google a mis en ligne une nouvelle version de son service BigQuery. Les améliorations majeures concernent la gestion du type TIMESTAMP et des jointures entre tables dont les tailles compressées sont supérieures à 8 MB appelées BIG JOIN.

Cet article documente mes retours d’expériences sur ces améliorations. Mes tests n’ont pas été réalisés en laboratoire et n’ont pas de prétention scientifique, ils ont été fait sur un portable connecté en Wifi. Il s’agit juste du point de vue d’un utilisateur.

Pour faire mes tests, j’ai utilisé deux datasets :

  • le premier c’est le dataset de référence de Netflix contenant 100 000 000 de notes données à plus de 17 000 films,
  • le deuxième est un dataset de données d’épidémiologiques fictives générées aléatoirement avec Benerator (http://databene.org/databene-benerator/).

Gestion des dates

Depuis le 14 Mars, BigQuery supporte le type TIMESTAMP, il n’est plus nécessaire de convertir les données de type dates au format EPOCH avant de les télécharger dans BigQuery. Les fonctions habituelles de manipulation de ce type sont aussi présentes. Elles sont mêmes nécessaires pour faire des tris.

img-1

La seule difficulté a été de charger les données. En effet, les timestamps générés par Benerator se terminaient tous par un point après les secondes. Il a fallu retirer ce point par un script pour que l’import dans BigQuery fonctionne.

Gestion des jointures

Ancienne version

Dans sa version antérieure, le fonctionnement de BigQuery était optimisé pour des grandes tables monolithiques.

img-2

La sélection des 10 films ayant obtenu les meilleures notes en moyenne prenait 2 secondes. Si l’on voulait connaître le titre de ces films, il fallait :

  • soit faire une jointure et ça coutait plus cher en temps,
  • soit inclure directement le titre du film dans la table, c’est à dire dénormaliser, et ça coutait plus cher en stockage.

img-3

Dans cet exemple la jointure coutait 8 fois plus cher en temps d’exécution.
D’où la tentation de tout mettre dans une seule table au détriment de l’espace de stockage.

img-4

Dans cet exemple, le temps d’exécution redescend à un peu moins de 3 secondes. La taille du fichier généré a été multiplié par 2,3.

Nouvelle version

Depuis le 14 Mars avec la nouvelle version de BigQuery, la requête qui prenait 16 secondes en prend maintenant 3,7. C’est quatre fois mieux.

img-5

Il est à noter que pour les tables dont la taille compressée est supérieure à 8 MB, il existe une opération spécifique JOIN EACH. Cette opération permet de faire des jointures entre tables de toutes tailles mais elle est moins performante. En l’appliquant sur cet exemple, ce qui n’est ni nécessaire ni recommandé, on obtient un temps d’exécution 2,6 fois supérieur.

img-6

Jointures multiples

Il y a une limite sur les jointures : une seule par SELECT. Si plusieurs jointures sont nécessaires, une imbrication de SELECT permet de les exprimer.

En utilisant le dataset sur les données d’épidémiologie, on peut rechercher les occurrences de bronchite en Aquitaine sur une année glissante.

img-7

En introduisant la notion de la classe d’âge dans une nouvelle table de référence, il est possible de pousser jusqu’à trois jointures. Le temps d’exécution reste similaire.

img-8

Big join

Pour tester la jointure entre deux tables géantes, ne disposant pas d’exemples fonctionnels, j’ai fait une jointure n’ayant aucun sens entre la table de 100 000 000 de lignes de Netflix et la table des données épidémiologiques fictives de 50 000 000 de lignes.

img-9

Un petit peu plus de 7 secondes, étant donné le volume des données traitées, c’est tout à fait correct.

Par contre, l’introduction d’un ORDER BY dans cette requête est vivement déconseillé, le client Web ne m’a pas rendu la main au bout de 52 832 secondes…

Conclusion

Il faut relativiser ces résultats. Dans les conditions de test utilisées, le temps d’exécution d’une requête balayant une table de référence de 130 lignes oscille entre 1,5 et 2 secondes. Les performances obtenues sur des tables contenant des dizaines de millions de lignes n’en sont que plus impressionnantes.

Les fonctionnalités annoncées sont bien là et changent le discours établi sur BigQuery : ce n’est plus le SGBD d’une seule table. Il est possible maintenant de faire des arbitrages entre le volume de stockage et la performance des requêtes, c’est à dire de dénormaliser ou pas.

De plus, l’ensemble de ces tests a couté moins de 6 $. Qui dit mieux ?

Quelle pourrait bien être la justification économique de faire autrement ?

La confidentialité des données ?

Peut-être mais il faudrait beaucoup de données très confidentielles pour justifier l’acquisition d’un système capable de supporter les mêmes traitements. Même l’équipe des données de la campagne de Barack Obama a utilisé les serveurs d’Amazon.

Le fait que tout individu possédant une carte de crédit et quelques notions de SQL soit en mesure d’explorer des tables de millions de ligne pour le prix d’une clé USB avec comme seul délai d’attente le temps de téléchargement change radicalement l’économie de la Business Intelligence. Celle-ci n’est plus un produit de luxe réservé à une élite, elle devient un produit de consommation courante et immédiate à la portée du plus grand nombre.

Remerciements

Merci à Souhail Hanfi et Christophe Cosnefroy pour leurs aides.