A la poursuite de MapR - Episode 1: le système de fichiers MapR-FS
A la poursuite de MapR - Episode 1: le système de fichiers MapR-FS
Cet article est le premier d’une série consacrée à la découverte de la distribution MapR.
Dans cet article, après avoir présentée le positionnement de la solution MapR, nous aborderons l’installation d’un environnement de test et la présentation de la partie administration.
Hadoop or not Hadoop
MapR est-elle une distribution Hadoop comme les distributions Cloudera ou Hortonworks ? A bien des égards, pas vraiment.
Comme nous le savons,le système de fichiers de Hadoop (HDFS) a été construit pour favoriser les traitements batch avec un volume important de données. Cela a conduit à mettre en place un système de fichiers optimisé pour les gros fichiers (plusieurs centaines de Mo ou quelques Go). En contrepartie, certaines opérations classiques ne sont pas possibles. Impossible par exemple de modifier une ligne du fichier: il faut le lire entièrement, le modifier en mémoire avant de le réécrire sur disque. Pas très green finalement.
La deuxième contrainte d’Hadoop est de reposer entièrement sur la technologie Java, ce qui lui assure une excellente portabilité mais pas forcément les meilleures performances, notamment sur des opérations d’entrée-sortie avec les disques.
Fort de ce constat, MapR s’est détourné de HDFS pour élaborer son propre système de fichiers: MapR-FS. En complément et pour garantir une compatibilité avec les distributions traditionnelles, les commandes HDFS ont été émulées.
Structure de MapR-FS
Ecrit en C/C++, MapR-FS propose plusieurs niveaux d’abstraction:
- le groupe de stockage est utilisé pour optimiser les entrées sorties disques
- le volume regroupe plusieurs conteneurs
- le conteneur généralement d’une taille de 32 Go est utilisé pour les opérations de réplication
- le chunk, d’une taille de 256 Mo, est utilisé lors des traitements de masse en map/reduce ou spark
- le block, d’une taille de 8 kb, est utilisé lors de la modification d’un fichier
A contrario, HDFS ne propose qu’un seul niveau d’abstraction des fichiers (généralement fixé par défaut à 64 ou 128 Mo suivant les distributions). Cela l’empêche d’être performant pour des opérations unitaires de modification d’un fichier par exemple (obligé de lire des millions de lignes d’un fichier pour en modifier une seule ligne) ou des opérations massives de réplication (obligé d’opérer la réplication sur des milliers ou millions de blocks de fichiers après une écriture massive).
Groupe de stockage (Storage pools)
Pour chaque machine du cluster, les disques sont regroupés dans un “storage pool”. Les opérations d’écriture au sein d’un groupe de stockage sont réparties sur plusieurs disques afin d’améliorer les performances en écriture.
Volume
MapR gère l’espace disque logique sous forme de volumes. On va pouvoir créer un ou plusieurs volumes sur notre cluster. Au sein de chaque volume, on pourra gérer des proriétés différentes comme par exemple le facteur de réplication ou les droits d’accès associés. Cela peut être intéressant par exemple pour gérer les espaces disques relatifs à différents environnements logiques (dev, recette, prod).
A chaque volume est rattaché un conteneur de noms et un ou plusieurs conteneurs de données.
Conteneur
Le service CLDB (Container Location Database) gère les informations suivantes sur chaque conteneur du système de fichiers MapR:
- le nœud où se trouve le conteneur
- la taille du conteneur
- le volume auquel appartient le conteneur
- les stratégies, les quotas et l’utilisation pour ce volume
Le service CLDB travaillant à plus haut niveau, gère relativement peu d’informations et peut s’installer sur les serveurs de traitements. Il fonctionne en cluster avec un noeud maître et des neouds esclaves. Le noeud maitre contient l’ensemble des emplacements des fichiers de tous les noeuds. La synchronisation entre noeud est assurée avec Zookeeper. Si le noeud maître n’est plus actif, un autre noeud pourra prendre le relais et assurer ainsi la haute disponibilité du cluster. Tous les noeuds sont des noeuds de traitement et de data. Cela contribue à simplifier l’architecture et son administration.
Le fonctionnement est très différent de HDFS. Pour rappel, le namenode enregistre des informations à la maille du bloc (64 Mo ou 128 Mo): cela génère donc beaucoup de contraintes sur ce service. C’est pour cela que les informations sont conservées en mémoire afin de faciliter la recherche des emplacements. Cela nécessite aussi de dédier in serveur entier à cette tâche.
Fichiers
A l’intérieur d’un conteneur, les fichiers sont d’abord découpés en plusieurs chunks de 256 Mo. Lors d’un traitement de type map ou en lecture spark, ce sont les chunks qui seront lus. Leur taille est un bon compromis pour optimiser la lecture séquentielle des données et paralléliser la lecture sur plusieurs noeuds.
Les chunks sont eux-même découpés en block de 8 kb. les blocks sont utilisés lors de la modification d’un fichier.
Un peu de pratique
Installation de la sandbox sous Docker
Afin d’expérimenter un peu la solution, nous allons utiliser la sandbox mise à disposition sous Docker: MapR container for developers
Attention à la configuration de Docker. Assurez vous de disposer de suffisamment de ressources pour faire fonctionner le container.
De mon côté, j’ai alloué 4 cores (logiques) et 8 Go de RAM pour travailler dans de bonne condition.
Après avoir installé les outils clients sur son mac, on installe le container en lançant le script d’installation fourni.
./mapr_setup.sh
Une fois lancé, il faut attendre que tous les services soient montés. Après s’être connecté, on peut vérifier la progression en exécutant la commande “jps” dans le container.
ssh root@127.0.0.1 -p 2222
A noter qu’on rencontre un problème de sécurité pour le certificat.
Il est possible d’outrepasser ce problème dans Firefox mais pas dans Safari qui est très restrictif sur ce plan. Si malgré tout, vous voulez quand même utiliser Safari, il faut exporter le certificat (à partir de firefox), l’importer dans votre trousseau puis modifier les propriétés pour approuver le certificat.
La console d’administration
L’accès à la console se fait via l’url:
https://localhost:8443/app/mcs/#/app/login
Une fois connecté avec les identifiants root/mapr, on accède à un tableau de bord général.
En cliquant sur Data/Volumes, on accède à la page des volumes.
Aucun volume utilisateur n’est déclaré. Mais il existe déjà des volumes systèmes (logs, audit, etc.). On voit ici l’intérêt de disposer de volumes différents pour pouvoir faire varier le facteur de réplication pour les logs ou le suivi des métriques du cluster.
Création d’un volume de données
Je vous propose de créer un volume de données à partir de la console MCS. On va en profiter pour modifier le facteur de réplication et le propriétaire du volume.
Comme on le voit, le volume est maintenant visible avec une commande hadoop.
Il est également visible comme un simple répertoire linux quand on est connecté directement à la machine.
Ajout d’un fichier dans notre volume
Essayons de nous connecter à ce cluster via les outils clients.
Afin de pouvoir les utiliser facilement, je rajoute le chemin des utilitaires dans mon fichier .bash_profile.
export PATH="/opt/mapr/bin:$PATH"
On peut maintenant ajouter notre fichier business.json extrait d’un dataset yelp.
sudo hadoop fs -copyFromlocal business.json /testvol/
Utilisation du fichier sous Spark
On va se connecter à Spark pour faire une première analyse de notre fichier. Notre fichier d’entrée étant au format json, on va utiliser la librairie sql pour lire le fichier et le transformer en table.
On peut également faire une requête un peu plus compliquée. Le résultat est retourné très rapidement.
Ce qui est intéressant, c’est la possibilité de modifier directement le fichier (via l’outil vi). Dans cet exemple, je remplace la valeur 5 étoiles pour la ville de Goodyear par 15000.
Je relance le traitement Spark et on voit bien apparaître la ville de Goodyear dans les résultats.
Cela clos cette première visite de la distribution MapR. A très bientôt pour découvrir ensemble la base de donnée associée à MapR: MapR Database.