Choisir Hadoop : 7 critères indispensables pour identifier les besoins de l’entreprise

Hadoop est un ensemble de briques logicielles qui s’assemblent comme des puzzles LEGO pour résoudre un problème métier. Ainsi, la première chose lorsque vous voulez choisir une distribution, est – justement - de ne pas choisir de distribution. La première des choses est d’écrire la problématique métier que vous souhaitez résoudre avec Hadoop et cherchez les outils (Open source dans un premier temps) qui permettent de résoudre cette problématique. Ce n’est qu’à ce stade que vous aurez le choix entre adopter ces outils purement Open Source tels qu’ils sont dans la fondation Apache, ou alors vous orienter vers les éditeurs de distributions.

Si vous choisissez la deuxième option, c’est-à-dire les distributions des éditeurs, alors nous vous proposons une liste de 7 critères avec laquelle vous pouvez vous rapprocher sereinement des différents éditeurs. Ces critères sont les suivants : la disponibilité des outils Hadoop ou ses substituts dans la distribution de l’éditeur, la sécurité, la performance, le support, le TCO, l’alignement de la distribution à l’entreprise, et la convivialité dans l’utilisation. Nous allons expliquer en détail chacun de ces critères.

• La disponibilité des outils de l’écosystème Hadoop : après avoir déterminé clairement votre problématique, le premier critère à nos yeux est la disponibilité des outils Hadoop dont vous avez besoin. En effet, vous devez vous assurer que l’éditeur intègre dans sa distribution la ou les outils Open Source dont vous avez besoin. Dans le cas où il ne les intègre pas, vous devez vous assurer qu’il en propose des substituts. Supposez par exemple que vous voulez résoudre une problématique de streaming opérationnelle, et que pour ça vous souhaitez utiliser Apache Storm, vous vous rendrez compte qu’il n’est pas nativement intégré dans la distribution CDH de Cloudera. Si votre choix se porte sur CDH alors, vous devrez soit changer Storm pour Spark soit voir avec Cloudera comment intégrer Storm à votre installation ;
• La sécurité : Les révélations d’Edward Snowden en 2013 concernant l’espionnage mondial des moyens de télécommunication ont envoyé des ondes de chocs sur toute la planète et nous ont rappelé à tous que la sécurité, plus précisément la confidentialité, sera l’un des plus grands défis de l’ère du Big Data.  A cause de sa capacité de centralisation de données, Hadoop sera l’un des éléments les plus importants de l’entreprise à sécuriser. Malheureusement, sécuriser un cluster Hadoop représente le plus grand challenge du monde de l’Open Source comme le monde du logiciel propriétaire actuellement. C’est un challenge si difficile à surmonter que le sujet est évité dans le milieu de l’Open Source. Ce qui rend Hadoop si difficile à sécuriser est qu’il ne s’appuie pas sur le modèle classique d’architecture client-serveur, mais sur un modèle distribué. En effet, dans un cluster Hadoop, le système de fichiers est partitionné et distribué, requérant ainsi une vérification d'autorisation à plusieurs niveaux. Ainsi un job soumis peut être exécuté plus tard, dans des nœuds différents du noeud sur lequel le client s'est authentifié et a soumis le job. De plus, le passage à l'échelle du cluster à l'ordre du millier de machines n'arrange pas la situation. 

  Par défaut, Hadoop s’exécute sans aucun mode de sécurité, aucune authentification n’est requise pour l’exploiter. Le mode de sécurité le plus abouti qui est fourni par Apache est l’authentification KERBEROS, un protocole d'authentification réseau qui repose sur un mécanisme de chiffrement symétrique et non sur les mots de passe en clair – ce qui évite  le risque d'interception frauduleuse des mots de passe en clair des utilisateurs. Malheureusement, l’authentification KERBEROS est un mode de sécurité très global. Votre politique de sécurité Hadoop devrait aller plus loin et inclure la sécurité des jobs, les restrictions des droits d’accès par catégorie d’utilisateurs, les niveaux d’autorisation sur les jobs, les fichiers, les applications, l’intégration de l’authentification avec l’annuaire de l’entreprise (authentification LDAP, Active Directory), le cryptage des données lorsqu’elles sont transférées d’un service Hadoop à un autre. Une fois que vous avez défini les éléments de votre politique de sécurité Hadoop, regardez l’offre de chaque éditeur selon ces différents éléments. Au-delà de cela, si la distribution de l’éditeur s’appuie exclusivement sur l’Open Source, alors l’éditeur doit garantir qu’il n’y’a aucun risque de sécurité lié au principe de partage du code source ;

