En el mundo de la empresa, hubo una saciedad con los sistemas front-end, los buses de datos y otros sistemas clásicos que han sido implementados por todos durante los últimos 10-15 años. Pero hay un segmento, que hasta hace poco estaba en el estado de "todo el mundo quiere, pero nadie sabe lo que es". Y esto es Big Data. Suena muy bien, promovido por las principales empresas occidentales: ¿cómo no convertirse en un tidbit?
Pero aunque la mayoría solo está mirando y preguntando, algunas compañías han comenzado a implementar activamente soluciones basadas en esta pila de tecnología en su panorama de TI. La aparición de distribuciones comerciales de Apache Hadoop, cuyos desarrolladores brindan soporte técnico a sus clientes, desempeñó un papel importante en esto. Sintiendo la necesidad de tal solución, uno de nuestros clientes decidió organizar un almacén de datos distribuido en el concepto de Data Lake basado en Apache Hadoop.
Objetivos del proyecto
Primero, optimice el trabajo del departamento de gestión de riesgos. Antes de comenzar a trabajar, todo un departamento se ocupó de calcular los factores de riesgo de crédito (FCR), y todos los cálculos se realizaron manualmente. El recálculo tardó aproximadamente un mes cada vez, y los datos en los que se basó tuvieron tiempo de quedar desactualizados. Por lo tanto, las tareas de la solución incluyeron la carga diaria del delta de datos en el repositorio, recalculando el FCD y construyendo marts de datos en la herramienta de BI (la funcionalidad de SpagoBI fue suficiente para esta tarea) para visualizarlos.
En segundo lugar, proporcionar herramientas de minería de datos de alto rendimiento para los empleados del banco que participan en Data Science. Estas herramientas, como Jupyter y Apache Zeppelin, pueden instalarse localmente y también pueden usarse para explorar datos y construir modelos. Pero su integración con el clúster Cloudera permite utilizar los recursos de hardware de los nodos del sistema más productivos para los cálculos, lo que acelera las tareas de análisis de datos en decenas o incluso cientos de veces.
El rack de Oracle Big Data Appliance se eligió como la solución de hardware de destino, por lo que se tomó como base la distribución Clachede de Apache Hadoop. El rack estuvo viajando durante bastante tiempo y, para acelerar el proceso, se asignaron servidores en la nube privada del cliente para este proyecto. La solución es razonable, pero hubo una serie de problemas, que analizaré a continuación.
Se planificaron las siguientes tareas dentro del proyecto:
- Implemente el CDH de Cloudera (Distribución de Cloudera, incluido Apache Hadoop) y los servicios adicionales necesarios para el trabajo.
- Configurar el software instalado.
- Configure la integración continua para acelerar el proceso de desarrollo (se tratará en un artículo separado).
- Instale herramientas de BI para crear informes y herramientas de descubrimiento de datos para garantizar el trabajo del centro de datos (se cubrirá en una publicación separada).
- Desarrollar aplicaciones para descargar los datos necesarios de los sistemas finales, así como su actualización periódica.
- Desarrolle formularios de informes para visualizar datos en una herramienta de BI.
No es el primer año que Neoflex ha estado desarrollando e implementando sistemas basados en Apache Hadoop e incluso tiene su propio producto para el desarrollo visual de procesos ETL: Neoflex Datagram. Durante mucho tiempo quise participar en uno de los proyectos de esta clase y estaba feliz de administrar este sistema. La experiencia resultó ser muy valiosa y motivadora para seguir estudiando el tema, así que me apresuro a compartirlo con ustedes. Espero que sea interesante.
Recursos
Antes de comenzar la instalación, se recomienda que prepare todo lo que necesita para ello.
La cantidad y la potencia del hierro dependen directamente de cuántos y qué medios necesitarán desplegarse. Para fines de desarrollo, puede instalar todos los componentes en al menos una máquina virtual frágil, pero este enfoque no es bienvenido.
En la etapa piloto del proyecto y el desarrollo activo, cuando el número de usuarios del sistema era mínimo, un entorno principal era suficiente: esto se podía acelerar al reducir el tiempo de carga de datos de los sistemas finales (el procedimiento más frecuente y largo para desarrollar almacenes de datos). Ahora que el sistema se ha estabilizado, hemos llegado a una configuración con tres entornos: prueba, preprod y prod (main).
En una nube privada, se asignaron servidores para organizar 2 entornos, el principal y el de prueba. Las especificaciones de los medios se muestran en la tabla a continuación:
| Cita | Cantidad | vCPU | vRAM, Gb | Discos, Gb |
|---|
| Entorno principal, servicios Cloudera | 3 | 8 | 64 | 2,200 |
| Entorno primario, HDFS | 3 | 22 | 288 | 5000 |
| Entorno central, herramientas de descubrimiento de datos | 1 | 16 | 128 | 2200 |
| Entorno de prueba, servicios de Cloudera | 1 | 8 | 64 | 2200 |
| Entorno de prueba, HDFS | 2 | 22 | 256 | 4000 |
| Entorno central, herramientas de descubrimiento de datos | 1 | 16 | 128 | 2200 |
| Ci | 2 | 6 6 | 48 | 1000 |
Más tarde, el entorno principal migró a Oracle BDA, y los servidores se usaron para organizar el entorno de preprod.
La decisión sobre la migración estaba justificada: los recursos asignados para los servidores HDFS carecían objetivamente. Los cuellos de botella eran pequeños discos (¿qué es 5 Tb para Big Data?) Y procesadores insuficientemente potentes, que se cargaron de manera estable al 95% durante el trabajo regular de las tareas de carga de datos. Con otros servidores, la situación es la opuesta: casi todo el tiempo están inactivos inactivos y sus recursos podrían utilizarse con gran ventaja en otros proyectos.
Con el software, las cosas no fueron fáciles: debido al hecho de que el desarrollo se realizó en una nube privada sin acceso a Internet, todos los archivos tuvieron que transferirse a través del servicio de seguridad y solo por acuerdo. En este sentido, tuve que precargar todas las distribuciones, paquetes y dependencias necesarias.
La configuración de keepcache = 1 en el archivo /etc/yum.conf (se utilizó RHEL 7.3 como sistema operativo) ayudó mucho en esta difícil tarea: instalar el software necesario en una máquina con acceso a la red es mucho más fácil que descargarlo manualmente desde los repositorios junto con las dependencias;)
Lo que necesita implementar:
- Oracle JDK (sin Java en ninguna parte).
- Una base de datos para almacenar información creada y utilizada por los servicios de CDH (por ejemplo, Hive Metastore). En nuestro caso, se instaló PostgreSQL versión 9.2.18, pero se puede utilizar cualquiera de los servicios de Cloudera compatibles (la lista es diferente para diferentes versiones de la distribución, consulte la sección Requisitos y versiones compatibles del sitio web oficial). Aquí debe tenerse en cuenta que la elección de la base de datos no fue del todo exitosa: Oracle BDA viene con la base de datos MySQL (uno de sus productos, que fue a ellos con la compra de Sun) y sería más lógico usar una base de datos similar para otros entornos, lo que simplificaría el proceso de migración. Se recomienda elegir una distribución basada en la solución de hardware de destino.
- Chrony Daemon para sincronización de tiempo en servidores.
- Servidor de Cloudera Manager.
- Demons Cloudera Manager.
Preparación para la instalación
Antes de comenzar la instalación de CDH, se deben realizar varios trabajos preparatorios. Una parte es útil durante la instalación, la otra simplificará la operación.
Instalación y configuración del sistema operativo
En primer lugar, vale la pena preparar las máquinas virtuales (y reales) que alojarán el sistema: instale la versión compatible en cada una de ellas (la lista difiere para las diferentes versiones de la distribución, consulte la sección "Requisitos y versiones compatibles" del sitio web oficial), asigne los nombres de host son nombres comprensibles (por ejemplo, <nombre_sistema> master1,2,3 ..., <nombre_sistema> esclavo1,2,3 ...), así como los discos de marca para almacenamiento de archivos y archivos temporales creados durante la operación del sistema.
Las recomendaciones de marcado son las siguientes:
- En servidores con HDFS, cree un volumen de al menos 500 Gb para los archivos que YARN crea durante el curso de las tareas y colóquelo en el directorio / yarn (donde este volumen debe montarse después de instalar CDH). Se debe asignar un pequeño volumen (aproximadamente 100 Gb) para el sistema operativo, los servicios de Cloudera, los registros y otras instalaciones. Todo el espacio libre que quedará después de estas manipulaciones debe combinarse en un gran volumen y montarse en el directorio / dfs antes de cargar los datos en el almacenamiento. HDFS almacena datos en forma de bloques bastante pequeños y es mejor no participar en su transferencia una vez más. Además, para la conveniencia de agregar discos más adelante, se recomienda usar LVM: será más fácil expandir el almacenamiento (especialmente cuando se vuelve realmente GRANDE).
- En servidores con servicios de Cloudera, puede montar todo el espacio disponible en el directorio raíz: no debería haber problemas con grandes volúmenes de archivos, especialmente si limpia los registros regularmente. La única excepción es el servidor con la base de datos que los servicios de Cloudera utilizan para sus necesidades: en este servidor tiene sentido marcar un volumen separado en el directorio en el que se almacenan los archivos de esta base de datos (dependerá de la distribución seleccionada). Los servicios escriben bastante moderadamente y 500 Gb deberían ser más que suficientes. Por seguridad, también puede usar LVM.
Configuración del servidor http e instalación fuera de línea de paquetes yum y CDH
Dado que el software se instala sin acceso a Internet, para simplificar la instalación de paquetes, se recomienda elevar el servidor HTTP y usarlo para crear un repositorio local que sea accesible a través de la red. Puede instalar todo el software localmente utilizando, por ejemplo, rpm, pero con una gran cantidad de servidores y la apariencia de varios entornos, es conveniente tener un único repositorio desde el que pueda instalar paquetes sin tener que transferirlos manualmente de una máquina a otra.
La instalación se realizó en el sistema operativo Red Hat 7.3, por lo tanto, el artículo contendrá comandos específicos para él y otros sistemas operativos basados en CentOS. Cuando se instala en otros sistemas operativos, la secuencia será similar, solo los administradores de paquetes serán diferentes.
Para no escribir sudo en todas partes, suponemos que la instalación es desde la raíz.
Esto es lo que debes hacer:
1. Se selecciona la máquina en la que se ubicarán el servidor HTTP y las distribuciones.
2. En una máquina con un sistema operativo similar, pero conectado a Internet, configure el indicador keepcache = 1 en el archivo /etc/yum.conf y se instala httpd con todas las dependencias:
yum install httpd
Si este comando no funciona, debe agregar a la lista de repositorios yum un repositorio que contenga estos paquetes, por ejemplo, este es
centos.excellmedia.net/7/os/x86_64 :
echo -e "\n[centos.excellmedia.net]\nname=excellmedia\nbaseurl=http://centos.excellmedia.net/7/os/x86_64/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/excell.repo
Después de eso,
usando el comando
yum repolist , verificamos que el repositorio esté ajustado; un repositorio agregado debe aparecer en la lista de repositorios (repo id - centos.excellmedia.net; repo name - excellmedia).
Ahora compruebe que yum vio los paquetes que necesitamos:
yum list | grep httpd
Si la salida contiene los paquetes necesarios, puede instalarlos con el comando anterior.
3. Para crear el repositorio yum, necesitamos el paquete createrepo. También se encuentra en el repositorio anterior y se configura de manera similar:
yum install createrepo
4. Como dije antes, los servicios de CDH requieren una base de datos para funcionar. Instale PostgreSQL para estos fines:
yum install postgresql-server
5. Uno de los requisitos previos para el correcto funcionamiento de CDH es la sincronización horaria en todos los servidores incluidos en el clúster. Para estos fines, se
utiliza el paquete
chronyd (en aquellos sistemas operativos donde tuve que implementar CDH, se instaló de forma predeterminada). Comprueba su disponibilidad:
chronyd -v
Si no está instalado, instale:
yum install chrony
Si está instalado, simplemente descargue:
yumdownloader --destdir=/var/cache/yum/x86_64/7Server/<repo id>/packages chrony
6. Al mismo tiempo, descargue inmediatamente los paquetes necesarios para instalar CDH. Están disponibles en
archive.cloudera.com -
archive.cloudera.com/cm <versión principal de CDH> / <nombre de su sistema operativo> / <versión de su sistema operativo> / x86_64 / cm / <versión completa de CDH> / RPMS / x86_64 /. Puede descargar paquetes manualmente (cloudera-manager-server y cloudera-manager-daemons), o agregar un repositorio por analogía e instalarlos:
yum install cloudera-manager-daemons cloudera-manager-server
7. Después de la instalación, los paquetes y sus dependencias se almacenan en caché en la carpeta / var / cache / yum / x86_64 / 7Server / \ <repo id \> / packages. Los transferimos a la máquina seleccionada para el servidor HTTP y las distribuciones, e instalamos:
rpm -ivh < >
8. Ejecute httpd, hágalo visible desde otros hosts en nuestro clúster y también agréguelo a la lista de servicios que se inician automáticamente después de la carga:
systemctl start httpd systemctl enable httpd systemctl stop firewalld
9. Ahora tenemos un servidor HTTP en funcionamiento. Su directorio de trabajo es
/ var / www / html . Cree 2 carpetas en él, una para el repositorio de yum, la otra para los analizadores de Cloudera (más sobre eso más adelante):
cd /var/www/html mkdir yum_repo parcels
10. Para los servicios de Cloudera necesitamos
Java . Todas las máquinas requieren la misma versión del JDK instalado; Cloudera recomienda el Hot Spot de Oracle. Descargue el paquete de distribución del sitio web oficial (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) y transfiéralo a la carpeta
yum_repo .
11. Cree el repositorio yum en la carpeta yum_repo utilizando la utilidad createrepo para que el paquete JDK esté disponible para su instalación desde las máquinas del clúster:
createrepo -v /var/www/html/yum_repo/
12. Después de crear nuestro repositorio local en cada uno de los hosts, debe agregar su descripción, similar al párrafo 2:
echo -e "\n[yum.local.repo]\nname=yum_repo\nbaseurl=http://< httpd>/yum_repo/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/yum_repo.repo
También puede hacer verificaciones similares al párrafo 2.
13. JDK está disponible, instale:
yum install jdk1.8.0_161.x86_64
Para usar Java, debe establecer la variable JAVA_HOME. Recomiendo que lo exporte inmediatamente después de la instalación, así como que lo escriba en los
archivos / etc / environment y
/ etc / default / bigtop-utils para que se exporte automáticamente después de reiniciar los servidores y su ubicación se proporcione a los servicios de CDH:
export JAVA_HOME=/usr/java/jdk1.8.0_161 echo "JAVA_HOME=/usr/java/jdk1.8.0_161" >> /etc/environment export JAVA_HOME=/usr/java/jdk1.8.0_144 >> /etc/default/bigtop-utils
14. Del mismo modo, instale chronyd en todas las máquinas del clúster (a menos que, por supuesto, esté ausente):
yum install chrony
15. Seleccione el host en el que funcionará PostgreSQL e instálelo:
yum install postgresql-server
16. Del mismo modo, seleccione el host en el que se ejecutará Cloudera Manager e instálelo:
yum install cloudera-manager-daemons cloudera-manager-server
17. Los paquetes están instalados, puede comenzar a configurar el software antes de la instalación.
Adición:
Durante el desarrollo y la operación del sistema, deberá agregar paquetes al repositorio de yum para instalarlos en los hosts del clúster (por ejemplo, distribución de Anaconda). Para hacer esto, además de transferir los archivos a la carpeta yum_repo, debe realizar las siguientes acciones:
Configurar software auxiliar
Es hora de configurar PostgreSQL y crear bases de datos para nuestros servicios futuros. Esta configuración es relevante para la versión 5.12.1 de CDH. Al instalar otras versiones de la distribución, se recomienda que lea la sección "Almacenes de datos de Managed Service y Managed de Cloudera" en el sitio web oficial.
Para comenzar, inicialicemos la base de datos:
postgresql-setup initdb
Ahora configuramos la interacción de red con la base de datos. En el archivo
/var/lib/pgsql/data/pg_hba.conf en la sección de conexiones locales IPv4, cambie el método para la dirección 127.0.0.1/32 al método md5, agregue el método de confianza y agregue la subred del clúster con el método de confianza :
vi /var/lib/pgsql/data/pg_hba.conf pg_hba.conf:
Luego haremos algunos ajustes en el archivo /var/lib/pgsql/data/postgres.conf (solo daré las líneas que necesitan ser cambiadas o verificadas para verificar su cumplimiento:
vi /var/lib/pgsql/data/postgres.conf postgres.conf: ----------------------------------------------------------------------- listen_addresses = '*' max_connections = 100 shared_buffers = 256MB checkpoint_segments = 16 checkpoint_completion_target = 0.9 logging_collector = on log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 0 log_timezone = 'W-SU' datestyle = 'iso, mdy' timezone = 'W-SU' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' -----------------------------------------------------------------------
Una vez completada la configuración, debe crear bases de datos (para aquellos que están más cerca de la terminología de Oracle: esquemas) para los servicios que instalaremos. En nuestro caso, se instalaron los siguientes servicios: Cloudera Management Service, HDFS, Hive, Hue, Impala, Oozie, Yarn y ZooKeeper. De estos, Hive, Hue y Oozie necesitan bases de datos, y se necesitan 2 bases para las necesidades de los servicios de Cloudera: una para el servidor de Cloudera Manager, la otra para el administrador de informes, que forma parte del Servicio de Administración de Cloudera. Inicie PostgreSQL y agréguelo a la carga automática:
systemctl start postgresql systemctl enable postgresql
Ahora podemos conectarnos y crear las bases de datos necesarias:
sudo -u postgres psql > CREATE ROLE scm LOGIN PASSWORD '<password>'; > CREATE DATABASE scm OWNER scm ENCODING 'UTF8'; # Cloudera Manager > CREATE ROLE rman LOGIN PASSWORD '<password>'; > CREATE DATABASE rman OWNER rman ENCODING 'UTF8'; # > CREATE ROLE hive LOGIN PASSWORD '<password>'; > CREATE DATABASE metastore OWNER hive ENCODING 'UTF8'; # Hive Metastore > ALTER DATABASE metastore SET standard_conforming_strings = off; # PostgreSQL 8.2.23 > CREATE ROLE hue_u LOGIN PASSWORD '<password>'; > CREATE DATABASE hue_d OWNER hue_u ENCODING 'UTF8'; # Hue > CREATE ROLE oozie LOGIN ENCRYPTED PASSWORD '<password>' NOSUPERUSER INHERIT CREATEDB NOCREATEROLE; > CREATE DATABASE "oozie" WITH OWNER = oozie ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1; # Oozie : > \q
Para otros servicios, las bases de datos se crean de la misma manera.
No olvide ejecutar el script para preparar la base de datos del servidor Cloudera Manager, pasándole los datos de entrada para conectarse a la base de datos creada para ello:
. /usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm <password>
Crear un repositorio con archivos CDH
Cloudera proporciona 2 formas de instalar CDH: usando paquetes y paquetes. La primera opción consiste en descargar un conjunto de paquetes con servicios de las versiones requeridas y su posterior instalación. Este método proporciona una gran flexibilidad en la configuración del clúster, pero Cloudera no garantiza su compatibilidad. Por lo tanto, la segunda versión de la instalación con perejiles es más popular: conjuntos de paquetes preformados de versiones compatibles. Las últimas versiones están disponibles en el siguiente enlace: archive.cloudera.com/cdh5/parcels/latest . Anteriormente se puede encontrar un nivel superior. Además del perejil de CDH, debe descargar manifest.json del mismo directorio de repositorio.
Para usar la funcionalidad desarrollada, también necesitábamos Spark 2.2, que no está incluido en el paquete de CDH (la primera versión de este servicio está disponible allí). Para instalarlo, debe descargar un paquete separado con este servicio y el manifiesto.json correspondiente, también disponible en el archivo Cloudera .
Después de cargar los parsels y manifest.json, debe transferirlos a las carpetas apropiadas en nuestro repositorio. Cree carpetas separadas para archivos CDH y Spark:
cd /var/www/html/parcels mkdir cdh spark
Transfiera los archivos parsels y manifest.json a las carpetas creadas. Para que estén disponibles para la instalación a través de la red, emitimos la carpeta de permisos de acceso correspondiente con perejiles:
chmod -R ugo+rX /var/www/html/parcels
Puede comenzar a instalar CDH, lo cual discutiré en la próxima publicación.