Lorsque l’on pense à des technologies liées à la Big Data, on pense de suite à l’éco-système Hadoop, ou bien à 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.
Pour ma part, comme beaucoup d’entreprises, nous avons besoin de faire parler la donnée pour nos équipes en interne et nos clients, et la première architecture technique que nous avions mise en place reposait sur l’éco-système Hadoop avec un cluster sous Cloudera d’une dizaine de serveurs hébergée. Les performances étaient au rendez-vous mais le temps passé pour la maintenance et l’opérationnel était élevé.
Lorsque BigQuery fut assez mature et répondait à nos besoins sur le papier, nous avions décider de créer une branche de notre projet et de tester cette nouvelle technologie de Google.
Résultats : une centaine d’euros d’économisés par mois pour l’électricité, les coût concernant l’opérationnel sur ce projet ont disparu et la facture de Google s’élève a environ 0,20$ par mois et des performances au final qui sont équivalentes avec celle du cluster Hadoop et qui répondent toujours au besoin des utilisateurs finaux.
Comme beaucoup d’outils et de services, BigQuery a été conçu pour résoudre un problème.
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; en 2012, 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 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. Selon Armando Fox, professeur d’informatique à l’Université de Californie à Berkley, « Dremel est devenu extrêmement populaire chez Google. Les ingénieurs de Google l’utilisent des millions de fois par jour. » Le moteur de requêtes Dremel a créé une façon de paralléliser l’exécution des requêtes SQL sur des milliers de machines.
Dremel peut scanner 35 milliards de lignes sans un index en une dizaine de secondes.
Il existe deux technologies que Dremel utilise pour atteindre la lecture d’1 To de données en quelques secondes. Le premier est appelé Colossus : un système de fichier distribué et parallélisable développé à Google comme un successeur de Google File System (GFS). Le second est le format de stockage, appelé ColumnIO, qui organise les données d’une manière à ce que ce soit plus facile de les interroger.
En 2012, lors du Google I/O, Google a lancé publiquement BigQuery, qui a permis aux utilisateurs en dehors de Google de profiter de la puissance et la performance de Dremel.
Google BigQuery est une solution en mode SaaS (Software as a service) qui repose sur la plateforme de Cloud de Google et de ce fait de sa puissance de calcul.
Grâce à BQ on peut stocker, effectuer des requêtes et analyser des grands volumes de données : requêter des tables de plusieurs Tera Octets de données ne prend que quelques secondes.
Cette solution s’intègre bien avec Google App Engine mais également avec d’autres plateformes.
Techniquement, le service BigQuery est juste un serveur qui accepte les requêtes HTTP et renvoie les réponses au format JSON. Il communique avec Dremel, le moteur de requêtes qui communique avec Colossus.
* Requêtes : 20 000 requêtes par jour (et jusqu’à 100 To de données).
* Chargement/Upload de donnée :
* Streaming : 100 000 lignes insérées par seconde par table maximum.
A noter que toutes les données qui sont en cache, ne sont pas comptées dans les quotas.
Vous pouvez voir la liste complète des quotas si cela vous intéresse.
Les utilisateurs de BigQuery sont actuellement facturés pour deux choses : le stockage et les requêtes. Les deux coûts sont proportionnels à la taille des données.
Importer des données via un fichier CSV ou JSON est gratuit.
Voici le modèle des coûts décrit de manière détaillée :
Les prix sont sujets à changement donc veuillez vous tenir informés sur le site officiel de BigQuery : https://developers.google.com/bigquery/pricing.
Pour comprendre comment BigQuery peut-il être aussi performant sur d’énormes tables, il faut se pencher sur son architecture technique.
Comme on l’a déjà vu ci-dessus, BigQuery est une implémentation externe de Dremel.
Pour essayer de comprendre en quelques mots comment fonctionne BigQuery, il faut connaître les deux technologies de base de Dremel :
1. Base de Données orientée colonne
Source : livre Google BigQuery Analytics
Dremel utilise BigTable et ColumnIO (des bases de données orientées colonne) et stocke les données sous forme de colonne. Grâce à cela, on ne charge que les colonnes dont on a vraiment besoin.
Dremel stocke les enregistrements par colonne sur des volumes de stockage différents, alors que les bases de données traditionnelles stockent normalement l’ensemble des données sur un seul volume. Cela permet un taux de compression très élevé.
2. Architecture en arbre
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.
Source : livre Google BigQuery Analytics
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.
Les tables sont groupées par dataset qui peut être partagé à d’autres utilisateurs. Un dataset peut contenir une ou plusieurs tables.
Les tables sont représentées comme ceci : <project>:<dataset>.<table_name>
Pour comprendre cette règle de nommage, regardons de plus prés une requête SQL :
SELECT message FROM [meetup:logs.latest]
le champ message est sélectionné de la table latest qui est dans le dataset logs qui est dans le projet meetup.
Lorsque l’on créer une table il faut définir son schéma.
Exemple de schéma :
word:STRING,wordcount:INTEGER,corpus:STRING,corpus_date:INTEGER
Type de données possible : string, integer, float, boolean, timestamp et record (nested / repeatable).
Toutes les opérations asynchrones que BigQuery effectue sont faites par les jobs (chargement, insertion de ligne, exécution d’une requête).
Pour communiquer avec BigQuery il existe plusieurs moyens :
Cette interface permet d’effectuer la plupart des opérations dans l’API : lister les tables disponibles, afficher leur schéma et leurs données, partager des dataset avec d’autres utilisateurs, charger des données et les exporter vers Google Cloud Storage.
La console de Google est très pratique lorsque l’on veut exécuter/tester/fine-tuner (optimiser) des requêtes.
En quelques clics on crée sa requête, on l’exécute et on obtient les résultats en quelques secondes.
Source : livre Google BigQuery Analytics
Si vous n’avez aucun projet de créé avec Google BigQuery d’activé et que vous souhaitez accéder à la Google console, vous pouvez cliquer sur le bouton « Essai gratuit ».
Si l’on souhaite par exemple ajouter une colonne dans une table, en ligne de commande c’est possible.
0. Pré-requis : vous devez installer ou avoir Python d’installé sur votre machine.
Puis vous devez vous authentifiez :
gcloud auth login
1. Il suffit de récupérer le schéma de la table :
bq --format=prettyjson show yourdataset.yourtable > table.json
2. Il faut maintenant modifier le fichier, tout supprimer excepté le schema (garder [ { « name »: « x » … }, … ]) et ajouter la nouvelle colonne a la fin par exemple.
3. Mettre à jour le schema de sa table :
bq update yourproject.yourtable table.json
– Il existe une dizaine de librairies clientes qui sont mises à disposition par Google. Elles sont disponible pour Java, Python, PHP, Ruby, .NET …
– Et bien entendu il existe une API de type REST.
A noter que les APIs utilisent l’API d’authentification OAuth2.
Il existe deux moyens pour charger des données dans une table :
Puis il faut bien penser à définir le schéma de cette table :
Le job qui a procédé au chargement des données et à la création de la table a bien fonctionné :
* Soit, via l’API, on peut charger un fichier CSV ou JSON également ou bien insérer des entrées dans une table :
List rowList = new ArrayList();
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());
Les requêtes sont écrites en utilisant une variante de l’instruction SQL SELECT standard. BigQuery prend en charge une grande variété de fonctions telles que COUNT, les expressions arithmétiques, et les fonctions de chaîne. Vous pouvez consulter la page Query Reference pour tout savoir sur le langage de requête de BigQuery.
Tout comme le SQL standard, l’instruction SELECT s’écrit de cette manière :
SELECT expr1 [[AS] alias1] [, expr2 [[AS] alias2], ...]
[agg_function(expr3) WITHIN expr4]
[FROM [(FLATTEN(table_name1|(subselect1)] [, table_name2|(subselect2), ...)]
[[INNER|LEFT OUTER|CROSS] JOIN [EACH] table_2|(subselect2) [[AS] tablealias2]
ON join_condition_1 [... AND join_condition_N ...]]+
[WHERE condition]
[GROUP [EACH] BY field1|alias1 [, field2|alias2, ...]]
[HAVING condition]
[ORDER BY field1|alias1 [DESC|ASC] [, field2|alias2 [DESC|ASC], ...]]
[LIMIT n]
;
A noter quelques fonctionnalités intéressantes de BigQuery SQL :
Au lieu de lister toutes les tables quotidiennes dans votre SELECT, comme ceci :
SELECT TIMESTAMP_TO_MSEC(rdt), cl, cid FROM myproject.MEETUP_20150317, myproject.MEETUP_20150318, myproject.MEETUP_20150319 WHERE rdt >= '2015-03-17 16:45:00' AND rdt < '2015-03-19 10:50:00' ORDER BY rk LIMIT 5001
Voici ce qu’il est possible de faire avec cette fonction de wildcard :
SELECT TIMESTAMP_TO_MSEC(rdt), cl, cid FROM (TABLE_DATE_RANGE(myproject.MEETUP_, TIMESTAMP('2015-03-17'), TIMESTAMP('2015-03-19'))) WHERE rdt >= '2015-03-18 16:45:00' AND rdt < '2015-03-19 10:50:00' ORDER BY rk LIMIT 5001
Lorsqu’il s’agit de faire un SELECT sur une liste de tables quotidiennes sur plusieurs jours/semaines/mois, imaginez le gain pour l’écriture de la requête et les performances avec cette fonction.
Vous pouvez également utiliser des expressions régulières directement dans vos requêtes :
SELECT TIMESTAMP_TO_MSEC(rdt), titi, tata FROM [myproject.mytable_20141108] WHERE cl=18 AND rdt >= '2014-11-07 23:00:00' AND rdt < '2014-11-08 22:59:00' AND REGEXP_MATCH(id, '(?i)^(123456789|55884772)$') AND REGEXP_MATCH(bid, '(?i)^(7423456|3465465415)$') ORDER BY tutu LIMIT 123
Il existe plusieurs solutions pour visualiser les données qui sont stockées dans BigQuery.
Voici quelques exemples du rendu que l’on peut avoir :
Source : http://bigquery-sensors.appspot.com/console
Source : Un des outils de reporting et de BI d’atchikservices.
Source : Twitter for BigQuery.
Je tenais à vous parler de Google BigQuery parce qu’il s’agit d’une techno que j’utilise au travail et qui ne fait pas assez parler d’elle à mon goût. Ce n’est pas une solution miracle, cela n’existe pas, mais elle peut répondre à un besoin donné.
Le fait de notamment pouvoir intérroger la base de données en SQL, c’est vraiment très pratique. En quelques secondes on peut exécuter sa requête sur la Web UI et obtenir un export en CSV.
A noter qu’une formation sur Google BigQuery sera donnée lors de Devoxx France 2015. Si cet article vous a donné envie d’en apprendre davantage à propos de BigQuery, inscrivez-vous !
Et vous, avez-vous des problématiques de Big Data, avez-vous déjà utilisé Google BigQuery ou prévu de le faire ?
EDIT:
Si vous voulez en savoir plus : https://fr.slideshare.net/aurelievache/google-bigquery-devfest-toulouse-2016
At the Devoxx Anvers conference, I met Shanee Nishry who talked about Sense override (Cardboard).
Ludwine : Can you introduce yourself in a few words?
Shanee : I am a game developer, technology enthusiastic and futurist. My current focus is on games, graphics and virtual reality, but artificial intelligence and biotechnology also holds a special spot in my heart.
Ludwine : You talked about Virtual Reality and presented “Senses Override (Cardboard)” at the Devoxx conference, Anvers. Could you tell us more about it?
Shanee : Definitely! I talked about the current developments in virtual reality (VR), where it is now, what’s out there, and how people can start working on it. I am very excited about the growth in adoption of VR, as I feel it can completely transform media consumption and entertainment and so much more.
In one specific future use case, imagine surgeons trained via extremely accurate computer simulation or even operating by controlling a robot with camera, which moves its tools according to motion controlled tool the doctor is holding. This could be the case when a patient cannot be transported near a qualified doctor.
Simpler implementations would include games and complete 3D movies where you are transported into the scene and follow the characters, completely immersed by the action and atmosphere. There are applications for education, where you can teach a class about space, physics and chemistry through the safety of their seat, taking them to places which would be too dangerous or impossible. Speaking of impossible, it can also help people with disabilities travel, even if they normally can’t.
This technology is evolving so fast now, but not many people know of it. It still has quite a way to go, but people can already create their own virtual reality applications and help us evolve this field.
Ludwine : This year at the Google’s booth, the cardboard was the star. I tested it and it liked to contrast between this cardboard and the VR you can see inside. It’s very intriguing. How does it work?
Shanee : It’s quite simple actually! There are three main components: the cardboard headset, lenses and your phone.
The Cardboard is just a cover to fit the screen, block environmental light and host the lenses. The lenses then focus your large field of view into the screen which sits inside and generates pictures for your eyes to see.
The last bit is the software itself which anyone can make. The idea is to create a split view rendering, drawing what the left eye would see on half the screen and the right eye’s image on the other half. These images are generated by placing a virtual camera in a scene, for example a 3D game. The camera is offset in position and orientation for each eye, creating an accurate representation for what it would see and resulting in the stereoscopic image.
There is a tiny bit more improvement due to the distortion of the lens and each of those images can benefit by applying Barrel Distortion to correct for it but that’s the main story.
The last interesting bit is the magnet on the side of the Cardboard device which is used for input, which I thought is really smart. As the screen can’t be accessed when it is in the headset, a different solution is required. Some people might pair their phone with a bluetooth controller but not everyone has one. On the other hand, most phones have a magnetometer used for compass so by moving a magnet near the sensor you can create a noise in the magnetic field, this noise is then converted into user input, acting as a trigger.
In addition to this, Cardboard also contains an NFC sticker to detect when the phone is inside and a rubber band to keep the phone in place.
Ludwine : You love working on games, graphics and virtual reality. What is the last surprising things you’ve seen/discovered about it?
Shanee : Unfortunately, there aren’t many virtual reality games available yet, as both hardware and software still needs to catch up. It is very exciting to see all kind of peripherals coming along to enhance virtual reality, such as three dimensional treadmills from Virtuix, head mounted motion cameras like the LeapMotion and different type of controllers like gloves and wearable sensors.
There are also very interesting games. I’m currently playing Dragon Age Inquisition, which isn’t a virtual reality game, but I really love the level of detail and graphics there. It is amazing how much graphics progressed in just about a decade and how much it is still improving.
This also makes me excited about mobile. It’s amazing that the latest smartphone has about the same computing power as the Xbox 360 and Playstation 3. I can’t wait to see where we will be in just a year or two.
Ludwine : One last message?
Shanee : Keep a look for what’s out there! Things aren’t always obvious. I work with game developers and a lot of people think virtual reality is only for games, but it can be for all kind of things from architecture design and social medium to even robots, like in Avatar.
Make exciting things and help shape our future. Someone’s got to do it and waiting for it to happen is boring.
Thank you Shanee !
Her talk about Senses Override (Cardboard) on Parley’s.
Les Duchess vous invitent à un événement DevFestW, co-organisé avec le GDG Paris (Google Developer Group).
DevFestW, avec un W comme Woman, est une série d’évènements organisés dans le monde entier sur la période février/mars par les GDG et en partenariat avec divers groupes féminins de la communauté IT. Ces évènements soutenus par Google, ont pour but de mettre en avant des femmes, tant au niveau des speakers que de l’organisation. C’est donc à cette occasion que le GDG Paris et les Duchess France se sont associés pour organiser conjointement ce premier DevFestW à Paris.
Continuing our interview series, the Mix-IT team asked some questions to Petra Cross who will be at Devoxx France and at Mix-IT.
Photo by Cody Bratt
Petra is a Senior Software Engineer at Google and an avid photographer. You could follow her on twitter or on G+.
With Petra, we will look behind the scenes of day-to-day development workflow in the engineering teams at Google. She will speak about this topic at Devoxx France and Mix-IT .
Mix-IT Team : Who are you?
Petra : I’m a Googler, photographer, and a pretty good wife. I live in San Francisco, California.
Mix-IT Team : Could you describe your typical day? Do you work all the day?
Petra : I wake up at 10am, get ready, and then walk to work (yes, I get to walk to work). I work from about 11am until about 7pm. I sometimes go rollerblading in the middle of the day (Google San Francisco office is right by the waterfront, with very ice trail along the bay) and do yoga in the evening. When I get home, I tend to work on a photography project or work on my travel plans.
Mix-IT Team : Which new tools/framework do you discover recently and that has inspired you?
Petra : Since I joined Google Wallet in San Francisco, I have been writing code using Android libraries. I have never done mobile development before, so a lot of the concepts are new to me, but I’ve been having fun.
Mix-IT Team : Does your team at Google use Scrum, or is it just inspired by Scrum?
Petra : Let’s not confuse Scrum with Agile. Scrum is a method for managing software projects. Most of Google engineering managers do not use Scrum, but some do.
However, Agile is more wide-spread at Google. Lots of engineering teams use Agile principles of planning task backlog, iterating in cycles, and estimating the tasks for the upcoming iteration.
Mix-IT Team : What would be your ideal technical stack for a webapp today ?
Petra : I have not seen an ideal technical stack yet. All technologies have their pros and cons and it takes time to learn about all the quirks and gotchas. I am comfortable with the Google server stack with Javascript on top. I’m not a Javascript expert though. I’ve spent most of my seven years at Google working on Java backends which use Google’s powerful distributed computing and storage resources.
Thanks Petra !
See you at Devoxx France for your talk about software development Workflow at Google on Thursday 19 April at 5 p.m. and at Mix-IT on Thursday 26 April at 2 p.m.
Le Paris Jug organise mardi prochain une soirée « La mode cloud, collections d’été ». Elle sera animée par Patrick Chanezon, français d’origine parti travailler chez Google USA. Il dirige l’équipe en charge de la promotion des services Google dans le nuage (App Engine, Storage, Prediction, BigQuery, Go) et des outils (GWT).
Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.
Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.
