echiechi - Fotolia

Conseil

Quel stockage pour Hadoop ?

HDFS, le système de gestion de fichiers distribué d’Hadoop, a considérablement évolué depuis les débuts du framework analytique. Ce qui n’empêche pas certains de lui chercher des alternatives.

Christophe Bardy
par
Publié le: 25 juin 2018

Au cœur du framework open source se trouve avant tout un système de fichiers en cluster, baptisé HDFS (Hadoop Distributed File System). HDFS a été conçu pour stocker de très gros volumes de données sur un grand nombre de machines équipées de disques durs banalisés.

À l’origine, HDFS a été conçu dans une logique de type « write once, read many », bien adaptée à la logique des traitements en mode batch de MapReduce, le framework initial d’analyse de données d’Hadoop.

S’appuyant sur le stockage local de chacun des nœuds, les premières moutures d’HDFS assuraient la sécurité des données en répliquant l’ensemble des données écrites sur le cluster. Par défaut, chaque donnée était écrite sur trois nœuds différents (dont une copie sur le nœud local).

Cette approche n’était à l’évidence ni la plus élégante, ni la plus efficace en matière de redondance – d’autant que la première mouture de HDFS n’opérait qu’avec un « namenode » unique, véritable faille dans l’architecture de gestion des métadonnées du cluster. Mais étant donné que l’on s’appuyait souvent sur des disques durs SATA économiques, ce dispositif permettait quand même d’offrir une solution de stockage économique par rapport aux baies de stockage traditionnelles.

Autre problème, les premières moutures d’HDFS étaient essentiellement optimisées pour maximiser les débits de données et non pas pour traiter des opérations transactionnelles aléatoires. Le fruit, là encore, de la nature batch de MapReduce.

Progressivement, HDFS a donc évolué pour tenter de corriger ses limitations initiales. Avec la version 2.0 d’Hadoop, la principale faiblesse d’HDFS a été levée : la fonction HDFS High Availability a ainsi permis de répliquer le « name node » en mode actif/passif, protégeant ainsi le système de fichiers contre une éventuelle défaillance d’un des namenodes. Cela  offre une tolérance aux pannes.

Plus récemment, la version 3.0 d’HDFS a apporté l’intégration native des codes à effacement. L’erasure coding (issue d’une contribution d’Intel et de Cloudera) permet à HDFS de stocker les données plus efficacement sur le cluster et d’améliorer la récupération et la fiabilité des données. Surtout, avec l’erasure coding, Hadoop n’a plus à stocker 3 répliques complètes des données sur le cluster. 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 l’erasure coding permet d’économiser 50 % de capacités de stockage tout en améliorant la tolérance aux pannes ». Ces gains se traduisent bien évidemment par une réduction globale des coûts de stockage.

Passer outre les limitations de HDFS

Quelles que soient les améliorations apportées à HDFS, un autre « défaut » du système de fichiers distribué est qu’il n’est pas conforme au standard POSIX. Certaines fonctionnalités et commandes familières sur un système de fichiers traditionnel ne sont donc pas disponibles. C’est ce qui a amené certains acteurs à tenter de trouver une solution de substitution à HDFS. MapR, l’un des pionniers d’Hadoop, a ainsi développé son propre système de gestion de fichiers distribué qui règle le problème de fragilité lié aux « name nodes » d’HDFS (il distribue les informations de métadonnées sur les nœuds de données).

Celui-ci ajoute aussi des fonctions avancées comme les snapshots, la réplication ou le clonage. Ce système de fichiers a récemment évolué pour gagner des capacités multi-datacenter, et multi-cloud (Azure, AWS) et, surtout, des capacités de tiering sophistiquées. Rebaptisé MapR-XD, il a aussi gagné le support du protocole S3 ; ce qui permet à MapR d’inclure le stockage objet Cloud d’AWS à son système de stockage et à sa politique de tiering.

Plusieurs constructeurs de baies de stockage comme Dell EMC, HPE ou IBM ont aussi développé des couches de compatibilité HDFS pour certaines de leurs baies de stockage. Leur objectif est de remplacer le modèle de stockage décentralisé de HDFS par un modèle centralisé de type SAN ou NAS. Leur argument est double : le stockage centralisé est plus efficace, plus optimisé et plus simple à gérer que le stockage HDFS. Surtout, il permet d’alléger les nœuds des fonctions de stockage pour leur permettre de se concentrer aux seuls calculs analytiques.

Pour les entreprises, on peut également souligner d’autres bénéfices. Tout d’abord, elles sont déjà familières des modèles de stockage SAN et NAS. Ensuite, elles sont habituées aux services de stockage riches offerts par les baies (snapshots, réplication, etc.). Enfin, le fait de s’appuyer sur les baies qui stockent déjà leurs données primaires et secondaires évite d’avoir à transférer des données sur HDFS. Cela permet aussi de s’appuyer sur des protocoles standards comme NFS ou SMB pour verser des données additionnelles dans le cluster Hadoop.

Notons pour terminer que le stockage traditionnel n’est pas la seule alternative au stockage HDFS. De plus en plus, le stockage objet émerge aussi comme une alternative au stockage Hadoop traditionnel grâce notamment à la montée en puissance du client s3a.

Pour approfondir sur Software Defined Storage