Hadoop OUI !

Vous le savez déjà mais Hadoop est un framework libre et open source destiné à faciliter la création d’applications distribuées (au niveau du stockage des données et de leur traitement) et évolutif (scalable) permettant aux applications de travailler avec des milliers de nœuds et des pétaoctets de données.

Le noyau d’Hadoop est constitué d’une partie de stockage : HDFS (Hadoop Distributed File System), et d’une partie de traitement.

Brique fondamentale dans la valorisation des données Hadoop est très pratique pour :

• Explorer les données : requête SQL avec Apache Hive (Batch), Apache Drill (Temps-réel), ou autres…
• Traiter et Préparer les données : Apache Spark, MapReduce, Tez…

Pouvoir stocker et préparer un grande quantité de données est très pratique pour entrainer des modèles d’intelligence artificielle (mais ces 2 écosystèmes ne sont pas nativement compatibles/connectés)

HDFS NON !

Aujourd’hui - l’ère où toutes les entreprises cherchent a valoriser leurs données - Hadoop apparait comme quasiment incontournable dans le chemin de la valorisation (Data Pipeline) au même titre que l’intelligence artificielle, le machine learning ou encore les architectures micro-service.

Mais voilà, aucune entreprise n’est prête a changer ses habitudes de travail, réduire ses niveaux de services ou encore créer un Nième silo (Hadoop) pour valoriser ses données. C’est la raison pour laquelle beaucoup de projets échoues lorsqu’il s’agit de passer en production, d’intégrer cette valorisation dans le SI ou encore d’agir sur des données temps-réel.

UNE ARCHITECTURE D’UN AUTRE TEMPS

Je vais donc vous parler de l’architecture du système de fichier distribué par défaut des distribution Open Source Hadoop (HDFS : Hadoop Distributed File System) et ainsi vous expliquer pourquoi tout l’écosystème Hadoop est pénalisé par ce socle fondamental qui héberge les données à valoriser.

Je n’aborderai volontairement pas la v3 de Hadoop étant donné que c’est trop récent et que le passage de v2 a v3 est tellement disruptif que peu de clients ont franchis le pas. (mais pour les curieux c’est ICI)

1- HDFS n’est plus adapté aux challenges d’aujourd’hui

Le design du Hadoop Distributed File System (HDFS) est assez simple et parfaitement aligné avec l’objectif premier d’HDFS lors de sa conception à savoir scanner les sites web (une startup qui s’appelait Google) et stocker tout ça dans de gros fichiers que l’on pouvait se permettre de perdre puisque chaque jour les robots recommençaient. Ensuite des traitements (batch) indexaient ces données pour vous permettre de trouver votre livreur de pizza près de chez vous ;-) C’est pour cette raison que le fait qu’HDFS soit Append-Only ne choquait personne à l’époque.

Euh… Append-Only c’est quoi ?

Un système de fichier Append-Only ne permet QUE de déposer des documents SANS pouvoir les modifier sur place. Pour faire simple si votre clé USB était formaté en HDFS vous pourriez déposer un document Word sans pouvoir le modifier directement depuis cette clé, pour ce faire il faudrait le copier sur votre ordinateur, modifier le document Word avant de le re-transférer sur la clé USB HDFS.

Modifier un document sur un système HDFS impose :

1. D’assumer que les documents déposés ne seront pas modifiés (d’où la nature BATCH et non TEMPS-REEL de HDFS)
2. Un espace tampon performant pour héberger le fichier a modifier
3. Un peu de patience car tout ceci prend du temps (transfert->modification->transfert)
4. Savoir coder car rien n’est intégré ni automatique

Vous l’avez compris aujourd’hui tout le monde veut se rapprocher du temps-réel en étant capable de faire de la BI/Analytic sur des données en perpétuel mouvement. Je n’irai pas jusqu’a parler de temps-réel (sinon vous allez grincer des dents) mais parlons plutôt de données “opérationnelles”

2- Le NameNode : une épine dans le pied qui fait très mal

Le design HDFS s’appuie sur un NameNode qui est un seul et unique processus contenant une table (en mémoire) servant à stocker les MétaDonnées (MD) du système de fichiers et plus particulièrement l’emplacement physique des blocks (de 128MB) composants les fichiers. Le but est de maintenir à jour les emplacements (et caractéristiques) des données au sein du cluster tout entier. Il s’agit d’un aspect clé du design de HDFS (qui a permis notamment d’accélérer son développement à sa création).

Mais voilà, cela introduit un SPOF mais aussi pas mal de limitations.

Euh…c’est quoi un SPOF ?

Un SPOF (Single Point Of Failure) est un composant qui s’il n’est pas disponible met en péril tout le système. En effet si vous perdez ce NameNode plus personne ne peut accéder aux fichiers et votre production Hadoop s’arrête littéralement.

Pourquoi le NameNode limite HDFS ?

L’évolutivité maximum est calculé comme suit : SCALE = #Blocks X BlockSize

Si vous pouvez stocker une centaine de millions de blocks de 128MB vous avez une idée de ce qu’un NameNode peut délivrer en terme d’évolutivité.

100 000 000 (blocks) X 128MB = 12 Petabytes (Po)

Déployer plusieurs NameNode est possible (HDFS Federation) mais introduit de la complexité et n’est pas supporté par toutes les distributions commerciales à ce jour.

