Comme l'a justement rappelé Manue sur le Figoblog, alors qu'il a atteint le ravin de la désillusion, le Big Data a désormais dépassé le stade du "buzzword". On peut aujourd'hui en voir les applications concrètes même si celles-ci restent souvent limitées, comme l'explique cette étude de Cap Gemini décryptée par ZDnet qui rappelle que seuls 13% des projets dits de Big Data sont entrés en production ou cet article très complet, "Le Big Data : un enjeu pour les industries créatives", paru sur le site INA Global qui, au-delà des exemples de réalisations, démontre les problèmes nombreux qu'ils restent à résoudre. Les espérances qui ont été placées dans cette évolution technologique doivent-elles être revues à la baisse ? Ou au contraire, est-ce le bon moment pour approfondir et développer les cas d'usage qui ont commencé à émerger ?

De fait, ces premières applications sont aujourd'hui suffisamment intéressantes pour justifier qu'on s'y intéresse de près et qu'on étudie les causes des échecs. Or, il apparaît qu'un des facteurs récurrents d'échec est la donnée elle-même (données de qualité insuffisante, mal agrégées...). Aurait-on oublié de s'intéresser à la donnée elle-même dans le Big Data ? Sans aller jusque là, il semble bien que la donnée, l'attention (pour ne pas dire curation...) qu'on y prête, sa compréhension n'aient pas totalement été au centre des préoccupations jusqu'à maintenant. Or, c'est précisément le rôle du professionnel de l'information. Mobilisant leurs compétences sur les données, ils doivent s'emparer du sujet pour faciliter son appréhension par les "directions métiers". Cela passe par une appropriation de la technologie : les professionnels de l'information ont aujourd'hui besoin de savoir ce qui se cache concrètement derrière ce terme de "Big Data". C'est que je me propose d'initier à travers ce billet.

Pour entrer directement dans le vif du sujet, une définition et un exemple :

Pour en donner une définition très générale, le Big data désigne la capacité technologique à traiter de très grandes masses de données avec des infrastructures matérielles standards.

L'exemple le plus frappant de projet big data, c'est Watson, l'application d'IBM qui a gagné Jeopardy. Afin de répondre à des questions posées en langage naturel, cette application agrège tous les systèmes possibles et imaginables de traitement automatique de la langue, recherche d'information, représentation des connaissances, raisonnement automatique et de machine learning. Mais, son fonctionnement a nécessité d'imaginer une infrastructure spécifique pour stocker les données et répondre aux besoins de ressources machines nécessaires pour effectuer les traitements. Or, l'enjeu du Big data, c'est de réussir à mettre en place des usages aussi performants qu'un Watson mais avec des infrastructures standards.

Le Big Data répond donc à un double objectif :

• assurer le passage à l'échelle (ou scalabilité), c'est-à-dire :
  • paralléliser les traitements informatiques (parallel computing) et les distribuer sur plusieurs machines (clustering) ;
  • stocker les données massives ;
• manipuler les données en masse, c'est-à-dire :
  • exploiter ces grandes masses de données (statistiques, analyse prédictive et apprentissage automatique) ;
  • traiter et préparer les données et orchestrer les traitements (ETL, data pipeline et système de gestion de workflow).

Que le traitement soit parallèle et distribué ! Et le Big Data fut !

Qui n'a pas entendu parler d'Hadoop ? Ce nom est pratiquement devenu synonyme de Big Data mais peu de gens savent exactement de quoi il s'agit. En effet, une fois qu'on a lu de A à Z l'article de Wikipédia qui explique qu'Hadoop est un framework logiciel en Java dont le logo est un éléphant jaune à cause du doudou du fils de son créateur, on n'est guère plus avancé... Alors à quelles questions Hadoop répond-il en réalité ?

Les informaticiens sont partis d'une idée simple : face à un problème, pour réduire sa complexité, on va le découper en problèmes plus petits, chacun pouvant être traité en parallèle par un processeur différent. Tous les développeurs vous expliqueront que pour faire cela, il faut concevoir dès l'origine les traitements pour qu'ils puissent être parallélisés. C'est complexe, coûteux et nécessite des compétences très spécifiques.

C'est là que l'algorithme Map Reduce intervient : il simplifie l'implémentation de ce découpage d'un processus en plusieurs processus plus simples. Ainsi au lieu d'allouer un traitement à un seul processeur, Map Reduce va utiliser toute la puissance machine disponible dans le serveur en attribuant le processus de départ à plusieurs processeurs. En gros, si j'ai huit processeurs dans ma machine, je sépare mon processus en huit et je vais donc pouvoir effectuer mon traitement huit fois plus vite.

