Google dévoile l'architecture du nouvel entrepôt de données décisionnel de YouTube

A l'occasion de la 5ème édition de la conférence XLDB organisée à l'université de Stanford en octobre 2011, Biswapesh Chattopadhyay, ingénieur chez Google a présenté l'architecture de l'entrepôt de données développé en interne pour analyser les contenus de son service YouTube.

Les chiffres de YouTube donnent rapidement le tournis. D'après une infographie de Go-Gulf.com compilant différents chiffres, YouTube diffuserait en 2012 environ 2 milliards de vidéos par jour, ce qui représenterait environ 10 % de la bande passante de l'internet mondial. Cette base de contenus vidéos s'enrichit chaque jour de plus de 800 000 nouvelles vidéos, c'est à dire que chaque minute de la journée, ce sont 24 heures de vidéo qui sont téléchargées sur le site. La base totale des vidéos représente environ 15 millions d'heures d'images… Et c'est donc l'usage de tout ce contenu que YouTube doit collecter et analyser dans son entrepôt de données, afin d'optimiser son modèle économique : monétiser ce contenu au travers de publicités.

Les vidéos, leurs visualisations, les traces de connexion, tout doit être analysé dans un entrepôt de données qui compte mille milliards de lignes, et représente avant compression plusieurs pétaoctets de contenu. Le chargement des données quotidiennes est à lui seul un enjeu puisqu'il faut alimenter l'entrepôt de plusieurs centaines de nouveaux téraoctets chaque jour.
YouTube avait utilisé des technologies disponibles sur le marché (Oracle, puis MySQL pour éviter que les coûts n'explosent au même rythme que la croissance du nombre de vidéos déposées sur le site, Python, Microstrategy…) avant qu'il ne soit racheté par Google. Google a choisi de redévelopper l'ensemble de son architecture décisionnelle YouTube autour de technologies internes. Ces technologies qui peuvent sans rougir s'attribuer l'étiquette Big Data, s'appellent Dremel, ABI Reports, Tenzing ou encore Sawzall. Vous n'en avez sans doute jamais entendu parler. Ce sont les noms de code internes utilisés par Google. Certaines de ces technologies pourraient demain (ou après-demain plutôt) être disponibles sur le marché, soit commercialisées par Google, soit comme l'éditeur l'a déjà fait par le passé, gratuitement au travers de projets à code ouvert.

Pourquoi redévelopper des outils qui existent déjà, en particulier dans la galaxie Hadoop ? Tout simplement parce que Google fait face à des volumes et à des contraintes particulières qui font que même les meilleurs outils du marché peuvent être insuffisants à ses besoins. Par ailleurs Google est une société d'informatique, où excellent même les meilleurs "computer scientist" venus du monde entier. Et une société de technologie comme Google a toujours plusieurs années d'avance dans le développement des outils, que l'on retrouvera peut-être pour certains ensuite sur le marché. Une autre raison, toute simple, est économique. Google opère des centaines de milliers de serveurs dans le monde; des serveurs développés par Google pour optimiser leur rapport puissance/prix. Il serait alors dommage de perdre une partie des économies faites par cette optimisation sur des licences de logiciels propriétaires. Pour Google, il est parfois tout simplement moins cher de développer que d'acheter !

Cela ne se produit que dans deux cas, lorsque vous êtes aux extrémités de la courbe d'usage; soit trop peu d'utilisateurs et vous développez vous-même car aucun éditeur ne peut rentabiliser l'investissement sur votre marché (c'est souvent le cas dans le domaine militaire par exemple); soit vous avez trop d'utilisateurs ou trop de serveurs et cela devient plus intéressant de développer vous-même que d'acheter.

Les données qui alimentent l'entrepôt décisionnel de YouTube proviennent essentiellement de trois sources :
- les logs de connexion au site, qui représentent le volume le plus important,
- MySQL qui héberge le contenu du site, les vidéos et les méta-données,
- BigTable de Google qui contient des données déjà analysées et des données en provenance d'autres sites (dont Facebook).

Pour extraire les données et alimenter l'entrepôt de stockage, Google s'appuie sur Sawzall et Tensing, deux projets internes;
Les processus d'alimentation sont complétés par des développements spécifiques en Python et du code MapReduce.

L'entrepôt de données en lui-même est stocké au format ColumnIO, un autre projet de base de données en colonne piloté par Google, et sous GFS .

Pour extraire les données de son entrepôt décisionnel, Google a là encore développé ses propres outils, encore une fois pour des raisons combinées et de coût et de performance. Tenzing et Dremel servent à interroger le data warehouse directement. Dremel permet de lancer des requêtes ad-hoc, et pour certaines d'alimenter ensuite l'outil de restitution, ABI Reports, qui remplace Microstrategy et Oracle Reports.

