Dans les coulisses de Google BigQuery
•Télécharger en tant que PPTX, PDF•
0 j'aime•1,049 vues
Présentation effectuée le 25 Novembre 2015 au Toulouse Data Science. 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...
Recommandé
Recommandé
Contenu connexe
Similaire à Dans les coulisses de Google BigQuery
Similaire à Dans les coulisses de Google BigQuery (20)
Plus de Duchess France
Plus de Duchess France (15)
Dans les coulisses de Google BigQuery
- 2. 2/35 Qui suis-je ? Aurélie Vaché Développeuse Full Stack chez @aurelievache #bigquery @aurelievache
- 3. “Big Data” != “Hadoop” 3/35#bigquery @aurelievache
- 4. 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
- 5. ● 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
- 6. Qu’est ce que BigQuery ? 6/35#bigquery @aurelievache
- 7. 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
- 8. 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
- 9. 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
- 10. ● BigQuery => Analytics. ● Cloud Bigtable => NoSQL - stockage a grande échelle, update possible. Différence entre BigQuery et Bigtable ? 7/35#bigquery @aurelievache
- 12. 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
- 13. 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
- 14. Architecture technique 1. BDD orientée colonne 14/35#bigquery @aurelievache
- 15. Architecture technique 2. Architecture en arbre 15/35#bigquery @aurelievache
- 16. 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
- 17. 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
- 18. Comment charger vos données ? 18/35#bigquery @aurelievache
- 19. Comment charger vos données ? 19/35#bigquery @aurelievache
- 21. 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
- 23. 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
- 24. Demo Time ! 24/35#bigquery @aurelievache
- 25. Visualisation et BI ETL Third-party tools Connecteurs 25/35#bigquery @aurelievache
- 27. Ils utilisent BigQuery 27/35#bigquery @aurelievache
- 28. É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
- 29. - Coût hardware : 0 € - Coût opé : 0 € Passage à Google BigQuery 29/35#bigquery @aurelievache
- 31. - 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
- 32. - 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
- 33. - 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
- 34. Pour aller plus loin ... 34/35#bigquery @aurelievache
- 35. SELECT questions FROM meetup:TDS.bigquery 35/35#bigquery @aurelievache
Notes de l'éditeur
- 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 ? :-)