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

Apache Bigtop y la elección de una 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 (en esencia, la adquisición de este último) y Mapr, debido a graves problemas financieros, se vendió a Hewlett Packard. Y si hace unos años, en el caso de las instalaciones locales, a menudo había que elegir entre Cloudera y Hortonworks, hoy, lamentablemente, no tenemos esa opción. Otra sorpresa fue el hecho de que Cloudera anunció en febrero de este año que dejaría de publicar conjuntos binarios de su distribución en el repositorio público, y que ahora están disponibles sólo mediante una suscripción paga. Por supuesto, todavía es posible descargar las últimas versiones de CDH y HDP lanzadas antes de finales de 2019, y se espera que sean compatibles durante uno o dos años. ¿Pero qué hacer a continuación? Para aquellos que previamente pagaron una suscripción, nada ha cambiado. Y para aquellos que no quieran cambiar a la versión paga de la distribución, pero al mismo tiempo quieran poder recibir las últimas versiones de los componentes del clúster, así como parches y otras actualizaciones, hemos preparado este artículo. En él consideraremos posibles opciones para salir de esta situación.

El artículo es más bien una reseña. No contendrá una comparación de distribuciones ni un análisis detallado de las mismas, ni habrá recetas para instalarlas y configurarlas. ¿Lo que sucederá? Hablaremos brevemente sobre una distribución como Arenadata Hadoop, que con razón merece nuestra atención debido a su disponibilidad, que es muy rara en la actualidad. Y luego hablaremos de Vanilla Hadoop, principalmente de cómo se puede “cocinar” usando Apache Bigtop. ¿Listo? Entonces bienvenido al gato.

Arenadata Hadoop

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

Se trata de una distribución de desarrollo nacional completamente nueva y, hasta el momento, poco conocida. Desgraciadamente, por el momento en Habré sólo hay este articulo.

Puede encontrar más información en el sitio oficial. sitio web proyecto. Las últimas versiones de la distribución se basan en Hadoop 3.1.2 para la versión 3 y 2.8.5 para la versión 2.

Puede encontrar información sobre la hoja de ruta. aquí.

Apache Bigtop y la elección de una distribución de Hadoop hoy
Interfaz del administrador de clústeres de Arenadata

El producto principal de Arenadata es Administrador de clústeres de Arenadata (ADCM), que se utiliza para instalar, configurar y monitorear varias soluciones de software de la empresa. ADCM se distribuye de forma gratuita y su funcionalidad se amplía agregando paquetes, que son un conjunto de manuales de estrategias de Ansible. Los paquetes se dividen en dos tipos: empresarial y comunitario. Estos últimos están disponibles para su descarga gratuita desde el sitio web de 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, pero para Hadoop 2 solo hay apache ambari como alternativa. En cuanto a los repositorios con paquetes, están abiertos al acceso público, se pueden descargar e instalar de la forma habitual para todos los componentes del clúster. En general, la distribución parece muy interesante. Estoy seguro de que habrá quienes estén acostumbrados a soluciones como Cloudera Manager y Ambari, y a quienes les gustará ADCM. Para algunos, también será una gran ventaja que la distribución incluido en el registro de software para la sustitución de importaciones.

Si hablamos de desventajas, serán las mismas 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 hemos dado cuenta de que siempre existe el riesgo de cambiar la política de una empresa.
  • Un retraso significativo con respecto a Apache en sentido ascendente.

Hadoop de vainilla

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

Como sabes, Hadoop no es un producto monolítico, sino, de hecho, toda una galaxia de servicios en torno a su sistema de archivos distribuido HDFS. Pocas personas tendrán suficiente con un grupo de archivos. Algunos necesitan Hive, otros Presto, y luego están HBase y Phoenix; Spark se usa cada vez más. Para la orquestación y la carga de datos, a veces se encuentran Oozie, Sqoop y Flume. Y si surge la cuestión de la seguridad, inmediatamente me viene a la mente Kerberos junto con Ranger.