Les trois outils essentiels sont donc Sawzall, Tenzing et Dremel. Dremel semble le plus évolué, et l'outil sur lequel Google concentre l'essentiel de ses efforts de développement. Les caractéristiques de chacun de ces trois outils sont complémentaires : Tenzing est une couche SQL qui vient se poser sur MapReduce, semblable à Hive ou HadoopSQL; Dremel est un outil plus interactif conçu pour des analyses de gros volumes de données en "temps réel", etc.
Face à ces trois outils de requête, Google a choisi de réunir le meilleur au sein de Dremel (que nous présenterons en détail dans un prochain article sur Decideo). A terme, une fois Dremel doté par exemple de fonctions MapReduce, Tenzing devrait disparaitre à son profit. Pendant de Dremel pour les utilisateurs extérieurs, Google Big Query devrait alors bénéficier de ces améliorations.
Dans le graphique ci-dessous, Google compare ses trois outils et leurs points forts et faibles.

Même pour la partie restitution, les outils du marché n'ont pas trouvé grâce aux yeux de Google. Comme nous l'évoquions plus haut, l'argument financier bien sur, mais surtout l'ADN de l'entreprise. Google est une société d'ingénieurs, qui sont passionnés par le développement d'outils et sans doute convaincus de pouvoir, dans tous les domaines, faire mieux que leurs petits camarades.
Google s'est donc séparé de ses précédents outils propriétaires et a développé ABI Reports (Actionnable Business Intelligence) que Biswapesh Chattopadhyay présente comme une solution complète de création de rapports et de tableaux de bord. Connecté nativement à Dremel et à ColumnIO, ABI Reports s'appuie sur les outils de représentation graphique Google Chart Tools et sur quelques développements complémentaires en Flash.
Entre Dremel, l'outil de requête et ABI Reports, Google a également développé un composant intermédiaire, le Query Rewriter. Il optimise les calculs lors de la transmission des données entre le résultat de la requête (Dremel) et la représentation graphique des données (ABI Reports).

En résumé, l'infrastructure mise en place par Google pour analyser l'activité de son site YouTube est clairement hors normes.
Hors normes par les volumes traités (en stockage et en nouvelles données quotidiennes), par l'infrastructure sous-jacente, et par les besoins analytiques de l'éditeur.
Hors normes par les méthodes de Google, société d'ingénieurs dont le développement logiciel est inscrit dans l'ADN.
Google a-t-elle raison de développer ainsi l'ensemble de ses outils plutôt que d'en faire l'acquisition sur le marché. N'oublions pas que le projet décrit ici ne concerne que YouTube, mais que les besoins analytiques de Google sont bien plus étendus. Et si YouTube sert en partie de laboratoire interne de test de nouvelles solutions, l'analytique du moteur de recherche et des insertions publicitaires dépasse certainement la puissance de toutes les solutions du marché.
D'autres grandes sociétés du secteur Internet comme eBay, Facebook, Twitter ou LinkedIn sont également à l'origine de développements logiciels originaux.

Une question reste en suspens, la stratégie de Google vis à vis de ces solutions dans le futur. Avec Dremel, ABI Reports, ColumnIO, etc, Google dispose d'une offre logicielle qui pourrait répondre aux besoins de grandes entreprises, non concurrentes de Google. Cela imposerait cependant à Google de sortir de son rôle d'ingénieur-développeur et d'en faire le marketing, d'en assurer la vente. Même si Google Apps semble recueillir certains suffrages, ce n'est pas encore un raz de marée sur le marché des solutions bureautiques et collaboratives d'entreprise. Google n'est peut-être tout simplement pas capable, ou n'a pas envie de se lancer dans la commercialisation de ces offres. Pourtant quelques tentatives émergent, comme Google Big Query.
L'avenir nous dira donc si Google poursuit sa politique actuelle d'ouvrir le code de certains de ses développements pour en faire profiter l'ensemble de la communauté, ou si l'éditeur devient à son tour fournisseur de solutions décisionnelles par nature adaptées au "big data".

L'enregistrement vidéo complet de la conférence de Biswapesh Chattopadhyay est disponible en ligne. Vous pouvez donc la visualiser dans son intégralité ci-dessus.
Vous pouvez également télécharger les slides de sa conférence sur le site http://www-conf.slac.stanford.edu/xldb2011/Program.asp et en profiter pour découvrir les autres cas présentés lors de cette conférence.