Ça arrive aux meilleurs d'entre nous. Vous savez que votre entreprise regorge de données utiles et vous n'avez fait qu'effleurer la surface. Vous avez donc décidé de créer une plate-forme d'analyse en utilisant tous les excellents outils open source dont vous avez tant entendu parler. Tout d'abord, vous devez capturer toutes les données qui vous parviennent, avant même de savoir ce que vous allez en faire. Vous construisez donc un filet à papillons pour tout attraper, en utilisant Hadoop. Mais dès que le réseau est lancé, tout devient noir. Vous savez que les données sont là, mais vous ne pouvez pas y accéder, ou si vous le pouvez, elles apparaissent dans des formats inutilisables. Ses systèmes actuels ne peuvent pas y accéder, et il n'a pas de doctorats en programmation, ni le budget pour acheter des traducteurs pour l'ensemble de l'ONU ou embaucher une armée de consultants. Un frisson vous parcourt le cou. Qu'est-ce que tu as fait? Vous êtes entré dans la vallée sombre d'Hadoop. C'est la mauvaise nouvelle. La bonne nouvelle est que vous n'êtes pas seul et qu'il existe une issue.
Panneaux d'avertissement indiquant que vous êtes dans la vallée sombre
De nombreuses entreprises riches en données tombent dans la Dark Valley pendant un certain temps. Vous avez les données, mais vous n'obtenez pas la valeur que vous en attendez. Vous rencontrez des difficultés pour tester et déployer les applications censées extraire cette valeur. Il s'efforce de traduire les besoins de l'entreprise en code qui transforme le grand léviathan qu'est le système de fichiers distribué de Hadoop en quelque chose de gérable. Le projet auquel tous ces efforts étaient destinés est retardé de plusieurs mois et les dépassements de coûts inquiètent les intéressés. Lorsque nous avons enfin la possibilité de tester, nous n'obtenons pas les résultats escomptés. D'autres retards se produisent.
L'un des tours les plus cruels de Dark Valley est l'illusion que vous avez réussi du premier coup. La philosophie de conception agile nous dit de travailler sur de petits projets et de les tester le plus rapidement possible, puis d'aller de l'avant. Mais Hadoop a tendance à révéler ses faiblesses de gestion au fur et à mesure de son cycle d'adoption. Si vous utilisez des outils conçus pour les programmeurs, comme Pig et Hive, vous pariez que le programmeur qui a créé la première itération sera toujours là pour la seconde. Dans le marché concurrentiel d'aujourd'hui, il n'y a aucune garantie à cet égard. Ensuite, il y a le fait que MapReduce, le langage natif de Hadoop, est déjà dans sa deuxième version, et un troisième moteur de calcul entièrement nouveau, construit à partir de zéro, est en train de faire son chemin. Dans l'écosystème Hadoop, de nombreuses pièces mobiles de bas niveau ont la mauvaise habitude de changer tous les 90 à 120 jours. Toutes ces pièces mobiles signifient que vous devez passer par de nombreux cycles de publication, vous éloignant de l'activité en cours.