• La performance : la performance est selon nous le troisième critère de sélection d'une distribution. Au départ, la performance d'un cluster Hadoop se mesurait par le débit des données qu'il était capable de traiter par batch et son niveau de scalabilité (seuil de nœuds qui pouvait être rajouté au cluster). Avec l'introduction des nouveaux cas d'usages, et spécialement les problématiques de temps réel, le concept de performance a évolué pour tenir compte du niveau de latence des traitements. Aujourd'hui, évaluer la performance d'un cluster Hadoop signifie évaluer sa vitesse d'ingestion des données, la vitesse de traitement de ses modèles de calcul et sa capacité à s'étendre localement (le nombre de grappes maximales que peut supporter le cluster, le nombre de nœuds maximal dans une grappe) et sa capacité à s'étendre géographiquement (dans certains cas d'usage, les clusters doivent s'étendre sur plusieurs zones géographiques pour supporter la réplication de données). Toutes les distributions ne permettent pas par exemple l'étendue géographique, le nombre de nœuds maximal du cluster sur lequel il s'installe n'est pas le même, la performance des modèles de calculs ne sont pas les mêmes. Tous cela sont autant de critères que vous devez prendre en compte lorsque vous évaluez la performance d'une distribution ;
• Le support : l’un des principaux problèmes avec l’Open Source est le manque de support, que ce soit en termes de documentation qu’en termes de compétences technologiques. Ce manque de support peut potentiellement bloquer vos équipes et, à termes, vous empêcher de rentabiliser votre cluster Hadoop. Ainsi, vous devez vous assurer que l’éditeur fournit suffisamment de documentation nécessaire à l’exploitation des outils de sa distribution, un support d’intervention sur site en cas de problème avec votre cluster, et les cursus de formations certifiants pour permettre aux utilisateurs de monter en compétence sur l’écosystème de la distribution. Aujourd’hui, les trois éditeurs du marché fournissent ces trois niveaux de supports, mais à des tarifs différents. Comparez leur offre et sélectionnez celle qui correspond  aux besoins de l’entreprise et à son budget ;
• Le TCO : le TCO ou Total Cost of Ownership(en français Coût Total de possession), est le coût de revient de l’infrastructure du système informatique d’une entreprise. Il prend en compte le coût des ordinateurs, le coût d’acquisition des logiciels, le coût des licences, et le coût de support de cette infrastructure (salaire des personnes qui travaillent pour maintenir l’infrastructure en marche, coût d’électricité pour faire tourner l’infrastructure…). Le TCO donne une indication sur le poids du système informatique dans la structure de coût globale de l’entreprise, et sert ainsi d’indicateur clé dans les affectations de budget et les achats informatiques.

  Le TCO d’un cluster Hadoop traduit le coût de l’infrastructure du cluster (coût de l’ensemble des nœuds du cluster, des commutateurs réseau, câbles réseau LAN), le coût des licences de la distribution, et le coût de support du cluster (coût d’électricité, coût du personnel d’exploitation et d’administration, coût de maintien des bâtiments dans lesquels résident le cluster,…). En clair le TCO d’un cluster Hadoop vous dit combien vous coûte votre cluster Hadoop. Ce coût ne dépend pas uniquement de l’éditeur, mais également de l’offre de cluster haute performance des différents fabricants d’ordinateurs tels que Dell, Lenovo, ou HP. En ce qui concerne les coûts des licences, vous devez savoir que globalement, les éditeurs facturent la location de leur distribution sous forme de licence souscrite annuellement. Le prix de cette licence varie en fonction du nombre de nœuds du cluster et du niveau de support offert. D’autres facteurs peuvent également être pris en compte, vérifiez-les avec l’éditeur ; 

