🌬️ 👌 🐪 Apache Bigtop et le choix de la distribution Hadoop aujourd'hui 📼 🤳🏼 🛋️

Ce n'est probablement pas un secret que l'année dernière a été une année de grands changements pour Apache Hadoop. L'année dernière, Cloudera et Hortonworks ont fusionné (essentiellement une prise de contrôle de la seconde) et Mapr, en raison de graves problèmes financiers, a été vendue à Hewlett Packard. Et si quelques années auparavant, dans le cas des installations sur site, le choix devait souvent être fait entre Cloudera et Hortonworks, aujourd'hui, hélas, nous n'avions pas ce choix. Une autre surprise a été le fait que depuis février de cette année, Cloudera a annoncé la fin de la sortie des assemblages binaires de sa distribution dans un référentiel public, et maintenant ils ne sont disponibles que par abonnement payant. Bien sûr, la possibilité de télécharger les dernières versions de CDH et HDP, publiées avant la fin de 2019, est toujours là, et leur prise en charge est attendue pendant un à deux ans. Mais que faire ensuite? Pour ceux,qui avait déjà payé l'abonnement, rien n'a changé. Et pour ceux qui ne veulent pas passer à une version payante du kit de distribution, mais veulent pouvoir obtenir les dernières versions des composants du cluster, ainsi que les correctifs et autres mises à jour, nous avons préparé cet article. Dans ce document, nous examinerons les moyens possibles de sortir de cette situation.

. , . ? Arenadata Hadoop, , . Vanilla Hadoop, , “” Apache Bigtop. ? .

Arenadata Hadoop

Il s'agit d'une répartition complètement nouvelle et, jusqu'à présent, peu connue du développement intérieur. Malheureusement, pour le moment il n'y a que cet article sur Habré à ce sujet .

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

Vous trouverez des informations sur la feuille de route ici .

Interface Arenadata Cluster Manager Le

produit clé d' Arenadata est Arenadata Cluster Manager (ADCM), qui est utilisé pour installer, configurer et surveiller diverses solutions logicielles de l'entreprise. ADCM est gratuit et ses fonctionnalités sont étendues en y ajoutant des bundles, qui sont un ensemble de livres de jeu ansibles. Les offres groupées sont divisées en deux types: entreprise et communauté. Ces derniers sont disponibles en téléchargement gratuit sur Arenadata. Il est également possible de développer votre propre bundle et de le connecter à ADCM.

Pour le déploiement et la gestion de Hadoop 3, une version communautaire du bundle en conjonction avec ADCM est offerte, et pour hadoop 2 il n'y a qu'Apache Ambaricomme alternative. Quant aux référentiels avec packages, ils sont ouverts à l'accès public, ils peuvent être téléchargés et installés de la manière habituelle pour tous les composants du cluster. En général, la distribution semble très intéressante. Je suis sûr qu'il y a ceux qui sont habitués à des solutions telles que Cloudera Manager et Ambari, et qui aimeront ADCM lui-même. Pour certains, le fait que le kit de distribution soit inclus dans le registre des logiciels de substitution des importations sera un énorme avantage .

Si nous parlons des inconvénients, ils seront les mêmes que pour toutes les autres distributions Hadoop. À savoir:

Le soi-disant «verrouillage des fournisseurs». En utilisant les exemples de Cloudera et Hortonworks, nous avons déjà réalisé qu'il y a toujours un risque de changer les politiques de l'entreprise.
Retard important derrière Apache en amont.

Hadoop vanille

Comme vous le savez, Hadoop n'est pas un produit monolithique, mais, en fait, toute une galaxie de services autour de son système de fichiers HDFS distribué. Peu de gens auront besoin d'un cluster de fichiers. L'un a besoin de Hive, et l'autre de Presto, et il y a HBase et Phoenix, Spark est de plus en plus utilisé. Oozie, Sqoop et Flume sont parfois trouvés pour orchestrer et télécharger des données. Et si le problème de sécurité se pose, Kerberos en collaboration avec Ranger est immédiatement mémorisé.