Las versiones binarias de los componentes de Hadoop están disponibles en el sitio web de cada uno de los proyectos del ecosistema en forma de archivos tar. Puede descargarlos y comenzar la instalación, pero con una condición: además de ensamblar paquetes de forma independiente a partir de binarios "sin formato", lo que probablemente desee hacer, no tendrá ninguna confianza en la compatibilidad de las versiones descargadas de los componentes con cada uno. otro. La opción preferida es construir usando Apache Bigtop. Bigtop le permitirá compilar desde repositorios de Apache maven, ejecutar pruebas y compilar paquetes. Pero, lo que es muy importante para nosotros, Bigtop ensamblará aquellas versiones de componentes que serán compatibles entre sí. Hablaremos de ello con más detalle a continuación.

Apache gran cima

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

Apache Bigtop es una herramienta para construir, empaquetar y probar una serie de
proyectos de código abierto, como Hadoop y Greenplum. Bigtop tiene mucho
lanzamientos. En el momento de escribir este artículo, la última versión estable era la versión 1.4,
y en master había 1.5. Diferentes versiones de lanzamientos utilizan diferentes versiones.
componentes. Por ejemplo, para 1.4 los componentes principales de Hadoop tienen la versión 2.8.5 y en master
2.10.0. La composición de los componentes compatibles también está cambiando. Algo anticuado y
lo no renovable desaparece y en su lugar viene algo nuevo, más demandado y
No es necesariamente algo de la propia familia Apache.

Además, Bigtop tiene muchos tenedores.

Cuando empezamos a conocer Bigtop, lo primero que nos sorprendió fue su modesta prevalencia y popularidad, en comparación con otros proyectos de Apache, así como su comunidad muy pequeña. De esto se deduce que hay información mínima sobre el producto y que la búsqueda de soluciones a los problemas que han surgido en foros y listas de correo puede no arrojar nada en absoluto. Al principio nos resultó una tarea difícil completar el montaje completo de la distribución debido a las características de la propia herramienta, pero hablaremos de esto un poco más adelante.

Como adelanto, aquellos que alguna vez estuvieron interesados ​​en proyectos del universo Linux como Gentoo y LFS pueden encontrar nostálgicamente agradable trabajar con esto y recordar aquellos tiempos "épicos" en los que nosotros mismos buscábamos (o incluso escribíamos) ebuilds y reconstruimos Mozilla periódicamente con nuevos parches.

La gran ventaja de Bigtop es la apertura y versatilidad de las herramientas en las que se basa. Está basado en Gradle y Apache Maven. Gradle es bastante conocido como la herramienta que utiliza Google para construir Android. Es flexible y, como dicen, “probado en batalla”. Maven es una herramienta estándar para crear proyectos en el propio Apache y, dado que la mayoría de sus productos se lanzan a través de Maven, tampoco se podría prescindir de ella aquí. Vale la pena prestar atención a POM (modelo de objetos de proyecto), un archivo xml "fundamental" que describe todo lo necesario para que Maven trabaje con su proyecto, alrededor del cual se construye todo el trabajo. exactamente en
partes de Maven y hay algunos obstáculos que los usuarios primerizos de Bigtop suelen encontrar.

Práctica

Entonces, ¿En dónde debes empezar? Vaya a la página de descarga y descargue la última versión estable como archivo. También puedes encontrar allí artefactos binarios recopilados por Bigtop. Por cierto, entre los administradores de paquetes comunes, se admiten YUM y APT.

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

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

Clonando 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), готово.

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 ensamblar, la parte principal de la herramienta
./bigtop-test-framework - marco de prueba
./bigtop-tests — las pruebas en sí, cargan y fuman
./bigtop_toolchain — entorno para el montaje, preparación del entorno para que funcione la herramienta
./build - construir directorio de trabajo
./dl — directorio de fuentes descargadas
./docker — creación de imágenes de Docker, pruebas
./gradle - configuración de gradle
./output – el directorio donde van los artefactos de compilación
./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 sus versiones. Aquí es donde podemos especificar una versión diferente del producto (si de repente queremos intentar compilarlo) o una versión de compilación (si, por ejemplo, agregamos un parche importante).

El subdirectorio también es de gran interés. ./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 desde github, ¿podemos comenzar a construir?

No, primero preparemos el ambiente.

Preparando el Ambiente

Y aquí necesitamos un pequeño retiro. Para construir casi cualquier producto más o menos complejo, necesita un entorno determinado; en nuestro caso, este es el 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 que necesita para Bigtop es instalar los componentes necesarios en el host de compilación. Podría estar equivocado en la cronología, pero parece que con la versión 1.0 también había una opción para crear imágenes de Docker preconfiguradas y accesibles, que se pueden encontrar aquí.

