Apache Bigtop et le choix d'une distribution Hadoop aujourd'hui

Il n'est probablement pas surprenant que l'année dernière ait été marquée par de grands changements pour Apache Hadoop. L'année dernière, il y a eu la fusion de Cloudera et Hortonworks (qui a essentiellement absorbé le second), et MapR, en raison de graves problèmes financiers, a été vendu à Hewlett Packard. Quelques années auparavant, lorsque des installations sur site étaient en jeu, le choix se portait souvent entre Cloudera et Hortonworks, mais aujourd'hui, il n'y a malheureusement plus ce choix. Une autre surprise a été le fait que Cloudera a annoncé en février de cette année l'arrêt de la publication des versions binaires de sa distribution dans le dépôt public, et celles-ci ne sont désormais disponibles que par abonnement payant. Bien sûr, il est encore possible de télécharger les dernières versions de CDH et HDP, publiées jusqu'à la fin de l'année 2019, et la prise en charge de celles-ci est prévue pour un ou deux ans. Mais que faire ensuite ? Pour ceux qui ont déjà payé un abonnement, rien n'a changé. Et pour ceux qui ne souhaitent pas passer à la version payante de la distribution, mais qui veulent avoir la possibilité d'obtenir les nouvelles versions des composants du cluster, ainsi que des correctifs et d'autres mises à jour, nous avons préparé cet article. Nous examinerons les options possibles pour sortir de cette situation difficile.

L'article est principalement une vue d'ensemble. Il n'y aura pas de comparaison des distributions ni d'analyse détaillée, et il n'y aura pas de recettes pour leur installation et configuration. Alors, que verra-t-on ? Nous allons brièvement parler de la distribution appelée Arenadata Hadoop, qui mérite notre attention en raison de sa disponibilité, ce qui est rare aujourd'hui. Ensuite, nous discuterons de Vanilla Hadoop, principalement de la façon dont il peut être 'préparé' à l'aide d'Apache Bigtop. Prêts ? Alors, bienvenue en dessous.

Arenadata Hadoop

C'est une distribution toute nouvelle et, pour l'instant, peu connue, développée localement. Malheureusement, à l'heure actuelle, il n'y a que cet article.

Plus d'informations peuvent être trouvées sur le site officiel site du projet. Les dernières versions de la distribution sont basées sur Hadoop 3.1.2 pour la version 3 et 2.8.5 pour la version 2.

Les informations sur le roadmap peuvent être trouvées ici.

L'interface Arenadata Cluster Manager

Le produit clé d'Arenadata est Arenadata Cluster Manager (ADCM), qui est utilisé pour l'installation, la configuration et le monitoring de diverses solutions logicielles de l'entreprise. ADCM est distribué gratuitement, et ses fonctionnalités sont étendues par l'ajout de bundles, qui représentent un ensemble d'ansible-playbooks. Les bundles se divisent en deux types : entreprise et communauté. Ces derniers sont disponibles pour un téléchargement gratuit sur le site d'Arenadata. Il est également possible de développer son propre bundle et de l'intégrer à ADCM.

Pour le déploiement et la gestion de Hadoop 3, une version community du bundle est proposée en association avec ADCM, tandis que pour Hadoop 2, il n'y a que Apache Ambari comme alternative. En ce qui concerne les dépôts de paquets, ils sont ouverts à l'accès public, et ils peuvent être téléchargés et installés de manière habituelle pour tous les composants du cluster. Dans l'ensemble, la distribution semble très intéressante. Je suis sûr qu'il y a des personnes qui sont habituées à des solutions comme Cloudera Manager et Ambari, et qui apprécieront ADCM lui-même. Pour certains, il sera également un grand avantage que la distribution figure dans le registre des logiciels pour le remplacement des importations.

En ce qui concerne les inconvénients, ils seront les mêmes que pour toutes les autres distributions Hadoop. En gros :

• Le soi-disant « verrouillage par le fournisseur ». Au travers des exemples de Cloudera et Hortonworks, nous avons déjà compris qu'il existe toujours un risque de changement de la politique de l'entreprise.
• Un retard considérable par rapport à l'upstream Apache.

