Tribune : A quel point Hadoop est-il essentiel pour un environnement Big Data?

Parce qu’Hadoop est devenu à la mode en même temps que l’expression Big Data, les deux termes sont largement devenus synonymes. Pourtant ils désignent des choses différentes. Hadoop désigne à la fois un système de gestion de fichiers en cluster et un modèle de programmation parallèle qui est mis en œuvre au-dessus d’un plus ou moins grand nombre de nœuds serveurs banalisés et qui est destiné à supporter des applications massivement distribuées de traitement de données. C’est tout l’objet d’Hadoop et la technologie existait bien avant que les entreprises et les médias ne se fascinent pour le Big Data. Mais comme Hadoop existait, il a été utilisé comme modèle de référence pour construire des infrastructures à même d’accueillir des application Big Data. Hadoop s’appuie sur HDFS (Hadoop Distributed File System), un système de gestion de fichiers en cluster, et sur l’algorithme MapReduce imaginé par Google et réimplémenté de façon OpenSource dans le cadre du projet open source Hadoop. Le framework est bâti en Java.

Je ne suis pas totalement rassuré sur l’avenir d’Hadoop. Et il est généralement admis que plusieurs aspects de l’infrastructure Hadoop nécessitent réellement du travail si le framework doit un jour acquérir des caractéristiques de classe entreprise. Tout d’abord au cœur du file system Hadoop, il y a le concept de NameNodes, qui gèrent les métadonnées relatives au cluster Hadoop : quelle est la nature de chaque équipement au sein du cluster, quelles sont ses capacités, quel type de workload il traite… Cette information n’est pas répliqué en un autre endroit et n’existe que dans un emplacement. Il s’agit donc d’un point de faute unique dans l’infrastructure Hadoop. Et ce problème doit être réglé si il faut confier des taches de calcul sérieuses à un cluster Hadoop. Un autre est JobTracker. JobTracker est un composant qui gère les tâches MapReduce et assigne les différents jobs de calcul aux différents serveurs, de préférence, ceux qui sont les plus proches des données à analyser par ce job particulier. JobTracker est lui aussi un SPOF. Il n’existe que dans un serveur du cluster. Ce sont deux des exemples des problèmes avec les architectures Hadoop disponibles aujourd’hui. [N.D.L.R : ces deux limitations mises en avant par Jon Toigo existent dans toutes les distributions Hadoop 1.x mais sont largement réglées dans Hadoop 2]

La technologie d’Hadoop elle-même n’est pas simple. Si vous devez le déployer, il vous faudra des développeurs compétents et il leur faudra comprendre un ensemble d’éléments qui ne sont habituellement fournis ensemble. Il leu faudra par exemple comprendre le logiciel d’analyse de données Pig – un raccourci de Pig Latin – mais aussi Hive,  un logiciel de base de données qui permet d’exécuter des requêtes quasi-SQL sur une infrastructure Hadoop. Et bien sûr, il leur faudra des compétences Java, spécifiquement en Jaql, qui est un langage de Query pour JSON(JavaScript Object Notation). Il est déjà parfois difficile de nos jours de trouver un développeur compétent en PHP, et là il vous faut quelqu’un qui dispose d’un bagage sur des langages plutôt exotiques.

Donc vous aurez des points de faute unique. Hadoop requiert aussi des compétences qui sont plutôt rares sur le marché et en plus vous allez avoir des problèmes de performances. Toutes les sociétés qui ont déployé Hadoop ont à un moment ou à un autre rencontré des problèmes de performances sur les opérations exécutes par Hadoop. Certains sont liés à du code applicatif particulièrement mal écrit, d’autres à l’infrastructure elle-même. Beaucoup de sociétés investissent de l’argent dans des serveurs additionnels, dans du stockage et dans des outils logiciels supplémentaires pour améliorer leur infrastructure.

Et bien sûr l’administration de l’infrastructure est un casse-tête. La gestion de l’infrastructure Hadoop est un aspect que beaucoup de gens tentent de résoudre avec une technologie baptisée Zookeeper, tandis que certains éditeurs tentent d’apporter une solution avec des composants développés en interne. Le problème est qu’il n’y a pas vraiment de bon modèle d’administration d’Hadoop actuellement et que faire fonctionner l’ensemble est un vrai défi.

Forbes magazine a récemment publié un article qui mettait en lumière une autre inquiétude que j’aimerai partager avec vous : Hadoop se préoccupe de l’infrastructure nécessaire pour mettre en œuvre un projet Big Data. Il s’attaque au problème du comment les données sont traitées. Mais les décideurs n’ont que faire du comment. Ils veulent juste des résultats et ils les veulent vite. L’auteur de cet article observe qu’Hadoop est peut-être bien pour traiter des données à grande échelle, ce qui est l’objectif affiché du logiciel. Toutefois, il n’est en rien optimisé pour vous fournir une analyse rapide ou pour faire de l’analytique en temps réel. Donc il ne sert pas directement un processus métier. Ce qu’il fait est fournir une fonction sous-jacente intéressante. Et il ne s’agit que d’une des façons disponibles pour ce faire

Cela va au cœur du problème et la vraie question est donc : à quoi va-t-on utiliser le Big Data ? Je ne suis pas sur que beaucoup de monde le sache pour l’instant, mis à part quelques spécialistes du marketing qui veulent mieux cibler leurs produits ou leurs services pour un public particulier.

Jon William Toigo a plus de 30 ans d’expérience dans l’IT ou il a travaillé comme simple exploitant et comme consultant pour deux intégrateurs systèmes internationaux. Il a écrit une quinzaine de livres et des milliers d’articles pour Storage Magazine, SearchStorage.com, Computerworld, Network Computing, Mainframe Executive, Scientific American, Washington Technology et z/Journal.

Il dispose de son propre blog, DrunkenData.com