Désormais disponible, Hadoop 3.0 se rapproche des entreprises
Résilience des données avec l’Erasure Coding, scalablité avec YARN Federation, contrôle des GPU et des disques par YARN : cet Hadoop troisième génération fait un pas de plus vers les entreprises.
Plus proche des exigences des entreprises. Après 5 ans de gestation, depuis la sortie de la version 2.0, la fondation Apache a officiellement présenté la version 3.0 d’Hadoop ce 14 décembre. Un peu en avance sur le calendrier initial. Cette version a dû traverser 4 alpha et une bêta pour recevoir son sceau final.
SI la v2 avait été marquée par l’apparition de YARN, ouvrant Hadoop à des traitements plus étendus que le batch de MapReduce, cette version 3.0 a pour vocation d’inscrire le framework plus près des préoccupations des entreprises. Le marché et les usages du Big Data ont évolué ; la place d’Hadoop s’est elle-aussi affinée avec le temps dans les SI des entreprises.
Un Hadoop v3 que Doug Cutting, le co-créateur du framework, présente d’ailleurs comme « mature ». « Avec cette mouture, Hadoop répond mieux aux besoins auxquels (le framework) est confronté dans les systèmes de données des entreprises. La communauté Open Source est toujours plus proches, des demandes des industriels », ajoute-t-il.
Erasure coding pour plus de résilience
Si Hadoop 3 apporte logiquement son lot de résolutions de bugs (302 ont été publiés), cette mouture comporte plusieurs ajouts majeurs, qui calent un peu plus Hadoop sur les SI.
L’un d’entre eux est l’intégration native de l’erasure coding à HDFS, ce système de fichiers distribué qui forme l’épine dorsale du framework. L’erasure coding (issue d’une contribution d’Intel et de Cloudera) permet ainsi à Hadoop de stocker les données plus efficacement sur un cluster – et sur le hardware associé – pour améliorer la récupération et la fiabilité des données, mais aussi pour en muscler les performances – ce qui est clé chez Hadoop. Surtout, avec l’erasure coding, Hadoop n’aura plus à stocker 3 replica complets des données sur un cluster – la mécanique par défaut d’Hadoop, comme l’explique MapR par exemple.
Techniquement, chaque dossier peut être associé à une règle (policy) particulière qui déterminera la répartition des blocs stockés. Les fichiers créés dans le dossier hériteront alors de cette règle. Selon la documentation d’Hadoop, « comparé à la triple réplication, la mise en place de ces règles d’erasure coding permet d’économiser 50% de capacités de stockage tout en étant plus tolérant aux pannes ». Une économie de coûts y est également associée.
Un YARN renforcé et plus étendu
Les autres améliorations clés portent sur YARN, le gestionnaire de ressources arrivé avec le v2 d’Hadoop. Le premier, YARN Federation, porte sur les capacités de scalabilité de ce socle. Cette fonction (une contribution de Microsoft) permet ainsi à YARN de supporter des applications distribuées sur plusieurs milliers de nœuds d’un cluster. Dans une présentation, Microsoft évoque même des centaines de milliers de nœuds. Ce principe de fédération avait été appliqué à HDFS à partir de la version 2.7 d’Hadoop.
Enfin, s’il fallait retenir un dernier élément pivot de cette mouture : la typologie des ressources par YARN a été étendue afin d’avoir un contrôle plus granulaire. Désormais, YARN est capable de prendre en compte et d’orchestrer les GPU et – cela est clé – les disques - au delà du CPU et de la mémoire donc. La fondation Apache estime d’ailleurs cela adapté aux environnements qui exploitent les containers et les différentes déclinaisons de l’Intelligence Artificielle – les GPU sont en effet de plus en plus sollicités dans ces cas d’usage.
