PDF de programación - Análisis de Hadoop y Map/Reduce

Análisis de Hadoop y
Map/Reduce
Benchmark en el SVGD
Diego Nieto





Análisis y benchmark de Hadoop



Análisis de Hadoop y MapReduce


Introducción:

Apache Hadoop es un framework basado en JAVA que soporta aplicaciones
distribuidas. Permite a las aplicaciones trabajar con miles de nodos y petabytes
de datos. Hadoop se inspiró en los documentos Google para MapReduce y
Google File System (GFS). Hadoop es un proyecto de alto nivel Apache y con
una gran comunidad base. Yahoo! ha sido el mayor contribuidor al proyecto.

Hadoop: Procesamiento de enormes cantidades de datos (TB y PB) en grandes
clusters de comodity hardware. Esta formado por 2 sistemas:


• Almacenamiento: HDFS
• Procesamiento: MapReduce


Y aporta una serie de ventajas:


• Bajo coste
• Facilidad de uso
• Tolerancia a fallos



Arquitectura

Cuatro procesos (dæmons) principales:

- En el master: namenode y jobtracker

- En los workers: datanode y tasktracker

- namenode y datanodes: sistema HDFS

- jobtracker y tasktrackers: trabajos MapReduce

Ficheros de configuración en $HADOOP_HOME/conf:

- core-site.xml: configuración principal, valores por defecto en
hadoop.apache.org/common/docs/current/core-default.html

- hdfs-site.xml: configuración del HDFS, valores por defecto en
hadoop.apache.org/common/docs/current/hdfs-default.html



Análisis y benchmark de Hadoop



1 de 11



Análisis y benchmark de Hadoop



- map-red-site.xml: configuración del MapReduce, valores por defecto en
hadoop.apache.org/common/docs/current/mapred-default.html


HDFS

Hadoop puede acceder a diferentes tipos de filesystems (local, HDFS, KFS,
S3,. . . )

Ventajas HDFS: Hadoop Distributed File System:


• Diseñado para almacenar ficheros muy grandes en commodity hardware

• Elevado ancho de banda

• Fiabilidad mediante replicación

• Tolerancia a fallos


Inconvenientes

• Elevada latencia



• Poco eficiente con muchos ficheros pequeños

• Modificaciones siempre al final de los ficheros

• No permite múltiples writers


Los principales procesos vinculados al HDFS son:


• Namenode: Mantiene la información (metadatos) de los ficheros que

• Datanode: Mantienen los datos y se encargan de la replicación de los

residen en el HDFS

mismos

• Secondary Namenode: Mantienen checkpoints del Namenode



La interfaz principal para acceder al HDFS es mediate CLI:

# hadoop dfs –help



Análisis y benchmark de Hadoop



2 de 11





Lectura de datos HDFS


Análisis y benchmark de Hadoop



Escritura de datos HDFS



(imágenes cortesía de Tomás Fernández Pena del CITIUS-USC)

Análisis y benchmark de Hadoop



3 de 11



Análisis y benchmark de Hadoop



MapReduce

Modelo de programación funcional en paralelo diseñado para escalabilidad y
tolerancia a fallos en grandes sistemas de commodity hardware:


• Basado en la combinación de operaciones Map y Reduce
• Diseñado originalmente por Google
• Usado en múltiples operaciones
• Manejo de varios petabytes diarios
• Popularizado por la implementación open source Apache Hadoop
• Usado por Facebook, Last.fm, Rackspace, yahoo, Amazon Web

Services…


Ejemplos de algunas aplicaciones de MapReduce:


• En Google:

o Construcción de índices para el buscador (pagerank)
o Clustering de artículos en Google News
o Búsqueda de rutas en Google Maps
o Traducción estadística



• En Facebook:

o Minería de datos
o Optimización de ads
o Detección de spam
o Gestión de logs



• En I+D+i:

o Análisis astronómico
o bioinformática
o
física de partículas
o simulación climática
o procesamiento del lenguaje natural


Organizaciones que usan Hadoop:


• A9.com
• AOL
• Booz Allen Hamilton
• EHarmony
• eBay
• Facebook
• Fox Interactive Media
• Freebase
•

IBM



Análisis y benchmark de Hadoop



4 de 11

ImageShack
ISI

•
•
• Joost
• Last.fm
• LinkedIn
• Meebo
• Metaweb
• Mitula15
• The New York Times
• Ning
• Powerset (ahora parte de Microsoft)
• Rackspace
• StumbleUpon16
• Tuenti
• Twitter
• Veoh
• Zoosk
• 1&1

Objetivos de las pruebas



Análisis y benchmark de Hadoop


Los objetivos principales de los set de pruebas son:


• Dimensionar rendimiento y escalabilidad del HDFS de Hadoop.

• Probar algoritmos en MapReduce para dimensionar la escalabilidad y su

capacidad de paralelización.



• Comprobar la capacidad de integración de Hadoop y MapReduce con
otras soluciones y herramientas open para proporcionar soluciones de
computación y almacenamiento alternativas:

o Que aprovechen mejor los recursos existentes.
o Que aporten una reducción de costes y consumo sin disminución
o Que sean escalables

de potencia

Descripción del hardware

El bechmark se divide en 2 sets de pruebas. Un primer set para el cluster
SVGD, centrado en dimensionar
la escalabilidad y paralelización de
MapReduce y un segundo set, para el cluster SVGD2 , orientado a dimensionar
el rendimiento del sistema de ficheros distribuido de Hadoop (HDFS).



Análisis y benchmark de Hadoop



5 de 11



Análisis y benchmark de Hadoop



En el cluster SVGD se han utilizado 16 nodos con 2 procesadores AMD
Opteron Processor 6174 2.2 GHz, por nodo (24 cores por nodo en total) y con
conectividad Gigabit Ethernet.

Para el cluster SVGD2, se han utilizado 8 nodos con 2 procesadores Intel
Sandy Bridge E5-2670 2.6 GHz por nodo (16 cores por nodo en total) y con
conectividad Infiniband de 40Gbps.

Descripción y ejecución del benchmark SVGD

Este set de pruebas se centra en analizar la escalabilidad y capacidad de
paralelización de MapReduce.

La instalación base ha constado de 4/8/16 nodos en el SVGD:


• 1x Master (namenode, secondary namenode, jobtracker, datanode y

tasktracker)

• 3/7/15 slaves/workers (datanode y tasktracker)


Como dataset se ha utilizado freebase (enciclopedia libre), una base de datos
de 5GB, y como ejemplo de código MapReduce se ha utilizado el clásico
WordCount (conteo de palabras y repeticiones de las mismas).

Los tiempos de carga no son muy significativos ya que la carga no se realiza en
paralelo, pero si el procesamiento de datos. También se puede observar que
utilizar ficheros comprimidos, no aporta mucho a la hora de procesar los datos:


#

wordcount gz

freebase

nodos

freebase
(min:seg)

gz

wordcount
(min:seg)

(min:seg)

16

8

4

7:59

7:54

7:59

2:43

2.42

2.43

3:07

4:33



7:15



3:52



5:30



7:48



Todas las máquinas han consumido entre un 10-15% de CPU. La memoria
está configurada para que no se supere el consumo de 2GB de RAM (1GB
para el datanode y 1 GB para el tasktracker). En principio se puede tunear el
número de threads para un proceso map o reduce, pudiendose optimizar al el
uso de la memoria RAM. Por ejemplo si disponemos de una aplicación



Análisis y benchmark de Hadoop



6 de 11



Análisis y benchmark de Hadoop



MapReduce, en donde el proceso map consume más memoria que el reduce,
se podría tunear el sistema para que asigne más memoria al proceso map.

La ejecución de los trabajos de procesamiento se ha realizado via interfaz CLI

# hadoop jar wordcount.jar WordCount /user/dnieto/freebase
/user/dnieto/freebase-out

La monitorización de la ejecución de los trabajo se ha realizado a través del
interfaz web del jobtracker.


Descripción y ejecución del benchmark SVGD2

Este set de pruebas se centra en analizar el rendimiento y la escalabilidad del
sistema de ficheros distribuido HDFS de Hadoop

La instalación base ha constado de 9 nodos en el SVGD2:


• 1x Master (namenode, secondary namenode y jobtracker)
• 8x Slaves (datanodes y tasktrackers)


Como prueba se van a utilizar los datos generados por el sistema de
consumo/accounting de las aplicaciones en los sistemas HPC del CESGA.
Estos datos se encuentran en un SGBD relacional, cuyo esquema está en 3FN,
configurado para transacciones (INSERTS y UPDATES). Este sistema está
montado sobre una VM con 3GB de RAM y 2 Vproc.

Para obtener un análisis de los datos de consumo es necesario ejecutar una
query que obtiene dichos datos por ejecutable, aplicación y máquina. Las
tablas del esquema consultado albergan del orden de 1000K rows y no siguen
una estrategia de particionado. El cuello de botella se detecta en la tabla en
donde se almacenan los datos del consumo de todos los ejecutables y
aplicaciones de los sistemas HPC del CESGA. Dicha tabla, que tiene unas 20
columnas cuyos valores se han calculado mediante operaciones aritméticas
básicas, alberga unos 20M de registros (5GB),. Dicha query tarda más de 60
minutos en ejecutarse, con un consumo de memoria y procesador de más del
90%, quedando la VM casi inaccesible durante la operación de consulta.

Una primera observación al respecto es que dicho sistema transaccional no
está pensado para ejecutar consultas que consulten masivamente datos de
distintas tablas y esquemas sobre los que aplican operaciones aritméticas y de
ordenamiento.

Para ello sería necesario crear un sistema OLAP, optimizado para consultas y
no para transacciones. El problema de crear este sistema es que habría que



Análisis y benchmark de Hadoop



7 de 11



Análisis y benchmark de Hadoop



utilizar hardware adicional y mantenerlo, además del sistema transaccional, con
todos los costes que esto conllevaría (mantenimiento, personal, formación, etc)

Aquí e