Huit processeurs c'est bien, mais que se passe-t-il si je veux en utiliser seize ou trente-deux ? Une fois qu'on est capable de répartir un processus sur plusieurs processeurs, l'étape suivante du passage à l'échelle consiste à être capable de distribuer la même opération sur plusieurs machines. On parle alors de clustering. Pour cela on "fait croire" au processus qu'il tourne sur une seule machine en lui fournissant une vue abstraite de l'infrastructure matérielle et en particulier du système de fichier. C'est le rôle de HDFS (Hadoop Distributed File System).

Hadoop est donc un framework de développement qui offre de base ces deux fonctions : le parallélisme avec Map Reduce et la distribution avec HDFS. Mais cela ne résout pas tout... En effet, il faut quand même réécrire les traitements informatiques dont on dispose déjà pour les rendre compatibles avec Map Reduce et les compétences en la matière sont encore rares.

A signaler que l'algorithme de Map Reduce, et, par conséquent, Hadoop sont aujourd'hui remis en cause, les utilisateurs se plaignent, entre autres, de sa latence qui en complique l'utilisation dans des environnement "temps réel". Spark, porté par la fondation Apache comme Hadoop, semble ainsi répondre mieux à cette problématique et remplace Map Reduce dans des cas de plus en plus nombreux (cf. par exemple le cas du framework de Machine Learning Apache Mahout).

Au delà du relationnel, vers l'infinité du NoSQL !

Pouvoir manipuler des données en masse, c'est bien, mais vient un moment où il faut les stocker ces données et dans le paradigme traditionnel des bases de données relationnelles, cet objectif devient relativement vite une gageure.

Pourquoi ?

Pour comprendre où se situe le problème, il est nécessaire de revenir sur la problématique de la montée en charge ou scalabilité. Il existe deux types de scalabilité :

• la scalabilité verticale : la montée en charge est assurée par la montée en puissance d'une machine et donc de la capacité du système à l'exploiter  ;
• la scalabilité horizontale : la montée en charge est assurée par l'ajout de machines et donc la capacité du système à répartir la charge et le stockage sur plusieurs machines. Ce type de scalabilité est théoriquement infini (dès qu'on manque de place, on rajoute une machine et hop ! le tour est joué. Bon dans les faits, ce n'est pas aussi simple...).

Le problème avec les bases de données relationnelles, c'est qu'intrinsèquement elles ne sont pas scalables horizontalement en raison de l'un de leurs principes fondateurs : ACID (atomicité, cohérence, durabilité, isolation) qui assure la fiabilité d'une transaction en garantissant la cohérence et l'intégrité des données.