Enfin en passant par le NameNode pour accéder aux données il devient un goulet d’étranglement (environ 500Mo/s par NameNode). Contournable par la fédération d’HDFS.

3- A un moment il faudra bien passer en production

Et oui, vous n’allez tout de même pas réduire vos SLA (Service Level Agreement = Niveaux de services) parceque vous avez décidé de valoriser vos données avec Hadoop (et HDFS)

Allo…Houston…vous avez un problème : car HDFS n’a pas été conçu pour offrir de PRA/PCA nativement.
PRA : Plan de Reprise d’Activité
PCA : Plan de Continuité d’Activité

HDFS tolère les pannes de noeuds (serveurs) en revanche vous n’êtes ni protégé contre la corruption de données (Malware /erreur humaine) ni contre la perte d’un Datacenter (feu/crash d’avion). Si vous voulez vous prémunir vous devrez développer (sur la base d’outils Open Source genre distscp) vos propres mécanismes de réplication (et réinventer la roue).

Et oui, mettre en place une simple réplication de datacenter sur Hadoop est un casse tête

4- HDFS n’est pas Multi-Workload

Un Workload est lié à la façon dont les données sont utilisées

Pour faire (très) cours vous avez 2 principaux types de Workload :

• Transactionnels (OLTP: petits fichiers, petits blocks et sensible a la latence) c’est par exemple ce qu’il se passe quand vous payer avec votre carte bancaire
• Décisionnels (OLAP: gros fichiers, gros blocks et sensible a la bande passante) c’est par exemple ce qu’il se passe quand vous générez un rapport analytique croisant beaucoup de données historiques pour prendre une décision.

Sur un cluster HDFS cette taille de block est configurable mais unique et globale, vous pouvez changer cette taille de block lors de l’installation et de la configuration du cluster mais il ne peut pas être changé ultérieurement. Et donc toutes les applications, tous les tenants du cluster doivent s’entendre sur cette taille unique défini à l’installation impliquant des compromis (petits/gros fichiers, Batch/Realtime, Transactionnel/Decisionnel…)

Habituellement cette taille de block est défini à 128MB, ce qui est optimisée pour les programme de type BATCH, ce qui à du sens si ce que vous faites c’est du batch, mais c’est vraiment dommage de re-créer un SILO Batch quand l’objectif ultime est de valoriser ses données et que le prérequis numéro 2 c’est d’avoir tout au même endroit et donc d’éliminer les silos.

5- Développé en JAVA

HDFS est codé en JAVA et traverse beaucoup de couches pour lire/écrire les données, ce qui n’en fait pas le Système de Fichier distribué le plus efficace ($$$) ni le plus performant.

En effet le système de fichier HDFS repose sur Java, qui repose lui même sur un Système de Fichier Unix, qui lui même passe par le système d’exploitation et bien souvent nécessite une protection RAID sous-jacente…

Conclusion

L’écosystème Hadoop est parfait pour traiter de grosses quantités de données mais mérite vraiment un système de fichier beaucoup plus performant, résilient, économique et ouvert qu’HDFS.

Sur le marché il y a pas mal d’options qui s’ouvrent a vous, rendez-vous sur Wikipedia

Retenez que pour tirer pleinement partie de l’écosystème Hadoop et intégrer parfaitement ces framework de traitement il est important de disposer d’un système de fichier :

• Accessible en lecture/écriture (pas de Append-Only) pour permettre à toutes les applications de continuer a travailler comme avant (non-régression)
• Résilient qui permet de survivre aux pannes des noeuds/disques pour assurer un niveau de service acceptable aux métiers
• Disposant de Snapshot/Réplication pour passer en production facilement et se protéger contre les malveillances/corruptions/désastres
• Ouvert vers l’extérieur (API) pour y connecter vos applications “anciennes” comme les plus récentes (car c’est là que sont produites vos données les plus valorisables)
• Temps-réel pour adresser les challenges du digital où tout est immédiat et sous la forme de notification (événementiel)
• Multi-Workload pour connecter vos services qui ne travaillent pas tous de la même façon (RH=Batch, Finance/Risk=Analytique, Production=Transactionnel)
• Compatible avec le Cloud car que vous le vouliez ou non un jour vous aurez un pied dans le cloud ;-)

Voilà, j’espère que ce n’était pas trop long, cette réflexion que je voulais partager avec vous est le résultat d’une centaine de rencontres dans de grandes sociétés (CAC40 et ETI)

Je prépare un autre article sur l’approche stratégique a adopter pour adresser les challenges de la valorisation des données que sont le Cloud/Multi-cloud, la modernisation des applications existantes, la BI/Analytique et l’intelligence artificielle.

Disclaimer

Les opinions exprimées dans cet article sont mes opinions personnelles. Je suis un blogueur qui travaille chez MapR et non pas un blogueur MapR. Je publie sur mon profile Linkedin qui est personnel et non pas sur la page corporate de mon employeur. Les contenus publiés ne sont ni lus, ni validé par mon employeur et ne reflètent pas nécessairement la vision et les opinions de cette compagnie. Ce post ainsi que les informations communiquées sont à prendre tel quel, à interpréter avec votre libre arbitre et sans aucune garantie.