Probablemente non sexa ningún segredo que o ano pasado foi un ano de grandes cambios para Apache Hadoop. O ano pasado, Cloudera e Hortonworks fusionáronse (fundamentalmente, a adquisición desta última), e Mapr, por graves problemas financeiros, foi vendida a Hewlett Packard. E se uns anos antes, no caso das instalacións en instalacións, moitas veces había que escoller entre Cloudera e Hortonworks, hoxe, por desgraza, non temos esta opción. Outra sorpresa foi o feito de que Cloudera anunciou en febreiro deste ano que deixaría de lanzar conxuntos binarios da súa distribución no repositorio público, e agora só están dispoñibles mediante unha subscrición de pago. Por suposto, aínda é posible descargar as versións máis recentes de CDH e HDP lanzadas antes de finais de 2019, e espérase compatibilidade con elas durante un ou dous anos. Pero que facer despois? Para aqueles que pagaron previamente por unha subscrición, nada cambiou. E para aqueles que non queiran cambiar á versión de pago da distribución, pero ao mesmo tempo queren poder recibir as últimas versións dos compoñentes do clúster, así como parches e outras actualizacións, preparamos este artigo. Nel consideraremos posibles opcións para saír desta situación.
O artigo é máis unha revisión. Non conterá unha comparación de distribucións e unha análise detallada das mesmas, e non haberá receitas para instalalas e configuralas. Que pasará? Falaremos brevemente dunha distribución como Arenadata Hadoop, que con razón merece a nosa atención pola súa dispoñibilidade, moi rara hoxe en día. E despois falaremos de Vanilla Hadoop, principalmente de como se pode "cociñar" usando Apache Bigtop. Listo? Entón benvido ao gato.
Arenadata Hadoop
Este é un kit de distribución de desenvolvemento doméstico completamente novo e, ata agora, pouco coñecido. Por desgraza, polo momento en Habré só hai .
Pódese atopar máis información no oficial proxecto. As últimas versións da distribución baséanse en Hadoop 3.1.2 para a versión 3 e 2.8.5 para a versión 2.
Pódese atopar información sobre a folla de ruta .
Interfaz do xestor de clústeres Arenadata
O produto principal de Arenadata é , que se utiliza para instalar, configurar e supervisar varias solucións de software da empresa. ADCM distribúese de xeito gratuíto e a súa funcionalidade amplíase engadindo paquetes, que son un conxunto de libros de xogos ansibles. Os paquetes divídense en dous tipos: empresa e comunidade. Estes últimos están dispoñibles para a súa descarga gratuíta na páxina web de Arenadata. Tamén é posible desenvolver o seu propio paquete e conectalo a ADCM.
Para a implantación e xestión de Hadoop 3, ofrécese unha versión comunitaria do paquete xunto con ADCM, pero para Hadoop 2 só hai como alternativa. En canto aos repositorios con paquetes, están abertos ao público, poden descargarse e instalarse do xeito habitual para todos os compoñentes do clúster. En xeral, a distribución parece moi interesante. Estou seguro de que haberá quen estea afeito a solucións como Cloudera Manager e Ambari, e que lle gustará o propio ADCM. Para algúns, tamén será un gran plus que a distribución para substitución de importacións.
Se falamos das desvantaxes, serán as mesmas que para todas as outras distribucións de Hadoop. A saber:
- O chamado "bloqueo de provedores". Usando os exemplos de Cloudera e Hortonworks, xa nos demos conta de que sempre existe o risco de cambiar a política da empresa.
- Retraso significativo con respecto a Apache upstream.
Vainilla Hadoop
Como sabedes, Hadoop non é un produto monolítico, senón, de feito, toda unha galaxia de servizos ao redor do seu sistema de ficheiros distribuído HDFS. Poucas persoas terán abondo dun clúster de ficheiros. Algúns necesitan Hive, outros Presto, e despois están HBase e Phoenix; Spark úsase cada vez máis. Para a orquestración e a carga de datos, ás veces atópanse Oozie, Sqoop e Flume. E se xorde o problema da seguridade, inmediatamente vén á mente Kerberos xunto con Ranger.
No sitio web de cada un dos proxectos do ecosistema están dispoñibles versións binarias dos compoñentes de Hadoop en forma de tarballs. Podes descargalos e comezar a instalación, pero cunha condición: ademais de montar paquetes de forma independente a partir de binarios "en bruto", o que probablemente queiras facer, non terás ningunha confianza na compatibilidade das versións descargadas dos compoñentes con cada un. outra. A opción preferida é construír usando Apache Bigtop. Bigtop permitirache construír a partir de repositorios Apache Maven, realizar probas e construír paquetes. Pero, o que é moi importante para nós, Bigtop ensamblará aquelas versións de compoñentes que serán compatibles entre si. Falarémolo con máis detalle a continuación.
Apache Bigtop
Apache Bigtop é unha ferramenta para construír, empaquetar e probar unha serie de
proxectos de código aberto, como Hadoop e Greenplum. Bigtop ten moito
lanzamentos. No momento de escribir este artigo, a última versión estable era a versión 1.4,
e en master había 1.5. As diferentes versións dos lanzamentos usan versións diferentes
compoñentes. Por exemplo, para a versión 1.4, os compoñentes básicos de Hadoop teñen a versión 2.8.5 e en master
2.10.0. A composición dos compoñentes soportados tamén está cambiando. Algo anticuado e
o irrenovable vaise, e no seu lugar chega algo novo, máis demandado, e
non é necesariamente algo da propia familia Apache.
Ademais, Bigtop ten moitos .
Cando comezamos a familiarizarnos con Bigtop, en primeiro lugar sorprendeunos a súa modesta, en comparación con outros proxectos Apache, a súa prevalencia e popularidade, así como unha comunidade moi pequena. Diso dedúcese que hai información mínima sobre o produto, e buscar solucións aos problemas que xurdiron en foros e listas de correo pode non producir nada. Ao principio, resultounos unha tarefa difícil completar a montaxe completa da distribución debido ás características da propia ferramenta, pero diso falaremos un pouco máis tarde.
Como teaser, aqueles que nalgún momento estiveron interesados en proxectos do universo Linux como Gentoo e LFS poden resultar nostálxicamente agradable traballar con isto e lembrar aqueles tempos "épicos" nos que nós mesmos buscabamos (ou incluso escribimos) ebuilds e reconstruíu regularmente Mozilla con novos parches.
A gran vantaxe de Bigtop é a apertura e versatilidade das ferramentas nas que se basea. Está baseado en Gradle e Apache Maven. Gradle é bastante coñecida como a ferramenta que Google usa para construír Android. É flexible e, como din, "probado na batalla". Maven é unha ferramenta estándar para construír proxectos no propio Apache, e dado que a maioría dos seus produtos se lanzan a través de Maven, tampouco se podería facer sen ela aquí. Paga a pena prestar atención ao POM (modelo de obxectos do proxecto): o ficheiro xml "fundamental" que describe todo o necesario para que Maven traballe co seu proxecto, arredor do cal se constrúe todo o traballo. Exactamente ás
partes de Maven e hai algúns obstáculos que adoitan atopar os usuarios de Bigtop por primeira vez.
Práctica
Entón, por onde deberías comezar? Vaia á páxina de descarga e descarga a última versión estable como arquivo. Tamén podes atopar artefactos binarios recollidos por Bigtop alí. Por certo, entre os xestores de paquetes comúns, admiten YUM e APT.
Alternativamente, pode descargar a última versión estable directamente desde
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitClonación en "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), готово.O directorio ./bigtop resultante ten un aspecto así:
./bigtop-bigpetstore — aplicacións de demostración, exemplos sintéticos
./bigtop-ci - Ferramentas de CI, Jenkins
./bigtop-data-generators — xeración de datos, sintéticos, para probas de fume, etc.
./bigtop-deploy - Ferramentas de implantación
./bigtop-packages — configuracións, scripts, parches para a montaxe, a parte principal da ferramenta
./bigtop-test-framework - Marco de proba
./bigtop-tests — as propias probas, carga e fume
./bigtop_toolchain — ambiente para a montaxe, preparando o ambiente para que a ferramenta funcione
./build - Construír o directorio de traballo
./dl — directorio para fontes descargadas
./docker - creación de imaxes docker, probas
./gradle - configuración de gradle
./output – o directorio onde van os artefactos de construción
./provisioner - aprovisionamento
O máis interesante para nós nesta fase é a configuración principal ./bigtop/bigtop.bom, no que vemos todos os compoñentes compatibles con versións. Aquí é onde podemos especificar unha versión diferente do produto (se de súpeto queremos tentar construílo) ou unha versión de compilación (se, por exemplo, engadimos un parche significativo).
O subdirectorio tamén é de gran interese ./bigtop/bigtop-packages, que está directamente relacionado co proceso de ensamblaxe de compoñentes e paquetes con eles.
Entón, descargamos o arquivo, desempaquetámolo ou fixemos un clon de github, podemos comezar a construír?
Non, primeiro preparemos o medio ambiente.
Preparando o Medio Ambiente
E aquí necesitamos un pequeno retiro. Para construír case calquera produto máis ou menos complexo, necesitas un ambiente determinado; no noso caso, este é o JDK, as mesmas bibliotecas compartidas, ficheiros de cabeceira, etc., ferramentas, por exemplo, ant, ivy2 e moito máis. Unha das opcións para obter o ambiente que necesitas para Bigtop é instalar os compoñentes necesarios no servidor de compilación. Podería equivocarme na cronoloxía, pero parece que coa versión 1.0 tamén había unha opción para construír imaxes de Docker preconfiguradas e accesibles, que se pode atopar aquí.
En canto á preparación do medio ambiente, hai un asistente para iso - Títeres.
Podes usar os seguintes comandos, executados dende o directorio raíz
ferramenta, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Ou directamente a través de títeres:
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"Desafortunadamente, as dificultades poden xurdir xa nesta fase. O consello xeral aquí é usar unha distribución compatible, actualizada no host de compilación ou probar a ruta docker.
Asemblea
Que podemos tentar recoller? A resposta a esta pregunta dará a saída do comando
./gradlew tasks
Na sección de tarefas do paquete hai unha serie de produtos que son artefactos finais de Bigtop.
Pódense identificar co sufixo -rpm ou -pkg-ind (no caso de edificio
en docker). No noso caso, o máis interesante é Hadoop.
Imos tentar construír no entorno do noso servidor de compilación:
./gradlew hadoop-rpmO propio Bigtop descargará as fontes necesarias para un compoñente específico e comezará a montar. Así, o funcionamento da ferramenta depende dos repositorios de Maven e doutras fontes, é dicir, require acceso a Internet.
Durante a operación, xérase unha saída estándar. Ás veces, iso e as mensaxes de erro poden axudarche a comprender o que pasou mal. E ás veces necesitas obter información adicional. Neste caso paga a pena engadir argumentos --info ou --debug, e tamén pode ser útil –stacktrace. Hai un xeito cómodo de xerar un conxunto de datos para o acceso posterior ás listas de correo, a clave --scan.
Coa súa axuda, bigtop recollerá toda a información e poñeraa en gradle, despois de que fornecerá unha ligazón,
ao seguir o cal, unha persoa competente poderá entender por que fallou a asemblea.
Teña en conta que esta opción pode expoñer información que non quere, como nomes de usuario, nodos, variables de ambiente, etc., así que teña coidado.
Moitas veces os erros son consecuencia da incapacidade de obter os compoñentes necesarios para a montaxe. Normalmente, pode solucionar o problema creando un parche para corrixir algo nas fontes, por exemplo, os enderezos en pom.xml no directorio raíz das fontes. Isto faise creándoo e colocándoo no directorio axeitado ./bigtop/bigtop-packages/src/common/oozie/ parche, por exemplo, no formulario parche2-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>
O máis probable é que, no momento de ler este artigo, non teñas que reparar o anterior.
Cando introduza algún parche e cambios no mecanismo de montaxe, é posible que necesite "reiniciar" o conxunto mediante o comando de limpeza:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedEsta operación fará retroceder todos os cambios realizados na montaxe deste compoñente, despois de que a montaxe realizarase de novo. Nesta ocasión tentaremos construír o proxecto nunha imaxe 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 executedA compilación realizouse en CentOS, pero tamén se pode facer en Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indAdemais de construír paquetes para varias distribucións de Linux, a ferramenta pode crear un repositorio con paquetes compilados, por exemplo:
./gradlew yumTamén podes lembrar as probas de fume e a implantación en Docker.
Crea un clúster de tres nodos:
./gradlew -Pnum_instances=3 docker-provisionerRealiza probas de fume nun grupo de tres nodos:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerEliminar un clúster:
./gradlew docker-provisioner-destroyObter comandos para conectarse dentro dos contedores docker:
./gradlew docker-provisioner-sshMostrar estado:
./gradlew docker-provisioner-statusPodes ler máis sobre as tarefas de implantación na documentación.
Se falamos de probas, hai un número bastante grande delas, principalmente de fume e integración. A súa análise está fóra do alcance deste artigo. Déixeme dicir que montar un kit de distribución non é unha tarefa tan difícil como podería parecer a primeira vista. Conseguimos montar e superar as probas de todos os compoñentes que utilizamos na nosa produción, e tampouco tivemos problemas para implantalos e realizar operacións básicas no entorno de proba.
Ademais dos compoñentes existentes en Bigtop, é posible engadir calquera outra cousa, incluso o seu propio desenvolvemento de software. Todo isto está perfectamente automatizado e encaixa no concepto CI/CD.
Conclusión
Obviamente, a distribución compilada deste xeito non debe enviarse inmediatamente á produción. Debes entender que se hai unha necesidade real de construír e apoiar a túa distribución, entón tes que investir diñeiro e tempo nisto.
Non obstante, en combinación co enfoque correcto e un equipo profesional, é moi posible prescindir de solucións comerciais.
É importante ter en conta que o proxecto Bigtop en si necesita desenvolvemento e non parece estar desenvolvido activamente hoxe. Tampouco está clara a perspectiva de que apareza Hadoop 3. Por certo, se tes unha necesidade real de construír Hadoop 3, podes consultar de Arenadata, na que, ademais de estándar
Hai unha serie de compoñentes adicionais (Ranger, Knox, NiFi).
En canto a Rostelecom, para nós Bigtop é unha das opcións que se barallan na actualidade. Se o escollemos ou non, o tempo dirá.
Apéndice
Para incluír un novo compoñente no conxunto, cómpre engadir a súa descrición a bigtop.bom e ./bigtop-packages. Podes tentar facelo por analoxía cos compoñentes existentes. Tenta descifralo. Non é tan difícil como parece a primeira vista.
Que opinas? Estaremos encantados de ver a túa opinión nos comentarios e grazas pola túa atención!
O artigo foi preparado polo equipo de xestión de datos de Rostelecom
Fonte: www.habr.com