1 – LES PROMESSES ET LES RISQUES DU BIG DATA
Comme pour beaucoup de technologies émergentes, il est délicat de proposer une définition à la fois précise et exhaustive de ce qu’il est convenu d’appeler désormais le « Big Data ». Une possibilité consisterait à voir dans cette nouvelle tendance la concrétisation d’un rêve technologique qui n’est pas sans rappeler les ruées vers l’or du passé. Profondément enfouis dans les logs des serveurs web des sites marchands ou dans les commentaires laissés par des myriades d’internautes sur les réseaux sociaux, se tapiraient de colossaux gisements de données non-structurées qui ne demanderaient qu’à être exploités. Pour le plus grand profit des entreprises qui se seront dotées des outils de « forage » appropriés pour exploiter ce nouveau filon.
A la différence de la Business Intelligence classique qui exploite des données structurées d’une entreprise pour fournir une aide à la décision, le Big Data cherche à exploiter des quantités massives de données non-structurées, situées en partie hors de l’entreprise, afin d’en dégager des tendances de consommation, des schémas de comportement, voir pour favoriser l’innovation. En vérité, ce rêve est devenu une réalité tangible depuis quelques années déjà pour les leaders du web tels que Google, Tweeter ou Facebook. Les technologies existent donc déjà et elles ont amplement fait leurs preuves, en atteste par exemple le succès foudroyant de Google. Son modèle économique de base, la publicité contextuelle, repose en effet sur une analyse à grande échelle de comportements, d’écrits et de choix individuels afin de cibler de manière fine certaines niches de marché. Le succès de Facebook, bien qu’apparemment moins assuré sur le long terme, repose lui aussi sur un principe de monétisation d’informations personnelles à l’échelle du web.
Les promesses implicites du Big Data résident donc moins dans l’annonce de futures prouesses technologiques que dans la démocratisation, à toutes les organisations, de techniques déjà disponibles de traitements, de stockage et d’analyse des données. Symboliquement, le coup de sifflet a retenti lorsqu’en décembre 2011, la communauté du logiciel libre a livré la version 1.0 du framework Hadoop, une infrastructure logicielle évolutive conçue pour les traitements de données massivement parallèles. A n’en pas douter, Hadoop constituera la pièce maitresse de nombreux projets Big Data durant ces prochaines années. Nous ne reviendrons pas ici sur la conjonction du contexte économique et des progrès technologiques qui ont permis l’émergence de ces technologies, l’objectif de cet article étant plutôt de passer en revue les principales compétences nécessaires pour tirer profit de ce nouveau paradigme informatique. D’emblée, vendons la mèche : on anticipe pour ces prochaines années une importante pénurie de compétences dans les domaines relevant du Big Data et, plus généralement, dans le secteur de l’analyse des données. Face à cette situation, les entreprises auront à choisir parmi différentes stratégies :
- former des compétences Big Data en interne en recourant à des organismes de formation spécialisés,
- créer des partenariats stratégiques avec des entreprises spécialisées,
- acquérir, vraisemblablement au prix fort, une startup spécialisée dans l’analyse des données,
- louer des services « Big Data » en mode SaaS auprès de fournisseurs tiers comme les réseaux sociaux publics dans la mesure où ceux-ci seront disposés à monnayer les données dont ils disposent. On peut imaginer par exemple l’intégration de fonctionnalités Big Data dans des applications métiers au moyen d’API analytiques spécialisées mises à disposition par ces fournisseurs.
Prendre des positions tranchées sur la pertinence de l’une ou l’autre de ces options apparait à ce jour bien hasardeux, tant l’expérience fait défaut. Un temps de pionniers s’ouvre donc qui favorisera les plus lucides et les plus audacieux. Cela étant, pour faire un choix en conscience, essayons à présent de dresser un inventaire raisonnable des principales compétences nécessaires pour tirer profit des opportunités du Big Data.
2 – LES NOUVELLES COMPÉTENCES A ACQUÉRIR
2. 1 – APPREHENDER UN NOUVEAU MODELE DE TRAITEMENT DES DONNEES
Pour qui cherche à s’initier au sujet, le phénomène Big Data pourra apparaître comme un fatras d’outils, d’algorithmes et de sigles obscurs qui se bousculent sans véritable principe directeur. Un concept pourtant se niche au cœur de cette révolution, il s’agit d’un modèle novateur de traitement parallèle de données, nommé MapReduce, popularisé par Google dans un article désormais célèbre (Ghemawat, 2004). La percée de ce modèle a consisté à rendre possible la réalisation, avec un matériel bon marché ce que l’on appelle en jargon technique un « scaling linéaire ». En clair, MapReduce permet de traiter en une minute un problème qui auparavant exigeait une heure, à condition de… multiplier par 60 le nombre de machines ! Si l’affirmation peut à priori paraître naïve, il faut bien voir qu’il s’agissait d’un véritable Graal à atteindre dans le calcul parallèle il y a seulement une dizaine d’années. Sur un plan conceptuel toutefois, le prix à payer pour bénéficier de ce scaling linéaire est double. Il faut d’une part consentir à restreindre la classe des problèmes que l’on souhaite traiter avec MapReduce, tous les problèmes en effet ne s’y prêtent pas. D’autre part, MapReduce exige de se familiariser avec un modèle de traitement des données qui apparaîtra de prime abord exotique au néophyte. Sans entrer dans les détails, il s’agit d’exprimer le traitement à effectuer au moyen de deux types d’opération. Les premières, dites « Mapper », opérèrent individuellement sur de petits lots de données indépendants, exprimés sous forme de listes de couples (clé, valeur). Les secondes, dites « Reducer », recombinent les résultats intermédiaires fournies par les « Mappers » pour calculer le résultat final.
Si le principe est simple dans sa conception, les détails en revanche sont plus ardus et exigeront pour être pleinement maîtrisés un effort d’apprentissage significatif de la part des développeurs, l’expérience des pionniers que sont Facebook et Yahoo! l’a amplement démontré. Il est vraisemblable cependant qu’une majorité des développeurs métiers pourra se dispenser d’une connaissance approfondie de ces espects algorithmiques. En effet, pour bénéficier du parallélisme massif de MapReduce, ils n’auront que rarement à coder explicitement les fameux « Mappers » et « Reducers » mais utiliseront plutôt des abstractions de haut niveau, essentiellement des langages de scripts (comme Pig) ou des langages pseudo-SQL (comme Hive QL) plus familiers. A partir de ces langages de hauts niveaux, des compilateurs (environnements Pig et Hive p.ex) sont aujourd’hui à même de générer automatiquement des plans d’exécutions MapReduce. Dès lors la question se pose : est-il possible de faire l’impasse complète sur les concepts de MapReduce ? Hélas non, et c’est là que réside la subtilité et les risques. Une connaissance élémentaire des mécanismes sous-jacents reste utile pour faire face aux situations où les automatismes dysfonctionnent ou dès lors que les performances exigent des optimisations. Gageons que ces situations ne seront pas rares. En réalité, ces abstractions sont à considérer davantage comme des outils de productivité que des moyens de masquer complètement la complexité inhérente à la distribution du calcul.
Plus généralement, on peut anticiper que l’une des difficultés à surmonter sera la prise en compte de certains aspects liés à l’architecture des couches basses de Hadoop, afin de bénéficier du fameux scaling linéaire promis par MapReduce. A titre d’exemple, le système de fichiers utilisé par Hadoop (voir ci-dessous), HDFS, bien qu’accessible par une API Java classique, possède des spécificités qu’il conviendra d’intégrer dans toute conception. Conçu pour prendre en charge des fichiers très volumineux (plusieurs To), ce modèle présuppose qu’ils soient accédés essentiellement en mode write-once-read-many-times. Il n’est pas conçu en revanche pour permettre un accès aléatoire à une myriade de petits fichiers. Dans le même ordre d’idées, il faudra veiller à ce que les plans d’exécution MapReduce générés par Hive ne soient pas trop complexes pour être exécutables et testables en un temps raisonnables. Liés aux ordres de grandeurs inhabituels des quantités de données traitées, il y a donc tout un jeu d’intuitions nouvelles à acquérir par les concepteurs.
Quelle est alors l’effort à consentir pour maitriser la programmation MapReduce explicite (sans scripts) sous Hadoop? Une durée comprise entre 6 mois à 1 an ne semble pas surestimée s’il s’agit d’acquérir une expérience significative. On estime à ce jour que moins de cinquante personnes possèdent ces compétences en France. Dans un tel contexte, il y a fort à parier que peu d’entreprises pourront s’offrir ce niveau de compétence, hormis peut-être les plus grandes ainsi que quelques SSII qui choisiront d’en faire leur cheval de bataille. Pour ce qui concerne les langages de plus haut niveau Pig, Hive QL on peut estimer à quelques semaines le temps de parvenir à un niveau de compétences suffisant, vu la proximité avec les langages existants. En donnant ces estimations, nous présupposons qu’un coach spécialisé soit à disposition pour assurer la formation initiale des développeurs ou alors qu’une cellule spécialisée et dédiée, fonctionnant en mode R&D, soit mise en place localement dont la mission sera de monter en compétence sur ces sujets et, à terme, former le reste des troupes. Soyons clair : le bricolage individuel en mode « Do It Yourself » n’a pas sa place dans le Big Data.
2. 2 – MAITRISER LE DEPLOIEMENT DE HADOOP OU CHOISIR UNE SOLUTION CLOUD
A l’appréhension des concepts et des langages de scripts spécifiques à MapReduce il convient d’ajouter la maitrise du déploiement d’une plateforme qui implémente ce modèle. Le rôle d’un tel framework consiste à masquer l’énorme complexité technique qu’implique un traitement massivement parallèle par un cluster de machines non fiables : planification des tâches en fonction des ressources du cluster, réplication des données, réexécution des tâches en cas d’échec, garantie de très haute disponibilité etc… Un outil sans véritable concurrence à ce jour domine la scène, il s’agit de Hadoop, un framework libre développé ses dernières années sous l’égide de la fondation Apache.
Bien qu’il existe d’excellents ouvrages sur le sujet (White, 2012), le déploiement « on premise » d’un cluster Hadoop et son optimisation reste un travail d’experts hautement qualifiés. Dès lors, l’alternative pour une DSI qui souhaiterait mettre en œuvre Hadoop, consistera à choisir de faire appel à un prestataire spécialisé ou alors à utiliser un déploiement de Hadoop dans le Cloud chez un fournisseur PaaS. La solution Elastic Map Reduce d’Amazon Web Services constitue ici une référence. Dans ce dernier cas, pour les très gros volumes de données, interviendront des considérations de coûts de transferts qu’il ne faudra pas prendre à la légère. La maturité des plateformes PaaS et la disponibilité de tutoriels pédagogiques devraient rendre accessibles le paramétrage et le déploiement d’applications à la plupart de DSI. Quelques semaines d’expérimentation devraient suffire pour permettre à une équipe IT chevronnée de maîtriser l’exploitation de Hadoop en mode PaaS.
2. 3 – SE FAMILIARISER AVEC DE NOUVELLES METHODES DE MODELISATION DES DONNEES
Traiter d’énormes quantités de données non-structurées exige non-seulement de nouveaux algorithmes et des nouvelles infrastructures de calcul, mais impose également de repenser l’organisation des données elles-mêmes. Dans ce nouveau contexte, les enjeux de performances priment le plus souvent sur ceux d’une stricte intégrité référentielle, contrairement aux principes qui s’appliquent aux bases relationnelles. Par ailleurs, le caractère non-structuré des données rend caduque la notion de schéma prédéfini. De nouvelles catégories de base de données répondent à ces exigences, les bases de données orientées colonnes ou orientées documents (HBase, BigTable, MongoDB), dites aussi NoSQL (pour Not Only SQL). Ce type de bases pourra jouer aussi bien le rôle de source que de destination pour les jobs MapReduce. L’expérience montre qu’elles s’avèrent particulièrement bien adaptées aux données hiérarchiques ou structurées en graphe qui sont monnaie courante dans un contexte Big Data. L’archétype ici est celui d’une webtable qui répertorie les attributs d’une collection de milliards pages web indexées par leur URL. A la panoplie des savoir faires déjà évoqués, il convient donc d’ajouter de nouvelles techniques de modélisation. A cette occasion, certains réflexes anciens devront être désappris, les processus de dé-normalisation et de duplications, autrefois prohibés, étant désormais à l’origine même des gains en performances et des capacités à monter en charge linéairement.
Une compréhension approfondie de la structure des données et des algorithmes qui les exploitent sera nécessaire, par rapport à ce qui est la norme pour les bases relationnelles. Alors que la modélisation se basait habituellement sur la structure des données existantes, les modèles NoSQL dépendent plus étroitement des applications et des méthodes d’accès à ces données (Katsov, 2012).
Les spécificités non fonctionnelles des bases NoSQL, performances, capacité à monter en charge, absence d’intégrité référentielle sont aujourd’hui les principales motivations invoquées pour leur utilisation. Pour autant, les aspects liés à la modélisation restent encore peu étudiés sur le plan théorique. Il semble donc qu’en la matière, les phases d’expérimentations avec leur lot d’essuyage de plâtres soient inévitables avec des coûts difficilement à estimer.
2. 4 – DECOUVRIR DE NOUVEAUX OUTILS D’ANALYSE DE DONNEES
Après la modélisation de données non structurées et la construction, explicite ou automatique, de jobs MapReduce vient l’extraction d’informations métiers significatives à partir du résultat de ces traitements. Là où les outils de BI classiques devaient se contenter de données partielles, les nouveaux outils Big Data permettent souvent une prise en compte exhaustive des données. C’est le domaine que l’on appelle le Big Analytics. De nombreux acteurs commerciaux, de même que la communauté du logiciel libre proposent des outils pour faciliter l’interaction avec un cluster Hadoop et ainsi permettre l’exploration et la visualisation interactive des données dans les outils BI et OLAP classiques.
Contrairement au framework Hadoop ou aux subtilités de la programmation MapReduce, les outils d’analyse Big Data sont des extensions des outils classiques de Data Mining. Leur maîtrise par les experts métiers concernés ne devrait par conséquent pas poser de problème majeur, ni constituer un investissement significatif. Toutefois, comprendre le rôle respectif des différents acteurs dans la galaxie Big Data pourra s’avérer un peu déroutant car les relations entre la myriade de distributeurs de solutions Hadoop, de fournisseurs de solutions Map Reduce dans le Cloud, d’éditeurs d’outils d’analyse en temps réel et d’intégrateurs sont souvent complexes et parfois redondantes.
Un point important à noter est que l’analyse de données Big Data nécessitera le plus souvent le développement d’applications spécifiques. Les développeurs continueront en l’occurrence à utiliser leurs environnements de développement favori et les langages de programmation qu’ils maîtrisent déjà mais les applications qu’ils développent s’adresseront à une catégorie d’utilisateurs finaux spécialisés, les analystes de données, dont ils devront assimiler le vocabulaire et avec qui ils devront apprendre à collaborer.
2. 5 – SAVOIR CE QUE L’ON CHERCHE !
Au-delà des enjeux purement techniques déjà évoqués, il reste avant tout à identifier des cas d’utilisations pertinents à un domaine métier spécifique ou à une organisation. Contrairement à ce qu’affirment certains slogans entendus ici ou là, « les données sont là, il suffirait de se baisser pour les ramasser », la mise en place d’une stratégie Big Data exigera de savoir au préalable ce que l’on cherche. En clair, il s’agit d’anticiper le type de corrélations que l’on souhaite mettre en évidence et par la suite d’élaborer les traitements et les analyses appropriées. Ce ne sera assurément pas la moindre des tâches.
Par ailleurs, nombreux sont ceux qui fondent de grands espoirs dans les aptitudes prédictives de ces nouvelles technologies d’analyse. On pourrait ainsi prédire les souhaits des consommateurs avant qu’ils ne les formulent, prévoir les pannes de systèmes complexes avant que celles-ci ne surviennent, voir même prévenir les délits avant que ceux-ci ne soit commis (revoir à ce sujet le film prémonitoire « Minority Report » de Spielberg sorti il y a tout juste dix ans). Que ce genre d’application soit considérée à priori comme réaliste ou non, éthique ou non, l’élaboration d’un modèle prédictif reste un préalable incontournable. Il s’agira d’un travail pluridisciplinaire à mener conjointement entre analystes de données, sociologues ou spécialistes du marketing. Nul automatisme aussi sophistiqué soit-il ne saura s’y substituer, il faut bien en être conscient.
Dans le même ordre d’idées, le simple volume d’un ensemble de données ne saurait être à lui seul un garant de qualité. Pour des données hétérogènes c’est même l’inverse qui pourrait être vrai. Là encore, contrairement à certaines idées reçues, une donnée n’est en réalité pas… donnée (sic) ! Une donnée doit être en réalité choisie, sélectionnée pour être représentative d’un phénomène que l’on souhaite mesurer ou mettre en évidence. Dans une approche trop naïve du Big Data, l’illusion guette donc que la quantité puisse être un substitut systématique et bon marché à l’élaboration d’un jeu de données de qualité. Une autre illusion consisterait à négliger désormais l’expérience et l’intuition des humains sur des questions dont le caractère quantitatif n’est pas avéré. Que l’on pense à la quantification de l’intensité et de la nature d’un lien entre deux individus au sein d’un réseau social par exemple, sur lequel reposeront beaucoup d’analyses d’influence.
Le manque de recul et la pénurie de compétences en la matière seront donc les principaux obstacles à surmonter, bien d’avantage que la complexité technique des nouvelles plateformes. Les pionniers dès lors auront recours à des spécialistes de l’analyse de données ou alors créeront des cellules pluridisciplinaires chargées de définir une stratégie Big Data. Y participeront des architectes logiciels, des experts métiers, des spécialistes du datamining et peut-être des statisticiens. Ces différentes compétences devront apprendre à communiquer par delà leur spécialisation respective. Cette pluridisciplinarité obligatoire sera probablement le principal écueil à surmonter pour tirer le meilleur parti des technologies émergeantes du Big Data mais, n’en doutons pas, elles seront aussi un important facteur de motivation pour ceux qui auront la chance de participer à l’aventure.
Références :
- Ghemawat, J. D. 2004 Simplified Data Processing on Large Clusters. Operating System Design and Integration
- Katsov, I. 2012 NoSQL Data Modeling Techniques. Highly Scalable Blog
- White, T. 2012 Hadoop: The Definitive Guide, 3nd Edition. O’Reilly éditeur
Classé dans:Actualité, Articles, Tribunes Tagged: Amazon Web Services, Big Data, cloud-computing, Mapreduce, PaaS, SAAS
Jeu de briques
Snake
Pacman
Bubble