Datalake comparaison - 6 BigQuery

Dans ce chapitre nous allons nous consacrer à la solution BigQuery, une solution managée sur la
plateforme cloud de Google GCP, cette solution a été développée par Google et est de ce fait une
exclusivité GCP. Google a développé et éprouvé cette solution pour ses propres besoins d’analyse
BigData.
Si vous voyez des erreurs commises dans ce comparatif veuillez nous adresser un mail à
contact@domwee.com nous nous efforcerons de corriger le plus rapidement possible.
  1. Architecture simplifiée
    L’architecture utilise le stockage de fichier distribué (HDFS) de Google cloud platform pour stocker les données et utilise des machines virtuelles de Google pour réaliser le traitement des données.

    Ce système implique donc qu’il faut d’abord lire les données sur des disques durs avant de faire la moindre opération, il faut donc oublier les requêtes sous la seconde. La particularité de cette solution se trouve dans la facturation, elle se base sur 2 critères : le stockage de données qui est relativement peu élevé (stockage cloud très compétitif) et sur le nombre d’octets lus qui en fonction des besoin peut vite grimper. Tout est automatique Google calcule lui même le nombre de processeurs à allouer pour réaliser la requête. Pour permettre la facturation à la consommation Google a fait une concession dans son architecture et les machines virtuelles sont mutualisées entre plusieurs clients et quelquefois il faut attendre que des ressources se libèrent pour avoir le résultat de la requête. Il est cependant possible de réserver des processeurs mais vu le prix ce choix est réservé aux grandes entreprises ou aux entreprises qui ont les moyens.

    Pour faciliter la lecture de données (et par la même occasion pour réduire les coûts) les données sont stockées en colonne non pas en ligne. Imaginons une table avec 6 lignes de données elle est stockée sur un stockage en ligne comme ceci :
id_commande
produit
client
Quantité
1
Bonheur
Nous
Plein
2
Joie
Vous
Beaucoup
3
Amour
Eux
Enormément
4
Amour
Vous
Beaucoup
5
Joie
Eux
Enormément
6
Bonheur
Eux
Plein

En colonne cela se présente sous cette forme :
Les données sont stockées et compressées par colonne (la compression se situe sur les colonnes qui ont des valeurs répétées : Produit, Client et Quantité, la colonne Id n’a aucune compression puisque toutes les valeurs sont différentes) Ensuite des liens sont créés entre les valeurs pour former une ligne de données. Dans l’exemple ci dessous seule la première ligne a été modélisée pour une raison de clarté mais en théorie il y a beaucoup plus de liens à faire pour modéliser les six lignes.