Vanilla Hadoop

Comme vous le savez, Hadoop n'est pas un produit monolithique, mais essentiellement une multitude de services autour de son système de fichiers distribué HDFS. Peu de gens se contenteront d'un seul cluster de fichiers. Certains ont besoin de Hive, d'autres de Presto, et il y a aussi HBase et Phoenix, tandis que Spark est de plus en plus utilisé. Pour l'orchestration et le chargement des données, Oozie, Sqoop et Flume sont parfois rencontrés. Et si la question de la sécurité se pose, on pense immédiatement à Kerberos en association avec Ranger.

Les versions binaires des composants Hadoop sont disponibles sur le site de chaque projet de l'écosystème sous forme d'archives tarball. Vous pouvez les télécharger et commencer l'installation, mais avec une condition : en plus de compiler vous-même les paquets à partir des binaires « bruts », ce que vous voudrez probablement faire, vous n'aurez aucune certitude quant à la compatibilité des versions téléchargées entre elles. Une option préférée est la compilation via Apache Bigtop. Bigtop vous permettra de compiler à partir des dépôts Maven d'Apache, d'exécuter des tests et de créer des paquets. Mais, ce qui est très important pour nous, Bigtop compilera des versions de composants qui seront compatibles entre elles. Nous en parlerons plus en détail par la suite.

Apache Bigtop

Apache Bigtop est un outil pour la compilation, l'emballage et le test d'un certain nombre
de projets open source, tels que Hadoop et Greenplum. Bigtop a de nombreuses
versions. Au moment de la rédaction de cet article, la dernière version stable était la 1.4,
et la version master contenait 1.5. Différentes versions de versions utilisent différentes versions
des composants. Par exemple, pour la 1.4, les composants principaux de Hadoop ont la version 2.8.5, tandis qu’en master
elle est à 2.10.0. La composition des composants supportés change également. Les éléments obsolètes et
non mis à jour disparaissent, tandis que de nouveaux et plus demandés apparaissent, et
il ne s'agit pas nécessairement de quelque chose issu de la famille Apache elle-même.

De plus, Bigtop a de nombreux forks..

Lorsque nous avons commencé à nous familiariser avec Bigtop, nous avons d'abord été surpris par sa modestie, comparée à d'autres projets Apache, en termes de diffusion et de notoriété, ainsi que par sa communauté assez petite. Cela signifie que les informations sur le produit sont minimales, et la recherche de solutions aux problèmes rencontrés sur les forums et les listes de diffusion peut s'avérer infructueuse. Au départ, il nous a semblé difficile de réaliser une compilation complète du distributeur en raison des particularités de l'outil lui-même, mais nous en parlerons un peu plus tard.

En guise de teaser – pour ceux qui, à l'époque, appréciaient des projets du monde Linux, comme Gentoo et LFS, il pourrait être agréablement nostalgique de travailler avec cette chose et de se souvenir des « époques glorieuses » où nous cherchions (et parfois écrivions) des ebuilds et recompilions régulièrement avec de nouveaux patchs Mozilla.

Un des grands avantages de Bigtop est l'ouverture et la polyvalence des outils sur lesquels il est basé. À sa base se trouvent Gradle et Apache Maven. Gradle est bien connu comme l'outil utilisé par Google pour compiler Android. Il est flexible et, comme on dit, "testé au combat". Maven est l'outil de construction standard dans Apache, et étant donné que la plupart de ses produits sont publiés via Maven, il est également indispensable ici. Il convient de prêter attention au POM (model d'objet de projet) – le fichier XML "fondamental" décrivant tout ce qui est nécessaire pour que Maven fonctionne avec votre projet, autour duquel s'articule tout le travail. C'est dans
la partie Maven que se posent certains obstacles auxquels ceux qui se lancent dans Bigtop se heurtent généralement pour la première fois.

Pratique

