🧖🏼 🤶🏼 🤘🏽 Apache Bigtop y la elección de la distribución de Hadoop hoy 🌩️ 🏈 👩🏽‍🚒

Probablemente no sea ningún secreto que el año pasado fue un año de grandes cambios para Apache Hadoop. El año pasado, Cloudera y Hortonworks se fusionaron (esencialmente una adquisición del segundo), y Mapr, debido a serios problemas financieros, fue vendida a Hewlett Packard. Y si unos años antes, en el caso de las instalaciones locales, la elección a menudo tenía que hacerse entre Cloudera y Hortonworks, hoy, por desgracia, no teníamos esta opción. Otra sorpresa fue el hecho de que desde febrero de este año, Cloudera anunció la finalización del lanzamiento de los ensamblajes binarios de su distribución en un repositorio público, y ahora están disponibles solo mediante suscripción paga. Por supuesto, la capacidad de descargar las últimas versiones de CDH y HDP, lanzadas antes de finales de 2019, todavía está allí, y se espera que la soporte durante uno o dos años. ¿Pero qué hacer a continuación? Para esos,quien previamente pagó la suscripción, nada ha cambiado. Y para aquellos que no desean cambiar a una versión paga del kit de distribución, pero desean poder obtener las últimas versiones de los componentes del clúster, así como parches y otras actualizaciones, preparamos este artículo. En él, consideraremos posibles formas de salir de esta situación.

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

Arenadata Hadoop

Esta es una distribución completamente nueva y, hasta ahora, poco conocida del desarrollo interno. Desafortunadamente, por el momento solo hay un artículo sobre Habré al respecto .

Se puede encontrar más información en el sitio web oficial del proyecto. Las últimas distribuciones se basan en Hadoop 3.1.2 para la versión 3 y 2.8.5 para la versión 2.

La información sobre la hoja de ruta se puede encontrar aquí .

Interfaz de Arenadata Cluster Manager El

producto clave de Arenadata es Arenadata Cluster Manager (ADCM), que se utiliza para instalar, configurar y monitorear varias soluciones de software de la empresa. ADCM es gratuito y su funcionalidad se expande al agregarle paquetes, que son un conjunto de libros de jugadas ansibles. Los paquetes se dividen en dos tipos: empresa y comunidad. Estos últimos están disponibles para descarga gratuita desde Arenadata. También es posible desarrollar su propio paquete y conectarlo a ADCM.

Para la implementación y administración de Hadoop 3, se ofrece una versión comunitaria del paquete junto con ADCM, y para hadoop 2 solo hay Apache Ambaricomo alternativa. En cuanto a los repositorios con paquetes, están abiertos al acceso público, se pueden descargar e instalar de la manera habitual para todos los componentes del clúster. En general, la distribución se ve muy interesante. Estoy seguro de que hay quienes están acostumbrados a soluciones como Cloudera Manager y Ambari, y a quienes les gustará ADCM. Para algunos, el hecho de que el kit de distribución esté incluido en el registro del software de sustitución de importaciones será una gran ventaja .

Si hablamos de los contras, serán los mismos que para todas las demás distribuciones de Hadoop. A saber:

El llamado "bloqueo de proveedores". Utilizando los ejemplos de Cloudera y Hortonworks, ya nos dimos cuenta de que siempre existe el riesgo de cambiar las políticas de la compañía.
Retraso significativo detrás de Apache aguas arriba.

Hadoop de vainilla

Como saben, Hadoop no es un producto monolítico, sino que, de hecho, es una galaxia completa de servicios en torno a su sistema de archivos HDFS distribuido. Pocas personas necesitarán un grupo de archivos. Uno necesita Hive, y el otro Presto, y hay HBase y Phoenix, Spark se usa cada vez más. Oozie, Sqoop y Flume a veces se encuentran para orquestar y descargar datos. Y si surge el problema de seguridad, Kerberos junto con Ranger se recuerda de inmediato.

Las versiones binarias de los componentes de Hadoop están disponibles en el sitio web de cada proyecto de ecosistema en forma de tarballs. Se pueden descargar e iniciar la instalación, pero con una condición: además del autoensamblaje de paquetes a partir de archivos binarios "sin procesar", que probablemente desee ejecutar, no tendrá ninguna confianza en la compatibilidad de las versiones descargadas de los componentes entre sí. La opción preferida es construir usando Apache Bigtop. Bigtop le permite construir desde los repositorios Maven de Apache, ejecutar pruebas y crear paquetes. Pero, lo cual es muy importante para nosotros, Bigtop recopilará esas versiones de componentes que serán compatibles entre sí. Hablaremos de ello con más detalle a continuación.

Apache bigtop

Apache Bigtop es una herramienta para construir, empaquetar y probar una serie de
proyectos de código abierto, como, por ejemplo, Hadoop y Greenplum. Bigtop tiene muchos
lanzamientos. En el momento de escribir este artículo, la última versión estable era la versión 1.4,
y en master era la 1.5. Las diferentes versiones de lanzamientos usan diferentes versiones de
componentes. Por ejemplo, para 1.4, los componentes principales de Hadoop son la versión 2.8.5 y en master
2.10.0. La composición de los componentes compatibles también está cambiando. Algo obsoleto y
no renovable se va, y en su lugar viene algo nuevo, más demandado, y
no necesariamente algo de la familia de Apache.

