Je viens de lire l’interview de Serge Abiteboul dans 01 Business & Techno du 13/09/2012, et je dois dire que je me sens rassuré dans mon opinion sur le Big Data par ce qu’un grand esprit comme lui décrit : le Big Data comme un effet de mode. Je renvoie également à son excellent article de blog sur Big Data.
Sans avoir la prétention d’arriver à la cheville d’un spécialiste de la donnée comme lui (Stanford, INRIA, Académie des Sciences), le fait de travailler depuis dix ans pour une entreprise spécialisée dans l’analyse intelligente de donnée, ainsi que d’avoir écrit un bouquin sur le sujet, me donnent suffisamment de confiance pour donner un avis polémique.
Statistiques commerciales
Il y a quelques semaines déjà, je m’étais posé la question d’une possible mise en avant pour des raisons commerciales, en lisant dans plusieurs magazines cette information :
70% des entreprises françaises n’ont pas d’initiatives ou de réflexion sur le Big Data
Personnellement, je ne trouvais pas l’information pour le moins choquante : j’avais plutôt dans l’idée que 10% des entreprises françaises pouvaient avoir un réel avantage à utiliser des approches Big Data. Alors, savoir que 30% s’y intéressait, ça me paraissait déjà limite trop… Plus tard, en cherchant un peu dans les sources, je me suis rendu compte que le sponsor de l’étude était EMC, un des spécialiste du stockage, et donc fortement intéressé à l’expansion de Big Data pour vendre plus de machines. Ca a achevé de me convaincre de l’inutilité de cette statistique (pourtant joyeusement reprise en chœur par ci par là ou encore ici).
Approche technique discutable
Voici, sous forme d’histoire, la façon dont je pense que le Big Data a pris de l’ampleur : il y a encore une décennie ou moins, les analystes des données voyaient les machines croitre au fur et à mesure de la taille de leurs données. Lorsque les bases se mesuraient en To, des serveurs embarquaient plusieurs disques durs. Plus tard, lorsque les tailles sont passées au Po, ce sont des machines, voire des architectures spéciales, qui sont apparues pour traiter tout ça, donnant ce genre d’horreurs :
Source : http://fr.slideshare.net/msitpro/sql-server-parallel-data-warehouse
J’ai pris l’approche Parallel Data Warehouse de Microsoft, mais il est évident que j’aurais pu montrer l’Exascale d’Oracle avec la même opinion à la clé : il s’agit d’architectures matérielles démentielles, réalisées principalement dans le but de flatter l’ego parfois démesuré de certaines DSI, et (pas tout à fait accessoirement) de les détrousser au passage 
.
Lorsqu’une personne à peu près censée dans leur équipe leur fait remarquer qu’avec un budget divisé par cent, on pourrait obtenir les mêmes résultats à condition que les analystes patientent trente secondes au lieu de trois, ces personnes rejettent en général l’importun d’un commentaire dédaigneux. Typiquement quelque chose attenant à sa compréhension limitée des problématiques fabuleuses auxquelles notre DSI a le courage de s’attaquer…
Mais revenons à notre histoire. Une fois passée cette période de montée en puissance sur des architectures unifiées, les analystes (qui en veulent toujours plus) ont demandé à passer à l’exaoctet (Eo). Et là, un mur… Un peu comme lorsque les développeurs, habitués à avoir toujours plus de vitesse de CPU, se sont rendus compte un jour que pour avoir plus de puissance, attendre le nouveau processeur avec une fréquence plus élevée ne suffirait plus. Il allait falloir coder en multithread. Et c’est beaucoup plus dur…
Pareil pour la donnée : au lieu de tout traiter sur des architectures centralisées à plusieurs millions de dollars, le prochain eldorado serait de paralléliser massivement les analyses, avec des dizaines de machines puissantes. Les vendeurs se sont bien évidemment abstenus de préciser que de simples PC, en nombre plus important mais au final bien moins chers, suffiraient, mais c’est une autre polémique. Seulement voilà, là aussi, ce n’était pas aussi facile. Il allait falloir changer de technologie. Impossible de continuer avec SQL et les bons vieux cubes OLAP. Il allait falloir passer à la vitesse supérieure.
Pour continuer avec notre parallèle sur le développement multithread, la solution est venue des approches de type Map / Reduce : on modifie le traitement pour qu’il s’applique de manière unitaire, et on trouve un algorithme permettant de recomposer les résultats. Ainsi, on peut augmenter à peu près linéairement la puissance de traitement (en volume en tout cas) en augmentant le nombre de nodes impliqués. Donc, plus de limite…
Des analystes ? Pour quoi faire ?
C’est à ce moment précis que tout ça a tourné à la catastrophe. Pour bien appréhender le phénomène, il faut comprendre le mot de Peter Norvig, Chief Scientist chez Google :
We don’t have better algorithms than anyone else. We just have more data.
C’est le nerf du problème : au lieu d’avoir à réfléchir à la façon de traiter la donnée, le surcroit de puissance qu’apporte Big Data permet de trouver des patterns dans un énorme volume sans même avoir à élaborer conceptuellement une requête. Lorsqu’on utilise Big Data pour analyser des logs de serveurs à la recherche d’une intrusion, par exemple, on n’effectue pas une requête précise sur un comportement donné (je veux savoir quand une personne a entré trois mauvais mots de passe à la suite, le tout sur deux serveurs), mais plutôt sur des ensembles flous, quitte à avoir du retraitement derrière (je veux remonter les fréquences de mauvais mots de passe atypiques).
Evidemment, cette perte de contrôle se paie un jour, et pour moi, c’est la raison pour laquelle Big Data est un phénomène de mode : il faut de toute façon de bons analystes derrière. Big Data a simplement rendu possible l’exécution de requêtes inimaginables auparavant, par le fait qu’une puissance énorme est aisément mobilisable (avec un coût en ressources à l’avenant, mais j’y reviendrai). Mais le problème demeure, aussi solide que le mur de la programmation multithread : c’est dur… Et les résultats ne sont pas transformables en réelle valeur sans analystes.
Dans un article, on parle d’ajouter un V comme Valeur aux trois V traditionnels du Big Data, à savoir Volume, Vitesse et Variété des données. N’est-ce pas révélateur ? La première approche du Big Data a été purement technique, et aujourd’hui, les analystes annoncent des manques criants en analystes “Big Data”… Rien que de très logique : on se rend tout simplement compte, après le peak of expectations dans le langage Gartner, que sans analystes pour utiliser l’outil Big Data, il n’y a pas de valeur à en tirer.
La minute Desproges
Attention, ne me faites pas dire ce que je n’ai pas dit ! Je ré-écoute tout Desproges en ce moment, alors je ne peux pas m’empêcher d’utiliser ses phrases clés . Bref, Big Data a des utilisations spécialisées dans lequel cette approche réalise des traitements impossibles à faire autrement. Cependant, non seulement ceci n’est pas nouveau (les bons analystes savent paralléliser leurs recherches au niveau conceptuel et non technique, et ce depuis longtemps), mais en plus c’est très loin d’être un outil générique. De la même manière qu’hormis la gestion des logs, des transactions, l’Aspect Oriented Programming n’a jamais réellement percé alors qu’au moment de son lancement, il était vu comme potentiellement révolutionnaire, le mouvement Big Data restera, à mon avis, cantonné à des niches spécialisées comme l’analyse de comportements (tests d’intrusion, comportement sur les réseaux sociaux, etc.).
Conclusion
Et l’écologie, dans tout ça ? Il y aurait à dire, là aussi, mais comme ce n’est pas le sujet principal, je me permets de vous renvoyer à un autre article.
Mais pour revenir à quelque chose de plus pratique : avant de mettre en oeuvre un projet Big Data pour analyser vos volumes de données hétérogènes, posez-vous tout simplement la question de comment vous feriez si Map / Reduce n’existait pas. Serge Abiteboul conseille de se demander en tout premier si une machine avec beaucoup de mémoire ne suffirait pas. Je ne peux que le seconder sur une approche simple et “to the point”, surtout lorsqu’elle rejoint l’approche NoSQL / Object Prevalence que j’affectionne (voir les multiples billets sur le sujet dans ce blog).
Dans de nombreux cas, une première passe de mise au propre de la donnée peut également permettre de s’en tirer avec une architecture centralisée (et donc de rentabiliser cet Exascale qui vous a coûté un rein pour le matériel et un bras pour le logiciel). De plus, avez-vous réellement besoin de ce temps de traitement de trois secondes ? Oui, ça permet à votre analyste de faire 10 fois plus de requêtes dans une heure de travail… mais avez-vous besoin de quelqu’un qui lance 100 requêtes au hasard, en espérant trouver quelque chose d’intéressant, ou plutôt de quelqu’un qui va réfléchir 58 minutes, puis lancer deux ou trois requêtes bien ciblées ? Si vous avec choisi la seconde alternative, pensez-vous vraiment que les trente secondes gagnées valait le coup ?