Pour le mode de facturation aux données lues on voit tout de suite l’intérêt de compresser les données et de les éclater par colonne de ce fait si on a besoin que deux colonnes dans une requêtes alors on ne liera que les données de ces deux colonnes et pas toute la ligne. Cette architecture est très efficace sur les très grosses tables et la partie facturation permet à toutes les entreprises grosses ou petites d’y trouver son compte. Cela permet surtout aux petites entreprises d’avoir une solution accessible économiquement et simple d’utilisation.
    1. BigData
      Comme son nom l’indique il a été créé pour faire des requêtes sur de très gros volumes de données. Cette architecture avec le nombre de processeurs qui s’adapte permet une grande flexibilité. Le temps des requêtes restent assez stables en effet puisque plus il y a de données plus il y a de processeurs en pratique chaque processeur va lire et traiter le même nombre d’information par requête c’est juste le nombre de processeurs qui change.Comme le prix est au nombre d’octets lus il est de fait inutile de se soucier de combien de processeurs BigQuery utilise pour exécuter la requête cela ne coûtera pas plus cher. Ce qui pourrait paraître être un gros point noir à savoir le stockage de données en colonne est en réalité un point positif car cette architecture prend tout son sens quand il faut faire des jointures entre deux grosses tables. Cette architecture basée sur des fichiers HDFS est parfaite pour faire du streaming de données la limite annoncée est de 100 000 lignes par seconde. Il y a de quoi faire. 
    2. Datawarehouse
      L’architecture annoncée ci dessus semble être le compromis parfait puisqu’elle permet les jointures et le BigData. Cette architecture permet de faire des datawarehouse mais il y a deux points à ressortir : le premier est le prix car conserver les données en schéma en étoile pour les utiliser ensuite et faire des requêtes complexes va entraîner beaucoup de lectures de données et donc coûter plus cher, nous pensons vu que le stockage n’est pas très cher d’opter pour des datamarts pré calculés ce qui évitera la facture de grimper trop vite et deuxième point le stockage des données en colonnes compressées ne permet pas de faire des Updates ou des Delete. Cela n’est pas bloquant, il est facile de s’en sortir en remplaçant ces instructions par des select/remplace de table mais cela peut être pénible et il faut en tenir compte.
    3. Reporting
      Cet outil est parfait pour faire du reporting, car comme tout est distribué il répond très bien aux pics de charge et en plus il est doté d’un cache de 24 h pour toutes les requêtes exécutées ce qui permet de ne pas payer 4000 fois pour la même requête exécutée le même jour et d’avoir pour ces requêtes une réponse très réactive. Bien sûr il faut pour cela que la requête soit exécutée sur des tables dont les données ne sont pas modifiées ce qui renforce encore le besoin d’utiliser des datamarts. 
    4. Datalake
      Cet outil est parfait pour un datalake, le coût à l’utilisation est ce qu’on attend d’un datalake, et la séparation coût de stockage / Traitement de données permet de ne pas devoir réserver des processeurs et de la mémoire vive pour des données rarement utilisées. Cette base de données accepte les données non structurées comme les Json, seuls les fichiers multimédias seront à stocker ailleurs dans GCP.
    5. Base de données Applicative
      Comme cette base de données ce permet pas les requêtes sous la seconde et qu’il est plus difficile de faire des Update et Delete que dans d’autres bases de données cette base de données n’a clairement pas vocation à stocker des données applicatives. Elle a été développée pour faire de l’analyse de données ou pour stocker des données de logs.
  1. Utilisateurs
    Etant donné que BigQuery utilise le SQL ANSI, autrement appelé le SQL standard, il sera parfait pour tous les utilisateurs de Datawarehouse ou autre analystes de données. Il existe une interface web pour faire les requêtes. L’interface est complète et permet aux utilisateurs de faire ce dont ils ont besoin. 
  2. Fonctionnalités additionnelles
    Ici ne seront traitées que les fonctionnalités natives présentent dans le moteur de la base de données, sinon ce tableau n’aura aucun sens puisqu’avec du développement ou des addons on pourrait tout faire avec n’importe quelle base de données.
    - Géographiques : oui
    - Graphes :
    - IP : oui
    - Window : Oui
    - ML : oui (les algorithmes ML classiques mais pas tensorflow)
  3. Administrateur
    C’est une solution managée très avancée, les administrateurs n’ont pratiquement rien à faire et ils peuvent aussi définir des quotas de consommations par mois à ne pas dépasser (exprimé en devise €,£,$...)
  4. Experts quand pourquoi
    Cette solution nécessite des experts au moment d’optimiser les coûts et le temps de certaines requêtes. Pour des choses simples ils ne sont pas utiles.
  5. Droits et sécurité
    Les droits sont liés à des comptes Google, seules les personnes ayant des comptes Google (Gmail.com ou G Suite) peuvent utiliser cette solution. Les droits sont aux niveaux des attentes, il y a les droits aux niveau des bases de données appelées projets GCP et des droits au niveau des schémas appelés datasets. Cette solution est compatible SAML et permet aussi de se connecter à un active directory.
  6. Logs et alertes
    Les logs sont disponibles dans l’outil de requêtage et sont déjà bien fournies. Mais en plus ils sont stockés dans stackDriver un outil de centralisation de logs. Google propose un système d’alertes personnalisées et aussi d’exporter les logs sur des fichiers ou dans bigQuery. Les logs permettent de voir les requêtes exécutées et le nombre d’octets lus pour chaque requête c’est l’idéal pour suivre la consommation et donc le coût payé.
  7. Coût et gestion
    La séparation des données et du traitement permet à toutes les entreprises de se doter de cette solution BigData. Il n’y a aucune licence à payer si ce n’est les comptes Google d’entreprise. Le fait de pouvoir définir des quotas et des alertes est très rassurant. La souplesse proposée par cette architecture doit être contrôlée et tous les outils sont disponibles pour le faire.
  8. Fin d’utilisation
    Il est possible à tout moment d’exporter les données des tables ou le résultat des requêtes sur le système de fichiers de Google en Json ou en CSV. 
  9. Documentation et API
    La documentation n’est pas la plus claire qui nous a été donnée de lire mais elle est bien fournie, celle ci comporte de nombreux exemples. Comme avec tous les outils Google les API foisonnent avec une documentation correcte.