Bigtop también tiene muchos tenedores .

Cuando comenzamos a conocer Bigtop, nos sorprendió principalmente su modestia, en comparación con otros proyectos de Apache, prevalencia y fama, así como una comunidad muy pequeña. De ello se deduce que hay un mínimo de información del producto, y una búsqueda de soluciones a los problemas que han surgido a través de foros y boletines informativos puede no producir nada en absoluto. Al principio, resultó ser una tarea difícil para nosotros completar el ensamblaje del kit de distribución debido a las características de la herramienta en sí, pero hablaremos de esto un poco más adelante.

Como adelanto, para aquellos que una vez visitaron proyectos del universo Linux como Gentoo y LFS, puede parecer nostálgicamente agradable trabajar con esto y recordar esos tiempos "pasados" cuando nosotros mismos buscamos (o incluso escribimos) ebuilds. y regularmente reconstruido con nuevos parches de mozilla.

La gran ventaja de Bigtop puede considerarse la apertura y versatilidad de las herramientas en las que se basa. Su fundación es Gradle y Apache Maven. Gradle es razonablemente conocida como la herramienta para la que Google recopila Android. Es flexible y, como dicen, "probado en la batalla". Maven es una herramienta de tiempo completo para construir proyectos en el propio Apache, y dado que la mayoría de sus productos se lanzan a través de Maven, no podría funcionar sin ella. Vale la pena prestar atención a POM (modelo de objeto de proyecto), un archivo xml "fundamental" con una descripción de todo lo necesario para que Maven trabaje con su proyecto, alrededor del cual se construye todo el trabajo. Es en
la parte de Maven donde surgen algunos obstáculos que generalmente se encuentran por primera vez cuando toman Bigtop.

Práctica

Entonces, ¿por dónde empezar? Vamos a la página de descarga y descargamos la última versión estable como archivo. Los artefactos binarios recopilados por Bigtop también se pueden encontrar allí. Por cierto, de los gestores de paquetes comunes, YUM y APT son compatibles.

Alternativamente, puede descargar la última versión estable directamente desde
github:

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

Clonación en el "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 directorio ./bigtop resultante se parece a esto:

./bigtop-bigpetstore- aplicaciones de demostración, ejemplos sintéticos
./bigtop-ci- herramientas de CI, jenkins
./bigtop-data-generators- generación de datos, sintéticos, para pruebas de humo, etc.
./bigtop-deploy- herramientas de implementación
./bigtop-packages- configuraciones, scripts, parches para el ensamblaje, la parte principal de la herramienta
./bigtop-test-framework- marco de prueba
./bigtop-tests- pruebas en sí mismas, estrés y humo
./bigtop_toolchain- entorno para el ensamblaje, preparación del entorno para que la herramienta funcione
./build- directorio de trabajo del ensamblaje
./dl- directorio para las fuentes descargadas
./docker- ensamblaje en docker- imágenes, pruebas
./gradle- gradle config
./output - el directorio en el que entran los artefactos de ensamblaje
./provisioner- aprovisionamiento

Lo más interesante para nosotros en esta etapa es la configuración principal./bigtop/bigtop.bom, en el que vemos todos los componentes compatibles con versiones. Aquí es donde podemos especificar una versión diferente del producto (si de repente queremos intentar construirlo) o una versión del ensamblaje (si, por ejemplo, agregamos un parche significativo).

También es de gran interés el subdirectorio ./bigtop/bigtop-packages, que está directamente relacionado con el proceso de ensamblaje de componentes y paquetes con ellos.

Entonces, descargamos el archivo, lo descomprimimos o hicimos un clon con github, ¿podemos comenzar el ensamblaje?

No, primero prepara el medio ambiente.

Preparación del medio ambiente

Y aquí se necesita una pequeña digresión. Para construir casi cualquier producto más o menos complejo, necesita un determinado entorno; en nuestro caso, es JDK, las mismas bibliotecas compartidas, archivos de encabezado, etc., herramientas, por ejemplo, ant, ivy2 y mucho más. Una de las opciones para obtener el entorno necesario para Bigtop es instalar los componentes necesarios en el host de ensamblaje. Puedo estar equivocado en la cronología, pero parece que a partir de la versión 1.0 también había una opción de compilación en imágenes acopladas preconfiguradas y accesibles, puede encontrarlas aquí.

En cuanto a la preparación del medio ambiente, hay un asistente para esto: Puppet.

Puede usar los siguientes comandos, el lanzamiento se realiza desde el directorio raíz de la
herramienta,./bigtop:

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

O directamente a través de la marioneta:

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, las dificultades pueden surgir ya en esta etapa. El consejo general aquí es usar una distribución compatible, actualizada en el host de compilación, o probar la ruta con docker.

Montaje

¿Qué podemos intentar recolectar? La respuesta a esta pregunta dará el resultado del comando