Alors, par quoi devrions-nous commencer ? Allons sur la page de téléchargement et téléchargeons la dernière version stable sous forme d'archive. On peut également y trouver les artefacts binaires construits par Bigtop. D'ailleurs, les gestionnaires de paquets les plus courants supportés sont YUM et APT.

Une autre façon consiste à télécharger la dernière version stable directement depuis
github :

$ git clone --branch branch-1.4 https://github.com/apache/bigtop.git

Clonage dans « bigtop »...

remote: Énumération des objets : 46, done.
remote: Comptage des objets : 100% (46/46), done.
remote: Compression des objets : 100% (41/41), done.
remote: Total 40217 (delta 14), réutilisé 10 (delta 1), pack-réutilisé 40171
Récupération des objets : 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, prêt.
Détermination des changements : 100% (20503/20503), prêt.
Mise à jour des fichiers : 100% (1998/1998), prêt.

Le répertoire résultant ./$bigtop ressemble à ceci :

./bigtop-bigpetstore — applications de démonstration, exemples synthétiques
./bigtop-ci — outils CI, jenkins
./bigtop-data-generators — génération de données, synthétique, pour des tests de validation, etc.
./bigtop-deploy — outils de déploiement
./bigtop-packages — configs, scripts, patchs pour la construction, partie principale de l'outil
./bigtop-test-framework — framework de test
./bigtop-tests — les tests eux-mêmes, tests de charge et smoke
./bigtop_toolchain — environnement de construction, préparation de l'environnement pour le fonctionnement de l'outil
./build — répertoire de travail pour la construction
./dl — répertoire pour le code source téléchargé
./docker — construction dans des images docker, tests
./gradle — config gradle
./output – répertoire dans lequel se trouvent les artefacts de construction
./provisioner — provisionnement

Ce qui est le plus intéressant à ce stade est la configuration principale ./bigtop/bigtop.bom, dans lequel nous voyons tous les composants pris en charge avec leurs versions. C'est ici que nous pouvons indiquer une autre version du produit (si jamais nous souhaitons essayer de la construire) ou la version du build (si, par exemple, nous avons ajouté un patch significatif).

Un grand intérêt est également suscité par le sous-répertoire .\/bigtop\/bigtop-packages, qui a un lien direct avec le processus de construction des composants et des packages associés.

Donc, nous avons téléchargé l'archive, l'avons décompressée ou avons fait un clone depuis github, pouvons-nous commencer la construction ?

Non, nous devons d'abord préparer l'environnement.

Préparation de l'environnement

Et ici, il faudra faire un petit détour. Pour construire pratiquement n'importe quel produit plus ou moins complexe, un certain environnement est nécessaire — dans notre cas, cela inclut le JDK, les bibliothèques partagées, les fichiers d'en-tête, etc., des outils comme ant, ivy2 et bien d'autres. Une des manières d'obtenir l'environnement nécessaire pour Bigtop est d'installer les composants requis sur l'hôte de construction. Je peux me tromper sur la chronologie, mais il semble qu'avec la version 1.0, une option de construction dans des images docker pré-configurées et disponibles ait également été introduite, que l'on peut consulter ici.

En ce qui concerne la préparation de l'environnement, il y a un assistant — Puppet.

Vous pouvez utiliser les commandes suivantes, en exécutant à partir du répertoire racine
de l'outil, .\/bigtop:

.\/gradlew toolchain\n.\/gradlew toolchain-devtools\n.\/gradlew toolchain-puppetmodules

Ou directement via puppet :

puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::installer"\npuppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"\npuppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::development-tools"

Malheureusement, à ce stade, des difficultés peuvent déjà survenir. Le conseil général ici est d'utiliser une distribution prise en charge et à jour sur l'hôte de construction ou d'essayer le chemin avec docker.

Assemblage

Que pouvons-nous essayer de construire ? La réponse à cette question sera fournie par la sortie de la commande

.\/gradlew tasks