Pour assurer la scalabilité horizontale (c'est-à-dire stocker les données sur un cluster de machines), il est nécessaire de relâcher les contraintes d'ACIDité, les contrôles d'intégrité étant potentiellement impossibles à réaliser en temps réel sur toutes les machines d'un cluster, au profit du principe BASE (Basically Available, Soft state, Eventual consistency). Il est basé sur le théorème CAP (dit théorème de Brewer) qui dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps la cohérence, la disponibilité et la résistance au morcellement.

De fait, le Big Data exige donc l'abandon de la base de données relationnelle en tant que système de stockage des données, au profit de systèmes dans lesquels chaque donnée porte sa propre cohérence sans qu'il soit nécessaire de vérifier ses liens avec d'autres pendant les traitements (stockage, requêtage). C'est ce qu'on appelle le NoSQL. Bien évidemment, si ces modèles très simples sont plus souples, ils ne permettent pas dans la plupart des cas une structuration de l'information aussi fine que les bases de données relationnelles.

Il existe trois modèles de stockage dans l'univers NoSQL qui répondent à la problématique de la scalabilité horizontale :

• le Key/Value store (base Clé/Valeur ou K/V store) : il consiste à stocker sur chaque ligne une paire atomique constituée d'un identifiant auquel est associé une donnée quelle que soit sa nature (exemples : Redis, Voldemort, Amazon DynamoDB, Tokyo Cabinet) ;
• le Document store (base de donnée orientée document) qui est le modèle le plus familier aux professionnels de l'information, puisque c'est le principe des bases de données XML ou des moteurs de recherche. Chaque « atome » est un document indépendant et structuré de manière hiérarchique en XML ou Json (entendez le terme document dans la définition que j'en ai donné dans le billet : les carcans de la pensée hiérarchique et documentaire) et il est assez complexe d'exploiter des liens entre les documents (exemples : MongoDB, CouchDB voire ElasticSearch) ;
• le column store (base de données orientée colonnes) : les données sont stockées sous forme de colonnes au lieu de les stocker sous forme de lignes, ce qui permet de stocker un très grand nombre de données dans une seule table. (exemples : HBase et Cassandra basés sur Hadoop, Google Big Table).

A signaler que pour en simplifier l'appropriation par les développeurs, le langage SQL est de plus en plus implémenté au-dessus des systèmes NoSQL. Ainsi, le logiciel Apache Drill offre une interface SQL à Hadoop. Le nouveau et l'ancien monde sont ainsi réconciliés ce qui a tendance à rassurer les DSI.

Parmi les solutions NoSQL, une quatrième famille est un peu à part : les graph databases (base de données orientée graphes). En effet, si, au contraire des précédentes, les bases de données de graphes présentent une structuration très fine de l'information de par l'utilisation du modèle de graphes (comme son nom l'indique), ce même modèle rend complexe la scalabilité horizontale.

Si vous êtes des lecteurs de ce blog (et pour les nouveaux, vous pouvez jeter un coup d'œil par là), vous vous doutez bien que, malgré leurs limites, j'ai un petit faible pour cette famille puisque les bases de données RDF (ou Triple store) sont un sous-ensemble des bases de données orientées "Graphe". Or, si j'en crois le buzz (ou encore) qui entoure actuellement les bases de données de graphes, je suis confiant quant à la résolution de ce problème. Ainsi, de très nombreuses solutions arrivent sur le marché avec la promesse de résoudre la problématique de la scalabilité horizontale. On peut citer les pionniers dans le domaine Neo4J, blazegraph, Virtuoso, AllegroGraph et les nouveaux venus : graphX, SparqlCity ou toutes les tentatives de construire des triples store sur des solutions NoSQL comme CumulusRDF. Même si, aujourd'hui, il est nécessaire de rester prudent avec ces technologies dans un environnement contraint au niveau des performances, l'intérêt est tel que les choses vont à coup sûr évoluer.

Si vous voulez en savoir plus sur les solutions NoSQL, je vous conseille cette présentation en anglais, SQL, NoSQL & Big Data in Data Architecture et celle-ci en français, Introduction NoSQL.

Abracadabra ! Et l'algorithme devient magie pour l'utilisateur !

L'analyse prédictive est aux usages ce que Hadoop est aux technologies : un symbole du Big Data. Et, pour cause, les résultats de tels systèmes peuvent être réellement bluffants et, à ce titre, l'usage qui en a été fait par l'équipe de campagne de Barack Obama pour sa réélection a marqué les esprits. Le système déployé par la Digital task Force d'Obama visait à identifier les quartiers susceptibles d'être réceptifs aux actions de porte-à-porte et le discours à y porter par les militants à partir de différents critères : l'analyse socio-démographique des différents quartiers (ou comment l'Open Data mis en place pendant le 1er mandat a permis de remporter le 2nd...), la corrélation prédictive des votes en fonction de l'analyse des votes précédents par zone géographique et la corrélation avec les sondages d'opinion ou études afin de connaître au plus près les thèmes de "bascule".

Mais, c'est bien évidemment dans le domaine du marketing que l'analyse prédictive est aujourd'hui le plus utilisée. A partir de l'analyse des traces laissées par les utilisateurs (clic, achat, paniers, temps resté sur une page, visionnage d'un média...), il est possible de prédire le comportement d'un internaute. Pour ce faire, tout comme dans l'exemple précédent, un modèle est mis au point à partir de motifs récurrents puis on soumet à ce modèle les nouvelles données pour en prédire la tendance ou le comportement futur. C'est ainsi que fonctionnent les systèmes de recommandations, de mises en avant, de similarité... Il est aussi possible aux sites Web de prédire le comportement d'achat d'un visiteur à partir de l'analyse de son parcours de visite et ainsi de le réorienter par une bannière pub ou une mise en avant spécifique.

Si auparavant l'analyse prédictive était l'apanage du monde de l'assurance (évaluation des risques) et de la finance (et on a vu la limite de certains modèles hasardeux pendant la crise financière...), l'analyse prédictive est maintenant utilisé pour des usages moins vénaux : prédiction du climat, diagnostic médical... Les technologies du Big Data ont peu à peu fait baisser le coût de déploiement de l'analyse prédictive et l'ont rendue accessible. Aujourd'hui avec des logiciels Open Source comme Prediction.io ou des solutions en SaaS comme Google Prediction API ou BigML, il est possible de déployer un tel système en quelques jours.

Parmi les systèmes d'analyse prédictive, on retrouve les systèmes d'apprentissage automatique ou machine learning. Leur objectif est de mettre en place un système permettant d'apprendre une tâche à la machine pour qu'elle puisse l'effectuer automatiquement. La mise au point des algorithmes d'apprentissage est bien souvent antérieur au Big Data. Mais, comme pour l'analyse prédictive, la simplification de la parallélisation et du clustering ont rendu possible l'usage de ces technologies à une très large échelle et donc leur coûts de déploiement avec des performances d'exploitation satisfaisantes.

Il existe deux catégories principales d'apprentissage automatique : les systèmes dits supervisés et non supervisés.

Le fonctionnement du premier cas est bien connu de tous puisque c'est le principe de base des anti-spam. Grâce à un algorithme dit bayésien, l'utilisateur apprend à la machine à détecter les spams en lui indiquant dans un premier temps la nature des différents mails d'un corpus d'exemple. D'une manière générale, l'apprentissage supervisé vise à déterminer la classe d'une donnée à partir d'exemples connus. Il est ainsi possible de mettre en place des systèmes qui classe automatiquement des documents dans des catégories (cf. dans Isidore la facette Disciplines) grâce à l'algorithme SVM (Support Vector Machine) qui se base sur la comparaison de vecteurs de motifs, dans le cas d'un texte, des vecteurs de mots. Ces technologies sont aussi au cœur des systèmes d'analyse d'images comme celui mis au point par le Département de la recherche de l'INA, Diginpix.

L'apprentissage non supervisé, quant à lui, se base uniquement sur des exemples de données sans classes ou étiquettes a priori pour effectuer du clustering de données, c'est-à-dire la création automatique d'ensembles cohérents de données. Les algorithmes tels que le LDA (Latent Dirichlet Allocation) permettent ainsi de déterminer des ensembles cohérents de documents au sein d'un corpus. Ce type d'apprentissage permet aussi de calculer des similarités entre des données.

Enfin, en matière d'exploitation des données, il est un domaine qui a retrouvé une nouvelle jeunesse grâce au Big Data : les statistiques et, avec elles, la Business Intelligence. Ainsi, que ce soit les acteurs historiques de la BI comme SAP ou les "pures players" du Big Data comme Cloudera avec Impala, tous conjuguent systèmes analytiques avec Big Data, ont adapté leur discours marketing à ce nouveau « buzzword » et leurs offres logicielles au nouvel environnement technologique. Et, pour cause, la donnée est maintenant nativement voire exclusivement numérique et les technologies sont matures et plus simples à déployer. Mais, les statistiques les plus traditionnelles ne sont pas en reste et on voit arriver sur le devant de la scène des suites logicielles anciennes comme le logiciel Open Source R bien connus des statisticiens. En effet, quoi de mieux que les statistiques pour appréhender des masses de données en les ramenant à des tendances chiffrées ou les représenter sous la forme de graphiques. C'est dans ce domaine que le Big Data rencontre les problématiques de la Data Visualisation ou dataviz.

Cette partie est la plus éloignée des compétences traditionnelles des professionnels de l'information. Elle a d'ailleurs vu émerger un nouveau profil très à la mode, le data scientist. Pour autant, associer un professionnel de l'information à un data scientist pourrait s'avérer un calcul gagnant tant leurs compétences sont complémentaires.

Si, finalement, ce n'était qu'une histoire de plomberie ?

L'exécution des algorithmes que nous venons d'évoquer nécessite de manipuler les données : récupération dans les systèmes de stockage, nettoyage, mise en cohérence, enrichissement et conversion des données, chargement dans les systèmes d'exploitation... Autant d'étapes qu'il est nécessaire d'implémenter pour disposer d'un système fonctionnel. Or, dans ce domaine, si l'industrialisation tant du développement que de l'environnement d'exécution n'est pas pensé en amont, le système d'information est peu à peu envahi par un empilement de scripts et de bouts de code qu'il s'avère difficile à maintenir et à réutiliser obligeant à réinventer la roue à chaque nouveau besoin et je ne vous parle pas de la supervision de tout ça, vos équipes de production vont rapidement vivre un cauchemar.

Or, on voit aujourd'hui des outils issus de mondes différents converger vers un objectif commun : industrialiser le développement et l'exécution de chaînes de traitement de données. Ils ont vocation à orchestrer des traitements simples, modulaires, de manière successive afin d'aboutir à un processus complexe et, pour ce faire, ils offrent, dans la plupart des cas, des interfaces graphiques de développement et de supervision des traitements. En outre, l'intérêt de ces outils réside dans leur extensibilité, puisqu'il est possible grâce à une API de créer des nouveaux modules et d'étendre ainsi les fonctionnalités proposées. Un non informaticien avec quelques connaissances de développement peut donc prendre en main facilement ces outils, je dirais même qu'ils constituent les outils de base du professionnel de l'information dans l'environnement du Big Data.

Les ETL (Extract, Transform, Load) sont la première famille d'outils de ce type. Ils viennent de la BI et ont à l'origine pour objectif de simplifier la récupération des données depuis les applicatifs du SI (souvent des bases de données relationnelles) pour alimenter des puits de données (data warehouse). Leur grande force réside donc dans leur capacité à extraire des données des différents types de bases de données, à les convertir et à les charger dans d'autres bases de données. Une interface graphique permet de construire la chaîne de traitement en articulant différents modules (ou node/component) atomiques ce qui simplifie la mise en œuvre. La plupart des ETL sont en train de s'adapter au monde du Big Data par l'ajout de connecteurs spécifiques pour interagir avec les bases NoSQL et par l'usage de Hadoop comme infrastructure de base à l'exécution des traitements. Par exemple, le logiciel Open Source Talend basé sur Eclipse propose une distribution spécifique Big Data : Talend Open Studio for Big Data. Il en va de même pour son concurrent libre : Pentaho Data Integration.

Les data pipeline dont le plus célèbre est Yahoo Pipes fonctionnent globalement sur le même principe (workflow de modules atomiques) mais sont plutôt issus du domaine des données semi et non structurées. De fait, là où les ETL sont très efficaces pour la manipulation de données issues de bases de données relationnelles, les systèmes de data pipeline sont plutôt adaptés aux flux XML et à l'exploitation de textes. De plus, ils intègrent nativement des modules d'enrichissement et d'exploitation de la donnée plus avancés couvrant toute la pile technologique du Big Data. Enfin, ils se présentent bien souvent sous la forme de plate-formes ou de "studios" qui intègrent à la fois le développement, l'exécution et la supervision au sein d'une même interface graphique. Dans ce domaine, on peut citer :

• Antidot Information Factory de mon précédent employeur Antidot ;
• Knime, un logiciel Open Source mis au point dans le domaine de la bio-informatique mais qui l'a largement dépassé et qui intègre de nombreux outils statistiques et différents algorithmes de machine learning par l'intégration de la bibliothèque Weka ;
• Data science studio du français Dataiku dont l'objectif est d'offrir les moyens de rapidement traiter des données et de les utiliser dans des systèmes intégrés de machine learning.

Enfin, les systèmes de gestion de workflow comme Bonita peuvent aussi constituer des solutions en la matière. Issus du monde de la gestion des processus métier, le BPM (Business Process Management), ils se basent sur la modélisation des processus métiers (diagrammes de flux ou flow charts) pour outiller chaque étape au moyen d'une interface graphique. Si on considère le traitement de la donnée comme un processus métier, on peut utiliser ce type d'outil pour le modéliser et l'implémenter.

Et le professionnel de l'information dans tout ça ?

Le Big Data est au milieu du gué : comme le Web à la fin des années 1990, les technologies sont matures mais les usages peinent à atteindre les espoirs qu'on a mis en lui et les échecs sont nombreux. Or, ces derniers et l'absence de montée en puissance des usages sont dus en grande partie à des limites dans l'exploitation de la donnée et de sa richesse. Lorsqu'on voit ce qu'il est possible de faire avec quelques logs, données d'une pauvreté affligeante, on peut facilement imaginer ce qu'on pourrait obtenir en les corrélant avec les "données métiers". Or, c'est bien là que les professionnels de l'information ont un rôle à jouer de par leur connaissance de la donnée.

Ainsi, si les professionnels de l'information s'appropriaient cette technologie à un niveau suffisant pour en comprendre ce qu'il est possible d'offrir en s'appuyant sur les données disponibles, les possibilités s'en trouveraient démultipliées. C'est un travail que les data scientists ne peuvent effectuer seuls : ils doivent s'associer à des professionnels de l'information qui comprennent les modèles de données et les objets qu'elles décrivent. Avec le Big Data, le professionnel de l'information est plus que jamais à l'articulation entre les informaticiens et le métier. L'enjeu est de faire du Big Data une évolution dans les usages et pas seulement une évolution technologique.

Par contre, vous l'aurez compris : investir le domaine du Big Data implique la révision d'un très grand pan de votre système d'information (et encore je vous ai épargné le concept de "lac de données"), ce n'est donc pas un sujet à prendre à la légère d'autant qu'il s'avère crucial pour faire face aux enjeux de demain.

Merci à Manue de m'avoir aidé à accoucher de cette synthèse !