Hadoop Versión 3.0 – ¿Qué hay de nuevo?

Hadoop es un marco escrito en Java que se utiliza para resolver problemas de Big Data. La versión inicial de Hadoop se lanzó en abril de 2006. La comunidad de Apache ha realizado muchos cambios desde el día del primer lanzamiento de Hadoop en el mercado. El viaje de Hadoop comenzó en 2005 por Doug Cutting y Mike Cafarella. La razón detrás del desarrollo de Hadoop es admitir la distribución del proyecto de motor de búsqueda Nutch . 

Hadoop conquista la supercomputadora en el año 2008 y se convierte en el sistema más rápido jamás creado por humanos para clasificar terabytes de datos almacenados. Hadoop ha recorrido un largo camino y se ha adaptado a muchos cambios con respecto a su versión anterior, es decir, Hadoop 2.x. En este artículo, vamos a discutir los cambios realizados por Apache en la versión 3.x de Hadoop para hacerlo más eficiente y rápido.  

¿Qué hay de nuevo en Hadoop 3.0?

1. JDK 8.0 es la versión mínima de JAVA admitida por Hadoop 3.x

Dado que Oracle dejó de usar JDK 7 en 2015, para usar Hadoop 3, los usuarios deben actualizar su versión de Java a JDK 8 o superior para compilar y ejecutar todos los archivos de Hadoop. La versión de JDK anterior a la 8 ya no es compatible con el uso de Hadoop 3.

2. Se admite la codificación de borrado

La codificación de borrado se usa para recuperar los datos cuando falla el disco duro de la computadora. Es una tecnología RAID (array redundante de discos independientes) de alto nivel utilizada por muchas empresas de TI para recuperar sus datos. El sistema de archivos de Hadoop HDFS , es decir, el sistema de archivos distribuido de Hadoop, utiliza la codificación Erasure para proporcionar tolerancia a fallas en el clúster de Hadoop. Dado que estamos utilizando hardware básico para construir nuestro clúster de Hadoop, la falla del Node es normal. Hadoop 2 utiliza un mecanismo de replicación para proporcionar un tipo de tolerancia a fallas similar al de la codificación Erasure en Hadoop 3. 

En las réplicas de Hadoop 2 de los datos, se crean bloques que luego se almacenan en diferentes Nodes en el clúster de Hadoop. La codificación de borrado consume menos o la mitad del almacenamiento que la replicación en Hadoop 2 para proporcionar el mismo nivel de tolerancia a fallas. Con la creciente cantidad de datos en la industria, los desarrolladores pueden ahorrar una gran cantidad de almacenamiento con la codificación de borrado. La codificación de borrado minimiza el requisito de disco duro y mejora la tolerancia a fallos en un 50 % con los recursos similares proporcionados.

3. Se admiten más de dos NameNodes

La versión anterior de Hadoop admite un solo NameNode activo y un solo NameNode en espera. En la última versión de Hadoop, es decir, Hadoop 3.x, la replicación del bloque de datos se realiza entre tres JournalNodes (JN). Con la ayuda de eso, la arquitectura Hadoop 3.x es más capaz de manejar la tolerancia a fallas que la de su versión anterior. Problemas de big data donde se necesita una alta tolerancia a fallas, Hadoop 3.x es muy útil en esa situación. En este Hadoop, los usuarios de 3.x pueden administrar la cantidad de Nodes en espera de acuerdo con los requisitos, ya que se proporciona la función de múltiples Nodes en espera. 

Por ejemplo, los desarrolladores ahora pueden configurar fácilmente tres NameNodes y Five JournalNodes con lo que nuestro clúster de Hadoop es capaz de manejar dos Nodes en lugar de uno solo.

4. Reescritura de guiones de Shell

El sistema de archivos de Hadoop utiliza varios comandos tipo shell que interactúan directamente con HDFS y otros sistemas de archivos compatibles con Hadoop, como WebHDFS, Local FS, S3 FS, etc. Las múltiples funcionalidades de Hadoop están controladas por el shell. El script de shell utilizado en la última versión de Hadoop, es decir, Hadoop 3.x, ha corregido muchos errores. Los scripts de shell de Hadoop 3.x también brindan la funcionalidad de reescribir el script de shell.

5. Servicio de línea de tiempo v.2 para YARN