Dans la section Package tasks, il y a plusieurs produits qui sont des artefacts finaux de Bigtop.
Ils peuvent être identifiés par le suffixe -rpm ou -pkg-ind (dans le cas d'une construction
dans docker). Dans notre cas, le plus intéressant est Hadoop.

Essayons d'effectuer la construction dans l'environnement de notre serveur de build :

.\/gradlew hadoop-rpm

Bigtop téléchargera automatiquement les sources nécessaires pour un composant spécifique et commencera la construction. Ainsi, l'outil dépend des dépôts Maven et d'autres sources, ce qui signifie qu'il a besoin d'un accès à Internet.

Au cours du processus, une sortie standard est générée. Parfois, on peut comprendre ce qui ne va pas à partir de cette sortie et des messages d'erreur. Dans d'autres cas, des informations supplémentaires sont nécessaires. Dans ce cas, il vaut mieux ajouter les arguments --info ou --debug, et il peut également être utile de consulter –stacktrace. Il existe un moyen pratique de former un ensemble de données pour un contact ultérieur dans les listes de distribution, la clé --scan.

Avec cela, bigtop collectera toutes les informations et les déposera dans gradle, après quoi il fournira un lien,
en suivant lequel, une personne compétente pourra comprendre pourquoi la construction a échoué.
Il faut garder à l'esprit que cette option peut rendre publique des informations que vous ne souhaitez pas partager, comme les noms d'utilisateur, les nœuds, les variables d'environnement, etc., alors soyez prudent.

Souvent, les erreurs résultent de l'impossibilité d'obtenir certains composants nécessaires à la construction. En général, le problème peut être corrigé en créant un patch pour corriger quelque chose dans les sources, par exemple, l'adresse dans pom.xml à la racine des sources. Cela se fait en créant et en plaçant le patch dans le répertoire correspondant .\/bigtop\/bigtop-packages\/src\/common\/oozie\/ patch, par exemple, sous la forme de patch2-fix.diff.

--- a\/pom.xml
+++ b\/pom.xml
@@ -136,7 +136,7 @@


central
- http:\/\/repo1.maven.org\/maven2
+ https:\/\/repo1.maven.org\/maven2

false

Il est probable qu'au moment de lire cet article, vous n'aurez pas à réaliser vous-même la correction mentionnée ci-dessus.

Lors de l'application de patchs et de corrections dans le mécanisme de construction, il peut être nécessaire de 'réinitialiser' la construction via une commande de nettoyage :

.\/gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed

Cette opération annulera toutes les modifications apportées à la construction de ce composant, après quoi la construction sera relancée. Cette fois, essayons de construire le projet dans une image docker :