• L’alignement de la distribution sur l’entreprise : dans l’ouvrage the « World View : Global Strategies for the New Economy » publié par la Harvard Business Review, l’un des auteurs, Ben M. Bensaou s’indigne du fait que beaucoup de dirigeants occidentaux croient à tort qu'améliorer son entreprise correspond avant tout à l'équiper en dernière technologies à la pointe, en dernières versions logicielles, associant ainsi nouveauté à compétitivité. Il dit à cet égard : « nous pensons que si les entreprises analysaient de façon rigoureuse leurs technologies propriétaires, elles seraient surprises du grand nombre d’entre elles qui n’apportent aucun avantage compétitif ». L’auteur Nicholas CARR confirme les propos de Ben M. Bensaou dans son article « IT Doesn’t matter » en montrant que la technologie, aussi nouvelle et efficace soit-elle, ne fournit aucun avantage concurrentiel. Il s’agit ici de changer les mentalités des dirigeants : passer d’une méthode centrée sur Hadoop en tant que technologie hype à une autre centrée sur des cas d’usage identifiés et utile pour l’entreprise.

  En d’autres termes, ne conformez pas votre entreprise à une distribution, mais conformez la distribution à votre entreprise. Lors de la sélection d’une distribution, gardez toujours à l’esprit que ce sont les processus métiers de l’entreprise qui créent de la valeur et pas la technologie ;

• La convivialité dans l’utilisation de la distribution : la convivialité est certes un critère simple, et plus discret que les autres critères. Pourtant, il est la clé du retour sur investissement de la distribution.  Avec  l’accroissement exponentiel du volume de données auquel nous assistons, il n’est pas difficile de prédire qu’Hadoop va devenir la plateforme standard de traitement de données, un peu comme l’est progressivement devenu Excel peu de temps après l’essor des PC. Problème : à  la différence d’Excel, Hadoop n’a pas été conçu au départ pour être utilisé par les utilisateurs métier, mais par les développeurs. Or, comme la loi de Metcalfe le stipule, l’adoption à grande échelle d’une technologie et son succès ne dépendent pas des utilisateurs spécialisés, mais des utilisateurs métiers.  Hadoop n’en fait pas exception ! Heureusement, la fondation Apache a vite compris cela. C’est pourquoi dès l’année de la sortie d’Hadoop en 2009, elle s’est évertuée à le rapprocher du SQL. Pourquoi spécialement le SQL ? Pour deux raisons majeures : premièrement, parce que le SQL est le langage favori des utilisateurs métier.   Pour que Hadoop les séduise, il faut qu’il leur donne la possibilité d’utiliser leur langage favori.  Deuxièmement, parce que les entreprises utilisent de plus en plus HDFS comme répertoire de stockage central pour toutes leurs données, données provenant pour la plupart des systèmes opérationnels (comptabilité, marketing, finance, Ressources Humaines, etc.) - la majorité des outils d’exploitation de ces données (par exemple Business Objects, Oracle, SAS, Tableau,  etc.) s’appuient sur le SQL. Il faut donc des outils capables d’exécuter le SQL directement sur HDFS. Les outils offerts par la distribution de l’éditeur doivent être simples à utiliser, et doivent être le plus proches possible du SQL. Votre ROI dépend directement de la facilité avec laquelle les utilisateurs métier pourront s’approprier la solution. Leur niveau de confort est donc un critère clé. Privilégiez donc les éditeurs qui proposent des interfaces graphiques pour l’exploitation de leur distribution et des outils compatibles avec SQL.

Si ces critères sont essentiels dans votre sélection, gardez toutefois à l’esprit  deux choses : premièrement,  une comparaison n’est pas absolue, elle se fait toujours dans un contexte et elle n’est valide que dans ce contexte. Par exemple, Hortonworks peut être meilleur que MapR pour une problématique donnée et dans un ensemble de conditions précises. Cela peut être différent dans un autre contexte. Donc,  il n’y’a pas de bonne ou de mauvaise distribution : tout dépend de votre besoin et comment  l’offre proposée par l’éditeur à votre besoin peut y répondre. Deuxièmement, le but d’un benchmark n’est pas de dire que Cloudera est meilleur que MapR ou que Hortonworks est meilleur que Cloudera. Le but d’un benchmark n’est pas de comparer les éditeurs sur la base de leurs produits, mais de les comparer sur la base d’un besoin, précisément de votre besoin.