./gradlew tasks

La sección Tareas del paquete tiene una serie de productos que son los artefactos finales de Bigtop.
Se pueden identificar por el sufijo -rpm o -pkg-ind (en caso de ensamblaje
en docker). En nuestro caso, lo más interesante es Hadoop.

Intentemos construir en el entorno de nuestro servidor de compilación:

./gradlew hadoop-rpm

Bigtop mismo descargará las fuentes necesarias necesarias para un componente en particular y comenzará a construir. Por lo tanto, la herramienta está vinculada a los repositorios de Maven y otras fuentes, es decir, necesita acceso a Internet.

En el proceso, se forma una salida estándar. A veces puedes entender de él y los mensajes de error lo que salió mal. Y a veces necesitas más información. En este caso, vale la pena agregar los argumentos --info o --debug, y también puede ser útil –stacktrace. Hay una manera conveniente de generar un conjunto de datos para referencia posterior a las listas de correo, la clave --scan.

Con él, bigtop recopilará toda la información y la pondrá en gradle, después de lo cual dará un enlace,
después de lo cual una persona competente podrá entender por qué falló la asamblea.
Debe tener en cuenta que esta opción puede hacer que la información sea indeseable para usted, como nombres de usuario, nodos, variables de entorno, etc., así que tenga cuidado.

A menudo, los errores son el resultado de la imposibilidad de obtener los componentes necesarios para el ensamblaje. Como regla general, puede solucionar el problema creando un parche para arreglar algo en la fuente, por ejemplo, la dirección en pom.xml en el directorio raíz de la fuente. Esto se hace al crearlo y colocarlo en el directorio de ./bigtop/bigtop-packages/src/common/oozie/parches apropiado , por ejemplo, en forma de 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>

Lo más probable es que, al momento de leer este artículo, la corrección anterior no tenga que hacerlo usted mismo.

Al introducir parches y ediciones en el mecanismo de ensamblaje, es posible que deba "restablecer" el ensamblaje mediante el comando de limpieza:

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

Esta operación revertirá todos los cambios en el ensamblaje de este componente, después de lo cual el ensamblaje se realizará nuevamente. Esta vez intentaremos construir el proyecto en una imagen acoplable:

./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 compilación se realizó en CentOS, pero también puede hacerlo en Ubuntu:

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

Además de ensamblar paquetes para varias distribuciones de Linux, la herramienta puede crear un repositorio con paquetes ensamblados, por ejemplo:

./gradlew yum

También puede recordar las pruebas de humo y el despliegue en la ventana acoplable.

Cree un grupo de tres nodos:

./gradlew -Pnum_instances=3 docker-provisioner

Ejecute pruebas de humo en un grupo de tres nodos:

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

Eliminar clúster:

./gradlew docker-provisioner-destroy

Obtenga comandos para conectarse dentro de los contenedores docker:

./gradlew docker-provisioner-ssh

Mostrar estado:

./gradlew docker-provisioner-status

Puede leer más sobre las tareas de implementación en la documentación.

Si hablamos de pruebas, entonces hay una gran cantidad de ellas, principalmente de humo y de integración. Su análisis está más allá del alcance de este artículo. Solo puedo decir que construir el kit de distribución no es tan difícil como podría parecer a primera vista. Logramos recolectar y pasar todos los componentes que usamos en nuestros productos en el producto, y tampoco tuvimos problemas con su implementación y realización de operaciones básicas en un entorno de prueba.

Además de los componentes existentes en Bigtop, es posible agregar algo más, incluso su propio desarrollo de software. Todo esto está perfectamente automatizado y se ajusta al concepto de CI / CD.

Conclusión

Obviamente, una distribución construida de esta manera no debe enviarse inmediatamente a producción. Debe comprender que si existe una necesidad real de construir y mantener su distribución, entonces necesita invertir financieramente y tiempo.

Sin embargo, en combinación con el enfoque correcto y un equipo profesional, es bastante posible prescindir de soluciones comerciales.

Es importante tener en cuenta que el proyecto Bigtop en sí mismo necesita ser desarrollado y parece que hoy en día no hay un desarrollo activo en él. Además, la perspectiva de la aparición de Hadoop 3 en él no está clara. Por cierto, si tiene una necesidad real de construir Hadoop 3, puede ver la bifurcación de Arenadata, en la que, además de los
componentes estándar , hay una serie de componentes adicionales (Ranger, Knox, NiFi).

En cuanto a Rostelecom, para nosotros Bigtop es una de las opciones consideradas hoy. Ya sea que lo paremos o no, el tiempo lo dirá.

Apéndice

Para incluir un nuevo componente en el ensamblaje, debe agregar su descripción en bigtop.bom y ./bigtop-packages. Puede intentar hacer esto por analogía con los componentes existentes. Intenta resolverlo. No es tan difícil como parece a primera vista.

¿Qué piensas? Estaremos encantados de ver tu opinión en los comentarios y ¡gracias por tu atención!

Este artículo fue preparado por el equipo de gestión de datos de Rostelecom

Apache Bigtop y la elección de la distribución de Hadoop hoy