El servicio YARN Timeline almacena y recupera la información del solicitante (la información puede ser continua o histórica). El servicio Timeline v.2 fue muy importante para mejorar la confiabilidad y escalabilidad de nuestro Hadoop. La usabilidad del sistema se mejora con la ayuda de flujos y agregación. En Hadoop 1.x con el servicio TimeLine, los usuarios de v.1 solo pueden crear una única instancia de lector/escritor y arquitectura de almacenamiento que no se puede escalar más. 

Hadoop 2.x utiliza una arquitectura de escritura distribuida en la que las operaciones de lectura y escritura de datos son separables. Aquí se proporcionan recopiladores distribuidos para cada aplicación YARN (Yet Another Resource Negotiator). El servicio de línea de tiempo v.2 utiliza HBase para fines de almacenamiento que se puede escalar a un tamaño masivo además de proporcionar un buen tiempo de respuesta para las operaciones de lectura y escritura.

La información que almacena el servicio Timeline v.2 puede ser de 2 tipos principales:

A. Datos genéricos de la solicitud cumplimentada

• informacion del usuario
• nombre de cola
• recuento de intentos realizados por aplicación
• información del contenedor que se ejecuta para cada intento de aplicación

B. Información por marco sobre la ejecución y la aplicación completa   

• recuento de Mapear y Reducir Tarea
• contadores
• información transmitida por el desarrollador para TimeLine Server con la ayuda del cliente Timeline.

6. Compatibilidad con el conector del sistema de archivos

Esta nueva versión 3.x de Hadoop ahora es compatible con Azure Data Lake y Aliyun Object Storage System, que son la otra opción de reserva para el sistema de archivos compatible con Hadoop.

7. Se han cambiado los puertos de servicio múltiples predeterminados

En la versión anterior de Hadoop, el puerto de servicios múltiples para Hadoop está en el rango de puertos efímeros de Linux (32768-61000) . En este tipo de configuración, debido a conflictos que ocurren en alguna otra aplicación, a veces el servicio no se vincula a los puertos. Entonces, para superar este problema, Hadoop 3.x ha movido los puertos de conflicto del rango de puertos efímeros de Linux y se le han asignado nuevos puertos, como se muestra a continuación.

// The new assigned Port
Namenode Ports: 50470 -> 9871, 50070 -> 9870, 8020 -> 9820
Datanode Ports: 50020-> 9867,50010 -> 9866, 50475 -> 9865, 50075 -> 9864
Secondary NN Ports: 50091 -> 9869, 50090 -> 9868  

8. Equilibrador intra-Node de datos

Los Nodes de datos se utilizan en el clúster de Hadoop con fines de almacenamiento. Los DataNodes manejan múltiples discos a la vez. Este disco se llenó uniformemente durante las operaciones de escritura. Agregar o quitar el disco puede causar una asimetría significativa en un DataNode. El HDFS-BALANCER existente no puede manejar este sesgo significativo, que se relaciona con el sesgo inter-, no intra-DN. La última función de equilibrio intra-DataNode puede gestionar esta situación que se invoca con la ayuda de la CLI del equilibrador de disco HDFS.

9. Frascos de clientes sombreados

La nueva Hadoop-client-API y Hadoop-client-runtime están disponibles en Hadoop 3.x, que proporciona dependencias de Hadoop en un solo paquete o un solo archivo jar. En Hadoop 3.x, Hadoop –client-API tiene alcance de tiempo de compilación, mientras que Hadoop-client-runtime tiene alcance de tiempo de ejecución. Ambos contienen dependencias de terceros proporcionadas por Hadoop-client. Ahora, los desarrolladores pueden agrupar fácilmente todas las dependencias en un solo archivo jar y pueden probar fácilmente los archivos jar para detectar cualquier conflicto de versión. De esta manera, las dependencias de Hadoop en la ruta de clase de la aplicación se pueden retirar fácilmente.

10. Gestión de montones de tareas y demonios

En la versión 3.x de Hadoop, podemos configurar fácilmente el tamaño del montón del demonio de Hadoop con algunas formas recién agregadas. Con la ayuda del tamaño de la memoria del host, el ajuste automático está disponible. En lugar de HADOOP_HEAPSIZE , los desarrolladores pueden usar las variables HEAP_MAX_SIZE y HEAP_MIN_SIZE . La variable interna JAVA_HEAP_SIZE también se elimina en esta última versión 3.x de Hadoop. También se eliminan los tamaños de almacenamiento dinámico predeterminados, que se utilizan para el ajuste automático de JVM (Java Virtual Machine). Si desea utilizar el valor predeterminado anterior, actívelo configurando HADOOP_HEAPSIZE_MAX en el archivo Hadoop-env.sh.