Visualizaciones de Big Data

Voy a hablar, más o menos, de un tema muy importante, pero que no domino mucho. Más bien, no domino ni de broma, pero debería. Me refiero a las visualizaciones.

Me paso el día hablando a gente de que Hadoop es la caña, que si terabytes de datos, que si Cassandra por aquí que si HBase por allá, pero siempre hay que "visualizar" los datos no?, si nos curramos todo esto, al menos que se pueda mostrar el trabajo.

La visualización es todo un mundo, hay que tocar un poco de matemáticas, un poco de estadística, informática y sobretodo arte.

Voy a intentar hablar un poco más sobre visualizaciones en este blog, pero hoy vengo preparado con un gran ejemplo.

Uno de mis ex-colegas en last.fm Martin Dittus (blog, last.fm, twitter) se ha currado una visualización de todos los scrobbles de todos los trabajadores (y ex-trabajadores de last.fm). En mi caso estamos hablando de la visualización de 129.000 canciones en 7 años.

Sobre este gran trabajo han aparecido comentarios en algunos lugares de la web, por ejemplo:

• El blog de Martin
• Infosthetics

Vamos a ver la visualización de mi historia musical: 

http://last.fm/user/grindthemall 

Vamos a analizarla un poco, en el eje de las X podemos ver los años, empezé a usar last.fm en el 2005, cuando un compañero de Gridcat me lo enseñó. Bueno, durante los primeros meses y hasta el Julio del 2006 podemos ver una historia de scrobbles un poco difusa y repartida por las 24 horas del día, básicamente demostrando que tenía unos horarios un tanto animales durante mis años universitarios.

De repente los scrobbles se agrupan en 8/9 horas, si señores, empezé a trabajar en el B.S.C. con horario fijo.  Creí que se iba a ver un cambio en 2009, cuando me fui a vivir a Londres, pero parece que el cambio horario (sólo de una hora) no es suficiente como para visualizarse.

Más temas, interesantes, parece que mantuve una buena disciplina de escuchas durante bastante tiempo. El color ( de verde a rojo ) indica la intensidad de scrobbling, en mi caso se puede mapear fácilmente al tipo de música que escuchaba. Colores más verdes indican pocos scrobbles por hora (escuchando probablemente Dark Ambient o Post Metal) y las rojas indican muchos scrobbles por hora, probablemente Grindcore.

El próximo tema a destacar es Octubre del 2010 dónde claramente mi actividad baja, qué pasó? pues que me cogí 3 semanas y me fui a Nueva Zelanda. Y finalmente ya llegamos a Mayo de 2011, dónde mi actividad de scrobbles parece que empieza y termina antes, por una o dos horas, pues marca mi vuelta a España, con unos horarios un poco distintos a los que hacía de cuando estaba en el Reino Unido.

Qué os parece? visualizar 7 años de canciones (y cambios en mi vida) con una sola imagen.

Taller de Hadoop en Zaragoza

El día 31 de Agosto dí una charla en Zaragoza sobre Hadoop, parte de los talleres que organiza Cachirulo Valley. Hoy quería subir las transparencias a slideshare cómo de costumbre, pero mirándolas me he dado cuenta de que no tiene mucho sentido ya que parece ser que mis presentaciones son muy gráficas. Así que he decidido hacer un pequeño resumen de la charla y colgarlo aquí. Espero que sirva para aclarar conceptos y como pequeña introducción a Hadoop.

Qué es Hadoop y para qué sirve ? 
Primero vamos a poner un problema, y luego alguien lo va a solucionar muy bien.
Por allí al 200X Google tenía un problema, y este problema era básicamente una cantidad gigante de datos con que trabajar. Las soluciones que había por aquel entonces o bien no eran lo suficientemente potentes o eran demasiado caras, así que teniendo los recursos, la gente de Google diseñó su propia solución, que finalmente implementó, provó, puso en producción y finalmente, explicó a la comunidad mediante una serie de papers:

• MapReduce: Simplified Data Processing on Large Clusters del que ya hablé en este mismo blog.
• The Google File System.

Poco después, Doug Cutting, que estaba participando en un proyecto llamado nutch tuvo el mismo problema, qué hacer con tantos datos? encontró el paper de google y se puso a implementarlo, así de fácil, y así nació Hadoop, la implementación libre de los dos papers de Google.

Aquí, igual que en el taller me voy a servir de una muy buena definición de Hadoop, de Parand Tony Darugar:

"Flexible infrastructure for large scale computational and data processing on a network of commodity hardware".

Vamos a analizar la frase:

1. Data processing: Hadoop no está pensado para problemas matemáticos, no estamos calculando simulaciones, no estamos calculando grafos. Hadoop es para procesar datos. Si no tienes muchos datos de entrada te estás equivocando de Framework. 
2. Network: I por qué en una red de ordenadores? pues porqué estás analizando tantos datos que no te caben en una sola máquina. Si los datos te caben en una sola máquina te estás equivocando de Framework. 
3. Large Scale: Muchos datos y muchas máquinas. 
4. Commodity Hardware: Tenemos una red de máquinas. El hardware va a fallar, estadísticamente los discos duros van a estropear-se, la RAM se averiará y las placas base se van a fundir. Si tenemos mucho hardware tenemos muchas posibilidades de que hayan desgracias, así que Hadoop está preparado para correr en máquinas "baratas". Si el hardware se va  a estropear y habrá que reemplazarlo, al menos que sea barato no?
5. Flexible: Si sabemos que el hardware se va a estropear durante la ejecución, Hadoop debe estar preparado para soportarlo. Vamos a ver un poco más adelante más detalles de esto, pero para empezar diré que el sistema de ficheros tiene réplicas de los ficheros (por defecto 3), por lo tanto si una máquina se estropea durante la ejecución no pasa nada, el fichero está en 2 otras máquinas, Hadoop se va a enterar, va a clasificar la máquina como "averiada" y va a continuar el job en otra parte. 

Qué es Big Data? 
He insistido bastante en los "muchos datos", cuánto es exactamente "muchos datos"? pues es tan fácil como: "BIG DATA es cuando la cantidad de datos es un problema".

Para alguien serán 100 gb, para alguien serán 1Tb y para algun otro seran petabytes.

Vamos a profundizar un poco más con el tema del "problema". Yo personalmente creo que hay 3:

1. Tiempo: Las herramientas que uso funcionan bien con esta cantidad de datos, pero tarda mucho. Vamos a imaginar que tenemos una base de datos sobre la qual hay que correr una serie de procesos, el departamento de márketing necesita datos actualizados cada 10 horas. Si el proceso finaliza, pero tarda 15 horas tenemos un problema.
2. Las herramientas dejan de funcionar: Tenemos un programa que funciona bien, crecen los datos y la herramienta cada vez va más lenta, pero no es un problema. Llega un momento que la herramienta simplemente de queda congelada con el input de datos. Tenemos otro problema. 
3. Los datos no caben en la máquina: Tenemos 1 Terabyte (o lo que sea) de datos a tratar y simplemente los datos no caben en la máquina y hay que moverlos a trozos por la red. 

Worflow de trabajo en Hadoop. 
Ya sabemos qué hace Hadoop y ya sabemos cuándo tiene sentido empezar a utilizarlo. Ahora bien, cómo se trabaja?
Hadoop consta de dos partes (como veremos en más detalle en el siguiente punto), un motor de map/reduce y un sistema de ficheros distribuido. Lo más importante en este punto es que nos imaginemos a Hadoop como una caja negra que es capaz de almacenar y transformar datos. Por lo tanto para trabajar lo que tenemos que hacer es:

1. Poner los datos nuevos en Hadoop (en caso de que haya): Ponemos los logs del día, los usuarios que se han dado de alta hoy, los eventos del día, etc, en el sistema de ficheros. 
2. Tratar los datos con un programa map/reduce. 
3. Sacar los datos del sistema de ficheros para ponerlos a un lugar dónde sean útiles. Vamos a recordar que de momento Hadoop es una caja negra, no es fácil que los del departamento de márketing usen los datos que hay en Hadoop, así que hay que sacarlos de allí y ponerlos en una base de datos, una nosql, una página web, lo que sea.

Cómo funciona Hadoop? (Map/Reduce y su amigo el DFS)
Hemos dicho que Hadoop almacena y transforma datos, almacena con un sistema de ficheros y trata los datos con un motor de map/reduce, vamos a verlos:

(H)DFS: Hadoop Distributed File System.
Vamos a empezar por el sistema de ficheros distribuido. Vamos a dejar claro que un sistema de ficheros distribuido es un tema muy serio y complejo. Nadie quiere poner sus ficheros en un sistema experimental con el riesgo de que desaparezcan ficheros, se corrompan o sean inaccesibles, por lo tanto, el principal requerimiento es su estabilidad y robustez.

El HDFS fue diseñado a partir del paper del Google File System, no me voy a liar mucho con la explicación de cómo funciona, pero voy a comentar algunas de sus características más importantes:

• Simple by design: Aunque internamente un sistema de ficheros es muy complejo, el HDFS ha sido diseñado y implementado con un conjunto muy básico y limitado de funcionalidades. Así que no nos podemos esperar grandes "virguerías", al menos a nivel de usuario.
• Robusto y replicado: Es robusto, recordemos que Hadoop está diseñado para ejecutarse en redes de hardware que puede estropearse en cualquier momento. El sistema de ficheros debe ser capaz de continuar trabajando efectivamente hasta un cierto nivel de error tolerable. Una de las características más importantes es que los ficheros están partidos por bloques, y que cada bloque está replicado 3 veces en el clúster, así que si una máquina cae o un disco duro se estropea no pasa nada, aún tenemos dos copias del bloque del fichero en la red.
• Optimizado para Big Data: Los bloques son de 64 mb por defecto, por lo tanto, optimizado para la lectura y escritura de volumenes de datos grandes.
• Escalable: El sistema debe escalar horizontalmente, si necesitas más espacio es tan fácil como poner más máquinas o ampliar los discos duros. El máster se va a encargar de repartir los bloques entre los nuevos nodos de forma transparente. 
• Transparente: Hemos dicho que el sistema es sencillo de cara al usuario y que es robusto y escalable, que es tolerante a fallos y que balancea su carga automáticamente y además, sin que el usuario se entere de lo que está pasando. El nodo máster se encarga de todo de forma totalmente transparence. En caso de que una máquina se estropee, el máster va a encargarse de ponerla en una lista negra y va a mirar qué bloques de ficheros contenía, y va a replicarlos (cogiéndolos de otras máquinas) hasta que el número de replicas vuelva a ser el deseado.

