2/35
Qui suis-je ?
Aurélie Vaché
Développeuse Full Stack chez
@aurelievache
#bigquery @aurelievache
“Big Data” != “Hadoop”
3/35#bigquery @aurelievache
GFS
MapReduce
BigTable
2004 2008 2012
Dremel
Colossus
BigQuery
Google et la révolution Big Data
2002 2006 2010 2015
Datala...
● AaaS (Analytics as a Service)
● stocker, analyser, exécuter des requêtes sur des grands volumes de
données et partager s...
Qu’est ce que BigQuery ?
6/35#bigquery @aurelievache
Pourquoi utiliser BigQuery ?
- SLA 99.9%
- Infrastructure de Google
- Pas de coût de serveurs, d'opération et de maintenan...
Pourquoi utiliser BigQuery ?
- Scalabilité
- Rapide
- “Pay only for what you use”
- Requêtes synchrones et asynchrones
- F...
Inconvénients/Limitations
- “ Append-only tables ”
- Latences réseau possibles
- Performant sur des énormes tables (Go, To...
● BigQuery => Analytics.
● Cloud Bigtable => NoSQL - stockage a grande échelle, update
possible.
Différence entre BigQuery...
Usages
11/35#bigquery @aurelievache
Quotas
Requêtes
● 20 000 req/jour
● 100 To données
100 000 lignes insérées
/sec / table
StreamingChargement
● 1 000 jobs /...
Coûts
Gratuit : Chargement des données + Export des données + tables lues + copies de tables +
données dans le cache.
Requ...
Architecture technique
1. BDD orientée colonne
14/35#bigquery @aurelievache
Architecture technique
2. Architecture en arbre
15/35#bigquery @aurelievache
Composants
Project (billing, top-level container)
Dataset (organization, access control)
Job (query, import, export, copy)...
Composants > Table
Ex de schéma :
date:TIMESTAMP,cid:INTEGER,cl,toto,titi,uid:INTEGER
Type de données possible : string, i...
Comment charger vos données ?
18/35#bigquery @aurelievache
Comment charger vos données ?
19/35#bigquery @aurelievache
L’API REST
20/35#bigquery @aurelievache
Exemple en JAVA
// insert data
List<TableDataInsertAllRequest.Rows> rowList = new
ArrayList<TableDataInsertAllRequest.Rows...
Connecteurs
22/35#bigquery @aurelievache
Fonctions intéressantes :
- TOP
- TABLE_DATE_RANGE
- REGEXP_MATCH / REGEXP_REPLACE / REGEXP_EXTRACT
BigQuery SQL
Variante ...
Demo Time !
24/35#bigquery @aurelievache
Visualisation et BI ETL
Third-party tools
Connecteurs
25/35#bigquery @aurelievache
Performances
26/35#bigquery @aurelievache
Ils utilisent BigQuery
27/35#bigquery @aurelievache
État des lieux - Cluster Hadoop
- 12 serveurs sous Cloudera Manager v4.6 et CDH 4.3.0
- Facturation de l'électricité pour ...
- Coût hardware : 0 €
- Coût opé : 0 €
Passage à Google BigQuery
29/35#bigquery @aurelievache
Utilisation
30/35#bigquery @aurelievache
- Bien structurer ses données
- Split by date
- Utiliser le query cache
- Définir une date d’expiration lors de la créatio...
- Attention aux jointures
- Possibilité de partager un dataset/des rows à des collaborateurs
- Format date : UTC !
- Ne pa...
- SLA : https://cloud.google.com/bigquery/sla
- Quotas : https://cloud.google.com/bigquery/quota-policy
- Prix : https://c...
Pour aller plus loin ...
34/35#bigquery @aurelievache
SELECT questions FROM meetup:TDS.bigquery
35/35#bigquery @aurelievache
Dans les coulisses de Google BigQuery
Prochain SlideShare
Chargement dans…5
×

Dans les coulisses de Google BigQuery

1 426 vues

Publié le

Présentation effectuée le 25 Novembre 2015 au Toulouse Data Science, soirée co-organisée par Duchess France.
Les ingénieurs de Google avaient du mal à suivre le rythme de croissance de leurs données. Le nombre d’utilisateurs de Gmail augmentait constamment et était de l’ordre de centaines de millions; Il y avait plus de 100 milliards de recherches Google effectuées chaque mois.
Essayer de donner un sens à toutes ces données prenait un temps fou et était une expérience très frustrante pour les équipes de Google.
Ce problème de données a conduit l’élaboration en 2008 d’un outil interne appelé Dremel, qui a permis aux employés de Google d’exécuter des requêtes SQL extrêmement rapides sur un grand ensemble de données.
En 2012 lors de la Google I/O, Google à annoncé la sortie de Google BigQuery, l'implémentation externe de Dremel...

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 426
Sur SlideShare
0
Issues des intégrations
0
Intégrations
496
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Avant de commencer, j’aimerai savoir qui connaît BigQuery dans la salle ?
  • Je m’apelle Aurélie Vaché, je suis développeuse Full-Stack chez atchikservices. J’ai 10 ans d’expérience. J’ai un profil plutôt “DevOps”.
    Je fais également partie du bureau des Duchess France qui a pour but de mettre en avant les femmes développeuses ou ayant un profil Tech, de susciter des vocations chez les plus jeunes et de faire en sorte qu’il y ait plus de speakeuses. Pour cela on organise des ateliers de préparation et de répétition à Paris ou via hangout et nous sommes en train de mettre en place un système de marrainage ainsi que des coding dojos.
  • Lorsque l’on pense à des technologies liées à la Big Data, on pense de suite à l’éco-système Hadoop, à Elasticsearch ou bien ces temps-ci beaucoup à Spark. Mais il y a un « petit service » de Google qui ne fait pas beaucoup parler de lui mais qui peut tirer son épingle du jeu dans différents cas de figure, il s’agit bien évidemment de Google BigQuery.
  • Les ingénieurs de Google avaient du mal à suivre le rythme de croissance de leurs données. Le nombre d’utilisateurs de Gmail augmentait constamment et était de l’ordre de centaines de millions; Il y avait plus de 100 milliards de recherches Google effectuées chaque mois.
    Essayer de donner un sens à toutes ces données prenait un temps fou et était une expérience très frustrante pour les équipes de Google.
    Ce problème de données a conduit l’élaboration en 2008 d’un outil interne appelé Dremel, qui a permis aux employés de Google d’exécuter des requêtes SQL extrêmement rapides sur un grand ensemble de données.
    Dremel peut scanner 35 milliards de lignes sans un index en une dizaine de secondes.
    En 2012 lors de la Google I/O, Google a annonçé la sortie de BigQuery, l’implémentation publique de Dremel.

    Et le 13 octobre dernier, lors du #GCPNext, Google a annoncé la sortie en version Beta de Google Cloud DataLab qui permettrait de faire du Machine Learning avec ses données stockées dans BigQuery. Je n’ai pas encore testé mais j’avoue que cela éveille/aiguise ma curiosité. A titre informatif ce nouveau servie a été conçu avec comme base IPython.


    A noter que depuis quelques années Google a pris l’habitude de sortir un produit par an, je vais par exemple citer DataFlow qui est sortie de sa version Beta cette année et Kubernetee : le Docker à la sauce Google.
  • Vous avez sûrement entendu parler des solutions du type PaaS, IaaS, et Saas … Google BigQuery, quant a lui, est une solution de type AaaS - Analytics as a service qui repose sur la plateforme de Cloud de Google et de ce fait de sa puissance de calcul.

    La technologie permet de stocker, analyser, executer des requetes sur des grands volumes de données et de partager ses données structurées.
    Pour faire simple, techniquement, le service BigQuery est juste un serveur qui accepte les requêtes HTTP et renvoie les réponses au format JSON.
  • BigQuery fait partie d’un des services de la plateforme Google Cloud qui s’enrichie d’année en année.
    Dernièrement nous avons notamment vu l'arrivée de DataFlow, de Pub/Sub et de DataLab qui n’est pas sur ce schéma.
  • Pourquoi devriez vous utiliser BigQuery ?
    Ils affichent un SLA de 99.9%. Et en effet en 2 ans d’utilisation il n’y a eu que 2,3 pannes du service pendant qq heures, leur équipe à été très réactive et nous avons eu le détail de l’incident et ce que leurs équipes ont fait pour que l’incident ne survienne plus. Chez Google, le service est monitoré en 24/7 et est répliqué.
    Le service utilise l’infrastructure de Google, donc c’est Google qu s’occupe de tout ce qui est maintenance et opérations. C’est Google qui achète et met en place les serveurs, qui gère les crash de serveurs et de disque dur, les mises à jour, les redimensionnement ... pas nous.
    C’est un doux euphémisme que de dire que l’écosystème Hadoop est compliqué, l’écosystème a 10ans d'expérience et est composé d’un nombre important de framework, de technologies, comme par exemple : Hive, HDFS, Impala, Zookeper ...
    Une des fonctionnalités de BigQuery que j’adore personnellement, c’est le fait de pouvoir faire du SQL ! Je ne sais pas vous mais requêter sa base BigData en SQL, j’adore :-).
  • Grâce à l’infrastructure de Google, si du jour au lendemain au lieu de stocker des Go vous devez stocker des To ou bien des Po de données, il n’y aura pas de problème de performances et d’interruptions. La techno est scalable. Après il en va s’en dire que stocker 5Go ou 5Po de données par mois, cela n’aura pas le même coût :D.
    Il est assez rapide d’implémenter BQ dans son appli dans et BQ est Rapide. En utilisant BQ on va exploiter les milliers de serveurs répliqués et la puissance de calcul et de stockage des serveurs de Google
    On ne paie uniquement que pour notre utilisation
    Il est possible de requeter en synchrone ou via des jobs en asynchrone. Tout dépend de votre besoin.
    Et enfin, vous allez le voir un peu plus tard, il y a une multitude d’outil de visualisation, d’ETL ... qui s’inter-connecte facilement avec BigQuery .
  • BigQuery a également des limitations :
    La chose importante à savoir est que l’on peut insérer/ajouter (par batch ou streaming/au fil de l’eau) des données dans une table mais on ne peut les modifier (update) ou les supprimer (delete).
    Il s’agit d’un service dans le Cloud donc il peut y avoir des latences réseaux par moment.
    Plus il y a de données dans vos tables, de données a requêter et plus BQ va être performant. Si vous voulez stocker une dizaine ou une centaine de tuples alors BigQuery n’est pas fait pour votre besoin mais par contre si vous voulez y stocker et pouvoir requeter/analyser des To, des Po de données, alors là BQ peu tirer son épingle du jeu et sera plus rapide que d’autres technologies telle que Hive.
    Et dernier point, les données doivent être structurées avant de pouvoir les insérer dans BQ.

    Une chose a noter également est qu’il n’y a pas d’Index, les tables sont lues en fullscan.
  • BigQuery est avant tout fait pour faire de l’analytics sur ses données.
    Ce n'est pas une base de données qui peut servir de backend a une application qui fait des updates. BigTable en revanche peut jouer ce rôle, surtout si l'application a besoin de stocker a grande échelle.
  • BigQuery est utilisé pour une multitude de besoins et de secteur de marché, il est par exemple utilisé :
    dans les jeux
    les social media analytics
    la surveillance/monitoring d’infrastructure
    pour analyser des logs et les représenter dans des Dashboards
    pour l’optimisation de campagnes de publicité
    l’analyse des données de sensor
    mais également dans plusieurs services de Google comme par exemple Google Play qui l’utilise pour afficher son Top 10 des applications

    BQ se relie facilement a Google Analytics si vous avez un compte Pro.
  • Comme vous pouvez le voir dans cette slide, il y a des quotats comme pour toute les technologies de ce genre et plus les mois passent, plus Google augmente les quotats donc moins nous sommes limités.
    Pour information chez atchik nous n’avons jamais atteint les limites pour notre utilisation.
    La chose a savoir concernant les quotats est que la taille max par type de fichier est de 1 Go pour les CSV et JSON compressés et 1To en non compressé pour les JSON et jusqu’a 4To pour les CSV.
    A noter que toutes les données qui sont en cache, ne sont pas comptées dans les quotas.
  • Parlons maintenant des coûts, un sujet qui vous intéresse je pense J.
    BigQuery n’est pas une solution OpenSource, c’est un service payant de Google.
    Le principe de BQ est de ne payer que lorsque vous l’utilisez et que pour les colonnes que vous utilisez.
    Depuis le 12 Aout 2015 il faut payer 0.01$ par tranche de 200Mo insérés alors que avant cette date il fallait payer la même somme par tranche de 100 000 lignes insérées.
    Tout comme les quotats, les couts évoluent également donc je vous invite à aller sur le site internet de bigquery pour les voir.
  • Je vous l’ai déjà dit tout à l’heure, BQ est une implémentation externe de Dremel.

    Pour essayer de comprendre comment fonctionne BigQuery, il va donc falloir s’intéresser aux deux technologies de base de Dremel :

    Dremel utilise une base de données orientée colonnes.
    Tout comme son nom l’indique, une base de données orientée colonnes est une base de données qui stocke les données par colonne et non par ligne.
    L'orientation colonne permet d'ajouter des colonnes plus facilement aux tables (les lignes n'ont pas besoin d'être redimensionnées).

    Dremel stocke les enregistrements par colonne sur des volumes de stockage différents, alors que les bases de données traditionnelles stockent l’ensemble des données sur un seul volume. Cela permet un taux de compression très élevé.
    Un avantage de ce sytème de stockage est que les champs vides sont gratuit, ils sont stocker gratuitement, et ils coûtent de l'argent que dans les requêtes quand ils sont explicitement utilisés.

  • La 2eme technologie de base de Dremel est son architecture en arbre.
    C’est une pyramide de serveurs/ de machines.

    Ce type d’architecture est utilisé pour dispatcher les requêtes et agréger les résultats à travers des milliers de machines en quelques secondes.

    etage du bas : responsable de lire sur le disque
    chaque machine qui obtient son resultat, l'envoi aux serveurs intermediaires
    et ensuite le serveur root aggrege le resultat et le renvoie au client, donc à nous :-)
  • BQ est composé de 4 composants :

    Projects : Toutes les données dans BigQuery sont stockées dans des projets. Un projet est identifié par un ID unique ainsi qu’un nom. Il contient la liste des utilisateurs autorisés, les informations concernant la facturation et l’authentification à l’API.
    Dataset : Les tables sont groupées par dataset qui peut être partagé à d’autres utilisateurs. Un dataset peut contenir une ou plusieurs tables.
    Table : Les tables sont représentées comme ceci : <project>:<dataset>.<table_name>. Nous verrons cette règle de nomage lorsque l’on parlera du SQL. Il y a une chose a savoir : il ne peut y avoir plus de 10 000 colonnes par table !
    Jobs : Toutes les opérations asynchrones que BigQuery effectue sont faites par les jobs (chargement, insertion de ligne, exécution d’une requête).

  • Lorsque l’on créé une table il faut définir son schéma, son architecture.
    Voici un exemple de schéma d’une table.
    La table message contient 4 colonnes :
    la colonne word qui est de type string/chaîne de caractères
    la colonne word_count de type integer/entier
    la colonne corpus de type string
    et la colonne corpus_date de type integer car elle contient une année



  • Il y a deux options pour charger vos données dans BigQuery :
    soit en direct
    soit via Google Cloud Storage

    Dans les deux cas vous pouvez insérer des données dans BQ :
    via l’outil en ligne de commande (bq command line tool)
    via la Google API console (web UI)
    ou bien via l’API REST

    Lors de la démo, d’ici quelques minutes, je vous montrerai la console de Google pour BigQuery, c’est un outil super pratique qui permet entre autre de charger vos données grâce à un CSV ou un JSON en entrée.
  • Vous pouvez soit charger vos données via batch/lot, ou au fil de l’eau via l’API de Streaming comme le montre ce schéma.
  • L’API REST est accessible via une multitude de librairies mise à disposition : En Java, en php, en python … mais également en C# et en Go.
  • Voici notamment un exemple en Java qui permet d’insérer des entrées dans une table.

    J’aimerai attirer l’attention sur la méthode setInsertId(), cette dernière est optionnelle mais importante, elle a besoin en paramètre d’une valeur unique.
    En effet, si vous tentez d’ajouter plusieurs rows ayant le même insertId, alors BigQuery pensera qu’il s’agit de doublons, et n’insérera en base que la dernière valeur de votre objet.
  • Il existe aussi plusieurs connecteurs dont un connecteur qui permet aux applications Hadoop et Spark d’accéder aux données dans BigQuery.
    Vous pouvez également interconnecter vos données avec votre tableur Excel ou Google apps scripts pour générer de jolis graphiques par exemple.
  • Le SQL de BigQuery est une variante de l’instruction SELECT SQL standard.
    Il y a quelques fonctions intéressantes tel que la fonction TOP, TABLE_DATE_RANGE et REGEXP_MATCH qui permet d’utiliser des expressions régulières directement dans une instruction en SQL.
    A savoir que généralement la fonction TOP est plus performante que le standard GROUP BY ... ORDER BY ... LIMIT ..., mais peut renvoyer des résultats approximatifs.
    Les mots clés ne sont pas sensible à la casse
    et la fonction table_date_range est très intéressante car elle fait partie des fonctions de wildcard des tables, au lieu de lister toutes les tables après le champ FROM, on peut appeler la fonction table_date_range pour sélectionner uniquement les tables d’une date à une autre date comme ceci
  • Comme nous l’avons vu, il y a plusieurs manières d'interagir avec BigQuery, dont la console

    Github met a disposition ses données publiquement sur BigQuery, nous allons donc en profiter pour exécuter quelques requêtes

    github_timeline > Details btn
    Comme vous pouvez le voir, les requetes que l’on va faire concerne une table qui fait plus de 3 Go

    1. SELECT count(*) FROM [publicdata:samples.github_timeline]
    --> nb d'enregistrement : + de 6 millions de lignes

    2. Sur ces millions de ligne, je veux récupérer la liste de ttes les repository qui ont plus de 50 bugs/issues d’ouvertes
    SELECT repository_url FROM [publicdata:samples.github_timeline] where repository_open_issues > 50

    3. Imaginons maintenant que l’on souhaite un top 10 des repository github ayant le + de fork
    Donc on fait un group by sur plus de 6 millions de ligne et on obtient le resultat en qq secondes

    SELECT repository_url, MAX(repository_forks) as max_forks FROM [publicdata:samples.github_timeline] GROUP EACH BY repository_url ORDER BY max_forks DESC LIMIT 10

    4. Et enfin, imaginons que l’on souhaite connaitre le top 100 des repositories Github les + actifs concernant le langage Java :

    SELECT repository_name, count(repository_name) as pushes, repository_description, repository_url
    FROM [publicdata:samples.github_timeline]
    WHERE type="PushEvent"
    AND repository_language="Java"
    AND PARSE_UTC_USEC(created_at) >= PARSE_UTC_USEC('2012-04-01 00:00:00')
    GROUP BY repository_name, repository_description, repository_url
    ORDER BY pushes DESC
    LIMIT 100

    J’ai une petite question pour vous. A votre avis, combien de disques en parallèle sont sollicités par Google lorsqu’une requête est exécutée ?
    -> Entre 1500 et 2000 disques selon Google.

    5. table+grosse 100 milliard de linges : logs de wikimedia
    combien d'accès d'images dessus, la langue ...
    qq secondes avec que sur une machine ça aurait pris 24 heures


    Il y a un énorme pool BigQuery, lorsque je lance un requete, entre 1500 et 2000 machines qui ont accédées aux disques
  • Il existe une multitudes d’outils de reporting et de visualisation de données qui possède un connecteur pour BigQuery donc vous pouvez facilement et rapidement interconnecter BigQuery a vos outils préférez : Tableau, Bime …
    Il existe également des connecteurs ODBC tel que Simba.
    La liste complète des outils de visualisation, d’ETL et des connecteurs est disponible sur le site de BigQuery.
  • Lorsque l’on étudie la faisabilité d’utiliser telle ou telle techno, une donnée qui est importante est celle de la performance.
    Pourquoi utiliser BigQuery ? Parce que justement le point fort de cette techno est que, comparée a Hive par exemple, il n’y a pas photo.
    En moyenne faire une requete SQL sur 3 To prend 7 secondes. Mais il faut savoir que comparé a HBase, BigQuery sera moins performant. Bien entendu dans ce cas on compare un torchon à une serviette mais il faut le savoir.

    Et redshift?
  • Que serait une présentation d’une techno sans une liste des clients ou applis qui l’utilisent ? :-)
    Pour information une petite appli très peu utilisée l’utilise aussi : Snapchat ;-)
  • Je vais maintenant vous parler de notre cas chez atchik.
    Il y a qq années nous avions un cluster hadoop d’une 12aines de serveurs sous Cloudera Manager.
    Cela représente un cout hardware, en électricité et en personnel également. Il y a de la maintenance a faire, lorsqu’il y a un soucis, un nodeserver qui est par terre par exemple, il faut évidemment les connaissances, que les membres de l’équipe soit disponible et sachent comment le monde merveilleux d’Hadoop fonctionne avec Zookeper, Impala, Hive …
    Notre cluster Hadoop fonctionnait bien, il répondait à nos besoins mais un événement est survenu : notre équipe technique a été sérieusement réduite.

    Dans un premier temps donc pendant de nombreux mois on a continué avec le cluster Hadoop mais étant donné que nous nous sommes trouvés a 2, que nous devions gérer la création, la maintenance et l’opérationnel de nos applications métiers et sociales plus un tas de petites tâches diverses et variées, il a été important de se poser la question de voir s’il n’y avait pas d’autres techno que l’on pouvait utiliser.
  • C’est à ce moment là que nous avons entendu parler de BigQuery qui n’était pas assez mature à l’époque, nous avons suivi son avancement et lorsque BQ fut assez mature et qu’ils répondait à nos besoins (avec notamment l’arivée de l’API de Streaming), nous avons créer une nouvelle branche de notre application métier, et avons implémenter BQ sur notre outil. Après avoir effectués des tests de performance, nous sommes définitivement passer à BigQuery ! :-)
    En terme d’économie il n’y a pas photo :
    au revoir les couts hardware
    les couts de maintenance
    et a noter que l’on économise par mois une 100aine d’euros en électricité

    En terme de cout comme vous pouvez le constater sur cette slide, on est a une 20aine de centimes de dollar par mois ...
  • Je sais que vous être friand de schéma, d’architecture, donc je vous ait représenter ici le schéma de notre appli qui stocke les données dans BQ et de notre appli qui récupère les informations pour en faire des reportings client, des dashboards pour nos équipes interne et qui permet à nos clients de suivre les actions de nos équipes en temps réel.

    Quelques mots sur notre plateforme : elle permet de centraliser l’ensemble des flux modérés, quel que soit le réseau social, le site internet, le blog ... sur une interface unique. Depuis l’outil nos équipes de modérateurs, de community managers et de veilleurs peuvent modérer, classifier, appliquer une tonalité aux contenus de nos clients.
    Quelques chiffres de notre plateforme : 6,2 milliards de messages par an

    La plateforme permet donc de récupérer, de traiter, de stocker et d’analyser ces données.
  • Quelques Astuces/tips et ce qu'il faut retenir pour réussir un projet avec BigQuery :

    Structurer ses données: Pour ne pas payer cher, il faut bien réfléchir à l’architecture de ces tables (compromis argent et performances)
    Découper les tables par date afin de diminuer le coût des données scannées et le temps de réponse de l’exécution des requêtes
    En activant le query cache, lorsqu’une requete est exécutée, BQ va regarder en premier s’il a le resultat dans son cache. Cela permet de gagner en performances et je vous rapelle que les données récupérées dans le cache ne vous couteront rien du tout.
    Il faut définir une date d’expiration lors de la création de la table pour éviter d’avoir trop de tables et ne payer que pour les tables que l’on utilise vraiment (avoir la main sur les coûts). Les tables se détruiront automatiquement au bout de x jours. Cela évite a avoir à développer un système de purge.
  • Faire des jointures sur beaucoup de petites tables peut impacter les performances
    Vous avez la possibilité de partager un dataset et/ou bien des rows a des collaborateurs ce qui peut être super pratique
    Le type date est en UTC donc il faut faire sois même les conversions, faire attention aux heures d’été et d’hiver ...
    Vous l’aurez deviner vu l’architecture de la base de données par colonnes, il est déconseillé d’utiliser l’instruction SELECT * FROM

    Depuis Aout 2015 on peut créer ses propres fonctions en Javascript via les UDF, si on veut créer sa propre méthode d'average/de moyenne par exemple, c’est possible
  • Je vous ais mis une liste de liens utiles sur cette slide dont un tutoriel
  • Si vous avez envie de vous lancer, je vous conseille ce livre édité aux éditions O’Reilly.
  • Des questions ? :-)
  • Dans les coulisses de Google BigQuery

    1. 1. 2/35 Qui suis-je ? Aurélie Vaché Développeuse Full Stack chez @aurelievache #bigquery @aurelievache
    2. 2. “Big Data” != “Hadoop” 3/35#bigquery @aurelievache
    3. 3. GFS MapReduce BigTable 2004 2008 2012 Dremel Colossus BigQuery Google et la révolution Big Data 2002 2006 2010 2015 DatalabBeta 4/35#bigquery @aurelievache
    4. 4. ● AaaS (Analytics as a Service) ● stocker, analyser, exécuter des requêtes sur des grands volumes de données et partager ses données structurées Qu’est ce que BigQuery ? 5/35#bigquery @aurelievache
    5. 5. Qu’est ce que BigQuery ? 6/35#bigquery @aurelievache
    6. 6. Pourquoi utiliser BigQuery ? - SLA 99.9% - Infrastructure de Google - Pas de coût de serveurs, d'opération et de maintenance - Moins complexe écosystème Hadoop - BigQuery SQL 8/35#bigquery @aurelievache
    7. 7. Pourquoi utiliser BigQuery ? - Scalabilité - Rapide - “Pay only for what you use” - Requêtes synchrones et asynchrones - Facilité d’interconnexion avec outils tiers 9/35#bigquery @aurelievache
    8. 8. Inconvénients/Limitations - “ Append-only tables ” - Latences réseau possibles - Performant sur des énormes tables (Go, To, Po), moins sur des petites tables - Les données doivent être structurées 10/35#bigquery @aurelievache
    9. 9. ● BigQuery => Analytics. ● Cloud Bigtable => NoSQL - stockage a grande échelle, update possible. Différence entre BigQuery et Bigtable ? 7/35#bigquery @aurelievache
    10. 10. Usages 11/35#bigquery @aurelievache
    11. 11. Quotas Requêtes ● 20 000 req/jour ● 100 To données 100 000 lignes insérées /sec / table StreamingChargement ● 1 000 jobs /table / jour ● 10 000 jobs /projet /jour ● ... 12/35#bigquery @aurelievache
    12. 12. Coûts Gratuit : Chargement des données + Export des données + tables lues + copies de tables + données dans le cache. Requêtes 5$ par To de requêtes 0,01$ pour 200 Mo Stockage Insertion 0,020$/Go/mois 13/35#bigquery @aurelievache
    13. 13. Architecture technique 1. BDD orientée colonne 14/35#bigquery @aurelievache
    14. 14. Architecture technique 2. Architecture en arbre 15/35#bigquery @aurelievache
    15. 15. Composants Project (billing, top-level container) Dataset (organization, access control) Job (query, import, export, copy) Table (data with schema) <project>:<dataset>.<table_name> 16/35#bigquery @aurelievache
    16. 16. Composants > Table Ex de schéma : date:TIMESTAMP,cid:INTEGER,cl,toto,titi,uid:INTEGER Type de données possible : string, integer, float, boolean, timestamp et record (nested / repeatable). 17/35#bigquery @aurelievache
    17. 17. Comment charger vos données ? 18/35#bigquery @aurelievache
    18. 18. Comment charger vos données ? 19/35#bigquery @aurelievache
    19. 19. L’API REST 20/35#bigquery @aurelievache
    20. 20. Exemple en JAVA // insert data List<TableDataInsertAllRequest.Rows> rowList = new ArrayList<TableDataInsertAllRequest.Rows>(); rowList.add(new TableDataInsertAllRequest.Rows() .setInsertId(""+System.currentTimeMillis()) .setJson(new TableRow().set("adt", null))); TableDataInsertAllRequest content = new TableDataInsertAllRequest().setRows(rowList); TableDataInsertAllResponse response = bigquery.tabledata().insertAll( PROJECT_NUMBER, DATASET_ID, TABLE_ID, content).execute(); System.out.println("kind="+response.getKind()); System.out.println("errors="+response.getInsertErrors()); System.out.println(response.toPrettyString()); 21/35#bigquery @aurelievache
    21. 21. Connecteurs 22/35#bigquery @aurelievache
    22. 22. Fonctions intéressantes : - TOP - TABLE_DATE_RANGE - REGEXP_MATCH / REGEXP_REPLACE / REGEXP_EXTRACT BigQuery SQL Variante de l’instruction SELECT SQL standard … FROM (TABLE_DATE_RANGE(TDS.meetup_, TIMESTAMP('2015-11-01'), TIMESTAMP('2015-11-30'))) 23/35#bigquery @aurelievache
    23. 23. Demo Time ! 24/35#bigquery @aurelievache
    24. 24. Visualisation et BI ETL Third-party tools Connecteurs 25/35#bigquery @aurelievache
    25. 25. Performances 26/35#bigquery @aurelievache
    26. 26. Ils utilisent BigQuery 27/35#bigquery @aurelievache
    27. 27. État des lieux - Cluster Hadoop - 12 serveurs sous Cloudera Manager v4.6 et CDH 4.3.0 - Facturation de l'électricité pour une dizaine de serveurs : environ 2 000 kilowatt heure / semaine : soit une centaine d'euros par mois - Coût hardware - Coût opérationnel - Évènement : Changement et réduction d’équipe 28/35#bigquery @aurelievache
    28. 28. - Coût hardware : 0 € - Coût opé : 0 € Passage à Google BigQuery 29/35#bigquery @aurelievache
    29. 29. Utilisation 30/35#bigquery @aurelievache
    30. 30. - Bien structurer ses données - Split by date - Utiliser le query cache - Définir une date d’expiration lors de la création de la table Astuces/Tips 31/35#bigquery @aurelievache
    31. 31. - Attention aux jointures - Possibilité de partager un dataset/des rows à des collaborateurs - Format date : UTC ! - Ne pas utiliser l'instruction SELECT * FROM - UDF (User-Defined Functions) Astuces/Tips 32/35#bigquery @aurelievache
    32. 32. - SLA : https://cloud.google.com/bigquery/sla - Quotas : https://cloud.google.com/bigquery/quota-policy - Prix : https://cloud.google.com/bigquery/#pricing - Pricing calculator : https://cloud.google.com/products/calculator/ - SQL : https://cloud.google.com/bigquery/query-reference - Tuto : Real-time data analysis with Kubernetes, Cloud Pub/Sub, and BigQuery Liens 33/35#bigquery @aurelievache
    33. 33. Pour aller plus loin ... 34/35#bigquery @aurelievache
    34. 34. SELECT questions FROM meetup:TDS.bigquery 35/35#bigquery @aurelievache

    ×