Descargar archivo PDF

Documento técnico de IT@Intel
Marzo de 2015
IT@Intel
Cómo TI de Intel migró con éxito
hacia Cloudera Apache Hadoop*
Resumen ejecutivo
A partir de nuestra experiencia
original con el software Apache
Hadoop , TI de Intel identificó
nuevas oportunidades
para reducir los costos de
TI y aumentar nuestras
capacidades de BI
Nghia Ngo
Ingeniero de Capacidades
de Big Data, Intel IT
Sonja Sandeen
Gerente de Producto de Big Data,
Intel IT
Darin Watson
Ingeniero de Plataformas, Intel IT
TI de Intel considera valioso el procesamiento de grandes cantidades de
datos (Big Data) basado en códigos abiertos utilizando el software Apache
Hadroop*. Hasta hace poco, utilizábamos el software Intel® Distribution
for Apache Hadoop (IDH) para soportar nuestros tres casos de uso de Big
Data en inteligencia de negocios (BI, por su sigla en inglés), y reportaba
resultados que ascendían a millones de dólares para Intel. Sin embargo,
nos dimos cuenta de que nos podríamos beneficiar con la migración hacia
el software de Distribución Cloudera para Apache Hadoop (CDH).
A partir de nuestra experiencia original con el software Apache Hadoop,
TI de Intel identificó nuevas oportunidades para reducir los costos de
TI y para aumentar nuestras capacidades en inteligencia de negocios
(BI). Gracias a la formación de una alianza estratégica con Cloudera,
TI de Intel adoptó CDH y migró rápidamente de IDH. Utilizamos las
herramientas CDH para empresas para mejorar el desempeño, la
gestión, y la facilidad de uso para los componentes clave de Hadoop.
Este documento explica los beneficios de la migración para los grupos
empresariales de TI e incluye las seis mejores prácticas desarrolladas
por el equipo de migración de Intel IT:
• Hacer una evaluación comparativa en un ambiente de prueba
• Definir la estrategia de implementación
• Dividir el ambiente del hardware
Chandhu Yalla
Gerente de Ingeniería de Big Data,
Intel IT
• Actualizar la versión de Hadoop
Seshu Edala
Ingeniero de Capacidades
de Big Data, Intel IT
• Rebalancear los datos
Sinforoso Tolentino
Ingeniero de Plataformas, Intel IT
• Crear un camino de pre-producción a producción
Se pudo lograr una migración exitosa a través de una planificación
cuidadosa, pruebas exhaustivas, comunicación proactiva y también mediante
una gestión eficiente del alcance, de los tiempos y de las habilidades.
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
Contenidos
1 Resumen ejecutivo
2Antecedentes
2 Mejores prácticas para la
migración de  IDH a CDH
Mejor Práctica 1: Identificar
las diferencias utilizando una
evaluación comparativa en un
entorno de prueba
Mejor Práctica 2: Definir
nuestra estrategia para la
implementación de cloudera
Mejor Práctica 3: Dividir el
ambiente de hardware
Mejor Práctica 4: Actualizar la
versión de hadoop
Mejor Práctica 5: Crear un
camino de preproducción a
producción
Mejor Práctica 6: Rebalancear los
datos
10Conclusión
Acrónimos
ACL
Lista de control de acceso
BI
Inteligencia de Negocios
CDH
Distribución Cloudera para
Apache Hadoop
HDFS Hadoop Distributed File
System
IDH
Intel Distribution for Apache
Hadoop
SLA
Acuerdo de nivel de servicio
2 de 10
Antecedentes
TI de Intel considera valioso el procesamiento de grandes cantidades de datos (Big
Data) basado en códigos abiertos con la utilización de Apache Hadoop*. Utilizamos
la distribución Hadoop propia de Intel, el software Intel® Distibution for Apache
Hadoop.
Luego, determinamos que pasarse a la Distribución Cloudera para Apache Hadoop
(CDH) ofrece ventajas significativas, que se muestran en la Figura 1. CDH contiene
la totalidad de la distribución a partir del proyecto de código abierto de Apache
Hadoop y también cuenta con otros componentes clave como la infraestructura
de almacén de datos Apache Hive* y el lenguaje de flujo de datos Apache
Pig*. CDH también ofrece herramientas de gestión y de desarrollo de software
empresariales para ayudar a los desarrolladores y a los administradores de
sistemas a mejorar el desempeño, gestión y facilidad de uso de los componentes
únicos de Hadoop como Cloudera Manager, Cloudera Impala, Navigator y Sentry.
La migración hacia CDH también nos permitió actualizar Hadoop de 1.0 a 2.0.
Mejores prácticas para la
migración de  IDH a CDH
Una migración exitosa necesita una cuidadosa planificación para hacer frente a
tres desafíos clave:
• Hacer frente a las variaciones de Hadoop. La instalación sin modificaciones
de Hadoop utiliza los valores de configuración preestablecidos. Estos valores
difieren dependiendo de las variaciones de Hadoop. Un análisis comparativo
puede resultar de ayuda antes de la migración (ver Mejor práctica 1: Identificar
las diferencias utilizando una evaluación comparativa en un entorno de prueba).
• Entender el alcance de los cambios. Debemos minimizar los impactos
negativos causados por los cambios de infraestructura a nuestros
desarrolladores de aplicaciones y a los clientes que utilizan dichas aplicaciones.
Para invertir y llevar a cabo dicha conversión, los equipos de las empresas o de
los clientes esperan tener la misma experiencia, o una aún mejor.
Ventajas de la Distribución
Cloudera para Apache Hadoop
Características
Soporte
Herramientas
Código abierto
Características deseables,
conjuntos de características
maduras y actualizaciones
más rápidas
Soporte basado en
el proveedor y
a nivel empresarial
Herramientas de gestión
de nivel empresarial y
de desarrollo
de software
Distribución completa
a partir del proyecto
de código abierto
de Apache Hadoop.
Figura 1. Distribución Cloudera para Apache Hadoop*(CDH) ofrece ventajas significativas.
Compartir:
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
• Completar la migración in situ puntualmente. La migración hizo que
tuviésemos que ejecutar los ambientes de IDH y de CDH en paralelo.
Nuestro objetivo fue operar ambos ambientes en tándem durante un período
de tiempo lo más corto posible para balancear todas las partes funcionales
entre los proyectos de los clientes y los cambios en la plataforma. Para hacerlo,
el equipo de migraciones tuvo que evitar que los racks o los servidores
permaneciesen ociosos durante la transferencia de datos y las pruebas.
Para abordar estos tres desafíos, el equipo de migración de TI de Intel siguió seis
mejores prácticas.
Mejor práctica 1: Identificar las diferencias utilizando
una evaluación comparativa en un entorno de prueba
Al utilizar un ambiente de prueba o restringido para efectuar una evaluación
completa de IDH y de CDH fue posible identificar las diferencias entre los
dos ambientes y, al mismo tiempo, tener una interrupción mínima en las
operaciones. El equipo de migración pudo estudiar la arquitectura de la solución
propuesta para los diversos casos de estudio y así determinar las características
críticas. Comparamos las características y las capacidades, como los marcos
de inteligencia de negocios (BI), contenedores de E/S, códecs de compresión,
seguridad y listas de control de acceso (ACL), límites de asignación de
contenedores y demás, aislando una configuración de la otra.
A partir de los resultados, el equipo confeccionó una tabla comparativa en la que
identificó las brechas y describió los diferenciadores clave, como se muestra en la Tabla 1.
Tabla 1. Comparación entre las características de la Distribución Cloudera para
Apache Hadoop* (CDH) e Intel® Distribution for Apache Hadoop (IDH)
Nota: El estudio comparativo fue realizado entre marzo y abril de 2014.
Mejor en CDH
Igual entre CDH e IDH Inexistente en CDH
Conectores
Ingestión de datos
Almacenamiento
de datos
Integración con Lustre*
Integración con
otros controladores
y software
Procesamiento por lotes
Igual
Analytics SQL
Mejor
NoSQL en línea
Búsqueda
Infraestructura
Mejor
Inexistente
Mejor
Mejor
Aprendizaje automático
Inexistente
Procesamiento de flujo
Mejor
Aplicaciones de terceros
Igual
Administración de datos
Mejor
Administración de trabajo
Igual
Administración del sistema
Igual
Alta disponibilidad
Igual
Sistema operativo
Igual
Integración Enterprise Access Management/
Igual
Microsoft Active Directory*
Seguridad
Compartir:
Inexistente
3 de 10
6 mejores prácticas
para la migración
1: Identificar las diferencias utilizando una
evaluación comparativa en un ambiente
de prueba
2: Definir nuestra estrategia para la
implementación de Cloudera
3: Dividir el ambiente de hardware
4: Actualizar la versión de Hadoop
5: Crear un camino de Preproducción a
producción
6: Rebalancear los datos
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
4 de 10
Esta tabla nos ayudó a establecer los objetivos para una migración ordenada. Luego
consultamos con Cloudera para desarrollar una hoja de ruta conjunta, solicitándoles
que indicaran sus compromisos para implementar las capacidades faltantes o
diferentes. En este momento el equipo evaluó el costo de la refactorización: es decir
la cantidad de cambios, pruebas y el tiempo que insumiría modificar la arquitectura
para obtener las ventajas de las recomendaciones de diseño de la distribución
de Cloudera. Optamos por hacer algunos cambios de diseño y de arquitectura, y
seleccionamos solamente los compuestos obligatorios de la distribución en vez de
adoptar todos los componentes disponibles de Hadoop.
Incluimos las diferencias entre el
ambiente de prueba y el camino
hacia la producción en lo que
respecta a la red y al hardware
como parte de los cálculos.
Hicimos cambios en el diseño y en los códigos para adaptarlos a cualquier
diferencia de características. Tomemos como ejemplo el soporte para el códec de
compresión sin pérdida. Utilizar el códec de CDH que es menos eficiente podría
impactar tanto en el código más adelante en el proceso como en la capacidad del
disco, de la memoria o de la CPU. Necesitábamos suficiente tiempo para poner
a prueba un nuevo código que utilice el códec de CDH y evaluar los efectos del
uso adicional de los recursos; de no ser así hubiésemos tenido una brecha en el
cronograma de trabajo que Cloudera hubiese tenido que resolver.
Crear un ambiente de prueba
Dentro del ambiente de prueba el equipo se aseguró de que todo lo planeado para
la migración funcionase como habíamos anticipado. La implementación del IDH
existente sirvió como base de los benchmarks funcionales, de desempeño y de
pruebas de datos. Los datos de prueba incluyeron los métodos de transferencia o de
copia, y también la velocidad de transferencia. Necesitábamos esta información para
determinar los plazos de implementación y así trazar un camino seguro antes de entrar
en producción. Incluimos las diferencias entre el ambiente de prueba y el camino hacia
la producción en lo que respecta a la red y al hardware como parte de los cálculos.
La implementación de CDH tenía que igualar los benchmarks paramétricos previos, o
sobrepasarlos, y también cumplir con los criterios no paramétricos.
Utilizar niveles de abstracción para simplificar la migración
La utilización de un nivel de abstracción con URL personalizados, soft links y proxies de
alta disponibilidad simplificó la migración. Por ejemplo, debido a que las bibliotecas de
IDH no se encontraban en el mismo lugar que las bibliotecas de CDH, utilizamos soft
links en vez de hacer una codificación dura de las ubicaciones de las bibliotecas.
Utilizar las capacidades de código abierto de Hadoop y minimizar las personalizaciones
Nos dimos cuenta de que la mayor parte del ecosistema central, como Hive y Pig,
entre otros, se comportaba de la misma manera en la implementación de CDH
que en la de IDH. La migración de código tuvo un impacto mínimo o nulo en los
clientes y en sus aplicaciones. A partir de nuestra propia experiencia y según lo que
vimos cuando nuestros clientes desarrollaron sus aplicaciones con Hive y con Pig,
descubrimos que estos componentes no necesitaban una modificación del código
para tener un desempeño sin dificultades en el entorno de CDH. Solamente un
proyecto, en el que se utilizaba Apache Mahout*, necesitó un mínimo cambio de
código debido a que la API de MapReduce* más antigua cayó en desuso frente a la
API más reciente de MapReduce. La actualización del código para utilizar la API más
reciente hace que cualquier conversión futura resulte más fácil.
Como resultado de las pruebas y del mapeo dentro del ambiente de prueba, nuestro
equipo pudo determinar que los cronogramas de trabajo eran sólidos y sin brechas.
Como mínimo, se documentó claramente cuándo se corregirían las brechas.
Compartir:
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
Mejor práctica 2: Definir nuestra estrategia para la
implementación de cloudera
Una vez concluida la fase de prueba, el equipo decidió qué opciones
y componentes clave incluir en la migración inicial y registró los
beneficios y los riesgos de dicha elección. Las opciones y componentes
críticos incluyeron seguridad, interfaces de usuario, APIs, lenguajes de
desarrollo y compatibilidad con la versión. Buscamos mantener todo el
ambiente simple durante la migración, preservando la estabilidad antes
de agregar servicios o características.
Tabla 2. Consideraciones para la migración de
Intel® Distribution for Apache Hadoop* (IDH) a la
Distribución Cloudera para Apache Hadoop (CDH)
Alcance
Migrar todas las plataformas y proyectos
internos de Big Data de IDH a CDH.
Estrategia
•Dividir el hardware a la mitad, instalar
CDH, y ejecutar los ambientes en
paralelo durante la migración.
•Alinear todos los clientes para que
completen la fase de prueba en CDH y
transición.
•Desinstalar IDH y agregar el hardware
al ambiente de CDH para volver a la
capacidad plena.
•Focalizarse solamente en los
componentes Hadoop* centrales
necesarios para los clientes actuales.
Se adoptarán nuevas características
y capacidades de CDH después de
la transferencia y una vez que los
ambientes retomen la capacidad plena.
Nuestras selecciones de componentes y de opciones validaron nuestros
hallazgos durante el entorno de prueba y fueron incorporadas a nuestra
estrategia de migración. En la Tabla 2 incluimos dicha estrategia y
también los beneficios, los riesgos potenciales y el estado actual.
La información presentada en la tabla guió la estrategia para migrar
el servicio Hive metastore y los archivos de metadatos. Tuvimos que
determinar nuestro marco de tiempo para la migración teniendo en
cuenta el impacto sobre nuestros clientes, los cambios en el código, las
pruebas de regresión y los tiempos de ciclos de ejecución.
Un componente que es fácil de pasar por alto durante la migración es
el servicio Hive metastore. Hadoop brinda abstracción de cómputo con
API de MapReduce y abstracción de almacenamiento con API de Hadoop
Distributed File System (HDFS). Resulta fácil centrarse en la transición de
estos componentes centrales y dejar de lado los componentes auxiliares
aunque importantes como el servicio Hive metastore, que necesita bases
de datos externas como MySQL o Postgres y es crítico para migrar las
tablas de almacenes de datos de una plataforma a otra. La distribución
central de Hadoop no brinda las herramientas para migrar los tipos de
datos del servicio Hive metastore como seguridad, compresión, listas de
control de acceso e información sobre tablas extendidas. Esa parte de la
migración precisa herramientas (o scripts) personalizados/adaptados que
puedan capturar, replicar y migrar hacia la nueva plataforma.
Beneficios •Adoptar el soporte del producto y del
proveedor de CDH ahora y alinearse con
las iniciativas estratégicas.
•Un único esfuerzo de pruebas de
regresión de la migración de CDH y
Hadoop 2.x/YARN.
• Menos recursos ahora para poner a prueba
el alcance actual de los casos de uso.
•Evitar la conversión a gran escala y las
pruebas de regresión significativas de
todo el proyecto más adelante.
• Aprovechar las ventajas de CDH cuanto antes
(Hue, HCatalog, Impala, Navigator y Sentry).
Riesgos e
impactos
• Clientes: riesgo e impacto mínimos
para las pruebas y para la migración de
dos proyectos de producción basados
en las pruebas iniciales y tempranas.
Contaremos con más información
después de recibir los resultados de las
pruebas de aplicaciones Customer Insight
y de la Sales and Marketing Account
Recommendation Tool.
• Plataforma: riesgo potencial si los clientes
demoran la migración a CDH de modo
que los ambientes permanecen divididos,
lo que implica necesidad de soporte,
mitad de la capacidad y un comienzo
demorado de las nuevas evaluaciones de
las características de Cloudera.
Estado
actual
•Migración de IDH a CDH completada en
cinco semanas.
•En la actualidad se ejecuta CDH 5.3 en
producción.
•Se completaron dos actualizaciones de
versión desde la integración inicial con
cero impacto a los clientes.
Durante la migración, cuando el ambiente se encontraba dividido en
dos partes, nos comunicamos con los clientes por la posibilidad de que
la plataforma sea más lenta. Reconfiguramos los acuerdos de nivel de
servicio (ANS) para el procesamiento de ciclos y diferimos todas las
actividades de puntos de referencia (benchmarking) de desempeño.
Compartir:
5 de 10
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
6 de 10
Mejor Práctica 3: Dividir el ambiente de hardware
Características de los
ambientes de
hardware dividido
• Dos switches de 10GbE de 48
puertos
• 352 núcleos que utilizan
procesadores Intel® Xeon®
• Intel® Distribution of Hadoop 2.51
basada en Hadoop Apache 1.x
• 22 nodos de datos equivalentes a
243 TB (replicación de 3 vías)
• Alta disponibilidad con verdadera
conciencia de racks
•Integración de la base de datos
con Teradata, Netezza, y MS SQL
•Integración con Enterprise ETL,
Active Directory/EAM e ITSM
El equipo de migración de TI de Intel dividió el ambiente de hardware de
Hadoop existente en dos clústers (uno para IDH y el otro para CDH) y completó
la construcción de dos sistemas paralelos utilizando los componentes
disponibles, según se observa en la Figura 2.
No pudimos hacer una migración in situ por tres razones. Primero: no
queríamos perder HDFS debido a que contenía grandes volúmenes de datos
distribuidos en los servidores. Segundo: queríamos pasar de Hadoop 1.0 a 2.0.
Tercero: IDH y CDH corrían Hadoop de maneras diferentes. Cada uno administró
los clústers con herramientas diferentes de aprovisionamiento y de gestión. Por
lo tanto, no pudimos migrar fácilmente de IDH a CDH in situ sin el software y las
configuraciones de reaprovisionamiento. Tuvimos que crear un clúster de CDH
sobre el hardware existente y migrar los datos de IDH a CDH.
Aún si hubiese sido posible una actualización in situ, hubiéramos necesitado
hacer un back up de terabytes de datos en otro clúster y luego transferirlo
nuevamente al clúster de CDH. Debido a que íbamos a transferir datos de
todas maneras, creamos el nuevo clúster de CDH en la misma red que el clúster
de IDH y planificamos transferir los datos directamente desde el viejo clúster de
Hadoop hacia el nuevo clúster. Los sistemas en paralelo brindaron la solución
más limpia y segura, considerando que estábamos trabajando con hardware
disponible limitado y que queríamos migrar los datos solamente una vez.
La división funcionó bien por las siguientes razones:
• Si bien teníamos hardware limitado contábamos con suficiente capacidad
de cómputo y de almacenamiento adicional para soportar la división del
hardware, lo que permitió desafectar nodos de IDH y construir un clúster de
CDH de tamaño suficiente como para soportar las migraciones de datos.
Rack 1
Rack 2
HBase Master, Oozie, ZooKeeper
Gateway
Nodo de datos 1
NameNode, Hive Metastore
NameNode secundario, Job History
Server, Resource Manager, ZooKeeper
Nodo de datos 2
ZooKeeper
Cloudera Manager
Nodo de datos 3
JobTracker
Backup JobTracker
Intel® Manager, Yum Repository
NameNode secundario,
Hive Metastore
NameNode primario, Hive Metastore
HBase Master, ZooKeeper
Gateway
Almacenamiento compartido de Gateway
Nodo de datos 1
Nodo de datos 1
Nodo de datos 2
Nodo de datos 2
Nodo de datos 3
Nodo de datos 3
Nodo de datos 4
Nodo de datos 4
Nodo de datos 1, NodeManager
Nodo de datos 1, NodeManager
Nodo de datos 2, NodeManager
Nodo de datos 2, NodeManager
Rack 3
Nodo de datos 4
Nodo de datos 1, NodeManager
Nodo de datos 2, NodeManager
Nodo de datos 3, NodeManager
Nodo de datos 4, NodeManager
Nodo de datos 5, NodeManager
Nodo de datos 6, NodeManager
Intel Distribution for Apache Hadoop
Distribución Cloudera para Apache Hadoop
Figura 2. Se dividió el ambiente de hardware en dos clústers, uno para Intel® Distribution
for Apache Hadoop* y el otro para la Distribución Cloudera para Apache Hadoop.
Compartir:
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
7 de 10
• Al segregar el hardware nos mantuvimos operativos durante la transferencia
de datos. Nuestros recursos de IDH fueron suficientes para la carga de
trabajo del cliente; sin embargo, tuvimos que coordinar con proyectos para
asegurarnos un impacto mínimo sobre los acuerdos de nivel de servicio
existentes y hacer un lote con las expectativas de desempeño a lo largo del
proceso de migración.
• Con clústers comparables construimos en uno y portamos hacia el otro.
Minimizar el impacto en los usuarios
Construimos el nuevo clúster
CDH en la misma red que el
clúster IDH y planificamos
transferir los datos
directamente del clúster
Hadoop antiguo al nuevo.
Al colocar IDH y CDH en la misma red local se facilitó la rápida transferencia de
datos de IDH a CDH. Al asignar la mitad de los servidores disponibles a cada
ambiente pudimos completar la migración con un impacto negativo mínimo
en las aplicaciones de nuestros clientes. La naturaleza distribuida de Hadoop
contribuyó con este enfoque.
El equipo de TI de Intel descargó los datos en un conjunto de nodos de datos y
luego desactivó el hardware que queríamos preparar para usar dentro del nuevo
entorno de CDH. Desinstalamos unos pocos servidores por vez, lo que le permitió
al clúster de IDH redistribuir los datos a los nodos restantes. Al manejar el proceso
de desinstalación del clúster de IDH pudimos mitigar la pérdida de datos y
monitorear el impacto en la carga de trabajo del clúster. Agregamos los servidores
que habían quedado liberados del clúster de IDH desafectado al clúster de CDH.
Al construir el clúster de CDH en la misma red que IDH y en los mismos racks
pudimos transferir los datos de IDH a CDH con rapidez. Utilizamos el failover
implícito y la tolerancia de fallas del marco de Hadoop para efectuar una
desactivación y reactivación por fases de los nodos de clústers entre los sistemas
paralelos. Al utilizar una infraestructura de red común disminuyeron los saltos entre
los nodos de IDH y de CDH y se aprovecharon las conexiones de 10G en todos los
hosts de transferencia de datos, lo que redujo el tiempo de transferencia de datos
entre clústers y minimizó el impacto en nuestra carga de trabajo existente en IDH.
Mejor práctica 4: Actualizar la versión de hadoop
Características de
Hadoop 2.0
El cambio de Hadoop 1.0 a Hadoop 2.0 resultó simple y directo. El equipo obtuvo
las características deseables que no estaban incluidas en IDH, junto con las
ventajas de una plataforma de código abierto. Estas características incluyen:
• Alta disponibilidad de HDFS
NameNode
• Alta disponibilidad para el NameNode de HDFS, que elimina el único punto
de falla previo en HDFS y las soluciones específicas de la distribución y de alta
disponibilidad de Hadoop.
• Instantáneas del sistema de
archivos de HDFS
• NameNodes federados
• Mejora en el desempeño
• YARN
• Soporte para las instantáneas (snapshots) de sistema de archivo en HDFS, que
le brinda a Hadoop procesos de backup nativo y de recuperación de desastres.
• Soporte para los NameNodes federados, que permite una escalabilidad
horizontal del espacio de nombres del sistema de archivos.
• Soporte para el acceso de NFS a HDFS, que permite que HDFS sea montado
como un sistema de archivos estándar.
• Soporte para encripción de red Native, que asegura los datos mientras están
en tránsito.
• Mejora en el desempeño para HDFS.
Compartir:
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
8 de 10
Además de estas características el sistema de gestión de recursos YARN puede
manejar una gran gama de cargas de trabajo al usar un clúster de Hadoop para
dar servicio a los marcos emergentes que no sean MapReduce, como Spark,
Impala y HBase. Esta nueva flexibilidad expande los casos de uso para Hadoop, al
tiempo que mejora la eficiencia de ciertos tipos de procesamiento sobre datos ya
almacenados en ese lugar.
Mejor práctica 5: Crear un camino de preproducción a
producción
Después de dividir el ambiente físico en un clúster de IDH y otro de CDH,
creamos un ambiente de preproducción que nos permitiría validar nuestros
procesos. El ambiente de preproducción fue alimentado por 128 núcleos (que
utilizaban procesadores Intel® Xeon®) e incluía volúmenes de datos reales, según
se muestra en la Figura 3. Estos volúmenes de datos consistieron en 8 nodos de
datos que eran equivalentes a 160 TB (con una replicación de dos vías).
La creación de un ambiente de preproducción nos permitió migrar
incrementalmente los datos al ambiente de CDH y comenzar con el proceso de
migración de datos de manera temprana, lo que nos dio suficiente tiempo para
completarlo y para tener una rápida transición al nuevo entorno de CDH.
En este ambiente de preproducción seguimos los siguientes pasos:
• Evaluamos el tiempo necesario para pasar de IDH a CDH.
• Alineamos los derechos, los servidores de control y los usuarios entre los
dos sistemas sin automatización.
• Para saber cuáles eran los mejores métodos para migrar los datos a
la nueva plataforma consultamos con Cloudera una serie de temas:
estándares de compresión de datos, estándares de seguridad de datos,
estándares de transferencia de datos, backup y procesos de restauración
de metadatos, factores de replicación, lineamientos de accesibilidad del
usuario (vía Hue), asignación de memoria Impala y lineamientos para el
manejo de recursos.
• Identificamos niveles de datos, códecs de compresión y factores de
replicación que optimizaban la transferencia de datos en línea y fuera
de línea. Luego comunicamos todos los cambios necesarios a los
desarrolladores de funciones de ALMACENAMIENTO y de CARGA de Intel
para que pudiésemos implementar adecuadamente los cambios en el
espacio de nombres de HDFS y códecs.
• Utilizamos scripts personalizados para el servicio Hive mestastore, y para
la migración de la lista de control de acceso. Tuvimos que capturar los
esquemas de gestión, permisos y partición. Creamos manualmente los
scripts fuera de línea antes de migrar los datos.
Una semana después implementamos el sistema en el entorno de
preproducción. Repetimos estas mismas tareas en el entorno de producción.
Este proceso ayudó a minimizar el riesgo y el impacto al desarrollo y a
los esfuerzos de corrección de errores que pudieran dar como resultado
diferentes distribuciones en los entornos de preproducción y de producción.
Compartir:
Rack 1
Preproducción
Gateway
Gateway (Sqoop1, HiveServer2)
NameNode, Hive Metastore, Zookeeper
JobTracker
Backup JobTracker
HBase Master, Zookeeper
HBase Master, Zookeeper, Servidor Oozie
NameNode secundario Job History Server, ZooKeeper
Resource Manager, ZooKeeper
Cloudera Manager
Intel® Manager
NameNode primario Hive Metastore
NameNode
Nodo de datos, NodeManager
Nodo de datos, NodeManager
Nodo de datos, NodeManager
Nodo de datos, NodeManager
Nodo de datos, NodeManager
Nodo de datos, Servidor de región
Nodo de datos, Servidor de región
Nodo de datos, Servidor de región
Nodo de datos, Servidor de región
Nodo de datos, Servidor de región
Intel Distribution for Apache Hadoop
Cloudera Distribution for Apache Hadoop S
Figura 3. El ambiente de preproducción
nos permitió validar nuestros procesos.
Este ambiente fue alimentado por 128
núcleos (que utilizaban procesadores
Intel® Xeon®) y ocho nodos de datos que
contenían volúmenes de datos reales.
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
9 de 10
Mejor práctica 6: Rebalancear los datos
En el ambiente de producción, debido a que teníamos dos modelos de
configuraciones datos-nodo-almacenamiento-capacidad, parte del proceso de
migración requirió un rebalanceo continuo de los datos de HDFS dentro del clúster.
HDFS cuenta con una utilidad que balancea la ubicación de los bloques de datos en
los nodos de datos de manera uniforme para obtener un desempeño óptimo.
Camino de madurez
de Hadoop
Hadoop 1.0
2005-2012
MapReduce
HDFS
Hadoop 2.0
2013-2014
El procesamiento de datos
se ejecuta nativamente
MapReduce
Procesamiento
de datos
YARN
HDFS
Hadoop de próxima generación
Las aplicaciones se ejecutan nativamente
Map
Open
Reduce Tez HBase Storm Giraph Spark MPI
YARN
HDFS
Utilizar nodos más antiguos de baja capacidad junto con nodos más nuevos de
alta capacidad creó una distribución poco uniforme. Los nodos de baja capacidad
se llenaban mientras que se cargaban los datos en el clúster de CDH, lo que
desencadenaba un rebalanceo constante para redistribuir los datos de los nodos de
baja capacidad hacia los de alta capacidad.
Aprovechamos la funcionalidad de rebalanceo en CDH que se puede ejecutar
desde la interfaz de usuario de Cloudera Manager. Después de cada proceso de
rebalanceo y de migración de datos, el equipo evaluó la distribución de datos e hizo
el rebalanceo según las necesidades.
Con nodos limitados, habríamos desequilibrado la capacidad del espacio del disco.
Por lo tanto detuvimos la carga de datos durante la migración.
Por último, el equipo documentó todos los cambios en el middleware o en kernel y
estableció las siguientes mejores prácticas de migración:
• Documentar los límites del contenedor para las asignaciones en comparación
con los rastreadores de tareas, APIs HCatalog para I/O entre Pig, Hive y
MapReduce. Documentar también las limitaciones del marco Impala: UDFs,
formatos de E/S, limitaciones de memoria, tablas internas y externas. Éstos
orientan a Spark y afectan la posición de Hive, Spark e Impala como almacén de
datos, ETL a granel y análisis en la memoria.
• Revisar y entender las diferencias y los valores de configuración que se deben
modificar. Algunos cambios clave que necesitaron ajustes estaban relacionados
con la asignación de recursos de MapReduce 1 a MapReduce 2/ YARN1 .
• Estabilizar el clúster con los componentes necesarios de migración solamente
antes de activar servicios o capacidades adicionales.
• Utilizar redes troncales con mucho ancho de banda para soportar las
migraciones de datos y minimizar el impacto de los procesos de transferencia
de datos y ajustar las configuraciones de ancho de banda de la copia distribuida.
• Verificar que los requisitos del firewall de la red estén configurados para
soportar la distribución de Hadoop.
• Utilizar nombres personales DNS en nodos límite o gateway e interfaces clave
para reducir el impacto en el desarrollo.
• Coordinar proyectos para monitorear y tener un impacto mínimo sobre los
acuerdos de nivel de servicio existentes y as expectativas de desempeño en el
trabajo por lotes a lo largo del proceso de migración.
• Asegurarse de que los parámetros de ajuste del sistema operativo, los
requisitos de permisos y los requisitos de espacio en el disco estén en línea con
cada uno de los requisitos de distribución de Hadoop.
1
Compartir:
MapReduce 2 es una actualización para la planificación de tiempos, gestión de recursos y ejecución en Hadoop. Lea el blog
para obtener información adicional en blog.cloudera.com/blog/2013/11/migrating-to-mapreduce-2-on-yarn-for-users
Documento técnico de IT@Intel : Cómo TI de Intel migró con éxito hacia Cloudera Apache Hadoop*
Conclusión
10 de 10
IT@Intel
El programa IT@Intel conecta a profesionales
de TI alrededor del mundo con sus colegas
dentro de Intel. Nuestro departamento
de TI resuelve algunos de los problemas
tecnológicos más exigentes y complejos de la
actualidad, y queremos compartir las lecciones
directamente con otros profesionales de TI en
un foro abierto de pares.
Nuestro objetivo es simple: mejorar la eficiencia
en toda la organización y aumentar el valor
para el negocio de las inversiones en TI.
Síganos y participe de nuestras
conversaciones en:
• Twitter
• #IntelIT
• LinkedIn
• IT Center Community
TI de Intel obtuvo una valiosa experiencia a partir de esta migración. A
pesar de que la migración de Hadoop fue compleja e involucró múltiples
niveles de cambio, el movimiento fue exitoso. Dependimos poco de los
equipos de aplicaciones y no encontramos ningún problema significativo
asociado con la migración de una distribución a la otra. Una planificación
cuidadosa, pruebas exhaustivas y una comunicación proactiva junto con
un manejo eficiente del alcance, de los tiempos y de las habilidades nos
ayudaron a tener una migración exitosa.
Cuando se haga una migración de Hadoop, tenga en cuenta los
siguientes consejos:
Elija con cuidado el equipo de migración. La tecnología es importante;
sin embargo, tener ingenieros de software con las habilidades necesarias
es esencial. Los proyectos de migración pueden resultar muy complicados;
por lo tanto, resulta fundamental para el éxito del proyecto planificar con
antelación, evaluar en detalle ambos productos y entender las brechas.
Conforme un pequeño equipo que entienda la solución en su totalidad:
las plataformas, el código y las ramificaciones de la migración de datos.
Asegúrese de que el equipo pueda comunicarse, ejecutar y evaluar la lista de
cambios que es necesario sincronizar para una migración exitosa.
Visítenos hoy mismo en intel.com/IT o
póngase en contacto con su representante
local de Intel para obtener más información.
Información relacionada
Visite intel.com/IT para obtener contenidos
sobre temas relacionados (en inglés):
Aproveche las opciones del código abierto. TI de Intel se benefició con
la distribución de Hadoop que cuenta con un código abierto en su núcleo,
no un software propietario. Mantenerse con los componentes de software
de código abierto ayuda a minimizar el costo total de propiedad. Comenzar
a una escala pequeña ayuda a mantener el foco en el diseño y en la
escalabilidad de la plataforma.
• Cómo Intel implementó una solución
de bajo costo para Big Data en cinco
semanas
• Las Mejores prácticas de TI de Intel
para implementar el software Apache
Hadoop*
Mantenga el diseño tan simple como sea posible. TI de Intel priorizó la
integración de los componentes y de las capacidades según los casos de uso,
en vez de pensar que se deben activar características completamente nuevas.
Mantuvimos un equilibrio de alcance, tiempos, pruebas y recursos. Si no
resulta claro qué características activar, priorice solamente las que indiquen los
casos de uso actuales. A partir de allí, el equipo podrá construir y avanzar en
los conjuntos de características según sea necesario. Para nuestra migración
los equipos técnicos, de negocios y de modelos utilizaron un método de
descubrimiento iterativo para entender los datos. Los entornos divididos
ayudaron a simplificar la transferencia de datos. En general, mantener simple el
proceso de migración fue la clave para nuestra migración exitosa.
• La Integración de Apache Hadoop* en el
ambiente de Big Data de Intel
Para obtener información adicional sobre las mejores
prácticas de TI de Intel visite www.intel.com/IT.
LA INFORMACIÓN EN ESTE DOCUMENTO PRETENDE SER DE CARÁCTER GENERAL Y NO UNA GUÍA ESPECÍFICA. LAS RECOMENDACIONES (INCLUYENDO LOS POTENCIALES
AHORROS DE COSTOS) ESTÁN BASADAS EN LA EXPERIENCIA DE INTEL Y SON SOLAMENTE ESTIMACIONES. INTEL NO GARANTIZA NI ASEGURA QUE OTROS PUEDA OBTENER
RESULTADOS SIMILARES.
LA INFORMACIÓN EN ESTE DOCUMENTO SE SUMINISTRA EN RELACIÓN CON PRODUCTOS Y SERVICIOS INTEL. EL PRESENTE DOCUMENTO NO OTORGA NINGUNA LICENCIA, NI
EXPRESA NI IMPLÍCITA, NI POR EXCLUSIÓN, NI DE NINGUNA OTRA MANERA, SOBRE NINGÚN DERECHO DE PROPIEDAD INTELECTUAL.
A EXCEPCIÓN DE LO ESTABLECIDO EN LOS TÉRMINOS Y CONDICIONES DE VENTA DE INTEL PARA DICHOS PRODUCTOS. EN NINGÚN CASO INTEL
SERÁ RESPONSABLE Y CONSECUENTEMENTE RECHAZA CUALQUIER GARANTÍA EXPLÍCITA O IMPLÍCITA CON RESPECTO A LA VENTA Y/O EL USO DE
LOS PRODUCTOS Y SERVICIOS INTEL, INCLUYENDO LAS RESPONSABILIDADES O GARANTÍAS RELACIONADAS CON LA IDONEIDAD PARA UN FIN DETERMINADO, LA
COMERCIABILIDAD O LA INFRACCIÓN DE CUALQUIER PATENTE, DERECHO DE AUTOR U OTRO DERECHO DE PROPIEDAD INTELECTUAL.
Intel, el logotipo de Intel y Xeon son marcas comerciales de Intel Corporation en los EE. UU. y en otros países.
*Otros nombres y marcas pueden ser reclamados como propiedad de terceros.
Copyright © 2015 Intel Corporation. Todos los derechos reservados.
Impreso en EE. UU
Por favor reciclar
0315/JSED/KC/PDF