Arquitectura HDFS

El diseño del sistema de archivos HDFS se basa en el Google File System (GFS).

- Es capaz de almacenar una gran cantidad de datos (terabytes o petabytes).

- Esta diseñado para almacenar los datos a traves de un gran numero de maquinas.

- Implementa replicacion de datos para enfrentar mal funcionamiento o perdida de equipos en el cluster.

- Para mejorar la relacion Hadoop – MapReduce, HDFS permite que los datos sean leidos y procesados localmente.

HDFS_Architecture

Los archivos de entrada se dividen en bloques de un tamaño fijo (64Mb por default), que se almacenan de manera distribuida en un cluster Hadoop. Un archivo puede estar formado por varios bloques, que se almacenan en diferentes DataNodes (máquinas individuales en el cluster) escogidos al azar. Como resultado, el acceso a un archivo por lo general requiere el acceso a múltiples DataNodes, lo que significa que el HDFS soporta tamaños de archivo mucho más grandes que una capacidad de disco de una sola máquina.

El NameNode, almacena toda la metadata del sistema de archivos en el clúster. Esto significa que HDFS implementa una arquitectura maestro / esclavo. Un único NameNode (que es un servidor primario) gestiona el espacio de nombres del sistema de archivos y se regula el acceso a los archivos de los clientes. La existencia de un único maestro en un clúster simplifica en gran medida la arquitectura del sistema, pero tiene como debilidad que es un unico punto de falla (Single Point of Failure). El NameNode sirve como un solo árbitro y repositorio para todos los metadatos HDFS.

Debido a la relativamente baja cantidad de metadata por archivo (sólo controla los nombres de archivo, los permisos y la ubicación de cada bloque), el NameNode almacena todos los metadatos en la memoria principal, lo que permite un rápido acceso aleatorio. Como resultado, un NameNode con 4 GB de RAM es capaz de soportar un gran número de archivos y directorios.

Varios DataNodes son servidores de un unico archivo, lo que significa que un archivo puede estar disponible en caso de que se pierda una de esas máquinasHDFS replica cada bloque a través de una serie de máquinas (tres, de manera predeterminada).

Cada DataNode envía periódicamente un heartbeat al NameNode. El NameNode marca los DataNode que no han enviado su hearbeat durante 10 minutos (default) como muertos y deja de enviar I/O requests a dichos nodos. Alli comienza el proceso de replicacion de los datos que contenia dicho nodo para mantener el replication factor (3 por default).

Si el replication factor es de 3, significa que el dato tiene que estar almacenado en 3 nodos en todo momento.

Publicado en Uncategorized | Etiquetado , , | Deja un comentario

Hive logs to stdout

Muchas veces necesitamos debugear alguna consulta Hive que esta dando error. Una manera facil es habilitar el logger por consola:

hive.root.logger specifies the logging level as well as the log destination. Specifying console as the target sends the logs to the standard error (instead of the log file).

$HIVE_HOME/bin/hive -hiveconf hive.root.logger=INFO,console

Mas informacion:

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Cli

 

Publicado en Uncategorized | Etiquetado , | Deja un comentario

Hive query with JOIN, GROUP BY and SUM does not return results

On Hive 0.11, and lower versions, if we set:

set hive.optimize.skewjoin=true; 
set hive.auto.convert.join=false;

A query with JOIN, GROUP BY and SUM does not return results.

But if we make the query a little more simple, using JOIN but not GROUP and SUM functions, We will GET RESULTS.

I have found that there are bugs reported recently:

https://issues.apache.org/jira/browse/HIVE-5888

and

https://issues.apache.org/jira/browse/HIVE-6041

This bug is related also with the previous one (https://issues.apache.org/jira/browse/HIVE-6520), already reported:

If we set:

set hive.optimize.skewjoin=true; 
set hive.auto.convert.join=true;

We will no have any output.

The reason is that the skew join in hive relies on a reduce phase to save skewed keys on local disk, but hive.auto.convert.join=true turns a mapreduce task into a mapjoin task in some scenarios.

As a result, there is no skewed keys generated by the mapjoin and the result is empty.

If you set hive.auto.convert.join=false to disable the auto conversion of a mapjoin, the performance is very bad because the reduce phase takes a very long time to process the skew keys.

 

This is expected to be resolved on version hive-0.13.0.

Publicado en Uncategorized | Etiquetado , | Deja un comentario

check system variables or environment variables on Hive

On Hive we can check values for system variables or environment variables with the command:

hive> set;

if we need to ask for a specific variable value, we can run:

hive> set hive.security.authorization.enabled; 
hive.security.authorization.enabled=false

More information:

https://cwiki.apache.org/confluence/display/Hive/AdminManual+Configuration

Publicado en Uncategorized | Etiquetado , | Deja un comentario

Actualizar OpenSSL / Update to 1.0.1g

Actualizar OpenSSL a la utilma version en tres pasos:

1) compilamos e instalamos la ultima version de openssl version:
$ sudo curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install_sw

2) Reemplazamos la vieja libreria openssl por la nueva con un link simbolico
$ sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

3) Probamos:

$ openssl version

Deberia devolver:

OpenSSL 1.0.1g

 

Publicado en Uncategorized | Etiquetado , | 2 comentarios

Stress Test: Bees With Machine Guns !

Hace unos días probé una herramienta sumamente interesante: Bees With Machine Guns !!

Esta es una herramienta para realizar pruebas de stress sobre los servicios Load Balancer y Autoscaling de Amazon AWS.

Luego de armar nuestra estructura de servidores, podremos generar una prueba de carga con las abejas. De esta manera, veremos actuar al servicio de Autoscaling creando nuevas instancias de nuestro servidor o decrementando las instancias si la carga disminuye.

Instalación:

$ git clone git://github.com/newsapps/beeswithmachineguns.git
$ easy_install beeswithmachineguns

Creamos archivo de Credenciales:

[Credentials]
aws_access_key_id = <your access key>
aws_secret_access_key = <your secret key>

Estas credenciales deben colocarse en el archivo .boto en nuestro home. Conteniendo la key y secret key que utilicemos en nuestra cuenta de Amazon AWS. Estas credenciales serán utilizadas por la aplicacion para crear las abejas, que no son otra cosa que instancias EC2.

Utilización:

bees up -s 4 -g public-sg -k hvivani-virg-1
bees attack -n 10000 -c 250 -u http://loadbalancer.hvivani.com/
bees down

La primera linea crea 4 abejas (instancias ec2) utilizando las credenciales del archivo .boto junto con los permisos seteados en ‘public-sg’ (Security Group definido en la región) y la key ‘hvivani-virg-1′ (llave privada utilizada para conectar a cualquier instancia en la región).

La segunda linea llama a las 4 abejas a atacar el sitio http://loadbalancer.hvivani.com/ con 10000 solicitudes de a 250 cada vez.

La ultima linea elimina las abejas (termina las instancias de ataque).

A jugar …

Publicado en Uncategorized | Etiquetado , , | Deja un comentario

Running on Molteno Reservoir – Cape Town

 

Registro Runkeeper: http://runkeeper.com/user/hvivani/activity/304377030

 

Publicado en Running & Cycling | Deja un comentario