Depuis le rachat d’HortonWorks par Cloudera, les distributions Hadoop sont devenues payantes.
Il y a quelques alternatives comme google cloud et son éléphant appelé dataproc.
Cela a un coût… en cloud cette fois J’ai régulièrement eu 200€ pour donner 3 jours de formation.
Choix des composants
Ceci mérite débat…
Dans l’approche classique d’un éléphant, vous avez des composants « externes », sur lesquels vous développez vos traitements, et des composants « internes », qui existent mais auxquels vous ne touchez pas.
Composants externes
- hive
- spark
- sqoop
- oozie
- hbase
- ranger
- atlas
Composants internes
- postgreSql
- Kafka
- SolR (base d’indexation de documents)
- Janus (base graphe, fork de Titan db)
Yarn
Hadoop s’appuie sur Yarn pour gérer les ressources, degré de parallélisme, mémoire allouée à vos applications.
Cela fonctionne assez bien; avec le temps, les développeurs sont de plus en plus sur Kubernetes et la question commence à se poser de l’avenir de Yarn.
J’ai bien lu à un moment que Yarn voulais évoluer dans ce sens mais je n’ai pas l’impression que cela arrive.
Si je devais comparer les deux, je dirais que Yarn vous donne de la ressource en fonction de ce qu’il a sous le pied alors que Kubernetes donne la ressource en fonction des besoins (nombre d’appels sur les API, CPU consommée..)
HDFS
Le stockage des fichiers sur ce système de disque a fait ses preuves:
- robustesse
- évolutivité (ajouter ou supprimer des noeuds)
- adapté à des volumes importants
Je ne sais pas vous mais moi, je présente HDFS, le Big Data, l’évolution des volumes sur Terre, etc.. Et finalement j’arrive sur un cluster où je trouve 20 millions de fichiers d’1ko!
L’aspect niveau de réplication de 3 doit aussi faire débat. En effet si vous montez un Hadoop sur un VMWare ESX, il y a de fortes chances que vos disques soient déjà en RAID 1 ou 5. Quel est l’intérêt de redonder vos volumes alors qu’il sont eux mêmes tolérant à la panne ?
Ces concepts sont valables pour des Facebook, Google et quelques autres. Cependant la plupart des clients ont des besoins de l’ordre de quelques Téraoctets et non de Exas ou de Pétas.
A titre d’exemple, un serveur à 5000€ offrira 20 core, 12 Téra disque utile, un bon gpu… Je me dis qu’un Ubuntu en RAID Z avec une tolérance de panne à 2 disques et quelques machines virtuelles pour votre éléphant dépassera vos attentes.
En synthèse, votre éléphant sera 3 fois plus rapide si HDFS est configuré sans réplication.
Vision d’une plateforme
Mon approche, est d’avoir un Hadoop ouvert et de mélanger des traitements de type « fil de l’eau » (ce que tout le monde appelle du temps réel) avec des traitements analytiques.
Les composants internes devaient être utilisables et j’en profite pour mettre elasticsearch au lieu de SolR (qui rime avec austère)
Atlas commence à être un produit vieillissant mais je ne connais pas d’autre solution pour gérer le RGPD et la CNIL. En revanche, il est nécessaire qu’il se connecte à Elastic au lieu de SolR. Là aussi, le dépoussiérer de ce qui ne sert à rien serait un plus.
L’administration de la plateforme
Jusqu’ici nous avions ambari ou cloudera manager pour administrer notre éléphant.
Ce sont de bons produits qui permettent d’historiser les modifications, afficher des dashboards (suivi de performances) et graphiquement plutôt réussis.
Quelques critiques:
- Même s’il est open source, je serais curieux de rencontrer quelqu’un qui arrive à le compiler, le configurer sur d’autres produit, et gérer les répository pour l’installation.
- Bien que cela donne un aperçu de l’utilisation du cluster, je n’ai pas été convaincu. Par exemple, j’ai lancé une grosse copie entre 2 clusters et les dashboards montraient une activité réseau vide ???
- vive les certificats (je ne remercierai jamais assez ambari d’avoir mis des certificats valables 365 jours en prenant soin de déplacer les repo)
En synthèse, une approche DevOps s’appuyant sur git, ansible, jenkins pour l’installation et l’administration de la plateforme sera bien plus efficace qu’Ambari.
Nous ajouterons Grafana pour la création de Dashboard et ce sera aussi plus pertinent.
Conclusion
Vous avez une première idée de ma vision d’un Hadoop entreprise gratuit, plus ouvert et plus performant.
A l’heure de cet article, nous sommes sur ce sujet depuis 4 mois. La stack de base fonctionne; Ranger donne du fil à retordre. Je suppose qu’il reste 2 mois de travail pour intégrer Atlas, vieux mammouth qui s’est déguisé en éléphant.
Un premier retour d’expérience est que bien que les produits soient open source, la moindre modification de code est un challenge. J’ai découvert le concept de shaded jar; un truc qui permet d’ajouter des jar dans des jar (en contrôlant que vous n’avez pas changer la liste ou le nom de classes java)… je trouve l’open source moins ouvert subitement 🙂