./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Building 1.2.1 hadoop-pkg on centos-7 in Docker...
+++ dirname ./bigtop-ci/build.sh
++ cd ./bigtop-ci/..
++ pwd
+ BIGTOP_HOME=/tmp/bigtop
+ '[' 6 -eq 0 ']'
+ [[ 6 -gt 0 ]]
+ key=--prefix
+ case $key in
+ PREFIX=1.2.1
+ shift
+ shift
+ [[ 4 -gt 0 ]]
+ key=--os
+ case $key in
+ OS=centos-7
+ shift
+ shift
+ [[ 2 -gt 0 ]]
+ key=--target
+ case $key in
+ TARGET=hadoop-pkg
+ shift
+ shift
+ [[ 0 -gt 0 ]]
+ '[' -z x ']'
+ '[' -z x ']'
+ '[' '' == true ']'
+ IMAGE_NAME=bigtop/slaves:1.2.1-centos-7
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 '!=' x86_64 ']'
++ docker run -d bigtop/slaves:1.2.1-centos-7 /sbin/init
+
CONTAINER_ID=0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8
+ trap 'docker rm -f
0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8' EXIT
....
much output
....
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-secondarynamenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-journalnode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-resourcemanager-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-nodemanager-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-proxyserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-timelineserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-historyserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-client-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-debuginfo-2.8.5-1.el7.x86_64.rpm
+ umask 022
+ cd /bigtop/build/hadoop/rpm//BUILD
+ cd hadoop-2.8.5-src
+ /usr/bin/rm -rf /bigtop/build/hadoop/rpm/BUILDROOT/hadoop-2.8.5-1.el7.x86_64
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.CwDb22
+ cd /bigtop/build/hadoop/rpm//BUILD
+ rm -rf hadoop-2.8.5-src
+ exit 0
[ant:touch] Creating /bigtop/build/hadoop/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) completed. Took 38 mins 1.151 secs.
:hadoop-pkg (Thread[Task worker for ':',5,main]) started.
> Task :hadoop-pkg
Task ':hadoop-pkg' is not up-to-date because:
Task has not declared any outputs despite executing actions.
:hadoop-pkg (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
BUILD SUCCESSFUL in 40m 37s
6 actionable tasks: 6 executed
+ RESULT=0
+ mkdir -p output
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/build .
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/output .
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
+ '[' 0 -ne 0 ']'
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
Error: No such container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD SUCCESSFUL in 41m 24s
1 actionable task: 1 executed

La construction a été réalisée sous CentOS, mais peut également être effectuée sous Ubuntu :

./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-ind

En plus de la construction de paquets pour diverses distributions Linux, l'outil peut également générer un dépôt avec des paquets construits, par exemple :

./gradlew yum

On peut également se rappeler des tests de validation et du déploiement dans Docker.

Créer un cluster de trois nœuds :

./gradlew -Pnum_instances=3 docker-provisioner

Lancer des tests de validation dans un cluster de trois nœuds :

./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisioner

Supprimer le cluster :

./gradlew docker-provisioner-destroy

Obtenir les commandes pour se connecter aux conteneurs Docker :

./gradlew docker-provisioner-ssh

Montrer l'état :

./gradlew docker-provisioner-status

Pour plus de détails sur les tâches de déploiement, vous pouvez lire la documentation.

En ce qui concerne les tests, leur nombre est relativement important, principalement des tests de validation et des tests d'intégration. Leur analyse dépasse le cadre de cet article. Je dirai simplement que construire une distribution n'est pas une tâche aussi complexe qu'elle peut le sembler au premier abord. Tous les composants que nous utilisons en production ont été assemblés et ont passé les tests, et nous n'avons pas eu de problèmes avec leur déploiement et l'exécution des opérations de base dans l'environnement de test.

En plus des composants existants dans Bigtop, il est possible d'ajouter d'autres éléments, y compris un développement logiciel propre. Tout cela peut être parfaitement automatisé et s'intègre dans le concept de CI/CD.

Conclusion

Il est évident qu'une distribution construite de cette manière ne doit pas être envoyée en production immédiatement. Il faut comprendre que s'il y a un besoin réel de construire et de maintenir sa propre distribution, cela nécessite un investissement financier et temporel.

Néanmoins, avec une approche correcte et une équipe professionnelle, il est tout à fait possible de se passer de solutions commerciales.

Il est important de noter que le projet Bigtop a besoin de développement et qu'il semble qu'il n'y ait pas d'activités de développement actif en cours aujourd'hui. L'avenir de l'intégration de Hadoop 3 y est également incertain. À propos, si vous avez un besoin réel de construire Hadoop 3, vous pouvez jeter un œil à fork Arenadata, qui, en plus des composants standards,
inclut également un ensemble d'autres (Ranger, Knox, NiFi).

En ce qui concerne Rostelecom, pour nous Bigtop est une des options considérées à ce jour. Si nous choisirons ou non cette option, le temps nous le dira.

Annexe

Pour inclure un nouveau composant dans l'assemblage, il faut ajouter sa description dans bigtop.bom et ./bigtop-packages. Vous pouvez essayer de le faire par analogie avec les composants existants. Essayez de comprendre, ce n'est pas aussi compliqué qu'il y paraît.

Et que pensez-vous ? Nous serions ravis de voir votre avis dans les commentaires et merci de votre attention !

Cet article a été préparé par l'équipe de gestion des données de Rostelecom

Source : habr.com