Mais Ă  quoi bon le big data ?

Un des mots Ă  la mode dans notre domaine du traitement des donnĂ©es est big data. Il s’agit de la capacitĂ© Ă  traiter des quantitĂ©s massives de donnĂ©es structurĂ©es ou non structurĂ©es. Mais massives comment ? A partir de combien est-ce du big data ? Qui en a besoin ? Quelle est la rĂ©alitĂ© opĂ©rationnelle derrière ces mots ?

Rappelons d’abord que l’origine du big data est liĂ©e Ă  une logique de programmation distribuĂ©e dite map-reduce qui a Ă©tĂ© dĂ©veloppĂ©e par des sociĂ©tĂ©s du Web comme Google, Yahoo!, Facebook etc : ces grands sites mondiaux ont des tonnes de donnĂ©es Ă  analyser et ne pouvaient pas se contenter des approches « bases de donnĂ©es centric Â» habituelles. Dropbox gère 100 millions de sauvegardes de fichiers par jour, Twitter annonce 200 millions de tweets quotidiens, Facebook supporte 250 millions d’uploads de photos par jour et en stocke plus de 40 milliards… Le big data est donc d’abord une approche informatique qui prend le relais quand une implĂ©mentation classique basĂ©e sur l’utilisation de quelques serveurs, mĂŞme très costauds, ne suffit plus pour assurer les temps de traitement attendus. Ainsi, ces acteurs exploitent des clusters regroupant chacun plusieurs milliers de serveurs et manipulant des pĂ©ta-octets [1] de donnĂ©es.

D’un point de vue logiciel, le big data est souvent associĂ© Ă  la pile technologique Hadoop mise en open source par Yahoo! et reprise par nombre d’entreprises Ă  vocation commerciale (EMC, Cloudera, Hortonworks…). Hadoop et ses dĂ©rivĂ©s apportent un système de stockage distribuĂ©, une base de donnĂ©es rĂ©partie, ainsi qu’un cadre de programmation et d’exĂ©cution de tâches de calcul rĂ©parties.

 

Mais Ă  quoi cela sert-il et quel sens cela a-t-il pour la plupart des entreprises qui ont quelques tĂ©ra-octets de donnĂ©es Ă  analyser ?

Quelques Ă©lĂ©ments de rĂ©ponse :

  • Le big data est une technologie et non une solution. C’est un moyen et pas une fin. Donc dire « je vais faire du big data Â» n’a pas de sens car celui-ci ne rĂ©pond Ă  aucun besoin fonctionnel en particulier. C’est comme dire « je vais faire de la base de donnĂ©es Â» ou « je vais faire du Web Â». Pour quoi faire ? La dĂ©marche doit rester pragmatique : partez de votre besoin, voyez s’il est satisfait de façon acceptable par des solutions existantes. Et si rien de ce qui existe ne convient (trop cher, trop lent) alors demandez-vous si une approche alternative exploitant les technologies du big data peut ĂŞtre envisagĂ©e.
  • Le big data nĂ©cessite de très fortes compĂ©tences. Tout d’abord, le niveau de maturitĂ© des technologies proposĂ©es nĂ©cessite des ingĂ©nieurs qualifiĂ©s pour installer, paramĂ©trer, optimiser et faire tourner ces couches logicielles. A fortiori si vous comptez bâtir des solutions opĂ©rationnelles critiques. Il en va de mĂŞme pour le dĂ©veloppement des applications car celles qui veulent tirer partie de l’approche doivent ĂŞtre rĂ©-Ă©crites selon les principes du map-reduce. Souvenons-nous que chez Google ou Facebook, ce sont leurs meilleurs ingĂ©nieurs logiciels et  mathĂ©maticiens qui dĂ©veloppent les applications big data.
  • Pour faire du big data, il faut beaucoup de donnĂ©es. Des tĂ©ra-octets, voire plutĂ´t des dizaines de tĂ©ra-octets. Ă€ moins de 10 ou 15 serveurs, le passage au big data n’a pas de sens.
    Un exemple : Oracle vient de sortir une appliance big data petit format : 18 serveurs, 864 Go de mĂ©moire, 648 To de stockage pour la modique somme de 455 000 $. Et encore… il reste Ă  intĂ©grer et Ă  dĂ©velopper les applications qui reposeront sur cette architecture.


    Avec l’arrivée des processeurs massivement multi-cœurs, du in-memory computing ou des SSD, la frontière se déplace et pour la majorité des cas, un seul serveur moderne suffit encore. Alors que dans le cas d’un cluster, il faut prendre en compte le coût élevé de possession (TCO) : achat des machines, installation et administration, électricité, froid, maintenance… A fortiori s’il s’agit de n’effectuer que quelques heures ou jours de calcul par mois, la rentabilité d’une telle approche est difficile à atteindre. Big data et cloud computing pourraient alors avoir un avenir commun, mais a condition que les entreprises veuillent bien envoyer dans le cloud leurs téra-octets de données à analyser.

En dĂ©finitive, il ne s’agit pas de savoir sur combien de serveurs les calculs sont faits, mais de savoir lesquels. Pour quel usage ? Quelle valeur crĂ©Ă©e ?
C’est pourquoi ce sont plutĂ´t les Ă©diteurs de logiciels qui vont s’emparer du big data, afin d’offrir des solutions opĂ©rationnelles rĂ©pondant aux besoins des entreprises et passant Ă  l’échelle du pĂ©ta-octets. Les Ă©diteurs de logiciels dĂ©jĂ  actifs dans la BI, le data mining ou les moteurs de recherche intĂ©greront ces techniques pour fournir des version « big Â» de leurs solutions.

Et d’ailleurs qu’en est-il cĂ´tĂ© Antidot ? Nos solutions sont conçues dès l’origine pour fonctionner aussi bien sur un seul serveur que sur des clusters de machines pour traiter des millions de donnĂ©es et rĂ©pondre Ă  des centaines de requĂŞtes par seconde. Et nous travaillons dĂ©jĂ  Ă  intĂ©grer Ă  nos solutions les apports de l’approche big data.

Mais au delà de la surenchère marketing, nous nous attachons surtout à fournir des solutions qui créent de la valeur pour nos clients. Ainsi, notre framework d’analyse de documents offre des modules prêts à l’emploi couvrant des besoins aussi variés que la classification, la normalisation, l’annotation, l’enrichissement sémantique ou la géolocalisation des données… Agilité et vitesse d’exécution sont des enjeux qui nous semblent plus importants que force et volume.

Conclusion : ce n’est pas la peine de complexer si vous n’avez pas plusieurs centaines de téra-octets de données à analyser et si vous vous sentez exclu du big data. Car en définitive, seule la valeur que vous saurez tirer de vos données a vraiment de l’importance !

[1] un péta-octet, en abrégé Po, représente 1015 octets, soit mille téra-octets ou un million de giga-octets…