Des versions binaires des composants Hadoop sont disponibles sur le site Web de chaque projet d'écosystème sous forme de tarballs. Ils peuvent être téléchargés et l'installation commencée, mais à une condition: en plus de l'auto-assemblage de packages à partir de binaires «bruts», que vous voudrez probablement exécuter, vous n'aurez aucune confiance dans la compatibilité des versions téléchargées des composants entre elles. L'option préférée est de construire avec Apache Bigtop. Bigtop vous permet de construire à partir des référentiels maven d'Apache, d'exécuter des tests et de construire des packages. Mais, ce qui est très important pour nous, Bigtop collectera les versions de composants qui seront compatibles entre elles. Nous en parlerons plus en détail ci-dessous.

Apache bigtop

Apache Bigtop est un outil pour construire, empaqueter et tester un certain nombre de
projets open source, tels que, par exemple, Hadoop et Greenplum. Bigtop a de nombreuses
versions. Au moment de la rédaction de ce document, la dernière version stable était la version 1.4,
et dans la version principale était 1.5. Différentes versions de versions utilisent différentes versions de
composants. Par exemple, pour 1.4, les composants de base Hadoop sont la version 2.8.5 et dans le maître
2.10.0. La composition des composants pris en charge change également. Quelque chose de dépassé et
non renouvelable part, et à sa place vient quelque chose de nouveau, plus en demande, et
pas nécessairement quelque chose de la famille d'Apache elle-même.

Bigtop possède également de nombreuses fourches .

Lorsque nous avons commencé à faire connaissance avec Bigtop, nous avons été principalement surpris par sa modestie, en comparaison avec d'autres projets Apache, sa prévalence et sa renommée, ainsi que par une très petite communauté. Il s'ensuit qu'il existe un minimum d'informations sur les produits et qu'une recherche de solutions aux problèmes survenus via les forums et les newsletters peut ne rien produire du tout. Au début, il s'est avéré être une tâche difficile pour nous de terminer l'assemblage du kit de distribution en raison des caractéristiques de l'outil lui-même, mais nous en parlerons un peu plus tard.

En guise de teaser, pour ceux qui ont déjà visité des projets de l'univers Linux tels que Gentoo et LFS, il peut sembler nostalgiquement agréable de travailler avec cette chose et de rappeler ces moments «révolus» où nous avons nous-mêmes recherché (ou même écrit) des ebuilds et régulièrement reconstruit avec de nouveaux patchs mozilla.

Le gros plus de Bigtop peut être considéré comme l'ouverture et la polyvalence des outils sur lesquels il est basé. Sa fondation est Gradle et Apache Maven. Gradle est raisonnablement bien connu comme l'outil pour lequel Google collecte Android. Il est flexible et, comme on dit, «testé au combat». Maven est un outil à temps plein pour la construction de projets dans Apache lui-même, et puisque la plupart de ses produits sont publiés via Maven, il ne pourrait pas s'en passer. Il vaut la peine de prêter attention au POM (modèle d'objet de projet) - un fichier xml «fondamental» avec une description de tout ce qui est nécessaire pour que Maven travaille avec votre projet, autour duquel tout le travail est construit. C'est dans
la partie Maven que surgissent certains obstacles que l'on rencontre généralement pour la première fois lors de la prise de Bigtop.

Entraine toi

Alors par où commencer? Nous allons sur la page de téléchargement et téléchargeons la dernière version stable sous forme d'archive. On y trouve également des artefacts binaires collectés par Bigtop. Soit dit en passant, des gestionnaires de packages communs, YUM et APT sont pris en charge.

Alternativement, vous pouvez 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 le "bigtop" ...

remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 40217 (delta 14), reused 10 (delta 1), pack-reused 40171
 : 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, .
 : 100% (20503/20503), .