Les notes vont de 0 à 5 (5 étant la meilleure)

1.1
B
I
G
D
A
T
A
1.2
DWH
1.3
R
E
P
O
R
T
1.4
D
A
T
A
L
A
K
1.5
A
P
P
S
2
U
T
I
L
I
S
A
3
F
O
N
C
T
+
4
A
D
M
5
E
X
P
E
R
T
6
D
R
O
I
T
S
7
L
O
G
S
8
C
O
U
T
9
F
I
N
10
D
O
C
BigQuery
5
3,5
5
5

5

5
5
4,5
5
4,5
5
4

Conclusion : C’est une plateforme de gestion de données méconnue, les choix forts qui ont été faits montrent que c’est une solution dédiée à l’analyse de données. Elle existe depuis plusieurs années et est arrivée à maturité. Elle a beaucoup d’atouts, c’est à notre sens le meilleur ratio coût/performances/fonctionnalités. Depuis peu cette solution commence à s’intégrer dans pas mal d’outils de la plateforme GCP ainsi que chez d’autres acteurs qui ont vu son potentiel.

 Plan :
1 introduction
6 BigQuery
7 Redshift


Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Datalake comparaison - 10 Conclusion

Franchement nous avions d’énormes à priori avant de commencer ce comparatif et honnêtement le résultat nous surprend nous même. Toutes les solutions analysées présentent des intérêts et aucune ne peut prétendre être la solution ultime, c’est d’ailleurs celle qui veut tout faire à la fois qui pour nous est la moins intéressante. Nous ne pouvons que saluer les efforts d’innovations que les différents éditeurs ont trouvées et nous les remercions de proposer des outils qui permettent de traiter nos chères données. En effet nous parlons toujours comme si LA donnée était une seule entité et devait se traiter de la même manière mais c’est faux il y a plusieurs types de données : les chaudes qui sont consommées immédiatement, les froides qu’on ne va voir qu’une fois de temps en temps, il y a aussi des données qui servent à tirer des tendances, il y a des données qui servent à savoir ce qu’il s’est passé pour trouver une cause au problème, il y a des données confidentielles, il y a d...
Lire la suite

Load Balancer

Image
Le load balancer est un composant majeur dans Google Cloud platform , Il participe comme son nom l’indique à router les utilisateurs sur une ressource disponible. Il participe également à la bonne santé du système complet car son premier rôle est de servir de point d’entrée ce qui simplifie grandement la vie des utilisateurs et des développeurs. C’est un aiguilleur qui dirige les utilisateurs vers la bonne ressource. C’est un organe essentiel  d’une solution cloud. De plus lors d’un changement de logiciel ou de mise à niveau cela évite aux utilisateurs de devoir changer leurs raccourcis et leurs habitudes. Il permet donc de faire des déploiements sans rupture de service. Après le déploiement, les utilisateurs ne changent rien à leurs habitudes et le load balancer envoie toutes leurs demandent à la nouvelle application et un lien direct peut être mis en place pour certains utilisateurs qui ont encore besoin de se connecter à l’ancienne application. ...
Lire la suite

Data loss prevention API

Image
Les entreprises traitent de plus en plus leur données automatiquement. Plusieurs profils peuvent être amenés à “jouer” avec leurs données : data scientists internes, data scientists externes ou entreprises spécialisées dans ce domaine. Par faute de temps ou par manque d’outil les données fournies ne sont pas toujours pré traitées et sont souvent envoyées telles quelles, or cela a deux inconvénients : le premier (que tout le monde avait trouvé) transmettre des informations importantes inutiles et donc augmenter le risque de fuite d’information, Le deuxième c’est qu’une donnée trop riche nuit à son traitement. Je donne un exemple pour un ordinateur un numéro de téléphone est une suite de 4 numéros et s’ils ne sont pas contextualisé il prendra cela pour 4 numéros de 2 chiffres. Dans certains cas il est préférable de remplacer ces 4 séries de chiffres par un libellé comme NumTéléphone pour faire comprendre à l’algorithme que c’est l’information de la présence de numéro...
Lire la suite