Hadoop ha recorrido un largo camino desde que fue creado en abril del año 2006. Desarrollado por una comunidad de entusiastas del código abierto y que soporta aplicaciones distribuidas bajo una licencia libre. En este blog haré una descripción de las tres versiones que se han visto y usado en el ambiente informático peruano y mundial.
Hadoop 1: El lanzamiento de la versión 1 de Hadoop fue seis años después del primer lanzamiento de Hadoop (2012). Con esta versión, la plataforma Hadoop tenía capacidades completas que pueden ejecutar computación distribuida MapReduce en el almacenamiento distribuido del Sistema de archivos distribuidos de Hadoop (HDFS). Tuvo algunas de las mejoras de rendimiento más importantes que se hayan realizado, junto con soporte completo para la seguridad. Esta versión también disfrutó de muchas mejoras con respecto a HBASE.
Hadoop 2: Lanzó saltos significativos en comparación con la versión 1. Introdujo YARN, un sofisticado administrador de recursos de uso general y un componente de programación de trabajos. La alta disponibilidad de HDFS, las federaciones de HDFS y los snapshots de HDFS fueron algunas de las características destacadas introducidas en las versiones 2.
Hadoop 3: Esta versión ha visto algunas características importantes, como la codificación de borrado HDFS, un nuevo servicio de línea de tiempo YARN (con nueva arquitectura), contenedores oportunistas YARN y programación distribuida, soporte para tres nodos de nombres e intra- balanceadores de carga de nodo de datos. Además de las principales incorporaciones de funciones, la versión 3 tiene mejoras de rendimiento y correcciones de errores.
VISTA LÓGICA HADOOP
Se debe de tener en cuenta que al diseñar cualquier aplicación con Hadoop, se tiene que pensar en términos de esas secciones y tomar decisiones tecnológicas de acuerdo con los problemas de casos de uso que está tratando de resolver.
Mejoras y novedades Hadoop 3
La versión 3 de Hadoop aún está en fase alfa y la comunidad Apache ha incorporado muchos cambios y aún se están trabajando en algunos de ellos. Por ello, explicaremos más ampliamente los cambios esperados.
1. La versión mínima que requiere Hadoop 3 es Java 8: Todos los JAR de Hadoop se compilan para una versión en tiempo de ejecución de Java 8. Por lo tanto, los usuarios que todavía usan Java 7 o inferior deben actualizar a Java 8 cuando comiencen a trabajar con Hadoop 3.
2. Soporte para la codificación de borrado (CB) en HDFS: En general, en los sistemas de almacenamiento, la codificación de borrado se usa principalmente en una matriz redundante de discos de bajo costo (RAID). Ahora, para admitir efectivamente la codificación de borrado en HDFS, hicieron algunos cambios en la arquitectura.
Arquitectura diseñada para la codificación de borrado HDFS
Extensiones de NameNode: Los archivos HDFS se dividen en grupos de bloques, que tienen un cierto número de bloques internos. Para reducir el consumo de memoria de NameNode de estos bloques adicionales, se introdujo un nuevo protocolo de nomenclatura jerárquica de bloques. El identificativo ID de un grupo de bloques se puede deducir de la ID de cualquiera de sus bloques internos. Esto permite la gestión a nivel del grupo de bloques en lugar del bloque.
Extensiones de cliente: Después de implementar la codificación de borrado en HDFS, NameNode funciona a nivel de grupo de bloques y las rutas de lectura y escritura del cliente se mejoraron para trabajar en múltiples bloques internos en un grupo de bloques en paralelo.
En la ruta de salida / escritura, DFSStripedOutputStream gestiona un conjunto de transmisores de datos, uno para cada DataNode que almacena un bloque interno en el grupo de bloques actual. Un coordinador se encarga de las operaciones en todo el grupo de bloques, incluida la finalización del grupo de bloques actual, la asignación de un nuevo grupo de bloques, etc.
En la ruta de entrada / lectura, DFSStripedInputStream traduce un rango de datos de byte lógico solicitado como rangos en bloques internos almacenados en DataNodes. Luego emite solicitudes de lectura en paralelo. Ante fallas, emite solicitudes de lectura adicionales para la decodificación.
Extensiones de DataNode: DataNode ejecuta una tarea adicional ErasureCodingWorker (ECWorker) para la recuperación en segundo plano de bloques codificados por borrado fallido. NameNode detecta los bloques CB fallidos, que luego eligen un DataNode para realizar el trabajo de recuperación. La reconstrucción realiza tres tareas clave:
Lea los datos de los nodos de origen y lea solo el número mínimo de bloques de entrada y bloques de paridad para la reconstrucción.
Nuevos datos y bloques de paridad se decodifican a partir de los datos de entrada. Todos los datos faltantes y los bloques de paridad se decodifican juntos.
Una vez que finaliza la decodificación, los bloques recuperados se transfieren a DataNodes de destino.
Política de ErasureCoding: Para acomodar cargas de trabajo heterogéneas, se permitimos que los archivos y directorios en un clúster HDFS tengan diferentes políticas de replicación y CB. La información sobre codificación y decodificación de archivos se encapsula en una clase ErasureCodingPolicy. Este contiene 2 piezas de información, es decir, el CB Schema y el tamaño de una celda de extracción.
La segunda mejora más importante en Hadoop 3 es YARN Timeline Service versión 2 de YARN versión 1 (en Hadoop 2.x)
3. Servicio YARN Timeline v.2: Hadoop ha presentando una revisión importante del Servicio YARN Timeline, por ejemplo, YARN v.2. Timeline Service. Este desarrollado aborda 2 desafíos principales:
- Mejora de la escalabilidad y la confiabilidad del Timeline Service
- Mejora de la usabilidad mediante la introducción de flujos y agregación
YARN Timeline Service v.2: Escalabilidad
La versión 1 de YARN está limitada a una sola instancia de escritor / lector y no escala mucho más allá de pequeños grupos. La versión 2 utiliza una arquitectura de escritor distribuido más escalable y un almacenamiento de fondo escalable. Separa la recopilación (escritura) de datos del servicio (lectura) de datos. Utiliza colectores distribuidos, esencialmente un colector para cada aplicación YARN. Los lectores son instancias separadas dedicadas a atender consultas a través de la API REST.
YARN Timeline Service v.2 elige Apache HBase como el almacenamiento de respaldo principal, ya que Apache HBase escala bien a un gran tamaño mientras mantiene buenos tiempos de respuesta para lecturas y escrituras.
YARN Timeline Service v.2: Mejoras de usabilidad
Ahora, hablando de mejoras de usabilidad, en muchos casos, los usuarios están interesados en la información a nivel de "flujos" o grupos lógicos de aplicaciones YARN. Es mucho más común iniciar un conjunto o una serie de aplicaciones YARN para completar una aplicación lógica. Timeline Service v.2 admite la noción de flujos explícitamente. Además, admite la agregación de métricas en el nivel de flujo. Ver el siguiente diagrama.
YARN Timeline Service v.2: Arquitectura
YARN Timeline Service v.2 utiliza un conjunto de recopiladores (escritores) para escribir datos en el almacenamiento de fondo. Los recopiladores se distribuyen y se posicionan conjuntamente con los maestros de aplicaciones a los que están vinculados, ver imagen líneas abajo. Todos los datos que pertenecen a esa aplicación se envían a los recopiladores de línea de tiempo de nivel de aplicación con la excepción del recopilador de línea de tiempo del administrador de recursos.
4. Shell Script Rewrite: Los scripts de shell de Hadoop se han reescrito para corregir muchos errores, resolver problemas de compatibilidad y cambiar en alguna instalación existente. También incorpora algunas características nuevas. Así que les indicaré algunos de los más importantes:
Todos los subsistemas de script de shell Hadoop ahora ejecutan hadoop-env.sh, lo que permite que todas las variables de entorno estén en una ubicación.
La demonización se ha movido de * -daemon.sh a los comandos bin a través de la opción –daemon. En Hadoop 3 simplemente podemos usar –daemon start para iniciar un daemon, –daemon stop para detener un daemon y –daemon status para establecer $? al estado del demonio. Por ejemplo, "hdfs –daemon start namenode".
Las operaciones que desencadenan conexiones ssh ahora pueden usar pdsh si están instaladas.
$ {HADOOP_CONF_DIR} ahora se paga correctamente en todas partes, sin requerir simbología y otros trucos similares.
Los scripts ahora prueban e informan mejores mensajes de error para varios estados del registro y dir pid en el inicio del demonio. Antes, los errores de shell desprotegidos se mostraban al usuario.
Comments