En cuanto a preparar el entorno, hay un asistente para ello: Puppet.

Puede utilizar los siguientes comandos, ejecutar desde el directorio raíz
herramienta, ./bigtop:

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

O directamente a través de Puppet:

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

asamblea

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

./gradlew tasks

En la sección Tareas de paquete hay una serie de productos que son artefactos finales de Bigtop.
Se pueden identificar mediante el sufijo -rpm o -pkg-ind (en el caso de construcción
en la ventana acoplable). En nuestro caso el más interesante es Hadoop.

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

./gradlew hadoop-rpm

El propio Bigtop descargará las fuentes necesarias para un componente específico y comenzará el ensamblaje. Por tanto, el funcionamiento de la herramienta depende de los repositorios de Maven y otras fuentes, es decir, requiere acceso a Internet.

Durante el funcionamiento, se genera una salida estándar. A veces, este y los mensajes de error pueden ayudarle a comprender qué salió mal. Y a veces es necesario obtener información adicional. En este caso vale la pena agregar argumentos. --info o --debug, y también puede ser útil –stacktrace. Existe una manera conveniente de generar un conjunto de datos para el acceso posterior a las listas de correo, la clave --scan.

Con su ayuda, bigtop recopilará toda la información y la colocará en gradle, después de lo cual proporcionará un enlace,
a continuación, una persona competente podrá comprender por qué falló el montaje.
Tenga en cuenta que esta opción puede exponer información que no desea, como nombres de usuario, nodos, variables de entorno, etc., así que tenga cuidado.

A menudo, los errores son consecuencia de la imposibilidad de obtener los componentes necesarios para el montaje. Normalmente, puede solucionar el problema creando un parche para corregir algo en las fuentes, por ejemplo, direcciones en pom.xml en el directorio raíz de las fuentes. Esto se hace creándolo y colocándolo en el directorio apropiado. ./bigtop/bigtop-packages/src/common/oozie/ parche, por ejemplo, en la forma 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>

Lo más probable es que, al momento de leer este artículo, no tengas que hacer tú mismo la solución anterior.

Al introducir parches y cambios en el mecanismo del ensamblaje, es posible que necesite "restablecer" el ensamblaje usando 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 se puede realizar en Ubuntu:

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

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

./gradlew yum

También puede recordar las pruebas de humo y la implementación en Docker.

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 un clúster:

./gradlew docker-provisioner-destroy

Obtenga comandos para conectarse dentro de contenedores acoplables:

./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, hay bastantes, principalmente humo e integración. Su análisis está más allá del alcance de este artículo. Permítanme decirles que ensamblar una distribución no es una tarea tan difícil como podría parecer a primera vista. Logramos ensamblar y pasar pruebas de todos los componentes que utilizamos en nuestra producción, y tampoco tuvimos problemas para implementarlos y realizar operaciones básicas en el entorno de prueba.

Además de los componentes existentes en Bigtop, es posible agregar cualquier otra cosa, incluso su propio desarrollo de software. Todo esto está perfectamente automatizado y encaja en el concepto CI/CD.

Conclusión

Obviamente, la distribución compilada de esta manera no debe enviarse inmediatamente a producción. Debe comprender que si existe una necesidad real de construir y respaldar su distribución, entonces debe invertir dinero y tiempo en esto.

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

Es importante señalar que el proyecto Bigtop en sí necesita desarrollo y no parece estar desarrollándose activamente en la actualidad. La perspectiva de que aparezca Hadoop 3 tampoco está clara. Por cierto, si realmente necesita construir Hadoop 3, puede consultar tenedor de Arenadata, en el que, además del estándar
Hay varios componentes adicionales (Ranger, Knox, NiFi).

En cuanto a Rostelecom, para nosotros Bigtop es una de las opciones que se están considerando hoy. Si lo elegimos o no, el tiempo lo dirá.

Apéndice

Para incluir un nuevo componente en el ensamblaje, debe agregar su descripción a 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é opinas? ¡Estaremos encantados de ver tu opinión en los comentarios y gracias por tu atención!

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

Fuente: habr.com

Añadir un comentario