Updating files: 100% (1998/1998), .

Le répertoire ./bigtop résultant 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étiques, pour tests de fumée, etc.
./bigtop-deploy- outils de déploiement
./bigtop-packages- configurations, scripts, correctifs pour l'assemblage, la partie principale de l'outil
./bigtop-test-framework- cadre de test
./bigtop-tests- tests eux-mêmes, stress et fumée
./bigtop_toolchain- environnement pour l'assemblage, préparation de l'environnement pour que l'outil fonctionne
./build- répertoire de travail de l'assemblage
./dl- répertoire pour les sources téléchargées
./docker- assemblage dans le docker - images, testing
./gradle- gradle config
./output - le répertoire dans lequel les artefacts d'assemblage entrent
./provisioner- provisioning

Le plus intéressant pour nous à ce stade est la configuration principale./bigtop/bigtop.bom, dans lequel nous voyons tous les composants pris en charge avec les versions. C'est ici que nous pouvons spécifier une version différente du produit (si soudain nous voulons essayer de le construire) ou une version de l'assemblage (si, par exemple, nous avons ajouté un correctif significatif).

Le sous-répertoire ./bigtop/bigtop-packages, qui est directement lié au processus d'assemblage des composants et des packages avec eux, présente également un grand intérêt .

Donc, nous avons téléchargé l'archive, décompressé ou fait un clone avec github, pouvons-nous démarrer l'assemblage?

Non, préparez d'abord l'environnement.

Préparation de l'environnement

Et ici une petite digression s'impose. Pour construire presque n'importe quel produit plus ou moins complexe, vous avez besoin d'un certain environnement - dans notre cas, c'est JDK, les mêmes bibliothèques partagées, les fichiers d'en-tête, etc., des outils, par exemple, ant, ivy2 et bien plus encore. L'une des options pour obtenir l'environnement nécessaire à Bigtop est d'installer les composants nécessaires sur l'hôte d'assemblage. Je peux me tromper dans la chronologie, mais il semble qu'à partir de la version 1.0, il y avait aussi une option de construction dans les images docker préconfigurées et accessibles, vous pouvez les trouver ici.

Quant à la préparation de l'environnement, il y a un assistant pour cela - Puppet.

Vous pouvez utiliser les commandes suivantes, le lancement se fait depuis le répertoire racine de l'
outil,./bigtop:

./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

Ou directement à travers une marionnette:

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

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

Assemblée

Que pouvons-nous essayer de collecter? La réponse à cette question donnera la sortie de la commande

./gradlew tasks

La section Tâches de package contient un certain nombre de produits qui sont les derniers artefacts de Bigtop.
Ils peuvent être identifiés par le suffixe -rpm ou -pkg-ind (en cas d'assemblage
dans docker). Dans notre cas, le plus intéressant est Hadoop.

Essayons de construire dans l'environnement de notre serveur de build:

./gradlew hadoop-rpm

Bigtop lui-même téléchargera les sources nécessaires pour un composant particulier et commencera la construction. Ainsi, l'outil est lié aux référentiels Maven et à d'autres sources, c'est-à-dire qu'il a besoin d'un accès Internet.

Dans le processus, une sortie standard est formée. Parfois, vous pouvez comprendre de lui et des messages d'erreur ce qui s'est mal passé. Et parfois, vous avez besoin de plus d'informations. Dans ce cas, cela vaut la peine d'ajouter les arguments --info ou --debug, et peut également être utile –stacktrace. Il existe un moyen pratique de générer un ensemble de données pour référence ultérieure aux listes de diffusion, la clé --scan.

