Probablement no és cap secret que l'any passat va ser un any de grans canvis per a Apache Hadoop. L'any passat es van fusionar Cloudera i Hortonworks (essencialment, l'adquisició d'aquesta darrera), i Mapr, per greus problemes financers, es va vendre a Hewlett Packard. I si uns anys abans, en el cas de les instal·lacions on-premises, sovint s'havia de triar entre Cloudera i Hortonworks, avui, per desgràcia, no tenim aquesta opció. Una altra sorpresa va ser el fet que Cloudera va anunciar el febrer d'aquest any que deixaria de llançar conjunts binaris de la seva distribució al repositori públic, i que ara només estan disponibles mitjançant una subscripció de pagament. Per descomptat, encara és possible baixar les últimes versions de CDH i HDP publicades abans de finals de 2019, i s'espera que tinguin suport durant un o dos anys. Però què fer després? Per a aquells que abans van pagar una subscripció, res ha canviat. I per a aquells que no volen canviar a la versió de pagament de la distribució, però al mateix temps volen poder rebre les últimes versions dels components del clúster, així com pedaços i altres actualitzacions, hem preparat aquest article. En ella considerarem possibles opcions per sortir d'aquesta situació.
L'article és més aviat una ressenya. No contindrà una comparació de distribucions i una anàlisi detallada de les mateixes, i no hi haurà receptes per instal·lar-les i configurar-les. Què passarà? Parlarem breument d'una distribució com Arenadata Hadoop, que amb raó mereix la nostra atenció per la seva disponibilitat, que avui dia és molt rara. I després parlarem de Vanilla Hadoop, principalment de com es pot "cuinar" amb Apache Bigtop. Preparat? Aleshores, benvingut al gat.
Arenadata Hadoop
Es tracta d'un kit de distribució de desenvolupament domèstic completament nou i, fins ara, poc conegut. Malauradament, de moment a Habré només n'hi ha .
Podeu trobar més informació a l'oficial projecte. Les últimes versions de la distribució es basen en Hadoop 3.1.2 per a la versió 3 i 2.8.5 per a la versió 2.
Podeu trobar informació sobre el full de ruta .
Interfície del gestor de clúster Arenadata
El producte principal d'Arenadata és , que s'utilitza per instal·lar, configurar i supervisar diverses solucions de programari de l'empresa. ADCM es distribueix de manera gratuïta i la seva funcionalitat s'amplia afegint paquets, que són un conjunt de llibres de jocs ansibles. Els paquets es divideixen en dos tipus: empresa i comunitat. Aquests últims es poden descarregar gratuïtament des del web d'Arenadata. També és possible desenvolupar el vostre propi paquet i connectar-lo a ADCM.
Per al desplegament i la gestió de Hadoop 3, s'ofereix una versió comunitària del paquet juntament amb ADCM, però per a Hadoop 2 només hi ha com a alternativa. Pel que fa als repositoris amb paquets, són oberts a l'accés públic, es poden descarregar i instal·lar de la manera habitual per a tots els components del clúster. En general, la distribució sembla molt interessant. Estic segur que hi haurà qui estigui acostumat a solucions com Cloudera Manager i Ambari, i que li agradarà el mateix ADCM. Per a alguns, també serà un gran avantatge que la distribució per a la substitució d'importacions.
Si parlem dels inconvenients, seran els mateixos que per a totes les altres distribucions de Hadoop. És a dir:
- L'anomenat "bloqueig de venedor". Utilitzant els exemples de Cloudera i Hortonworks, ja ens hem adonat que sempre hi ha el risc de canviar la política de l'empresa.
- Un retard significatiu enrere d'Apache aigües amunt.
Vainilla Hadoop
Com sabeu, Hadoop no és un producte monolític, sinó, de fet, tota una galàxia de serveis al voltant del seu sistema de fitxers distribuït HDFS. Poques persones en tindran prou amb un clúster de fitxers. Alguns necessiten Hive, altres Presto, i després hi ha HBase i Phoenix; Spark s'utilitza cada cop més. Per a l'orquestració i la càrrega de dades, de vegades es troben Oozie, Sqoop i Flume. I si sorgeix el problema de la seguretat, de seguida ve al cap Kerberos juntament amb Ranger.
Les versions binàries dels components Hadoop estan disponibles al lloc web de cadascun dels projectes d'ecosistema en forma de tarballs. Podeu descarregar-los i començar la instal·lació, però amb una condició: a més de muntar de manera independent paquets de binaris "crues", cosa que probablement vulgueu fer, no tindreu cap confiança en la compatibilitat de les versions descarregades dels components amb cadascuna. altres. L'opció preferida és construir amb Apache Bigtop. Bigtop us permetrà crear a partir de repositoris Apache maven, executar proves i crear paquets. Però, el que és molt important per a nosaltres, Bigtop muntarà aquelles versions de components que seran compatibles entre si. A continuació en parlarem amb més detall.
Apache Bigtop
Apache Bigtop és una eina per crear, empaquetar i provar diversos
projectes de codi obert, com Hadoop i Greenplum. Bigtop en té molt
llançaments. En el moment d'escriure aquest escrit, l'última versió estable era la versió 1.4,
i en màster hi havia 1.5. Les diferents versions dels llançaments utilitzen diferents versions
components. Per exemple, per a la versió 1.4, els components bàsics d'Hadoop tenen la versió 2.8.5 i en master
2.10.0. La composició dels components suportats també està canviant. Alguna cosa antiquat i
l'irrenovable se'n va, i en el seu lloc ve alguna cosa nova, més demandada, i
no és necessàriament una cosa de la pròpia família Apache.
A més, Bigtop en té molts .
Quan vam començar a familiaritzar-nos amb Bigtop, ens va sorprendre en primer lloc la seva modestia, en comparació amb altres projectes Apache, la prevalença i la popularitat, així com una comunitat molt petita. D'això es dedueix que hi ha una informació mínima sobre el producte, i la recerca de solucions als problemes sorgits als fòrums i llistes de correu pot no donar res. Al principi, va resultar ser una tasca difícil per a nosaltres completar el muntatge complet de la distribució a causa de les característiques de l'eina en si, però d'això en parlarem una mica més endavant.
Com a teaser, aquells que en algun moment estaven interessats en projectes de l'univers Linux com Gentoo i LFS poden trobar nostàlgicament agradable treballar amb aquesta cosa i recordar aquells temps "èpics" en què nosaltres mateixos buscàvem (o fins i tot escrivint) ebuilds i reconstruïa regularment Mozilla amb nous pegats.
El gran avantatge de Bigtop és l'obertura i versatilitat de les eines en què es basa. Es basa en Gradle i Apache Maven. Gradle és força coneguda com l'eina que Google utilitza per crear Android. És flexible i, com diuen, "provat a la batalla". Maven és una eina estàndard per crear projectes al mateix Apache, i com que la majoria dels seus productes es publiquen a través de Maven, tampoc no es podria fer sense aquí. Val la pena parar atenció al POM (model d'objectes del projecte): el fitxer xml "fonamental" que descriu tot el necessari perquè Maven pugui treballar amb el vostre projecte, al voltant del qual es construeix tot el treball. Exactament a les
parts de Maven i hi ha alguns obstacles que solen trobar els usuaris de Bigtop per primera vegada.
Pràctica
Llavors, per on hauries de començar? Aneu a la pàgina de descàrrega i descarregueu la darrera versió estable com a arxiu. També hi podeu trobar artefactes binaris recollits per Bigtop. Per cert, entre els gestors de paquets comuns, s'admeten YUM i APT.
Alternativament, podeu descarregar l'última versió estable directament des de
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitClonació a "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), готово.El directori ./bigtop resultant té un aspecte semblant a això:
./bigtop-bigpetstore — aplicacions de demostració, exemples sintètics
./bigtop-ci - Eines CI, Jenkins
./bigtop-data-generators — generació de dades, sintètics, per a proves de fum, etc.
./bigtop-deploy - Eines de desplegament
./bigtop-packages — configuracions, scripts, pedaços per al muntatge, la part principal de l'eina
./bigtop-test-framework - Marc de prova
./bigtop-tests — les proves en si, càrrega i fum
./bigtop_toolchain — entorn de muntatge, preparació de l'entorn perquè l'eina funcioni
./build - crear un directori de treball
./dl — directori de fonts descarregades
./docker — creació d'imatges docker, proves
./gradle - configuració de gradle
./output – el directori on van els artefactes de construcció
./provisioner - aprovisionament
El més interessant per a nosaltres en aquesta etapa és la configuració principal ./bigtop/bigtop.bom, on veiem tots els components compatibles amb versions. Aquí és on podem especificar una versió diferent del producte (si de sobte volem provar de construir-lo) o una versió de compilació (si, per exemple, hem afegit un pedaç important).
El subdirectori també és de gran interès ./bigtop/bigtop-packages, que està directament relacionada amb el procés de muntatge de components i paquets amb ells.
Així doncs, vam descarregar l'arxiu, el vam desempaquetar o vam fer un clon des de github, podem començar a construir-lo?
No, primer preparem l'entorn.
Preparant el Medi Ambient
I aquí necessitem una petita retirada. Per crear gairebé qualsevol producte més o menys complex, necessiteu un entorn determinat; en el nostre cas, aquest és el JDK, les mateixes biblioteques compartides, fitxers de capçalera, etc., eines, per exemple, ant, ivy2 i molt més. Una de les opcions per obtenir l'entorn que necessiteu per a Bigtop és instal·lar els components necessaris a l'amfitrió de compilació. Podria equivocar-me en la cronologia, però sembla que amb la versió 1.0 també hi havia una opció per incorporar imatges de Docker preconfigurades i accessibles, que es poden trobar aquí.
Pel que fa a la preparació de l'entorn, hi ha un assistent per a això: Titella.
Podeu utilitzar les ordres següents, executades des del directori arrel
eina, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
O directament a través de titella:
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"Malauradament, ja poden sorgir dificultats en aquesta etapa. El consell general aquí és utilitzar una distribució compatible, actualitzada a l'amfitrió de compilació, o provar la ruta de Docker.
assemblea
Què podem intentar recollir? La resposta a aquesta pregunta la donarà la sortida de l'ordre
./gradlew tasks
A la secció de tasques del paquet hi ha una sèrie de productes que són artefactes finals de Bigtop.
Es poden identificar amb el sufix -rpm o -pkg-ind (en el cas de l'edifici
al docker). En el nostre cas, el més interessant és Hadoop.
Intentem construir a l'entorn del nostre servidor de compilació:
./gradlew hadoop-rpmEl mateix Bigtop descarregarà les fonts necessàries per a un component específic i començarà el muntatge. Així, el funcionament de l'eina depèn dels repositoris Maven i altres fonts, és a dir, requereix accés a Internet.
Durant el funcionament, es genera una sortida estàndard. De vegades, això i els missatges d'error us poden ajudar a entendre què ha fallat. I de vegades cal obtenir informació addicional. En aquest cas, val la pena afegir arguments --info o --debug, i també pot ser útil –stacktrace. Hi ha una manera convenient de generar un conjunt de dades per a l'accés posterior a les llistes de correu, la clau --scan.
Amb la seva ajuda, bigtop recopilarà tota la informació i la posarà a gradle, després del qual proporcionarà un enllaç,
a continuació, una persona competent podrà entendre per què va fallar l'assemblea.
Tingueu en compte que aquesta opció pot exposar informació que no voleu, com ara noms d'usuari, nodes, variables d'entorn, etc., així que aneu amb compte.
Sovint, els errors són conseqüència de la incapacitat d'obtenir els components necessaris per al muntatge. Normalment, podeu solucionar el problema creant un pedaç per solucionar alguna cosa a les fonts, per exemple, adreces a pom.xml al directori arrel de les fonts. Això es fa creant-lo i col·locant-lo al directori corresponent ./bigtop/bigtop-packages/src/common/oozie/ pegat, per exemple, en el formulari 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>
El més probable és que, en el moment de llegir aquest article, no haureu de solucionar-ho vosaltres mateixos.
Quan introduïu pedaços i canvis al mecanisme de muntatge, és possible que hàgiu de "restablir" el conjunt mitjançant l'ordre de neteja:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedAquesta operació farà retrocedir tots els canvis al muntatge d'aquest component, després del qual es tornarà a realitzar el muntatge. Aquesta vegada intentarem construir el projecte en una imatge de 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 executedLa construcció es va realitzar amb CentOS, però també es pot fer amb Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indA més de crear paquets per a diverses distribucions de Linux, l'eina pot crear un repositori amb paquets compilats, per exemple:
./gradlew yumTambé podeu recordar les proves de fum i el desplegament a Docker.
Creeu un clúster de tres nodes:
./gradlew -Pnum_instances=3 docker-provisionerExecuteu proves de fum en un grup de tres nodes:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerSuprimir un clúster:
./gradlew docker-provisioner-destroyObteniu ordres per connectar-vos dins dels contenidors Docker:
./gradlew docker-provisioner-sshMostra l'estat:
./gradlew docker-provisioner-statusPodeu obtenir més informació sobre les tasques de desplegament a la documentació.
Si parlem de proves, n'hi ha força nombroses, principalment de fum i d'integració. La seva anàlisi està fora de l'abast d'aquest article. Permeteu-me dir que muntar un kit de distribució no és una tasca tan difícil com podria semblar a primera vista. Vam aconseguir muntar i passar proves de tots els components que utilitzem a la nostra producció, i tampoc vam tenir problemes per desplegar-los i realitzar operacions bàsiques en l'entorn de prova.
A més dels components existents a Bigtop, és possible afegir qualsevol altra cosa, fins i tot el vostre propi desenvolupament de programari. Tot això està perfectament automatitzat i s'adapta al concepte CI/CD.
Conclusió
Evidentment, la distribució compilada d'aquesta manera no s'ha d'enviar immediatament a producció. Heu d'entendre que si hi ha una necessitat real de construir i donar suport a la vostra distribució, heu d'invertir diners i temps en això.
Tanmateix, en combinació amb l'enfocament adequat i un equip professional, és molt possible prescindir de solucions comercials.
És important tenir en compte que el projecte Bigtop en si necessita desenvolupament i no sembla que es desenvolupi activament avui dia. La perspectiva que hi aparegui Hadoop 3 tampoc no està clara. Per cert, si teniu una necessitat real de construir Hadoop 3, podeu mirar d'Arenadata, en què, a més d'estàndard
Hi ha una sèrie de components addicionals (Ranger, Knox, NiFi).
Pel que fa a Rostelecom, per a nosaltres Bigtop és una de les opcions que es plantegen avui dia. Si ho triem o no, el temps ho dirà.
Apèndix
Per incloure un component nou al conjunt, n'heu d'afegir la descripció a bigtop.bom i ./bigtop-packages. Podeu provar de fer-ho per analogia amb els components existents. Intenta esbrinar-ho. No és tan difícil com sembla a primera vista.
Què penses? Estarem encantats de veure la teva opinió als comentaris i gràcies per la teva atenció!
L'article va ser preparat per l'equip de gestió de dades de Rostelecom
Font: www.habr.com