Cela 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 vous lancez donc dans la construction d’une plateforme analytique, 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 filet est lancé, tout devient noir. Vous savez que les données sont là, mais vous ne pouvez pas y accéder ou, si vous y parvenez, elles apparaissent dans des formats inutilisables. Vos systèmes actuels ne peuvent pas y accéder, et vous n’avez pas de doctorats en programmation, ni le budget nécessaire pour acheter des traducteurs à l’échelle des Nations unies ou engager une armée de consultants. Un frisson vous parcourt la nuque. Qu’avez-vous fait ? Vous êtes entré dans la Dark Valley d’Hadoop. C’est la mauvaise nouvelle. La bonne nouvelle, c’est que vous n’êtes pas seul et qu’il existe un moyen d’en sortir.
Signes d’alerte indiquant que vous êtes dans la Dark Valley
De nombreuses entreprises riches en données tombent dans la Dark Valley pendant un certain temps. Vous avez les données, mais vous n’en tirez pas la valeur que vous attendez. Vous avez des problèmes pour tester et déployer les applications qui sont censées extraire cette valeur. Vous avez du mal à transformer les besoins de l’entreprise en code qui transformera le grand Léviathan qu’est le système de fichiers distribués Hadoop en quelque chose d’à peu près gérable. Le projet pour lequel tous ces efforts étaient destinés est retardé de plusieurs mois et les dépassements de coûts rendent les parties prenantes nerveuses. Lorsqu’on a enfin l’occasion de tester, on n’obtient pas les résultats escomptés. D’autres retards s’ensuivent.
L’un des tours les plus cruels de la 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 aussi rapidement que possible, puis d’itérer en avant. Mais Hadoop a tendance à révéler ses faiblesses en matière de gestion au fur et à mesure que l’on avance dans le cycle d’adoption. Si vous utilisez des outils conçus pour les programmeurs, comme Pig et Hive, vous faites le pari que le programmeur qui a construit la première itération sera encore là pour la deuxième. Sur 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 d’Hadoop, en est déjà à sa deuxième version, et qu’un troisième moteur de calcul entièrement nouveau, construit de A à Z, est rapidement en route. Dans l’écosystème Hadoop, de nombreuses pièces mobiles de bas niveau ont la fâcheuse habitude de changer tous les 90 à 120 jours. Toutes ces pièces mobiles signifient que vous devez suivre de nombreux cycles de versions, ce qui vous éloigne de l’activité à mener.