A nivel un poco más técnico, todo el sistema de ficheros está controlado por un nodo máster que se llama el NameNode, podéis ver más información aquí.

Map/Reduce
El motor de map/reduce es la parte que realiza los cálculos y transformaciones sobre los datos. Básicamente se trata de una serie de componentes software que ejecutan un programa, programado en Java (o alguna otra alternativa que veremos más tarde) que sigue el model de programación del mismo nombre (map/reduce).

Bien, pero qué es esto del map/reduce? pues se trata de un esquema de programación paralela que tiene sus orígenes en la programación funcional. Encontraréis mucha más información por la red, pero lo básico y lo importante ahora mismo es entender un poco el concepto, que es bastante sencillo.

Tenemos un problema, A, este problema es muy grande y no se puede tratar de forma individual, por lo tanto vamos a coger una función, a la que llamaremos mapper y la vamos a aplicar a trozos de A, de forma que tendremos:

 A1 --> Mapper --> A'1  

 A2 --> Mapper --> A'2

  ...
 Ax --> Mapper --> A'x

Ya tenemos parte del problema resuelto, pero en trozos, ahora toca aplicar el reducer, que es otra función que sabe interpretar y juntar los pequeños resultados que nos ha dado el mapper. De tal modo que:

[A'1, A'2, ... , A'x] --> Reducer --> Resultado.

No es más que aplicar el 'divide y vencerás' sobre un fichero muy grande. Lógicamente no todos los problemas se pueden resolver con este modelo de programación, es por esto que cale ver si Hadoop es la mejor solución antes de lanzarnos a crear un proyecto.


Ejemplos de código: 
En el taller vimos un par de ejemplos (muy básicos y sencillos cabe decir). Están colgados en github y bastante comentados. Otro recurso para tutoriales de programación Java en Hadoop en su página oficial, bastante más completo.

Clúster virtual en EC2 vs Clúster local. 
Tengo que admitir que soy bastante novato en este aspecto. Siempre he tenido la suerte de trabajar con un clúster dedicado así que eché una ojeada rápida para crear un pequeño clúster virtual en EC2. Según he visto hay 3 possibilidades:

1. Pico y pala: Creas los nodos manualmente y te instalas Hadoop. 
2. Scripts en el src de Hadoop.
3. Apache Whirr.

Lógicamente escogí la más rápida, en este caso Whirr, que es un proyecto que trata de facilitarnos la creación de clústeres en plataformas de virtualización. El proyecto es bastante joven y aún le falta, pero ya se puede utilizar con unos resultados muy satisfactorios. Con este simple fichero de configuración pude crear un cluster en amazon: 

whirr.cluster-name=hadoop
whirr.instance-templates=
  1 hadoop-namenode+hadoop-jobtracker,
  2 hadoop-datanode+hadoop-tasktracker
whirr.provider=aws-ec2
whirr.identity=*************
whirr.credential=***********
whirr.hardware-id=c1.xlarge
whirr.image-id=us-east-1/ami-da0cf8b3
whirr.location-id=us-east-1

Creo que es bastante autoexplicativo, pero podéis encontrar más detalles en su página web.

La clara ventaja sobre los clústeres virtuales sobre los clústeres físicos es claramente la inversión inicial ya que no hay que comprar las máquinas (y el espacio en el datacenter), ni pagar mensualmente la electricidad + mantenimiento, bla bla. Aunque sí que tengo que decir que he oído que el rendimiento de un clúster dedicado es mucho mayor a la que nos encontraremos utilizando un clúster virtual. Del orden de 10 veces más rápido, aunque este número tendría que verse de forma un poco más "científica", cómo dije, esto es un rumor que me dijo un usuario de EC2 que se pasó a clúster dedicado.

Ecosistema de Hadoop
Hasta ahora he hablado del core de Hadoop. Como se ha visto es muy potente, pero es bastante espartano y no da muchas facilidades amigables al usuario o programador. No obstante el proyecto tuvo una gran adopción, debido a que era software libre y a que básicamente era lo único disponible. Esto causó que muchas empresas pusieran recursos para mejorar el proyecto y crear pequeños proyectos auxiliares que con el tiempo se han convertido en partes importantes de un ecosistema muy activo.

Podéis encontrar más información sobre los proyectos que considero más interesantes en un post que ya escribí en este mismo blog.

Preguntas?
Esto ha sido una pequeña introducción a Hadoop, muy a grosso modo y sin entrar en detalles peliagudos. Como siempre, si tenéis alguna duda no dudéis en preguntarla en la sección de comentarios o bien contactando conmigo.