Avec lui, bigtop collectera toutes les informations et les mettra en gradle, après quoi il donnera un lien,
après quoi une personne compétente pourra comprendre pourquoi le montage a échoué.
Vous devez garder à l'esprit que cette option peut rendre publiques des informations indésirables, telles que 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 les composants nécessaires à l'assemblage. En règle générale, vous pouvez résoudre le problème en créant un correctif pour corriger quelque chose dans la source, par exemple, l'adresse dans pom.xml dans le répertoire racine de la source. Cela se fait en le créant et en le plaçant dans le répertoire ./bigtop/bigtop-packages/src/common/oozie/correctif approprié , par exemple, sous la forme patch2-fix.diff.

--- a/pom.xml
+++ b/pom.xml
@@ -136,7 +136,7 @@
<repositories>
<repository>
<id>central</id>
- <url>http://repo1.maven.org/maven2</url>
+ <url>https://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>

Très probablement, au moment de lire cet article, vous n'aurez pas à faire la correction ci-dessus.

Lors de l'introduction de correctifs et de modifications dans le mécanisme d'assemblage, vous devrez peut-être «réinitialiser» l'assemblage via la 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 de l'assemblage de ce composant, après quoi l'assemblage sera à nouveau effectué. Cette fois, nous allons essayer 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
....
 
....
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é effectuée sous CentOS, mais vous pouvez également le faire sous Ubuntu:

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

En plus d'assembler des packages pour diverses distributions Linux, l'outil peut créer un référentiel avec des packages assemblés, par exemple:

./gradlew yum

Vous vous souvenez peut-être également des tests de fumée et du déploiement dans Docker.

Créez un cluster de trois nœuds:

./gradlew -Pnum_instances=3 docker-provisioner

Exécutez des tests de fumée dans un cluster de trois nœuds:

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

Supprimer le cluster:

./gradlew docker-provisioner-destroy

Obtenez les commandes de connexion à l'intérieur des conteneurs Docker:

./gradlew docker-provisioner-ssh

Afficher le statut:

./gradlew docker-provisioner-status

Vous pouvez en savoir plus sur les tâches de déploiement dans la documentation.

Si nous parlons de tests, il y en a un assez grand nombre, principalement des tests de fumée et d'intégration. Leur analyse dépasse le cadre de cet article. Je peux seulement dire que la construction du kit de distribution n'est pas aussi difficile que cela puisse paraître à première vue. Nous avons réussi à collecter et à passer tous les composants que nous utilisons dans nos produits lors des tests, et nous n'avons également eu aucun problème avec leur déploiement et leurs opérations de base dans l'environnement de test.

En plus des composants existants dans Bigtop, il est possible d'ajouter autre chose, même votre propre développement logiciel. Tout cela est parfaitement automatisé et s'inscrit dans le concept CI / CD.

Conclusion

De toute évidence, une distribution ainsi construite ne doit pas être immédiatement envoyée en production. Vous devez comprendre que s'il existe un réel besoin de construire et de maintenir votre distribution, vous devez investir financièrement et en temps.

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

Il est important de noter que le projet Bigtop lui-même doit être développé et il semble qu'aujourd'hui il n'y a pas de développement actif. De plus, la perspective de l'apparition de Hadoop 3 n'est pas claire. En passant, si vous avez un réel besoin de construire Hadoop 3, vous pouvez regarder la fourche d'Arenadata, dans laquelle, en plus des
composants standard , il existe un certain nombre de composants supplémentaires (Ranger, Knox, NiFi).

Quant à Rostelecom, Bigtop est pour nous l'une des options envisagées aujourd'hui. Que nous l'arrêtions ou non, le temps nous le dira.

annexe

Pour inclure un nouveau composant dans l'assemblage, vous devez ajouter sa description dans bigtop.bom et ./bigtop-packages. Vous pouvez essayer de le faire par analogie avec les composants existants. Essayez de le comprendre. Ce n'est pas aussi difficile qu'il y paraît à première vue.

Qu'est-ce que tu penses? Nous serons heureux 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

Apache Bigtop et le choix de la distribution Hadoop aujourd'hui