Distribuïnt...

Es "Big Data" una buzzword?

2011-12-15T11:21:00.001Z

Hace muy poco un amigo mío hizo un tweet:
"Es Big Data la siguiente Buzzword"?

Si además ponemos a la mezcla los posts en algunos posts bastante "mainstream" de algunos gurús de la informática pues ya tenemos una combinación un poco explosiva.

Mi opinión es que probablemente los comerciales, "gurús" y otros consigan que Big Data sea una buzzword como lo ha sido cloud computing, IA, o grid computing. Y creo que es una lástima, para mi estas tecnologías tienen un sentido y una utilidad.

En general me hace gracia que las tecnologías con las que trabajo sean conocidas, me sale la vena hipster y puedo decir eso de: Yo trabajaba con Hadoop antes de que... pero llega un momento que el tema se hace cansado. Y lo digo porque de seguro ahora mucha gente va a coger sus productos de siempre y les va a meter "Big Data" para que sean más vendibles, van a empezar a salir "entendidos" y vamos a ver qué más. Hasta que salga la siguiente Buzzword, y a por otra cosa.

Para mi big data no es una tendencia, es un problema que existe. El cloud, el grid, la IA son metodologías, una mezcla de tecnologías, que han tenido más o menos éxito, que han sido tendencia y que han servido para sacar dinero de subvenciones para proyectos. Uno de los problemas que ha habido (en mi humilde opinión) es que se han intentado encontrar soluciones a problemas que no existían, creándose así un sinfín de tecnologías poco prácticas, flojas y muy poco realistas. Este pues, no es el caso, aquí primero estuvo el problema, luego la solución.

Big data no es una tendencia, es un problema. Punto y final.

Visualizaciones de Big Data

2011-09-06T12:25:00.000+01:00

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:

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

2011-09-05T07:54:00.003+01:00

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:

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.
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.
Large Scale: Muchos datos y muchas máquinas.
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?
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:

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.
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.
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:

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.
Tratar los datos con un programa map/reduce.
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:

Pico y pala: Creas los nodos manualmente y te instalas Hadoop.
Scripts en el src de Hadoop.
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.

Hadoop NG, o cómo liarla gorda.

2011-03-29T10:55:00.001+01:00

Hace un tiempo vi en diferentes blogs de Yahoo! su propuesta para una reimplementación de una parte bastante importante de Hadoop. Una propuesta interesante, pero que creí bastante teórica. Bueno, pues la semana pasada pude ir a otra edición del grupo de usuarios de hadoop del reino unido, en el que Owen O'malley mismo presentó estas mismas ideas a la comunidad, podéis ver la página del evento así como las presentaciones en:

http://lanyrd.com/2011/an-evening-with-hadoop/

Entrando un poco más en detalle. Esta propuesta (que está en fase de testing en Yahoo! por lo tanto, de teórico nada) se trata de sustituir el JobTracker de Hadoop (la parte que lanza los jobs a los diferentes nodos que forman el cluster de Hadoop) por dos nuevos elementos:

Un Resource Manager / Scheduler: El cual cogerá los requerimientos del job en concreto y buscará un nodo capaz de poder realizarlo.
Un Node Manager en cada nodo: El cual monitorizará el nodo y informará al Resource Manager. Dentro de este nodo el Node Manager será capaz de crear un container, dentro del qual se ejecutará el mapper, el reducer, y lo que es más interesante: o lo que sea. Ya que este diseño pretende hacer de Hadoop un framework de programación distribuido general.

podéis encontrar más información ( y mucho más detallada ) en:

Mis primeras impresiones fueron bastante negativas. En primer lugar porque estamos sustituiendo un elemento QUE FUNCIONA de Hadoop por otro de mucho más complejo. Y en segudo lugar por la complejidad de este segundo elemento. No quisiera parecer conservador pero mis temores se fundamentan en la experiencia que tuve con otros middlewares de computación distribuida, en los que estabas más tiempo definiendo las características del job en un "formato simple de definición genérica de jobs" en XML que programando el job en sí mismo.

Otro aspecto es que como ya he dicho anteriormente este Node Manager permitiría no sólo crear containers con mappers o reducers, sino otro tipo de containers (implementados por la comunidad) en los que se podría lanzar otro tipo de procesos (intensivos de CPU, MPI, ...). Tampoco me hizo mucha gracia esto, y otra vez fue por culpa de alguna mala experiencia. Lo que me gustó de Hadoop desde el principio es que era un framework que sólo hacía una cosa, pero que la hacía muy bien. Cosa que no hacían otros, que intentaban hacer muchas cosas diferentes y no hacían nada bien.

Aproveché la ronda de cervezas del final de la reunión para ver más opiniones acerca de estos cambios, las conclusiones que saqué es que la gente es muy optimista, frases que oí mucho:

La comunidad hadoop será capaz de hacerlo bien.
Asi podremos aprovechar el cluster para más cosas.

Veremos qué tal la primera, espero que si :) en cuando a la segunda, es pura verdad.

Estoy viendo muchos clústers dedicados 100% a hadoop/map reduce. Esto no es necesariamente malo, pero como no me canso de decir, Map Reduce es un modelo de programación y va muy bien para unas cosas y va muy mal para otras. El hecho de que sólo haya instalado Hadoop en un cluster hace que todo tenga que estar programado siguiendo una estrategia map/reduce o tengamos que instalar otro framework (Condor/Globus/...) en las mismas máquinas. Por ejemplo he sido testigo de un intento (que acabó en nada) de implementar un Load Tester con Hadoop, cuando claramente map/reduce no es el modelo más apropiado (que se puede hacer ojo!, simplemente digo que hay cosas mejores).

Si la comunidad Hadoop consigue hacerlo bien Hadoop se puede convertir en un framework de sistemas distribuidos _genérico_, cosa que facilitaría mucho la tarea de administradores de sistema, ya que sólo tendríamos que tener Hadoop instalado. Pero bueno, estamos hablando de largo plazo.

Asi que más o menos, cambié de opinión, aún me quedan dudas sobre la complejidad de estos nuevos componentes.

Open Data Manual

2011-03-17T10:47:00.000Z

Me acabo de encontrar esto por los Internets:

http://opendatamanual.org/

Se trata de un documento que pretende, cito:

This report discusses legal, social and technical aspects of open data. The manual can be used by anyone but is especially designed for those seeking to open up data. It discusses the why, what and how of open data — why to go open, what open is, and the how to ‘open’ data

Muy interesante el contenido (aún no he tenido oportunidad de leerlo todo, pero bueno) y también el formato, dónde te permite hacer comentarios y discusiones en cada parágrafo.

Dev Fort

2011-03-12T17:56:00.000Z

Aunque este post salga bastante de la temática del blog creo que es interesante.

Últimamente he estado dando vueltas al tema de la productividad. Que si metodologías ágiles, que si buen equipo informático, que si las herramientas idóneas. Sí muy bien, pero no sería mejor meterse con el equipo de desarrollo durante una semana en castillo en una isla sin Internet ?

Pues esto existe y se llama /dev/fort

La idea es muy sencilla, se trata de ponerse con el grupo de desarrollo (diseñadores/programadores) en un lugar aislado, sin ningún tipo de conexión a Internet y concentrarse en una sóla idea y a implementarla.

La idea de desarrollar sin conexión a la red puede ser un poco chocante al principio, esto significa que tienes que ir bien preparado, con librerías, documentaciones y programas de desarrollo en el portátil, pero es sin duda una muy buena idea. Si contara las horas de productividad que he perdido en Reddit/Wikipedia/Twitter... en fin.

Volviendo al /dev/fort, unos compañeros de trabajo participaron en la quinta edición y hicieron esto: http://spacelog.org , la parte curiosa es que compraron el dominio en el aeropuerto de vuelta a la civilización mientras subían todo el código a github.

En fin, no deja de ser una idea interesante y curiosa. A lo mejor convierto casa mis padres en un castillo por el próximo desafío Abredatos :)

Experimento (Data Science y España)

2011-03-09T13:59:00.000Z

LinkedIn te da una gráfica en la que se muestra el número de veces que tu perfil sale en las búsquedas. Yo tengo un perfil bastante acorde a "data science" y lógicamente, la localización es Londres.

El otro día decidí hacer un experimento y cambiar la localización a Barcelona.

Puede, el avispado lector, adivinar qué día cambié la localización?

Mi presentación en el Huguk #7

2010-12-17T17:51:00.000Z

Y como ya anuncié en un post anterior, aquí teneis el video de mi presentación:

HUGUK#7 - Using HFile outside HBase by Marc de Palol (Last.fm) on Vimeo.

OpenData en Catalunya

2010-11-25T17:29:00.000Z

Hace poco la Generalitat se sumó a las iniciativas de otros gobiernos para la apertura de datos y abrió un nuevo portal: http://opendata.gencat.cat

Como me interesa mucho el tema decidí hacer una buena ojeada al portal y explicar aquí mis opiniones al respecto. Y aquí están (más vale tarde que nunca).

Asi que vamos a ver las secciones del portal, luego los datos y finalmente algunas conclusiones que se me ocurren:

Secciones:
El portal está dividido en tres secciones: El catálogo, el proyecto en sí y además otra sección que habla del Open Data.

Vamos a ver la sección de catálogo:
Está muy bien organizada, los datos están en subsecciones bien clasificadas y con datos destacados. De momento 12 conjuntos de datos. Lógicamente son pocos, pero también estamos hablando de un portal nuevo que tiene poco tiempo de vida, sin duda vamos a ver como se van añadiendo más.

El siguiente punto es una lista de aplicaciones ya hechas. Esto es muy importante de cada al ciudadano ya que permite demostrar que la apertura de datos es útil y que realmente aporta valor. Todas las aplicaciones (al menos eso me parece) están hechas por la Generalitat. Realmente me ha gustado que incorporaran esta sección ya que si no se corre el riesgo de que se haga la pregunta: "Y esto, para qué sirve?", aquí tienes la respuesta en forma de 8 aplicaciones prácticas. Espero que pronto pueda participar yo también!

Por si esta subsección no fuera suficiente para demostrar la utilidad del opendata para el ciudadano de a pie tenemos otra subsección con enlaces a proyectos en curso, unas quince aplicaciones más que utilizan los datos (todas impulsadas por la Generalitat parece).

El proyecto:
La siguiente sección es bastante sencilla, se explica qué es el proyecto y también una explicación del acuerdo de gobierno que ha hecho posible la creación del porta. Bueno muy bien, supongo que tenía que salir a algún lado, pero vamos a la sección ~~interesante~~ importante, la licencia.

No soy ningún experto, pero creo que son las que deben ser. Agradecería si algún experto en el tema me lo pudiera confirmar, pero lo más importante es para mi:

Reconeixement (by): Es permet qualsevol explotació de l'obra, incloent-hi una finalitat comercial, així com la creació d'obres derivades, la distribució de les quals també està permesa sense cap restricció.

Reconeixement - SenseObraDerivada (by-nd): Es permet l'ús comercial de l'obra però no la generació d'obres derivades.

Las dos Creative Commons.

Qué es Open Data
La última sección es un poco más de información sobre que es el Open Data, los diferentes formatos que existen y experiencias en otros paises, temas de los que ya he ido hablando en este blog, por lo que no me voy a enrollar mucho más. Vamos a otro tema más interesante, los datos que el portal ofrece:

Los Datos
Tenemos ocho secciones:

Trámites y procedimientos administrativos:

Tenemos 2 datasets, uno para trámites ciudadanos y otro para trámites de empresas, los dos en RDF. Después de echarle una ojeada al fichero veo que utilizan un redireccionador para las ontologías de términos (http://purl.org, yo no lo conocía pero está bien la idea). El fichero RDF está muy bien hecho, como dijo alguien en Twitter (ahora no me lo hagáis buscar por favor) el fichero está tan bien que se puede leer. Esto es mucho, recordad que hablamos de ficheros RDF.

Datos estadísticos: Esta sección nos ofrece unos links a la API REST de Idescat. Hice un wrapper de esta API en Java, la podéis encontrar en Github y la intento mantener al día con los cambios de la API (y lógicamente doy la bienvenida a cualquier tipo de colaboraciones).

Indicadores económicos: Diferentes datos económicos.
Poblaciones y muncipios de Catalunya: Lista de las poblaciones de Catalunya.
Rectificaciones de Idescat: Y rectificaciones de datos.

Datos geográficos y cartográficos:

Equipamientos de Catalunya: Otro fichero RDF (cuidadín que es grande, si lo intentais abrir con el navegador a lo mejor os fríe la máquina). Este fichero contiene los datos sobre 26000 equipamientos (escuelas, hospitales, bibliotecas...) como son teléfonos, horarios, direcciones. Un lujo vaya.
Cartografía de Catalunya: Mapas, muchos mapas, en formatos que yo desconozco.
Servicios de posicionamiento geodésico: También formatos muy raros :P

Datos visuales:

Imágenes y videos de Catalunya: Links a una API y una página web dónde puedes decargarte fotos y videos sobre Catalunya.

Datos lingüsticos:

Terminologia Abierta: Aquí podemos encontrar muchos XML's clasificados en areas temáticas con su traducción al catalán, español, francés e inglés.

Datos Metereologicos:

Predicciones: Ficheros XML con las predicciones metereológicas en diferentes zonas de Catalunya.

Datos de actualidad:

Noticias: RSS's con las noticias de las diferentes areas de la Generalitat.

Tránsito y mobilidad:

Transporte público: RSS's con las noticias de diferentes linias de Regionales (de la Generalitat)

Mis conclusiones:
Estoy muy contento que la Generalitat haya realizado este esfuerzo, lógicamente aún está muy lejos de monstruos com data.gov.uk (del Reino Unido) o data.gov (de U.S.A.) es un primer paso.

Los datos, aunque pocos aún, están muy bien estructurados y los formatos son los que tocan, de momento no me he encontrado ninguna sorpresa ni ninguna macro.

Sin duda ahora lo que toca es crear una buena comunidad que aporte ideas y lo más importante, aplicaciones reales para mejorar la situación ciutadana.

A raiz de esto estoy pensando en ampliar mi proyecto en github para hacerlo un poco más general y aportar mi granito de arena al #opendata Catalán. Si alguien se anima ya sabe a dónde encontrarme!

Presentación en el HUGUK #7

2010-11-22T17:48:00.000Z

La semana pasada hice una presentación en una de las reuniones de usuarios de Hadoop UK.

Se trató de utilizar el formato HFile fuera de su entorno, que es HBase. Os dejo la presentación en slideshare:

Espero que en poco tiempo pueda poner un link al video.

El Ecosistema Hadoop.

2010-09-29T22:19:00.002+01:00

Hadoop es sin duda uno de los proyectos que más acogida últimamente ha tenido entre la comunidad de software libre y es también uno de los responsables del auge de la ciencia de datos.
Hadoop es un framework, aunque hoy en día se puede hablar de todo un ecosistema de proyectos alrededor del nucleo, vamos a intentar explicar en este post los distintos componentes de forma senzilla:

vamos a empezar por el principio,

Hadoop
Con Hadoop nos referimos a la parte central del sistema, que es el sistema de ficheros distribuido (HDFS) y el motor de Map/Reduce. Si echamos un vistazo a la página del proyecto veremos que hay 3 subproyectos, calma y tranquilidad!, a efectos prácticos van totalmente juntos y es una separación que se hizo por temas de código fuente:

Hadoop MapReduce.
HDFS.
Hadoop - Commons.

Una vez aclarado el tema de la separación. Qué es Hadoop? Pues es la combinación de:

un sistema de ficheros distribuido (diferentes discos duros en diferentes máquines se ven como uno solo) (HDFS)
de un modelo de programación que se llama Map/Reduce, con su API en Java (Hadoop MapReduce)
y un componente software que ejecuta los programas que hemos programado con la API en un cluster, usando asi el sistema de ficheros distribuido.
y una serie de classes comunas (Hadoop - Commons)

Esto es lo básico que debemos instalar en el clúster para obtener la funcionalidad. De este modo podemos meter datos en el sistema de ficheros y tratarlos con nuestros programas programados con el API de Hadoop.

Vamos a ver qué más hay:

HBase

Una vez tenemos los datos procesados en Hadoop seguramente nos interesará tenerlos fácilmente accesibles para diferentes tipos de consultas, algo así como una base de datos con los resultados de Hadoop. Aquí es donde entra HBase.

HBase es una implementación libre del Bigtable de Google, es una de las famosas bases de datos NoSql. Como el nombre indica, no usa Sql, sinó que tiene una API, además el model de datos no es tabular, sinó que está basado en columnas de n dimensiones. Ya hablé de este modelo de datos en un post anterior.

A efectors prácticos, se tratan los datos en Hadoop mediante Map/Reduce y se escriben en HBase (importante saber que HBase está totalmente integrado con Hadoop, y que por lo tanto, HBase entiende perfectamente el sistema de ficheros de Hadoop asi como el formato de los ficheros), que puede estar en el mismo clúster que Hadoop o en otro, para que otras aplicaciones puedan utilizar los datos en tiempo real.

Zookeeper
Tanto HBase como Hadoop son sistemas distribuidos en los que el sistema debe controlar y saber en cada momento lo que está pasando en procesos que están en otras máquinas. Si hemos programado alguna vez este tipo de sistemas sabremos que eso no es una tarea fácil, nos vamos a encontrar todo tipos de problemas.

Zookeeper aparece justamente para solucionarlos. Igual que HBase es la implementación libre de un paper de google, en este caso de Google Chubby.

Básicamente es un sistema de locks distribuido y de consenso (utilizando Paxos), no hace mucho los ingenieros de LinkedIn lo usaron para un sistema interno y hicieron un post muy interesante, en el que utilizaron la siguiente definición, muy acertada en mi opinión:

ZK has a very simple, file system like API. One can create a path, set the value of a path, read the value of a path, delete a path, and list the children of a path. ZK does a couple of more interesting things:

(a) one can register a watcher on a path and get notified when the children of a path or the value of a path is changed,

(b) a path can be created as ephemeral, which means that if the client that created the path is gone, the path is automatically removed by the ZK server.

de: http://sna-projects.com/blog/2010/08/zookeeper-experience/

Asi que ya tenemos otra pieza del puzzle, si hay que sincronizar sistemas distribuidos (que utilizen o no Hadoop), podemos utilizar ZooKeeper.

Ahora toca el turno de hive, pero atención porqué después viene pig y aunque vamos a ver que son bastante diferentes, los dos proyectos pretenden solucionar un problema muy similar:

Hive
La principal incomodidad que tiene Hadoop es que para hacer una simple consulta de datos hay que escribir un programa completo en Java, y esto, no es rápido, es un poco difícil de debuggear y puede llegar a ser frustrante.

Pongamos el caso en que tenemos 500 Gb de datos del tipo:

Key: Integer
Value: Objecto(Id: Integer, valor1: Integer, valor2: Integer)

y que en un momento dado queremos un listado de todos los pares Key/Value dónde valor2 > 500.

Si los datos estuvieran guardados en una base de datos podriamos hacer una senzilla consulta Sql con un where. En Hadoop tocaría escribir un programa en Java. Pues bien, Hive al rescate.

Se trata básicamente de una infraestructura de data warehousing encima de Hadoop. Y esto que significa? pues básicamente se trata de crear unos metadatos encima de los directorios de HDFS describiendo el formato de los ficheros, asi pues creamos una estructura tabular virtual encima de Hadoop. Hive también tiene un intérprete de comandas sql, por lo tanto podemos escribir una consulta sql de toda la vida en la command line, luego hive coge el sql, lo convierte automáticamente en jobs Map/Reduce y estos son ejecutados de forma transparente en el clúster como jobs normales.

Si quereis más información, anteriormente hice un post hablando de hive con más detalle.

Pig
Otro modo de ver el anterior problema es: en vez de escribir un programa en Java para hacer una consulta de unos datos, voy a hacerlo con nserta aquí tu lenguaje de scripting favorito>. Hadoop tiene como parte del Hadoop Core una opción de streaming. Básicamente te permite especificar como parámetro dos scripts (uno que hace de mapper y otro que hace de reducer) que leen y escriben por la entrada y salida estándar. Esto es práctico pero te limita a unos programas muy sencillos y poco aplicables a la vida real.

Pues bien, Pig es un lenguage de programación (tipo scripting) para Hadoop, y por lo que estoy viendo parece que tiene una muy buena aceptación en la comunidad Hadoop (pero que muy buena aceptación).

Avro
Una de los puntos fuertes del ecosistema Hadoop es que facilita trabajar con grandes cantidades de datos. Estos datos están guardados en el HDFS, pero cómo? pues se pueden guardar en diferentes formatos, el más simple es el de texto plano, pero normalmente se recomienda usar serialización.

Qué es la serialización? pues se trata de como almacenamos la información internamente de un objeto a disco (o memoria), podemos leer más en la wikipedia. Para Hadoop lo más interesante son los formatos binarios, que son los más rápidos y comprimidos, el problema es que un humano no los puede leer, pero en este caso no nos importa.

Tenemos diferentes formatos:

Protocol Buffers, creado por Google.
Thrift, creado por Facebook.
y otros dos, creados por los programadors de Hadoop:
RecordIO: Hasta hace pronto el formato de serialización de facto en Hadoop, bastante interesante en su implementación, pero con algunos problemas en temas de mantenimiento a largo plazo (los objetos generados son estáticos, esto significa que si modificamos las características del objeto (introducimos un nuevo campo) el objeto nuevo será incompatible con el viejo). Si echamos una ojeada a la documentación veremos que está deprecated by... si señor:
Avro.
Tiene unas características muy interesantes, básicamente:
Permite almacenar estructuras de datos simples y complejas (desde números hasta objectos con listas y maps)
Es compacto, rápido y binario. (Esto no es mucha novedad)
Tiene un format de fichero propio.
Tiene una especificación de RPC. (como Thrift)
Y lo más interesante: El esquema de serialización (el índice que dice que tipo de datos está en cada posición del fichero) está incluido en el fichero en si. Esto permite que la generación de código por parte del precompilador sea opcional y lo que es más importante, hace que podamos canviar la estructura interna de los objectos almacenados sin perder la compatibilidad con ficheros viejos.
Por lo tanto, si trabajais con Hadoop, a serializar los datos con Avro desde ya.

Flume
The "new kid in town". Flume fue liberado por Cloudera no hace ni medio año y ya ha tenido una gran adopción.

La idea es muy sencilla, se trata de una pipe al HDFS.
Lógicamente para trabajar con Hadoop debemos tener los datos en el HDFS, y tenemos diferentes herramientas para poner los ficheros allí, el problema es que cuando tenemos diferentes fuentes de datos (el syslog de muchos servidores web por ejemplo) hay que construir una infraestructura que se asegure que los logs se van subiendo periódicamente y que no falte ninguno. Pues bien, Flume es exactamente esto. Además utiliza ZooKeeper, por lo tanto es:

tolerante a fallos ( si un nodo cae de la red, cuando se vuelva a conectar sabrá que tiene que enviar de nuevo ),
tiene configuración distribuida (puede reconfigurar los nodos cliente a partir de un nodo máster)

Y no se acaba aquí! hay más, mucho más en Hadoop, pero creo que estos son los proyectos más interesantes y que estás más ligados a Hadoop.

Echáis en falta alguno?

El ciclo de los datos, de la generación al uso.

2010-09-12T23:50:00.000+01:00

Trabajar con grandes cantidades de datos es complicado. Muchas empresas están incorporando Map/Reduce, básicamente su implementación libre, Hadoop para el tratamiento de sus datos. El ecosistema de herramientas de Hadoop va creciendo también, y cada vez es más complejo, ya que tiene que solucionar muchos casos, pero aún le falta alguna pieza para completar el ciclo total de los datos.

Con "ciclo total de los datos" me refiero a las diferentes fases del proceso, en Hadoop normalmente:

Ingestión de datos en el sistema de ficheros: Hadoop trabaja sobre DFS (normalmente), así pues tenemos que enviar los datos al clúster.
Tratamiento de datos: Operaciones Map/Reduce en Hadoop.
Visualización o acceder a los datos: Una vez tenemos los resultados de los trabajos, hay que sacar los datos del DFS para poder presentarlos.

El primer punto es bastante interesante. Hadoop es útil cuando trabajamos con muchos datos (>Gbs), ahora bien, los datos deben estar en el DFS, esto puede ser un problema. El framework ofrece diferentes comandas para insertar ficheros, en mi caso un poco de scripting combinado con estos comandos siempre ha sido suficiente. Aunque estoy empezando a considerar usar Flume, un proyecto de Cloudera muy interesante que inserta datos en el sistema de ficheros distribuido como si fueran Pipes de Unix.

El segundo punto es bastante sencillo, ya que es el nucleo de Hadoop. Una vez finalizado estamos en el tercer punto, algunas veces el volumen de datos de salida será mucho inferior respecto a la entrada, a veces similar, y otras muy mayor.

Lógicamente nos interesan estos datos de salida, y la mayoría de veces necesitaremos sacarlos del DFS para poderlos estudiar, visualizar, o como es mi caso, servir a través de un servicio web.

Por qué hay que sacar los datos del DFS? por qué no los puedo usar desde allí?

Básicamente el problema viene del diseño del DFS en sí mismo, el sistema de ficheros está optimizado para los trabajos de Hadoop, que leen sequencialmente todo el fichero, esto significa que el sistema es muy lento leyendo posiciones aleatorias en un fichero. A efectos prácticos esto significa que haya mucha latencia y que no sea factible servir datos de forma rápida.

La solución más viable si no queremos (o no podemos) mover los datos es usar HBase, aunque de momento no es considerado como la mejor opción para servir las peticiones de una página web con un volumen importante de datos, aunque la comunidad está poniendo muchos esfuerzos para mejorar este tipo de rendimiento (lectura en posiciones aleatorias de ficheros) así como la estabilidad. Pero bueno, esto es otra historia.

Así pues, qué se hace para solucionar este tercer punto?

Lo más común es volcar los contenidos de los ficheros de DFS a una base de datos o a una K/V Store. Aunque tampoco es trivial.

El primer caso, sacar los ficheros y insertar el contenido a una RDBMS, caso plantea unos problemas bastante interesantes, básicamente se pueden hacer dos cosas:

Meterle caña a la base de datos: Una vez tenemos los ficheros del DFS se pueden convertir a SQL, luego se sube este fichero a la base de datos (con un copy), se crea una tabla nueva y se hace un swap. El problema? pues que si la nueva tabla ocupa 90 Gbytes y lo tienes que hacer cada día a lo mejor el administrador de la base de datos te viene chillando como un poseso (comprobado).
Insertar sólo las deltas: Esta solución puede parecer más diplomática. Se trata de calcular (si se puede) las diferencias que hay entre la salida de Hadoop con el contenido de la base de datos, el resultado será una bateria de inserts, otra de updates y otra de deletes. Esta solución no es senzilla programáticamente y tiene el problema que hay que volcar los contenidos de la base de datos a Hadoop para que se pueda ver que ha cambiado.

Nótese que en ningún momento estoy recomendando hacer las operaciones contra la base de datos desde los reducers de Hadoop, a no ser que queramos hacer un DDoS a nuestra base de datos (o que odiemos al DBA).

El segundo caso (utilizar una K/V Store en vez de una base de datos relacional) dependerá mucho de la K/V Store que utilizemos, pero la idea es la misma, podemos intentar actualizar los datos desde Hadoop y arriesgarnos a que se caiga todo o crear un fichero para que la K/V lo lea, en este caso jugamos un poco con ventaja ya que el movimiento NoSQL ha ido muy ligado al movimento Hadoop. Esto significa que muchas bases de datos no relacionales ya tienen un "conector".

Algunos ejemplos:

Apache Cassandra: Se puede utilizar un OutputFormat especial para que la salida de los jobs de Hadoop sea totalmente compatible con los ficheros de almacenamiento que usa Cassandra, asi pues, sólo se trata de crear estos ficheros, enviarlos a los nodos de Cassandra para que los lean. Feature un poco experimental a día de hoy.
MongoDB: También hay un OutputFormat , en este caso escribe el resultado del tratamiento en Hadoop en BSON. El formato no forma parte de la distribución de MongoDB a día de hoy, está en un proyecto en github (no he podido probarlo aún, pero me muero de ganas).
Voldemort: Fue creada por los chicos de LinkedIn justamente para solucionar este problema, tiene soporte de Hadoop por defecto.
HBase: Aunque he dicho que no es la mejor solución para servir datos online cabe decir que tiene soporte de leer ficheros generados por Hadoop por defecto.

Recientemente he estado trabajando mucho en este tema y he estado modificando un servicio web para solucionar en parte este problema. Voy a presentarlo en la séptima reunión del HUGUK el próximo 7 de noviembre (creo), espero poder colgar las transparencias y hacer un post aquí cuando lo tenga todo listo.

Mientras, hay alguien que tenga alguna sugerencia para solucionar todo este follón ?

Linked Data y Government 2.0

2010-09-03T14:09:00.001+01:00

Hace poco se publicó la página web http://www.legislation.gov.uk/ del gobierno inglés. Se trata (como podemos leer en http://data.gov.uk/blog/legislationgovuk-api) de una lugar en dónde se pueden consultar todas las leyes que afectan a Inglaterra, Gales, Irlanda del Norte y Escocia así como sus cambios a través del tiempo.

Qué gracia tiene? pues dos:

Incluye una API para que terceros desarrollen aplicaciones y
Cada ley está identificada únicamente por una URL, y está descrita con RDF, por tanto, es un resource de Linked Data.

A efectos prácticos (técnicos) esto significa que una aplicación con conocimiento semántico pueda interpretar las leyes y que estas sean únicas y referenciables siempre, un requisito de la Web de Datos ( o 3.0).

A efectos prácticos (no técnicos) esto significa que el gobierno británico continúa adelante con su apuesta por abrir sus datos para desarrolladores y colabora a la construcción de la Web Semántica.
Recordemos que el gobierno británico, juntamente con el americano, son los que están apostando más con lo que se llama el Gobierno 2.0 (o Open Government, o e-Gobernment, o ...). La página http://data.gov.uk/ es simplemente espectacular.

Y en España?
En España el tema no está nada mal, podría ser peor lógicamente, pero tenemos algunos gobiernos autonómicos (como el basco) que están publicando sus datos y Institutos de Estadística que también lo hacen (yo mismo hice una implementación en Java de la API del Idescat). Y también aparecen iniciativas como las del concurso Abredatos 2010, de las que salieron proyectos muy interesantes.

Durante el concurso Abredatos, participé con un amigo y la principal dificultad (bueno, la segunda, nuestra principal dificultad fue el CSS de la página) fue sacar los datos de diferentes páginas. El INE ofrece datos, pero desgraciadamente es muy difícil parsearlos, los datos están pensados para visualizarlos desde la web, o para descargarlos con excel (cada fichero con un formato diferente por cierto).

Es en este sentido que la apertura de datos en España podría mejorar mucho, mis requerimientos para una apertura de datos real serían:

Abrir los datos con una licencia no restrictiva.
Publicarlos via API
Describir los datos semánticamente.

En la conferencia NoSql - EU 2010 vi una presentación de unos programadores de The Guardian, en ella explicaban sus experiencias con bases de datos no relacionales, uno de los ejemplos (con Redis) se trató del escándalo de los gastos de los ministros en Inglaterra.

El gobierno publicó en pdf miles de documentos con las facturas de los ministros. Lógicamente se tardaría mucho en poder revisarlos uno por uno, lo que hiciero fue crear una página web dónde los ciudadanos podían ver facturas aleatorias, y seguidamente clasificar la factura como "escandalosa" (para que un reportero del diario la revisara) o como "aceptable". He aquí un muy buen ejemplo de lo que se puede ganar la ciudadanía con las nuevas tecnologías y la apertura de datos y lo que pueden perder algunas personas que están muy bien acostumbradas.

Por cierto, esta es la presentación de The Guardian (el tema de los gastos empieza en la página 46):

Cuidado con los fanboys!

2010-08-28T22:29:00.000+01:00

Hadoop, Big Data, NoSql y compañía han tenido bastante repercusión. Es fácil encontrar noticias relacionadas en las portadas de algunos de los medios más importantes, se han creado muchas startups relacionadas y ha habido mucha controversía y algunas que otras discusiones poco sanas entre algunos expertos.

Y lógicamente, ha pasado lo que tenía que pasar, han aparecido los fanboys.

NoSql está muy bien, Hadoop también, pero estos softwares, arquitecturas, modelos de programación son soluciones para problemas muy concretos, y recordemos, son relativamente jóvenes, vayamos con cuidado, tienen sus limitaciones.

Os dejo con un video muy representativo de lo que no tendría que pasar (pero pasa), en este caso una discusión entre un osito fanboy de MongoDB (una base de datos genial por cierto) y un osito con dos dedos de frente.

Comentarios sobre el artículo "the seven secrets of successful data scientists" de Dataspora.

2010-08-27T19:01:00.000+01:00

Acabo de leer el siguiente artículo: "The seven secrets of successful data scientists", de Dataspora (blog muy recomendable por cierto), definitivamente no podría estar más de acuerdo. Resume muy bien algunos de los problemas que he descubierto "a batacazos" durante los dos años en los que he estado trabajando con Big data.

Veamos los puntos:

Choose The Right-Sized Tool (Usa la herramienta que toque): Muy importante. Hadoop está muy bien, pero sólo tiene sentido si realmente tienes gigabytes de datos. Si tienes pocos datos usa macros de vim, si tienes unos pocos más con las herramientas estándar de Unix y algún lenguaje de scripting bastará.

Compress Everything (Comprímelo todo): Tengo un post pendiente que habla de esto desde hace mucho tiempo. Cuando se trabaja con datos normalmente la CPU no es el problema. La mayoría de veces es el disco (ya que se usa mucho para sustituir la falta de memoria), la solución es comprimir.

Split Up Your Data (Parte los datos): Divide y vencerás, pues eso, de hecho se llama "sharding", pero cuidadín al elegir cómo partes los datos.

Sample Your Data (Samplea, estadísticamente hablando, claro): Un paso importante del desarrollo del software es la parte de testing. Lógicamente muchas veces no se puede disponer de todo el conjunto de datos de entrada, la solución será poder coger un subconjunto estadísticamente representativo de la entrada para probar el programa.

Smart Borrows, But Genius Uses Open Source (usa código abierto): Nada a decir aquí, antes de redescubrir la rueda pásate por github o google code a dar un vistazo.

Keep Your Head in the Cloud (Mantén tu cabeza en la nuve, o trabaja en local, dónde quiera que sea "local"): Fallo muy clásico, estamos hablando de muchos datos. Cuando debas manipularlos quieres hacerlo localmente, no quieres mover Terabytes de datos de una máquina a la otra porque la otra tiene un poco más de memoria.

Don’t Be Clever (No te pases de listo): No se hasta qué punto estoy de acuerdo con este punto, supongo que muy personal, aunque me gusta la última conclusión: mantén el diseño simple.

Cheat Sheet per Nosql.

2010-07-12T23:17:00.002+01:00

Us deixo aquí un link molt interessant amb una 'Cheat Sheet' amb un resum del que són i per què s'utilitzen les tecnologies Nosql, a més amb exemples de MongoDB:

http://refcardz.dzone.com/refcardz/getting-started-nosql-and-data

Hadoop Summit 2010

2010-07-03T15:55:00.015+01:00

Sembla ser que el jet-lag comença a desaparèixer, per tant em poso a explicar el meu viatge a San Francisco per estar al Hadoop Summit 2010, fer una visiteta a alguns ex-companys de feina i unes visites a les oficines de Twitter, Facebook, LinkedIn i Cloudera.

Algo sèrio, bé, comencem pel començament:

Dia 1: LinkedIn + Cloudera.

Vam visitar el "data team" de LinkedIn, una gent molt interessant, apart de treballar en Hadoop (i per cert, ténen uns clusters bastant grossos) són els que han fet Voldemort, una K/V store en la qual serveixen les dades a la pàgina.

A més, ens van donar la oportunitat d'explicar com utilitzem Hadoop a last.fm i esmorzar :).

A la tarda vam anar cap a Cloudera, a on organitzaven un Hackaton de temes relacionats amb Hadoop. Més que els hacks en sí va ser interessant conèixer a la gent de Cloudera i altres que s'havien acostat a l'event, gent d'Infochimps i d'Opscode entre d'altres.

Dia 2: Hadoop Summit 2010.

El plat principal del viatge. Van vendre totes les entrades, hi havia aproximadament 1000 persones i les xerrades estaven repartides en 3 tracks diferents, aplicacions, desenvolupament i investigació. El hashtag era #hadoopsummit .

Tinc 8 folis de llibreta de notes que vaig pendre, per tant intentaré fer un resum del que vaig trobar més interessant, però primer, parlaré del que em va sorprendre més: la barreja de gent que hi havia.

Hi vaig trobar dos grans grups de persones, els que ja utilitzaven Hadoop i que per tant els interesava saber què s'està fent i com continuarà el projecte i els que volien començar a utilitzar Hadoop.

En aquest subgrup em vaig trobar i vaig parlar amb molta gent de consultories, de bancs i d'empreses d'assegurances. El seu cas és bastant curiós, els seus departaments d'IT han vist que Hadoop els pot ajudar molt en moltes de les seves activitats de mineria de dades i de processament, però els managers no s'acaben de fiar de que sigui software lliure. Una mica la història de sempre, gent que està més preocupada en escalar posicions dins de l'empresa que d'estar al corrent del que passa al món real.

Però bé, tornant a l'event en sí.

Com ja he dit, no faré un resum exhaustiu de tot el que es va parlar, però algunes de les idees més interessants:

Novetats dins Hadoop:

Facebook, Cloudera i Yahoo! estan començant a emmagatzemar Petabytes d'informació i estan creixent de forma exponencial. I en general molta gent utilitza Hadoop com a Data Warehouse.
La majoria d'empreses que ténen els seus propis clusters utilitza màquines amb 12 discs durs (la majoria de vegades d'1 Tb), per tant, 12 Tb per màquina.
Facebook i Yahoo! (les dues empreses ténen gent dedicada al 100% a desenvolupar Hadoop) estan invertint la majoria d'hores de commiters a millorar el DFS i el Namenode (el sistema que s'encarrega d'administrar el sistema de fitxers), bàsicament a fer-lo més estable (més encara ) i a permetre rèpliques i un possible Namenode secundari.
Hadoop ara incorpora seguretat (de forma opcional) amb certificats Kerberos. El projecte mai havia tingut en compte la seguretat, però hi ha moltes empreses usuaries (bancs, departaments de defensa (si si, departaments de defensa), consultories ) han apretat molt perquè Hadoop fos compatible amb Kerberos i tecnologies similars.
Facebook crearà la seva propia distribució de Hadoop.

Hadoop i Amazon AWS:

No sóc usuari dels Amazon Web Services, bàsicament perquè mai n'he tingut la necessitat, sempre he treballat en companyies que tenien les seves pròpies màquines, però en sóc un gran fan. Des de fa un temps Amazon ofereix màquines virtuals amb Hadoop instal·lat, em va sorprendre la quantitat d'empreses que ho utilitza dia a dia. Els punts més interessants:

La imatge de Hadoop que ve instal·lada amb les màquines incorpora de sèrie Hadoop, Pig i Hive, s'està treballant per incorporar HBase.
Permet ampliar i reduïr la mida del cluster en calent. Hi ha moltes empreses que ho utilitzen, per exemple, ténen un cluster de 4 màquines durant els dies de setmana per còrrer els seus treballs diaris i llavors per processar els treballs del cap de setmana (molt més grossos) amplien el cluster a 10 màquines, i quan els treballs estan acabats, tornen a les 4. Molt interessant, sobretot pel punt de vista econòmic.
Empreses com Netflix ténen tota la seva infrastructura de Data Warehousing a Amazon. Així no han de mantenir el seu propi cluster i poden dedicar més esforços a altres temes.

En general però la impressió que m'estic enduent és que cada vegada hi ha més empreses (de noves tecnologies i d'altres) utilitzant Hadoop, ja sigui en les seves pròpies màquines o bé en clústers virtuals, a més, estan apareguent empreses com Cloudera, Datameer i Karmasphere que dónen suport i eines relacionades en Hadoop, un fet que prova que Hadoop està sient acceptat per la comunitat i per les empreses.

Dia 3: Twitter + Facebook.

L'últim dia vam anar a Twitter, a veure a Johan Oskarson, ex-Last.fm. Està a l'equip d'analytics desenvolupant la integració de Cassandra amb Hadoop. Ens va portar a fer un tour per les oficines i ens van convidar a dinar.

Cap a la tarda a les oficines de Facebook, al grup d'usuaris de HBase, que és la implementació de Google Bigtable que ha fet la gent de Hadoop i que Facebook utilitza bastant ( té 3 enginyers només dedicats al seu desenvolupament).

A la reunió es van presentar les novetats d'HBase per la nova versió (0.9). De nou, es podria fer tot un post sobre el que es va dir, però intentaré resumir-ho en uns pocs punts:

S'ha treballar per la estabilitat del codi (abans era bastant inestable)
S'ha treballat en millorar la rèplica entre datacenters i la tolerància a fallades.
La velocitat de HBase és semblant a la Cassandra. Això són paraules gruixudes ja que sempre s'havia catalogat HBase com incapaç de servir dades per una pàgina web. Es veu que ara si (jo no ho he provat).
Facebook deixarà Cassandra (recordem que Cassandra surt de Facebook justament) per utilitzar HBase. Això també són paraules gruixudes. Molt gruixudes.

Enllaços relacionats:

Aquí podeu trobar més enllaços sobre el summit:

http://perspectives.mvdirona.com/2010/07/03/HadoopSummit2010.aspx
http://mndoci.com/2010/06/30/massive-data/
http://www.r-bloggers.com/my-experience-at-hadoop-summit-2010-hadoopsummit/
...

Enllaços de la setmana (II)

2010-06-14T15:24:00.003+01:00

Un parell d'enllaços que he trobat durant la setmana:

You're doing it wrong: Article molt interessant de Poul-Henning Kamp, de FreeBSD, creador d'entre d'altres, de la llicència Beerware, sobre la repercusió de la memòria virtual i la paginació en els algorismes.
Java Simon: Una llibreria de Java per monitoritzar el rendiment de les aplicacions. Molt senzilla d'usar.

Enllaços de la setmana (I)

2010-06-06T21:18:00.003+01:00

Obro una "nova secció" al blog, cada setmana intentaré posar els links més interessants que he anat trobant. Ja aviso que no tot seran novetats dins el món de la informàtica distribuïda, però sempre hi tindran (espero) alguna cosa a veure.

Comencem amb la primera setmana:

Java Community Process: No té res de nou, però és la pàgina principal per fer investigacions sobre com funciona el llenguatge Java i la màquina virtual under the hood.
Article molt interessant sobre eficiència en servidors multiprocessadors en Java: Més Java, aquest link és un article bastant tècnic sobre les millores d'eficiència quan es fan còrrer diversos (o alguns) processos Java en un sol processador en comptes d'un multiprocessador. És lectura obligada per programadors de servidors en Java, i promet discussió.
Article d'Oreilly sobre què és la Data Science: Ja n'he parlat alguna altra vegada de la Data Science. Aquest és un article/explicació que va ser molt popular la setmana pasada per Internet.
Vídeo molt interessant sobre Data Science: I més Data Science, aquesta vegada en format vídeo d'una de les enginyeres de bit.ly

Rest vs Soap (II)

2010-05-28T14:04:00.001+01:00

Us deixo un enllaç molt interessant sobre l'estat de les API de serveis d'Internet al 2009 i 2010:

http://www.readwriteweb.com/cloud/2010/05/pen-api-madness-the-party-has.php

Fixeu-vos en la gràfica que mostra el número de crides REST vs SOAP.

La màquina virtual de java (I)

2010-05-25T07:16:00.002+01:00

Aquests últims dies he estat intentant informar-me de quines són les millor tècniques per optimitzar processos Java. Hi ha molta informació a la web, la majoria està a la pàgina oficial de ~~Sun~~ Oracle.

He intentat fer un petit resum per si a algú li interessa. Lògicament és una petita introducció amb molts de links a les pàgines amb la documentació oficial.

Primer, unes consideracions sobre optimitzacions i "benchmarks" que crec que són importants:

Java SE 6 no va introduïr moltes novetats pel que fa a la API. Bàsicament és una actualització que atacava la performance de Java. Podem veure algunes gràfiques comparant els diferents rendiments a [7]. Per tant, és important que ens assegurem que sempre tinguem la última versió de Java instal·lada al sistema. Un altre tema és que la informació que trobareu aquí parla exclusivament de la VM Hotspot (de Sun). Hi ha altres VM, amb altres rendiments, com podeu veure a [8].

En quant a les monitoritzacions, sempre que provem alguna cosa cal que les dades i l'estat de la màquina sigui el mateix. Tot i això en java cal tenir en compte:

Warmup: La JVM funciona interpretant codi compil·lat. Segons la modalitat en que s'estigui executant (client o server) detectarà mètodes hot (que s'usen molt sovint) i els compilarà a codi natiu de la màquina per millorar-ne el temps d'execució. Això fa que el rendiment millori a mesura que s'executa el programa.
Garbage collection (GC): He pogut comprovar que la majoria de tècniques d'optimització en Java tenen a veure amb la gestió del GC i de la memòria. Malauradament el tema és molt complexe i es mereix un post ( o un llibre ) per si sól.
Mesurament de temps: En cas de que volguem pendre mesures de temps del programa i que no tinguem un profiler a mà Java ofereix dues crides que retornen temps. Es veu però que la System.currentTimeMillis() no és del tot fiable (sobretot en sistemes operatius Windows) i es recomana utilitzar la System.nanoTime().

Finalment tenim la interpretació de resultats. No hi ha prou en executar-lo una vegada. Si es pot s'hauria de fer un anàlisi estadístic (més sobre tot això en un pròxim post).

Un cop feta la introducció al tema, comentaré alguns dels links més interessants que he trobat:

Java Tuning Whitepaper [1], tot i que sigui del 2005, és un molt bon recurs introductori. Molt genèric i fàcil d'entendre. Com ja he dit abans, bàsicament es parla de memòria i de GC.

La màquina virtual de Java té les opcions que formen part dels Ergonomics, que són les opcions que permeten modificar el comportament a l'hora d'executar els divesos programes, les opcions més conegudes són:

Xms: La quantitat de memòria inicial del programa. Si no donem una mida inicial aquesta serà de 2 Mb.
Xmx: La quantitat màxima de memòria que la màquina virtual estarà permesa a utilitzar.

Lògicament, hem de vigilar a l'hora d'asignar aquests valors, ja que influiran molt en el rendiment del programa, com més memòria millor, ara bé, com més memòria més haurà de treballar el GC i menys quedarà pel sistema operatiu, cosa que pot ocasionar que el rendiment general del sistema es vegi perjudicat.

Algunes opcions relacionades amb el GC [2]:

The -XX:+UseParallelGC parallel (throughput) garbage collector.
The -XX:+UseConcMarkSweepGC concurrent (low pause time) garbage collector (also known as CMS)
The -XX:+UseSerialGC serial garbage collector (for smaller applications and systems)

Una de les opcions que no coneixia d'abans és la de canviar la mida de les pàgines de memòria, bàsicament modificarem la mida de la TLB (Translation-Lookaside Buffer) que és la part de memòria que manté les traduccions de memòria virtual a memòria física. Ampliant la mida de les pàgines també ampliarem la mida de la TLB, i per tant seran menys fallades a l'hora de buscar adreces de memòria. Pot millorar l'eficiència d'aplicacions que utilitzin molta memòria. Cal tenir en compte que es pot afectar negativament l'eficiència del sistema, ja que l'aplicació pot fer un us execessiu de memòria fent que la resta del sistema es quedi curt, a més no és fàcil de configurar (s'ha de fer canvis a nivell del SO) podeu trobar instruccions aquí [3].

I més opcions llistades a [4], de les quals destacaria:

XX:+UseFastAccessorMethods: Use optimized versions of GetField.
XX:+StringCache: Enables caching of commonly allocated strings.

El document també té una secció molt interessant amb exemples explicats [5].

Finalment us deixo una llista de links bastant interessants sobre la JVM:

Referències.

[1] http://java.sun.com/performance/reference/whitepapers/tuning.html

[2] http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

[3] http://java.sun.com/javase/technologies/hotspot/largememory.jsp

[4] http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#PerformanceTuning

[5] http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2

[6] http://java.sun.com/performance/reference/whitepapers/6_performance.html

[7] http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.3

[8] http://www.usenix.org/event/jvm02/full_papers/jacob/jacob_html/node12.html

Nou disseny!

2010-05-18T21:12:00.002+01:00

Bé, com que n'estava bastant fins als nassos del disseny vell, i sobretot dels problemes que tenia amb les fonts, els paràgrafs i els espais he decidit canviar de plantilla. Espero que aquesta sigui més agradable.

M'ha anat d'un pèl a no muntar el blog a un altre sistema com wordpress o postero.us.

Resum de la NoSQL EU 2010

2010-05-17T17:29:00.015+01:00

Fa temps que tenia pendent un post sobre les bases de dades "nosql". Les he tractat una mica per sobre en anteriors posts, i aprofitant que el mes passat vaig poder anar a la NoSQL EU 2010 crec que és un bon moment per reprendre el tema.

Primer de tot, posem-nos en contexte i comencem pel principi.

Què són les bases de dades #Nosql?

Ja n'he parlat en posts anteriors, però podem dir de forma resumida que són unes bases de dades que no segueixen el model relacional, i que per tant, no intenten seguir les normes ACID.

Aquestes bases de dades han sorgit d'un seguit de necessitats molt lligades a uns grans volums d'informació, i per tant, a la distribució i escalabilitat dels sistemes. És per això que molt sovint estan relacionades a frameworks com Hadoop, del qual també n'he parlat en aquest blog.

Hi ha diverses categories de Nosql, ràpidament:

Key-Value stores: Són taules de hash gegants. Volen ser molt ràpides.
Document stores: Contenen informació sense esquema, normalment representada en json i indexada per qualsevol tipus dels seus valors.
Column stores: Model Bigtable.
Graph databases: Representen un graf amb els seus nodes i connexions.

De què es va parlar a la NoSQL EU 2010.

La conferència va ser organitzada de tal manera que fos més un punt de trobada de programadors interessats en aquesta tecnologia que una conferència de classes magistrals.

Van haver-hi una sèrie de discussions sobre què és aquesta tecnologia i sobretot, què no és, ja que no ha sigut gaire ben rebuda per alguns sectors del món informàtic. S'ha d'admetre que el nom de NOSQL no és que estigui molt ben triat, certament dona una impressió potser una mica massa agresiva, però sembla que s'hagi muntat una espècie de guerra religiosa, en la qual, lògicament no penso entrar. [1] [2] [3]

Dins d'aquest "bloc" més general de la conferència hi va haver una explicació sobre les diferents categories i models de dades i una xerrada molt interessant a càrrec de Werner Vogels (@Werner), CTO d'Amazon, un dels creadors de Dynamo, i probablement una de les persones més importants dins del món dels sistemes distribuïts (opinió personal, feel free a opinar :) .

El tema més tractat i el que va ser més interessant per tothom va ser sens subte els casos d'ús d'aquesta tecnologia i experiències reals, on es va explicar com funcionen aquests sistemes en producció a la BBC, The Guardian i Twitter entre d'altres, com s'han fer per escalar, sobre quins tipus de màquines corren, la càrrega i els problemes que havien tingut els equips que les havien desplegat.

Sensacions de les sessions i idees a destacar.

Bé, sens cap mena de dubte el plat fort va ser la xerrada de Werner Vogels. Molt genèrica sobre sistemes distribuïts, la seva dificultat d'implementació i la seva història, però així mateix molt interessant. Els punts que em van agradar més:

Va destacar la importància de la col·laboració entre l'academia i la industria, per aconseguir tenir els punt de vista teòric i pràctic per finalment poder arribar a un sistema real i utilitzable.
La dificultat dels sistemes, i que no hi ha un sistema perfecte, ni hi serà.

I guardo pel final el que em va agradar més i el que em va fer pensar més també:

Un sistema (distribuït, en producció i crític) ha de ser anti tot. Volent dir que s'ha de fer de tal manera que el sistema aguanti TOT el que li caigui. En uns límits lògicament. Ha d'aguantar caigudes de xarxa, net splits, data centers que es queden sense conexió (això pasa, no m'ho creia, però us puc assegurar que pasa), sistemes de fitxers que es corrompen i bases de dades (relacionals o no) que es queden penjades. Va utilitzar la següent frase per resumir-ho:
"Si hi ha un problema el dissabte a la nit, el sistema hauria de ser capaç a mantenir-se funcionant fins que l'encarregat del sistema vagi a treballar el dilluns a les 9 del matí".
Vaig tornar a pensar amb aquesta frase quan el fa dos dissabtes em va sonar el mòbil a les 4 de la matinada (fet verídic).

Si algú vol més informació sobre el tema pot obtenir més informació en els següents links:

Presentacions de la conferència a slideshare. (la més introductòria)
My Popescu. Un blog amb noticies sobre el moviment #nosql
El grup de discussió a google groups.

I lògicament, qualsevol dubte, ja sabeu a on em podeu trobar!

Implementant servidors RPC

2010-01-20T22:40:00.005Z

Recentment he implementat un servidor a la feina. Es tracta d'un programa relativament senzill que presenta una API en thrift, a on cada mètode retorna una llista de valors. A on és la gràcia? doncs la gràcia és la càrrega que ha d'aguantar aquest servidor, i saber i tenir en compte quins tipus de recursos hardware utilitzarà més.

Primer de tot ens hem de fer unes preguntes sobre el que li caurà a sobre:

Què aguantarà normalment, o sigui, quantes peticions per segon haurà de contestar?
Quantes peticions de mitjana?
Quantes peticions rebrà a l'hora punta?
Hi haurà algun cas excepcional (però que igualment s'haurà de cobrir) a on les peticions per segon es disparin?
Quin timeout tindrà el client que l'utilitzarà.

Següent, quins tipus de recursos hardware seran el coll d'ampolla?
Utilitzarà molta RAM?
Farà moltes lectures a disc (el disc és local o bé remot?)
Utilitzarà molta CPU?
Utilitza recursos remots, com bases de dades?

Lògicament això depen totalment del tipus de servei que estem implementant, tots són diferents, però en el meu cas es tracta d'un servei a on el coll d'ampolla és el disc. Estic llegint de diferents fitxers de text gegants, que canvien periòdicament i sense repetició de peticions del mateix valor, ah, i també necessito valors d'una base de dades remota. Què vol dir això?

El fet de que siguin fitxers gegants i bastants vol dir que no es poden llegir una vegada i tenir-los guardats a memòria. Per tant, cada vegada s'haurà de llegir de disc i…
Si mai es requereix el mateix valor vol dir que sempre s'hauran de llegir posicions diferents (i aleatòries) del fitxers i que per tant no val la pena tenir "valors populars" a la memòria cau perquè com a màxim es llegiran una vegada.
I de regal en la majoria d'invocacions he de consultar un valor en una base de dades.

Bé, tinguent en compte tot això… ho implementem. Uns dies després, s'haurà de provar.

Com ho proves un servei d'aquests?

Lògicament el servei tindrà una sèrie de testos unitaris i una sèrie de comprovacions. Però en aquest cas no em refereixo als testos d'integritat de dades i de funcionalitat. Em refereixo als testos de càrrega. Perquè no podem posar un servei en viu sense saber perfectament que aguantarà el que hagi d'aguantar. Oi?

La solució immediata és implementar un client que utilitzi l'API del servei. Una cosa tant senzilla com un bucle que invoqui mètodes i controlar els temps de resposta, amb això aconseguirem un nivel de càrrega baix, però ja tindrem per començar. Els següent pas és paral·lelitzar aquest client, fer que crei diferents threads, i que cada thread faci les seves peticions al servidor, aquí ja podem aconseguir un nivell de càrrega decent, tot i que dependrà de l'ample de banda de la màquina a on estiguem corrent el client. El següent pas és utilitzar aquest client en diverses màquines a l'hora contra el mateix servidor, aquesta és la única manera amb la que es podrà recrear un volum de trànsit "real".

Ara bé, a l'hora d'implementar el client, uns punts que s'han de tenir _molt_ en compte:

S'han d'invocar _tots_ els mètodes del servidor, amb paràmetres _reals_ i vàlids. Així recrearem les peticions òptimes que hauria de rebre el servidor.
S'han d'invocar _tots_ els mètodes del servidor, amb paràmetres _reals_ i _invàlids_. Un cop tinguis el servidor instal·lat i de "cara al públic" mai sabràs el que t'arribarà. No té sentit optimitzar el servidor si llavors un paràmetre fora d'ordre o fora de rang fa que saltin excepcions de forma interna o bé que es bloquegi. En el món real arribaran peticions invàlides, s'han de tenir en compte.
S'ha de provar el servidor a poder ser amb dades reals o bé de la mateixa magnitut de les dades amb que treballarà. El programa no tardarà el mateix en llegir un fitxer de 2Mb que un de 200Gb, depen del que facis fins i tot es pot quedar sense memòria. De la mateixa manera que si s'utilitza una base de dades no és el mateix fer una consulta a una taula amb 100 files d'una base de dades de test local que a una taula de centenars de milions de files en una base de dades en producció amb diversos usuaris utilitzant-la de forma concurrent.

En el meu cas vaig programar un client multithread en java amb tota una bateria de peticions vàlides i invàlides, que anava cridant de forma aleatòria, vaig tenir la sort de poder provar el servidor amb dades reals, ja que és només de lectura en una màquina exactament igual a la màquina de producció.

Pel tema de provar el client a l'hora en diverses màquines vaig poder utilitzar 40 màquines a l'hora amb 100 threads cadascunta, això son 4000 threads fontent canya al servidor :) .

Ah, una eina molt pràctica i senzilla per paral·lelitzar comandes en bash és dsh.

Vaja, tarda molt, es queda sense memòria o es penja.

Bé, el servidor funciona bé amb un thread, ja li costa més amb 100 threads i deixa de respondre en 4000. Què passa?

Això ja depén bastant del llenguatge d'implementació. En el meu cas vaig utilitzar Java i una molt bona eina per trobar problemes d'eficiència és jstack que permet veure volcats de la pila d'una aplicació corrent sense matar-la.

Bàsicament es tracta d'executar aquesta aplicació al servidor i llavors buscar entra els volcats de pila dels diversos threads el que estan BLOCKED, en cas de que n'hi hagi vol dir que són threads que estan en l'espera d'alguna cosa. Això pot donar pistes de llocs a on es pot optimitzar el codi.

i finalment, us deixo amb:

les receptes de l'àvia per optimització en Java.

Algunes coses que convé recordar a l'hora de programar en Java (tot i que algunes són de calaix):

En cas de que s'utilitzi bases de dades. És important que les connexions estiguin en un "pool" i que no es crein/destrueixin cada vegada. En cas d'utilitzar Spring/Hibernate, cal saber què s'està fent. Aquests frameworks ténen moltes classes i cadascuna fa una cosa, convé utilitzar la que toca.
També en cas de que s'utilitzi una base de dades. Vulguis o no, pot ser costós, sobretot si es fa moltes vegades. Cal pensar sobre el resultat que n'obtenim. Spring/Hibernate utilitzen Cache per emmagatzemar valors de forma transparent, això és una cosa que també es pot fer a nivell d'aplicació. Abans d'anar a la capa de dades, pensem-ho dues vegades, si ja hem buscat exactament allò a la base de dades quina és la probabilitat de que hagi canviat? si és poca, no cal fer la consulta. Posem el resultat en cache i ja ho preguntarem de nou al cap de 1 minut, 10 minuts o 1 hora.
Utilitzem llistes? LinkedList o ArrayList? Utilitzem conjunts? HashSet o TreeSet? la elecció de l'estructura de dades òptima pot tenir implicar unes diferències de recursos i de velocitat impressionants. Ah, i lògicament si sabem més o menys la mida que tindrà la llista resultat, inicialitzem la talla de la llista al crear-la. En aquest cas, la api de sun és la vostra amiga.
Estem concatenant strings? doncs StringBuilder.

Espero que l'article sigui clar i que almenys el checklist de coses a provar estalvïi problemes a algú :)

SOAP fail

2009-11-08T12:17:00.002Z

Estic veient una tendència a la xarxa?

Blog de Github, post sobre RPC's:

"XML-RPC, SOAP, and other XML based protocols are hardly even worth mentioning. They are unnecessarily verbose and complex. XML is not convertible to a simple unambiguous data structure in any language I’ve ever used. I’ve wasted too many hours of my life clumsily extracting data from XML files to feel anything but animosity towards the format."

Un altre, blog que es lamenta dels SOAP's.

Del paper sobre Thrift (by Facebook): Thrift és un RPC que han fet els de Facebook per ús intern, al paper on n'expliquen les bases fan una comparació amb altres frameworks i dónen els motius pels quals no els han utilitzat, en cas de SOAP, simplement:

"SOAP. XML-based. Designed for web services via HTTP, excessive XML parsing overhead."

Estic convençut d'haver llegit més històries recentment, però vaig ser massa mandrós per anar-les apuntant.

En definitiva. No utilitzeu SOAP Web Services. Algun dia explicaré perquè els hi tinc tanta mania.

Spring killed the Java star.

2009-10-29T22:09:00.003Z

Un títol suggerent no ?

Els que em coneixen sabran que mai he sigut un fan ni de Spring ni d'altres frameworks ni convencions de programació. No sé, sempre he sigut de la vella escola.

Anem en compte. Són uns grans frameworks i realment ajuden en el desenvolupament, sobretot d'aplicacions d'un nivell avançat i complicat. I tot i que els utilitzo poc, els utilitzo.

Actualment a last.fm estem buscant gent, tenim dues posicions obertes:

Enginyer de Dades: Necessitem un enginyer que es manegui bé treballant amb moltes dades (Terabytes) i Java.
Enginyer de Catàleg: Hauria de tenir un nivell avançat de Java + SQL + Postgres.

Que ho sapigueu.

Bé, estem fent entrevistes de feina i tenim alguns problemes. Bàsicament tenim moltes aplicacions de gent que sap Hibernate, però no domina SQL i sap Spring, però no domina Java. Fatal.

Per què? doncs per els següents motius:

Bases de dades: Hibernate es una solució meravellosa. Un cop tens tota la història configurada et permet accedir a la base de dades de forma còmoda, sense històries i sense SQL. Meravellós oi? doncs sí. Ara bé! què passa quan hi ha una urgència i s'han de fer queries complicades a la base de dades des d'un terminal per ssh. Ja l'hem liada. Doncs no pot ser.
Java: Aquest tema és més general. Molta gent que sap Spring té clares com fer les coses, però moltes vegades no sap perquè es fan d'aquesta manera. Si t'estàs enfrontant amb un projecte clàssic, com és tenir una base de dades amb un nivell de domini ben definit, un nivell amb els controladors i el nivell de vistes el que t'importa és fer les coses el més bé i el més còmodament possible, en aquest cas Spring (o qualsevol altre framework) és una solució idònia. Quan estàs en una situació estranya què s'ha de fer? doncs tirar de l'API de Java. I si és una situació estranya cal dominar-la.

El cas de last.fm és bastant peculiar. El meu equip treballa amb moltes quantitats de dades, és per això que entre d'altres eines utilitzem Hadoop. Però no sempre es soluciona tot amb Map Reduce.

Amb un volum d'entrada de dades normals, l'elecció entre un HashMap o un TreeMap (lògicament per alguna tasca auxiliar i no guardar les dades!) pot sembla anecdòtica. La diferència serà de microsegons. Ara bé, si l'entrada és de Terabytes de dades la diferència pot arribar a ser d'hores en quan a velocitat, apart de que podem rebentar el límit de memòria de la màquina virtual. Per tant, en el nostre cas, són coses que s'han de saber.

Lògicament són coses que s'aprenen amb experiència, però estic veient que aquests tipus de coneixements, els coneixements sobre com funciona un llenguatge o un compilador a fons manquen cada vegada més i més. Aquest tipus de frameworks estan apartant coneixements bàsics d'informàtica que sempre s'haurien de tenir en compte.

Bé, això són tant sols unes reflexions personals. Cal saber de tot i aquests frameworks són importants, ara bé, com tot, s'ha de saber quan s'han d'utilitzar i quan no.

Technical documentation guidelines.

2009-07-30T00:43:00.003+01:00

After some years of working as a developer I've realized the lack of standard guidelines when it comes to writing technical documentation. Not user manuals. Technical documentation, the one you should write when you develop a system, or the one you should get when you start maintaining a system somebody developed.

So, no standard guidelines around ? (at least that i liked), no problem, open source, open world. I made my own.

I started researching, getting technical documentations from different projects, getting the opinions from lots of good professional developers and using lots of common sense (my common sense, well, and sometimes other people's common sense) and this is what i came to:

Ok, I tried, I promise, I tried. I cannot format the document in Blogspot. I've created a static html page. You can find the article: HERE

Hive

2009-07-11T20:52:00.005+01:00

Aquest post parlo de Hive, una eina que han fet a Facebook que converteix un llenguatge d'accés a dades semblant SQL a treballs map-reduce per fer consultes als directoris guardats en el DFS de Hadoop.

Un dels problemes que tenim els usuaris de Hadoop és que estem treballant amb uns volums de dades considerables. En cas contrari seria millor utilitzar Python o Erlang o una base de dades relacional (insisteixo una vegada més, Hadoop si i només si s'ha de treballar amb moltes dades). Com ja he explicat en altres posts un dels sub-projectes de Hadoop és el sistema de fitxers, fet a inspiració del Google File System (GFS). És un sistema redundant i distribuït, per tant cada fitxer està fragmentat per la xarxa i n'hi ha diverses còpies. Això implica que sigui molt difícil perdre un fitxer (ja que n'hi ha 3 còpies diferents), però al mateix moment es fa més complicat poder accedir a aquest fitxer, ja que qualsevol manipulació que se li vulgui aplicar (sense un treball map/reduce de Hadoop) força que s'hagi de baixar del clúster, i aquests fitxers poden arribar a ser molt grans (molt molt grans).

Això a efectes pràctics significa que no es pot fer de forma senzilla un 'grep' per buscar continguts. El fitxer està repartit pel clúster per tant, s'ha de fer un treball map-reduce per fer el grep. El codi de hadoop ja porta implementada aquesta utilitat, però igualment és incòmode i poc potent.

En principi no hauria de ser un problema, ja que normalment interessa processar una entrada i un cop tenim la sortida a punt la baixem tota del clúster per servir-la a la pàgina web, per inserir-la a la base de dades o el que sigui. El problema ve quan necessites saber (urgentment) una certa línia d'un fitxer de 200 Gb que està fragmentat dins el clúster.

Potser això és una mica difícil d'entendre, un exemple:

Com sabeu fa poc es va morir Michael Jackson, doncs bé, quan la noticia es va escampar la gent va començar a escoltar la seva música. A last.fm vam començar a rebre scrobbles de Michael Jackson, aquests scrobbles, que basicament hi ha l'identificador d'usuari i la cançó que aquest ha escoltat es guarden al sistema de fitxers distribuït per a ser processats per Hadoop. No ens volíem esperar a que fos al vespre per saber quanta gent de més havia escoltat al difunt rei del pop. La solució era fer un programa (en Java o bé en Dumbo) per agafar aquestes dades i fer un grep per veure quants usuaris era, una cosa que utilitzant bash senzillament seria:


bash $> grep michaeljackonid fitxer_scrobbles | sort -k columna_usuari -u | wc -l

és en Java molt més pesat i complicat d'escriure.

Els de l'equip de dades ja havíem tingut diverses peticions d'aquestes anteriorment, i ja tenim una sèrie de programes (mal fets, a base de copy and paste, ràpids) per fer consultes. El principal problema és que d'aquesta manera s'acaba tinguent una bateria d'scripts de consulta que són impossibles de reutilitzar, totalment específics i que serveixen tant sols una vegada.

Però aquesta vegada va ser diferent, perquè des de feia uns dies estàvem jugant amb Hive!

Segons la seva pàgina, Hive és una infraestructura de 'warehouse' (magatzem de dades) que corre sobre Hadoop i permet la consulta de dades. Per tant, és en certa manera. Una infraestructura per córrer SQL sobre directoris de DFS.

Convé tenir en consideració els següent punt, molt important:

Hive no és una base de dades.

El que fa Hive és tenir en uns fitxers propis del DFS de Hadoop una sèrie de dades que en certa manera descriuen les estructures de directoris dels directoris normals del DFS. Un cop tenim això, la línia de comandaments de Hive permet fer consultes amb SQL. S'ha elegit aquest llenguatge de consulta perquè (desgraciadament?) és el que sap tothom i realment no fa falta crear-ne cap altre.

Aquesta consulta SQL és convertida per Hive en diversos passos, com podem veure en el document d'arquitectura en una sèrie de tasques Map Reduce que corren de forma normal al clúster.

Aquestes tasques senzillament agrupen les dades i les filtren tal com hem dit a la consulta, i en cas que sigui necessari les ordenen (order by), treuen duplicats (distinct)...

Per tant, amb Hive podem córrer una consulta sobre totes les dades del sistema de fitxers distribuït, de forma senzilla i sense haver de carregar totes les dades en una base de dades relacional.

A mi personalment, m'estalviarà moltes hores, ah, i per cert, l'augment d'oients de Michael Jackson el podeu trobar aquí.

Nosql

2009-06-16T23:27:00.002+01:00

Tot just la setmana passada es va celebrar la primera trobada Nosql a San Francisco, sobre bases de dades distribuïdes i no relacionals. Coincidint amb el Hadoop Summit 2009.

Bàsicament va ser una trobada dels principals desenvolupador / usuaris de bases de dades no relacionals (basades en Google BigTable i Amazon Dynamo), on cada desenvolupador va explicar les característiques del seu sistema.

Aquí us deixo un link del blog de'n Johan Oskarsson que hi va assistir amb els links a totes les transparències utilitzades així com els videos. Espero que us sigui de servei!

Hadoop, the definitive guide.

2009-06-15T18:17:00.002+01:00

S'acaba de publicar a O'Reilly 'Hadoop, the Definitive Guide'. Un llibre sobre Hadoop (lògicament) que ha escrit Tom White i en el qual he contribuït en un capítol d'experiències.

pd.- Lògicament sóc el culpable de la imatge de la pàgina 413.

Dynamo

2009-05-17T17:50:00.002+01:00

Avui toca comentar el segon article sobre nous models de bases de dades. Per tant, nens i nenes, Dynamo. Per cert, un dels autors del paper és Werner Vogels, CTO d'Amazon, i realment recomano molt el seu blog, All things distributed. Vinga va, comencem...

Dynamo és una key-value store que és utilitzada ( i dissenyada i programada ) a Amazon. Suposo que tots sabeu a què es dedica Amazon i també podeu tenir una idea de com és la pàgina web. Per tant, no és una sorpresa quan veiem que dos dels principals objectius de Dynamo son:

Escalabilitat.
Alta disponibilitat.

Igual que la Google va dissenyar i programar la seva pròpia solució al emmagatzemament de dades, ja que no va trobar cap producte que pogués utilitzar, per tant Dynamo es va fer a mida. Hi ha molts serveis interns d'Amazon que només necessiten accés simple a un valor segons un clau. Per tant, una taula de hash.

Dynamo utilitza una barreja de tècniques ben conegudes dins de l'àmbit de sistemes distribuïts per aconseguir escalabilitat i disponibilitat, entre les quals hi ha la partició i replicació de dades entre els diferents nodes i versionat d'objectes. Ara bé, quan tenim objectes replicats i repartits a través de la xarxa apareixen problemes. Com ho fem per assegurar que totes les còpies dels objectes són la mateixa ? com ho fem perquè quan un usuari afegeixi un CD al seu carro de la compra, totes les còpies s'actualitzin? En aquest cas Dynamo utilitza una tècnica, semblant a un quòrum i un protocol descentralitzat de sincronització de rèpliques (sona guai eh?, tranquils que ja explicaré una mica més endavant què és), a més, té un detector de fallades mitjançant un protocol de gossip (hi haurà un article aviat només d'aquests protocols, no patiu). Tot això fa que els nodes d'emmagatzemament puguin ésser afegits i trets de la xarxa sense cap tipus de partionament o redistribució manual. Tot és automàtic.

Aquesta key-value store està en producció i ha estat provada repetides vegades, el seu primer gran repte va ser suportar tota la càrrega addicional del període nadalenc. Simplement va funcionar i va escalar el que va fer falta sense que ningú hi fes res (si més no, és el que diuen, jo no hi era :P).

Consideracions de disseny

Amazon al principi utilitzava RDBMS per tots els seus sistemes. Molts d'aquests sistemes guardaven la informaci i la consultaven per la clau primària, això vol dir que realment no utilitzaven totes les possibilitats d'aquests sistemes. A més, les funcionalitats de rèplica que ofereixen aquestes tecnologies trien la consistència en comptes de disponibilitat. Això en paraules planes vol dir que si la base de dades troba que un valor que està replicat (té "còpies de seguretat") té valors diferents entre les còpies, prefereix solucionar el problema en comptes de retornar el resultat, causant retards.

Per tant, els requeriments que tenia l'equip d'enginyers d'Amazon eren:

Model de consulta: Operacions de lectura i escriptura a un element que simplement està identificat per una clau. No hi ha operacions que realitzin consultes a diferents elements a l'hora, simplement no hi ha necessitat de cap esquema relacional.
Propietats ACID: Les bases de dades que implementen les 4 lletres tendeixen a tenir poca disponibilitat en casos extrems, per tant, es va decidir rebaixar la 'C' (Consistència), cosa que implica una millora en la disponibilitat.
Eficiència: El sistema havia de funcionar (igual que Google/BigTable) en hardware senzill i barat, i tots les mètriques de latència estan preses en el 99.9 percentil de la distribució. Cosa que vol dir que SEMPRE ha d'anar molt ràpid.
Altres: Dynamo funciona dins d'Amazon, per tant s'entén que és un entorn no hostil, per tant, no hi ha requeriments de seguretat, ergo, no hi ha ni autenticació i autorització.

Un cop tenim clars els requeriments passem al disseny de Dynamo.

En entorns de bases de dades distribuïdes és important el tema de la consistència entre rèpliques (com ja s'ha comentat abans). Normalment s'utilitza una coordinació síncrona de rèpliques per poder tenir una consistència fiable. Això implica que la disponibilitat del sistema és menor en alguns escenaris de fallada, ja que el motor de la base de dades marca les dades com no disponibles fins que està totalment segur que tot és correcte.

Dynamo ho fa diferent, utilitza tècniques de replicació optimista, que vol dir que els canvis es propaguen passi el que passi i que es permet continuar treballant amb normalitat tot i que hi hagi casos de desconnexió. Aquesta aproximació pot portar a casos on es poden trobar conflictes, lògicament aquests conflictes s'han de descobrir i arreglar. Ara bé:

Qui ho resol?
Quan ho resol?

Atenció amb la següent frase que té tela (i la poso en negreta perquè almenys jo, la primera vegada que la vaig llegir vaig caure de culs a terra): Dynamo està dissenyat per ser una data store que tard o d'hora serà consistent, cosa que vol dir que tots els canvis tard o d'hora arriben a tots els nodes. Que xulos que són.

Ara bé, perquè tard o d'hora les dades siguin consistents s'han de resoldre les dues preguntes anteriors. La de quan es resol vol dir si es fa durant les lectures de les dades o les escriptures. Normalment les resolucions es fan en les escriptures per mantenir les lectures senzilles. En el cas de Dynamo ho han fet diferent. I una altre vegada, al ser una base de dades per a Amazon, van considerar que era millor que les escriptures fossin més senzilles i ràpides, no és d'estranyar, perquè en el seu cas una escriptura implica que un usuari afegeix un producte al carro de la compra. Per tant, és important que l'operació d'afegir sempre funcioni.

La pròxima pregunta, qui resol els problemes, les opcions són o bé que ho faci Dynamo o bé que ho faci el programa que està utilitzant Dynamo. Dynamo permet les dues dues, en cas de que sigui la mateixa key-value store que ho faci poca cosa hi pot fer, tant sols pot utilitzar polítiques ben senzilles com ara "l'últim d'escriure guanya". D'altre banda, en cas de que sigui l'aplicació que arregli els conflictes, al tenir tota la informació de què són les dades i d'entendre la lògica del sistema pot fer qualsevol cosa que sigui necessària.

Altres detalls tingut en compte en el disseny:

Escalabilitat incremental
Simetria: Cada de node que participa a Dynamo ha de tenir les mateixes responsabilitats que la resta. No hi ha rols especials (això ho converteix en un P2P).
Descentralització
Heterogeneïtat: Les màquines que formaran els nodes de Dynamo no seran iguals, i no seran super màquines, per tant, és necessari que el sistema tingui en compte el tipus de màquina que és cada node i que la seva càrrega sigui proporcional a les seves capacitats.

Arquitectura

L'arquitectura de Dynamo, recordem, ha de tenir maneres escalables i robustes de:

Poder balancejar la càrrega.
Detectar fallades.
Recuperar-se de fallades.
Sincronitzar les rèpliques.
Detectar i reaccionar a sobrecarrega.
Ésser capaç de treballar amb concurrència de tasques.
Distribuir tasques.
Agrupar requestes.
Monitoritzar el sistema.
Disparar alarmes en cas d'errors o de situacions estranyes.
Configurar-se.
Fer massatges als programadors (aquesta la he afegit jo, però crec que no ve d'aquí, francament).

Si heu llegit el post anterior, el de BigTable recordareu que no es parlava en tant detall de l'arquitectura del sistema. Això és perquè l'equip de BigTable va poder aprofitar molts components que altres equips d'enginyers de Google ja havien implementat i que en part, solucionaven la majoria d'aquests problemes, d'altre banda, l'equip d'Amazon ho va haver d'implementar tot de dalt a baix.

Algunes de les tècniques clàssiques que utilitza Dynamo per tractar alguns dels problemes citats anteriorment (s'expliquen en més detall a continuació):

Problema	Tècnica	Avantatge
Partionament de dades	Hashing	Té bona escalabilitat
Bona disponibilitat per les escriptures.	Rellotges vectorials amb reconciliació.	La mida de la versió es deslliga de les tasses de renovació.
Tractament de fallades temporals.	Quòrum reduït	Té bona disponibilitat i garantia de durabilitat quan algunes de les rèpliques no estan disponibles.
Recuperació de fallades permanents.	Anti-entropia utilitzant arbres de Merkle	Sincronitza rèpliques divergents en segon terme.
Detecció de fallades i de membres.	Gossip protocols i de detecció de fallades.	Manté la simetria i evita tenir un registre centralitzat per guardar la llista de membres i el seus estats.

Interfície del sistema

Dynamo guarda els objectes amb les seves claus mitjançant una interfície simple. Ofereix dos mètodes, get() i put(). El mètode get localitza les rèpliques de l'objecte associat amb la clau al sistema d'emmagatzemament i retorna un sòl objecte en cas de que no hi hagi conflicte, o bé una llista amb els objectes amb conflictes amb un context.
D'altre banda, el mètode put determina on les rèpliques de l'objecte haurien d'estar guardades i les hi escriu a disc. El context codifica meta-data (dades sobre dades), com per exemple la versió de l'objecte. Aquesta informació és guardada amb l'objecte de tal manera que el sistema en pot verificar la validesa.

Dynamo tracta tant la clau com l'objecte com un vector de bytes. L'algorisme de hashing per generar l'identificador de la clau és MD5, i genera un id de 128 bits.

Algorisme de partionat

Un dels requeriments de Dynamo és que pugui escalar. Això implica que té un mecanisme per partionar dinàmicament les dades a través dels nodes. La sortida d'aquest algorisme de partionat és tractada com un espai circular o "anella". A cada node del sistema se l'hi assigna un valor aleatori en l'espai, cosa que representa la seva "posició" dins de l'anella.

Cada element de dades és identificat per un clau, la qual és assignada a un node aplicant-li la funció de hash, que ens retorna la seva posició en l'anella. Tot seguit seguim l'anella en sentit anti-horari fins que trobem el primer node amb una posició més gran que la posició teòrica de la clau. Per tant, cada node passa a ésser responsable d'una regió de l'anella. Per tant, una arribada o sortida d'un node dins el conjunt de nodes que usen Dynamo tant sols afecta als seus dos veïns.

El fet de que el mètode de hashing sigui uniforme planteja alguns problemes amb heterogeneïtat de les màquines que conformen l'anella, cosa que porta a un malt balanceig del sistema. Per tant, el que es fa és en comptes de assignar a cada node un sòl punt en el cercle, cada node és assignat diversos punts. Per tant, cada node passa a tenir "servidors virtuals", i cadascun d'aquests servidors és responsable per una posició de l'anella. Utilitzar nodes virtuals comporta entre d'altres els següents avantatges:

Si un node cau, la càrrega que tenia aquest node és dispersada en la resta de nodes.
Quan el node torna a estar de nou disponible, aquest accepta més o menys una quantitat equivalent de dades de la resta de nodes.
El número de nodes virtuals que un node real té està decidit per les característiques del node.

Replicació

Dynamo replica les dades. Cada clau, k és assignada a un node coordinador, aquest node serà el responsable de la replicació dels elements de dades. Per tant, a més de ser el responsable d'assegurar que els valors es llegeixin i s'escriguin a disc també serà el responsable de replicar aquestes dades en els anteriors N-1 nodes (en sentit antihorari) de l'anella. Per tant, cada node és responsable d'ell mateix i de les rèpliques en els seus N predecessors, preferiblement nodes reals, no virtuals.

Versionat de dades

El fet de que Dynamo ofereixi consistència tard o d'hora permet que les actualitzacions puguin ser propagades a totes les rèpliques de forma asíncrona. A efectes pràctics vol dir que una operació de put() contestarà al client abans de que s'hagin actualitzat totes les rèpliques, cosa que implica que puguin existir escenaris en que el següent get() retorni un objecte al qual li manquin actualitzacions.

Per assegurar la consistència, el que fa Dynamo tracte el resultat de cada actualització com una nova versió de les dades, i permet que en alguns moments existeixin diverses versions d'un mateix objecte en el mateix moment. Lògicament en la majoria de vegades les versions més actuals substitueixen a les més velles, de totes maneres de vegades apareixen "branques", resultant en versions amb conflictes entre elles. En aquests casos el client és encarregat de fer la "reconciliació" d'aquestes branques per convertir-les de nou en una sola. Per detectar els conflictes i perquè s'han produït Dynamo utilitza rellotges vectorials.

Els vectors clocks és un sistema que va ser inventat per Leslie Lamport. Són molt utilitzats en informàtica distribuïda i tenen molta tela. Aviat hi haurà tot un article que parli de vectors clocks, ara mateix deixem-ho estar en que serveixen per detectar col·lisions temporals com la que acabem de veure.

Execució de les operacions de lectura i escriptura

Les operacions de lectura i escriptura són invocades a través de l'API de Dynamo, mitjançant HTTP, els clients poden triar dues maneres:

Dirigir la petició a través d'un balancejador de càrrega que triarà un node basant-se en l'informació de càrrega.
Utilitzar una llibreria específica per redirigir la petició directament al node coordinador de la clau.

Com hem vist anteriorment cada clau ha de ésser rebuda pel seu node coordinador, en el segon cas, el node que rep la petició és sempre el coordinador, en el primer cas però, la petició pot anar a parar a qualsevol node, el que fa llavors aquest node és enrutar-la cap al node que toca, que serà el coordinador de la clau.

Tractament de fallades

En el cas de Dynamo utilitzés un sistema de quòrum típic faria que el sistema no estigués disponible en casos en que algun o alguns nodes tinguessin problemes, per tant el sistema utilitzat per Dynamo no força un quòrum complert, sinó que utilitza un quòrum relaxat. Per tant, no tots els nodes que formen part de la rèplica han d'estar disponibles a l'hora de fer una actualització, cosa que implica que l'operació serà més ràpida, però cosa que implica que poden donar-se inconsistències al sistema, i és per això que tenim els vector clocks per arreglar-les.

Detecció de membres

Tots els nodes saben l'estat i la llista de nodes que hi ha al sistema formant part de l'anella. Per propagar els canvis també s'utilitza un protocol de gossip. Per tant, sempre cada node sabrà qui és el node coordinador de qualsevol clau.

Lògicament les deteccions de fallades són relativament senzilles, si un node intentat contactar amb un altre node (ja sigui per demanar que faci de coordinador o bé per replicar alguna dada) i aquest no contesta, ràpidament el node s'encarrega de fer saber a la resta que aquell node no està disponible i que cal reaccionar rebalancejant les dades.

Afegint i traient nodes

Quan un nou node apareix al sistema, se li assigna un número de tokens que estan aleatòriament repartits dins de l'anella. Fins llavors altres nodes estaven encarregades de mantenir aquelles dades, per tant el node nou contacta amb aquestes màquines, els fa saber que ha aparegut i demana que l'hi enviïn les claus emmagatzemades més les dades.

Implementació

Amazon ha implementat Dynamo amb Java, i cada node pot emmagatzemar les dades mitjançant un connector a bases de dades. Per tant, cada node té a sota una base de dades per guardar les dades a disc, depenent del tipus de dades s'utilitza un producte o un altre.

Bigtable

2009-05-08T07:25:00.003+01:00

Bé, avui toca parlar del primer article de la sèrie de noves bases de dades. BigTable, de Google.

El que trobareu aquí és un resum de l'article Bigtable: A distributed storage system for structured data que va aparèixer a la conferència OSDI al 2006.

Primerament, BigTable és el nom del producte que van programar internament a google, és bàsicament un sistema d'emmagatzemament distribuït per guardar dades estructurades i està pensat perquè sigui molt escalable. A més, un detall important, és que els enginyers de google el van dissenyar per còrrer en moltes màquines genèriques, no calen grans servidors ni discs durs especials, simplement, màquines com les que podem tenir ara mateix al davant. Google utilitza aquest servei per guardar moltes de les seves dades, per exemple índexs web, o imatges de Google Earth, per tant, no és una idea, és una implementació existent i està en producció<

Com ja havia introduït en el post anterior, Bigtable no utilitza ni dona suport a un model de dades relacional, al contrari, facilita un model de dades molt senzill que permet un control dinàmic sobre l'estructura dels continguts i del seu format. Les dades són indexades mitjançant columnes i files, els noms de les quals són cadenes de texte, els continguts d'aquestes són cadenes de texte també, per tant, la base de dades no sap (ni li interessa) el format dels continguts, això és problema de l'aplicació.

Model de Dades

Atenció amb la definició: Bigtable és un mapa ordenat, multidimensional, distribuït, persistent i dispers (aplaudiments i furor general!). Aquest mapa està indexat per:

Clau de la fila
Clau de la columna
Instant de temps (!)

Per tant té aquest format:


(row:string, column:string, time:int64) --> string

Anem a explicar una mica cada factor d'indexació:

Fila

Les clau de cada fila són strings, de fins a 64Kb, cada lectura i escriptura a una fila es considera atòmica. Un detall important és que per a cada taula es particiona dinàmicament el número de files que té una tablet, que és la unitat de distribució i balancejament de dades de Bigtable (més explicació sobre això una mica més endavant).

Familia de Columnes

Les claus de les columnes estan agrupades en families de columnes, que són els elements més bàsics d'accés a control a la taula. Aquestes no haurien de canviar de forma dinàmica, per tant, una taula té un número fixe de families de columnes durant l'execució, ara bé, dins de cada familia de columnes hi pot haver un número indeterminat de columnes, que poden aparèixer i desaparèixer en temps d'execució. Per tant, una familia de columnes de Bigtable equival a una columna d'una base de dades de model relacional, i a més aquesta columna podria tenir columnes a dins, i a més dinàmiques!

Instant de temps

La idea és ben senzilla, es tracta que una taula tingui un històric dels valors que hi havia en les columnes/files. Lògicament això és un valor configurable i a més, Bigtable té un garbage collector, semblant al Java que va netejant valors a mesura que es fan més vells del que ens interessa.

API

Una altre gran diferència entre les bases de dades relacionals i Bigtable és que mentres que les RDB interactuen amb l'exterior mitjançant SQL, Bigtable ho fa mitjançant una API, per tant, en aquest punt s'aproxima més al Hashmap distribuït. Apart d'això, els usuaris poden crear scripts amb un llenguatge de query de google anomenat Sawzall per fer consultes més complexes.

Parts de l'arquitectura de Bigtable

Hem de tenir en compte que els enginyers de google no van crear Bigtable del res, es van basar i lògicament van utilitzar coses que ja estaven fetes dins de Google:

Google File System, un sistema de fitxers distribuït.
Google SSTable, un format de fitxers binari. Bàsicament és una taula de hash de clau->valor ordenats.
Chubby, un servei de locks distribuit i persistent. Bàsicament es tracta d'un servei que és capaç de mantenir semàfors i altres tipus de locks de concurrència de forma distribuïda.

Casi res :D, mare meva que animals que són aquests de can google...

Implementació de Bigtable

Ja aviso que a partir d'aquí la cosa es complica una mica, si no us interessa la implementació d'aquest petit monstre us recomano que passeu directament a Coses que han aprés a can Google. De totes maneres, l'article no és molt detallat en quant a l'implementació, ja que és una implementació propietària i tancada i jo bàsicament n'he fet un resum per destacar-ne els detalls més importants.

Per la resta de valents... Bigtable està format per 3 components:

Un llibreria que usa l'aplicació client.
Un servidor master
Molts servidors de tablets, que poden ser afegits o trets de forma dinàmica del cluster per suplir necessitats de càrrega.

El master és l'encarregat d'assignar les tablets als servidors de tablets, detectar canvis en les màquines (afegim o treiem servidors de tablets), fer el balanceig de càrrega, neteja de files (temes temporals) i finalment manegar els canvis d'esquema de la base de dades, com són la creació de taules i de families de columnes.

Cal tenir en compte que tot i tenir un servidor master, les dades dels clients no hi passen a través, per sino que es comuniquen directament amb els servidors de tablets per fer les escriptures/lectures, i important, no utilitzen el servidor master per localitzar les tablets!, per tant, a efectes pràctics el màster està bastant descarregat.

Localització de les tablets

Tema important, com s'ho fa un client per localitzar el tablet que té les files que l'interessen?, però abans d'això és important saber que aquesta informació està guardada en una estructura de dades de 3 nivells, semblant a un arbre B+, i el primer nivell de l'estructura està en un fitxer guardat a Chubby, per tant, el client el primer que fa és preguntar a Chubby a on és aquest fitxer,i amb un màxim de 3 salts tenim el tablet que té l'informació que necessitem.

Assignació de les tablets

Següent pregunta: a on són els tablets? i per què hi són?
Lògicament cada tablet està assignat només a un servidor de en cada moment, el servidor màster manté una llista dels servidors de tablets que estan actius a cada moment, els tablets que ténen assignats cadascun i també els tablets que no estan assignats a cap servidor (i que per tant estan guardats al GFS). Aquesta llista només canvia quan:

Una taula és creada.
Una taula és destruïda
Dos tablets s'han fet tant petits que el màster decideix ajuntar-los en un sol tablet.
Un tablet s'ha fet tant gran que el màster decideix partir-lo en dos.

Altres detalls interessants

El paper dóna bastants més detalls d'implementació, però realment això pretén ser una introducció al model de dades de Bigtable, per tant els he ignorat, ara bé vull destacar:

Grups de localitat: Els clients poden agrupar diversos grups de families en el que són els grups de localitat, cosa que permet garantir que estaran al mateix servidor de tablets.
Compressió: Lògicament es permet compressió a l'hora de guardar els valors. S'han triat un conjunt d'algorismes de compressió ràpids (comprimeixen a 100-200Mb/s i descomprimeixen a 400-1000Mb/s en una bona màquina) i també poden descomprimir el fitxer per parts, sense haver de descomprimir-lo tot, molt pràctic en cas de que volguem llegir només una part petita del fitxer.
Bloom Filters: No saps què són els bloom filters? (wikipedia) Per evitar fer molts d'accessos a disc Bigtable utilitza Bloom Filters per veure si un fitxer en format SSTable conté les dades per un clau/valor en concret.
Caching: les lectures estan en una cache per una lectura més ràpida.

Coses que han aprés a can Google

L'article original té tot un apartat de les lliçons apreses en l'implementació, evaluació i ús de Bigtable internament a google, voldria destacar les dues següents:

La majoria d'aplicacions només necessiten transaccions d'una sola columna.
És important mantenir un, atenció aquí: DISSENY SENZILL, perquè més endavant sigui senzill de modificar, segons les necessitats reals, que normalment són diferents a les inicials.

I això és bàsicament un resum del que és Bigtable. És recomanable llegir el paper original, ja que dóna molts més detalls sobre implementació i decisions de disseny. Cal tenir en compte que és un paper bastant important i que ha sigut molt influent en les noves bases de dades que s'estan utilitzant i implementant actualment. Sobretot perquè va ser de les primers en trencar amb el model de dades relacional i es va posar en producció (i va funcionar)

Hadoop, la guia definitiva.

2009-05-07T15:06:00.002+01:00

Avui he rebut la noticia que està a punt de ser publicat, 'Hadoop, the definitive guide' un llibre que ha escrit Tom White i en el qual he pogut participar escriguent part d'un capítol d'experiències.

Podeu trobar més informació al següent post (anglés).

Nous models de bases de dades

2009-04-27T23:12:00.001+01:00

Aquest post és una introducció a una sèrie d'escrits que aniré fent relacionats amb els nous models de bases de dades que estan apareguent, i que estan tinguent una bona acceptació en diversos sectors del món empreserial relacionat amb informàtica (el perquè d'això mereix un post per si sól)

Primer de tot, aquests nous models s'allunyen bastant del model relacional de bases de dades al que suposo que tots estàvem més que acostumats. Sí, això vol dir tenir una base de dades sense SQL. Estrany oi?

El model relacional funciona molt bé per algunes aplicacions, però no és una solució universal que serveixi per tot. Fins fa poc era ben normal trobar aplicactius o arquitectures que tenien instal·lada una RDB tipus MySql o Postgres i que tant sols era utilitzada com a magatzem de dades. Amb això vull dir que no s'utilitzaven les propietats ACID d'una base de dades relacional, per tant, SELECTS senzills i UPDATES.

Fins aquí tot bé i cap problema, s'està infrautilitzant una eina molt potent, però no és res greu i si funciona doncs perfecte. Ara bé, pot ser que arribin els problemes en forma de:

Escalabilitat: La base de dades s'ha fet molt gran i la màquina, o bé la base de dades no pot suportar els continguts que ha de guardar o bé la càrrega de les diverses aplicacions que l'usten. Què cal fer? cal passar-se a una base de dades més potent o intentem repartir la càrrega de la base de dades entre altres màquines?
Disponibilitat: Què passa si la màquina de té la base de dades no està disponible? es queda tot aturat? És fàcil fer backups i restaurar-los en cas de que sigui necessari?. Serà un drama?

Qualsevol administrador de bases de dades sabrà que els dos punts anteriors són importants i els dos són, lògicament, solucionables utilitzant qualsevol motor de base de dades decent, fins a cert punt.

Ara bé, si tenim en compte empreses del nivell de Google, Amazon, Linkedin, Yahoo... que maneguen cada dia unes quantitats de dades MOLT grans hem de pensar que les seves bases de dades han de ser inmenses i lògicament els seus administradors han hagut de tenir en compte els dos problemes anteriors. Com s'ho han fet? doncs bàsicament han abandonat el model de bases de dades relacionals (i les seves implementacions) i han passat a uns models nous, fets a mida (lògicament només pels usos que no requerien una base de dades relacionals!).

Hem de tenir en compte que aquestes empreses tenen molts de recursos i que també ténen unes necessitats bastant específiques, probablement per moltes de les seves aplicacions el model relacional els ajudi ben poc. En molts casos el que necessiten és tant sols "una taula de hash monstruosament gran i monstruosament ràpida". Aquest concepte, conegut com DHT (Distributed Hash Table) no és nou, en l'àmbit de recerca ja és ben conegut i fins i tot hi ha diverses implementacions disponibles, cadascuna enfocada a solucionar problemes lleugerament diferents:

Aquests projectes són els que van posar les bases del que després acabaria apareguent. Si aneu a les pàgines d'aquests projectes veureu que tot i que ténen implementacions estables no són utilitzades en entorns de producció empresarial (que jo sàpiga o hagi sapigut trobar, si estic equivocat sisplau feu-m'ho saber). Una part molt interessant d'aquests projectes és l'apartat d'articles, on s'expliquen les diverses decisions de disseny, diferents problemes que s'ha hagut de solucionar així com diferents algorismes molt importants en el món de la informàtica distribuïda i sobre els quals tinc pensat fer algun post properament.

Les DHT no són trivials ni de dissenyar ni d'implementar, el seu concepte és senzill, una taula de hash distribuïda, però no ens hem de deixar enganyar. Ténen molta tela.

Google i Amazon es van posar en marxa i cadascuna va implementar-se la seva pròpia base de dades especificament pels seus usos, un cop les van tenir implementades, provades i en producció van publicar cadascuna un article, que en certa manera són els articles que van començar amb la "moda" de les noves bases de dades:

De part de Google. Bigtable: A Distributed Storage System for Structured Data.
De part d'Amazon. Dynamo: Amazon's Highly Available Key-value Store.

A partir de llavors han aparegut moltes bases de dades basades en aquests papers, gens sorprenentment algunes basant-se amb el model Bigtable i d'altres que més que bases de dades s'anomenen Key-Value Stores i que, lògicament, es basen en Dynamo.

Els articles són realment molt interessants i de lectura obligada per qualsevol persona interessada en escalabilitat, bases de dades i noves tecnologies.

En el pròxim post resumiré el paper de la Bigtable de google, i en el següent la Dynamo d'Amazon, per veure'n bé les diferències, tant de disseny com d'ús pràctic. I més endavant, i depenent del meu temps descriuré les meves experiències reals amb diverses implementacions, de moment tinc pensades:

CouchDB, de la qual ja n'he parlat en aquest blog.
Voldemort, que és la Key-Value Store que han implementat a LinkedIn.

Volunteer Computing i BOINC

2009-04-07T00:07:00.008+01:00

Aquest post va del Volunteer Computing, amb la seva implementació més famosa, BOINC.

El Volunteer Computing ve d'una idea bastant senzilla. Molta gent té ordinadors, i molta d'aquesta gent no els hi treu tot el suc que podria, per tant, estaria molt bé aprofitar tota aquesta potència restant oi ? doncs es tracta d'això.

BOINC és un software molt senzill que s'instal·la en un ordinador, hi ha versions per Windows, GNU/Linux, BSD's, etc. Un cop el software està instal·lat l'usuari s'autentifica i s'apunta a un o diversos projectes. Ja està.

El que passa llavors és que aquest software contacta amb els servidors de BOINC i demana feina. Els servidors li enviaran uns "paquets" amb un o diversos treballs de computació, un cop rebuts aquests l'ordinador començarà a processar-los. Una vegada s'hagi calculat el resultat, aquest s'enviarà de nou als servidors i demanarà més treballs. Tot això de forma totalment transparent a l'usuari i sense que aquest ho noti.

Boinc prové de SETI@Home , un programa que bàsicament va crear aquest esquema per analitzar ones de ràdio provinents de l'espai per intentar trobar vida extra terrestre. Més tard va aparèixer Folding@Home un programa de caire més... biològic per processar plegaments de mol·lècules per l'investigació de malalties i fàrmacs. El problema és que cada projecte utilitzava el seu propi client, i a mesura que anaven sortint més projectes s'havia d'anar instal·lant els seus clients. Finalment es va decidir unificar el format i tenir un sol programa a on et podies apuntar a diferents projectes, així és com va nèixer BOINC.

Passos ràpids per habilitar una conta

La manera més fàcil d'entendre com funciona (en general) és veure-ho funcionant. El software es pot descarregar des de la pàgina de BOINC, o en cas de Linux del gestor de paquets.

El següent cas és triar els projectes en els quals volem participar. N'hi ha molts, aquí podeu trobar-ne una llista, n'hi ha per tots els gustos; problemes matemàtics, de salut, de recerca de vida alienígena...

Per cada projecte al que volem participar ens hi n'hem de donar d'alta a la seva pàgina, llavors ens donaran un nom d'usuari i una clau d'identificació que haurem d'introduir al programa (BOINC). De totes maneres, per fer-nos la vida més senzilla hi ha "paquets" o managers. Aquests són projectes com el World Community Grid, que és una iniciativa d'IBM que agrupa els projectes de BOINC que ténen a veure amb investigació mèdica i mediambiental. Si ens donem d'alta al WCG ens donem d'alta amb un sol identificador a una sèrie de projectes de BOINC, per tant és una forma bastant agradable de simplificar.

Per tant si algú li fa gràcia i vol provar-ho el més senzill és:

Baixar-se el BOINC i instal·lar-lo.

Donar-se d'alta al WCG

Entrar l'identificador del WCG + la clau al BOINC.

Un cop a dins pots entrar a formar part d'equips. Es tracta de fer una competició sana de veure quin equip aconsegueix processar més paquets. Jo formo part de l'equip 'Catalunya', per tant, si voleu contribuir hi sereu molt benvinguts ;)

Com funciona

Cal tenir clares les diferències entre Volunteer Computing i altres tipus de supercomputació o computació distrbuïda, com el Grid Computing. El poder del primer es basa en tenir moltes màquines, de diverses categories de forma totalment descontrolada. Aquestes màquines no són teves, no tens el control sobre elles, no saps ni et pots fiar de que l'endemà continuaran funcionant o que estaran connectades a Internet, cosa que com més endavant veurem comporta unes particularitats en el disseny del sistema.

Bàsicament un projecte de Boinc funciona independentment de qualsevol altre. Cada projecte té el seu servidor, i cada servidor està format per una sèrie de programes, els quals funcionen tinguent com a nucli una base de dades relacional. Aquests subprogrames s'encarreguen de:

Servidor de Fitxers. Cada servidor té una sèrie de fitxers que són les feines que ha de fer cada màquina. Lògicament aquests fitxers estan guardats en el servidor i són enviats quan toca a cada màquina que ha de processar-lo. Un cop el paquet s'ha processat és enviat de nou cap al servidor. El servidor, a més d'emmagatzemament té diverses funcions addicionals:

Comprovació d'integritat: Quan es rep un resultat és necessari comprobar que el fitxer no sigui corrupte, per causa malintencionada o bé per error de transferència.

Comprovació de correcció: En parlaré en pocs paràgrafs però cada tasca es processa més d'una vegada en més d'una màquina. Així doncs es rep el mateix resultat (o el que hauria de ser exactament el mateix resultat) en diverses ocasions. Per tant, si hem enviat una feina a processar a 5 màquines diferents hauriem de rebre 5 vegades el mateix resultat. En cas de que rebem resultats diferents cal descartar aquest resultat i tornar a calcular-lo.

Organitzador (normalment s'utilitza el nom anglés, scheduler) Aquesta és el procés que decideix quina feina s'envia a quina màquina. Per tant, aquest és el procés que decideix quantes vegades rebrem un resultat. Aquesta redundància es per diversos motius:

Seguretat: Podria ser que per qualsevol motiu un usuari volgués boicotejar un projecte (coses més estranyes s'han vist) i que per tant intentés enviar resultats incorrectes. Cal sempre comparar el resultat amb diverses màquines, mai ens en podem fiar d'una sola.

Evitar colls de botella. És un punt molt relacionat amb l'anterior, pot ser que tinguem dependències entre tasques, i que per tant tinguessim una tasca molt important i sense el resultat d'aquesta no poguéssim continuar. El que no es pot fer en un entorn com aquest (Volunteer Computing) és fiar-nos de que una màquina enviarà el resultat del paquet que hem enviat. No controlem aquella màquina, i per tant, no ens podem fiar. És per això que sempre enviem el paquet més vegades de les que és necessari, i com més important és la tasca, més vegades l'enviem.

Programar la teva pròpia apliació

Una de les gràcies de Boinc és que pots programar la teva pròpia aplicació perquè corri en diverses màquines alhora, ja siguin dins la pròpia empresa o fins i tot en una xarxa més casolana. En principi no és senzill, ja que estem parlant d'una aplicació que ha de ser paral·lelitzable i que pugui còrrer en diverses plataformes, ja siguin Microsoft Windows, Mac o bé GNU/Linux.

La pàgina de Boinc posa a l'avast de qualsevol persona que ho vulgui fer una sèrie d'ajudes i tutorials per configurar l'entorn de desenvolupament així com programes d'ajuda.

No tinc experiència personal amb això, però realment m'agradaria sentir noticies d'algú que ho hagi intentat.

Diversos Usos

Lògicament tota aquesta tecnologia es pot aplicar en altres camps, a la mateixa pàgina de BOINC ens dónen unes petites explicacions de com configurar una xarxa de màquines amb BOINC pels nostres propis projectes. En cas de tenir una empresa amb moltes màquines potser no cal invertir grans sumes en servidors d'aplicacions o bé d'utilitzar serveis externs com els Amazon WS, ja que ens podem muntar el nostre "super computador virtual" amb BOINC:

Per empreses.

Per Campus Universitaris.

Per tant crec que puc concloure dient que el BOINC és informàtica distribuïda popular!, va vinga no sigueu garrepes, feu-vos una compta i a cremar cicles de CPU!!

Hadoop

2009-03-25T23:42:00.003Z

Els que estigueu posats en el món de l'informàtica distribuïda o bé d'alt rendiment o bé, simplement que esteu una mica a l'aguait de les novetats informàtiques potser us sonarà Hadoop.

Hadoop és una plataforma de software que bàsicament permet escriure programes que processin unes grans quantitats de dades. Grans grans. El projecte ja té diversos anys i alguns dels seus components s'han separat en subprojectes:

Hadoop Core: Plataforma de Map Reduce + Sistema de fitxers distribuit.
HBase: Una base de dades distribuïda i escalable.
Pig: Nivell d'alt llenguatge per aplicacions que utilitzen Hadoop-core.
ZooKeeper: Sistema de coordinació per Hadoop.
Hive: Una espècie de SQL fer queries a les dades emmagatzemades en Hadoop (moltes dades, moltes moltes)

És un projecte Open Source utilitzat en producció (molt important) en diverses empreses, tal com podeu veure aquí. A més, té una comunitat d'usuaris / desenvolupadors molt activa tal com podreu veure si doneu un tomb pel seu tracker

En aquest post parlaré exclusivament del projecte principal, Hadoop Core.

Les característiques que ells destaquen en la seva pàgina són les següents:

Escalabilitat: Pot manejar grans quantitats de dades (petabytes) i té escalabilitat horitzontal, és a dir, si necessites més potència o més espai, simplement afegeixes màquines.
Econòmic: És Open Source (llicència Apache) i treballa amb qualsevol tipus de màquines, no és necessari que siguin servidors d'alta gamma. A més, és una plataforma de software que suposa que els errors de hardware són usuals i per tant, sap reaccionar. També cal destacar que està preparat per còrrer al Amazon EC2
Segur: Sempre es mantenen diverses còpies de les dades repartides en diverses màquines, així ens estalviem desgràcies quan una màquina decideix morir sense avisar.

Hadoop és capaç de processar grans quantitats de dades perquè utilitza Map Reduce. Map Reduce és un model de programació pensat, o més bé, readaptat, per procés de moltes dades. Amb això voldria aclarar que de fet, només serveix per això. Sembla ser que hi ha certa moda en utilitzar Map Reduce en alguna de les seves implementacions per moltes coses. Si no es té una entrada de com a mínim gigues de dades probablement no sigui el que es necessita.

Bé, els causants de tota aquesta febre MR (Map Reduce) van ser Google quan van publicar un article on explicaven què era, com es programava i com ho utilitzaven en producció a diari en els seus clústers. A partir d'aquí van començar a aparèixer implementacions d'aquest model de programació en diversos llenguatges, una de les més importants, si no és la que més és sens dubte Hadoop.

En resum, MR i per tant Hadoop treballen de la següent manera (molt per sobre):

Tenim les dades al sistema de fitxers distribuit que comparteixen totes les màquines que conformen el nostre clúster. Tenim un programa que implementa MR mitjançant Hadoop, això bàsicament vol dir que hem programat un programa semblant a aquesta, el qual té una classe Mapper, amb un mètode map i una classe Reducer amb un mètode reduce.

Hadoop parteix el clúster en mappers i reducers, una màquina pot ser mapper i reducer a l'hora, això es pot definir en la configuració del sistema. Les màquines que fan de mappers agafen les dades del sistema de fitxers distribuit i li apliquen la funció map. Així de bon principi ja tenim tot de màquines que estan llegint les dades d'entrada de forma paral·lela.

MR té uns requeriments per les dades. Bàsicament han d'esser de la forma. Clau -> Valor, on la clau i el valor poden ser qualsevol cosa. Per tant, un cas típic seria un log d'apache:


127.0.0.1 - - [31/Jul/2008:00:37:04 +0100] "GET /~marc/images/imatge1.jpg HTTP/1.1" 200 16624
127.0.0.2 - - [31/Jul/2008:00:37:05 +0100] "GET /~marc/images/imatge2.jpg HTTP/1.1" 200 16624
127.0.0.3 - - [31/Jul/2008:00:37:06 +0100] "GET /~marc/images/imatge3.jpg HTTP/1.1" 200 16624
127.0.0.1 - - [31/Jul/2008:00:37:04 +0100] "GET /~marc/images/imatge3.jpg HTTP/1.1" 200 16624

Per exemple en aquest programa ens interessa saber quines IPs han agafat quines imatges. Per tant podriem dir-li al mapper que la clau de sortida sigui la imatge, i que el valor de la clau sigui la IP:


Clau   Valor
imatge1.jpg  127.0.0.1 
imatge2.jpg 127.0.0.2 
imatge3.jpg 127.0.0.3 
imatge3.jpg 127.0.0.1

Ok, per cada Clau/Valor que el mapa troba l'envia a un reducer. És important notar que no associa res de res, en aquest cas enviarà una clau/valor per cada linia de fitxer. Aquesta és una part molt interessant ja que el mètode map simplement invoca una funció amb la clau i el valor com a paràmetres i se n'oblida. Aquests valors són emmagatzemats "màgicament" al sistema de fitxers distribuit de forma totalment transparent fins que tots els mappers han acabat. Això vol dir que els reducers no comencen a processar les dades fins que els mappers estiguin (en veritat si que comencen en certa manera, però no és important ara). Hadoop té un particionador de manera que, atenció que això és important, cada reducer (cada instància d'un reducer) rep una i només una clau amb una llista dels valors: Això és una mica espinós per entendre, exemple:


Clau 1 / Valor A
 Clau 2 / Valor B
 Clau 3 / Valor A
 Clau 2 / Valor A
 Clau 3 / Valor C

I el reducer rebrà:


Reducer1 : Clau 1 amb una llista que contindrà: Valor A
Reducer2 : Clau 2 amb una llista que contindrà: Valor B, Valor A
Reducer3 : Clau 3 amb una llista que contindrà: Valor A, Valor C

Per tant hi haurà tants reducers com claus tingui la sortida el mapper. En l'exemple anterior es tradueix a:


imatge1.jpg 127.0.0.1
imatge2.jpg 127.0.0.2
imatge3.jpg 127.0.0.3, 127.0.0.1

Llavors lògicament el reducer pot fer el que vulgui amb aquestes dades. L'exemple aquest és extremadament senzill, però pensem que un map i un reduce complex poden fer les mil i una bestieses i si estem parlant d'un fitxer de log complert d'apache d'alguna pàgina important pot ser molt i molt gros.

Un cop el reduce està també escriu els resultats en forma clau valor. Aquests resultats són guardats al sistema de fitxers distribuit.

Podeu trobar molta més informació sobre Map/Reduce + Hadoop al tutorial de hadoop.

Bé, en pròxims articles entraré més en detalls sobre Hadoop i probablement publicaré snippets de codi, amb problemes que em vaig trobant al dia a dia i alguns números.

CouchDB i Key-Value Stores.

2009-03-20T21:53:00.005Z

Avui he estat a una presentació de Jan Lehnard sobre CouchDB. Podeu trobar les slides aquí.

CouchDB és una key-value store, i aquest és justament el primer post sobre aquest tema. En vindran molts més ja que és un tema molt extens i molt interessant, si més no per mi. Bàsicament podriem dir que una key-value store és una base de dades molt senzilla distribuïda per la xarxa, també hi ha qui ho enten com una taula de hash gegantina distribuïda en diversos ordinadors. I molt més pensada per a l'eficiència dels gets/sets que a per la complexitat que poden tenir altres bases de dades com Postgres o Mysql.

Una de les coses que m'ha fet pensar més de la xerrada és la quantitat de key-value stores que hi ha actualment. La majoria són bastant noves i tot i que totes serveixen pel mateix, emmagatzemar i obtenir certs valors, els seus dissenys són totalment diferents i fan que cadascuna tingui la seva sortida de mercat.

Aquí podeu trobar un post molt complert i interessant sobre key-value que va fer l'RJ (CTO de last.fm)

Unes pinzellades per a qui li faci mandra llegir-se tot l'article o li faci cosa perquè està en anglés:

Les principals diferències de disseny de les key-value stores que convé mirar abans d'adoptar-ne una, o bé que s'han de tenir en compte són:

Tolerància a fallades: Les key-value stores normalment estan en màquines dedicades, i més d'una màquina, per tant diem que tenim 5 màquines servint l'informació. Què passa si una de les màquines s'espatlla de cop?. Depenent de la tolerància a fallades de la key-value store pot ser que no passi res, o que tinguem un problema gros. Entre els tipus de tolerància a fallades que són més normals destacaria:
- Replicació: Tant senzill com tenir més d'una còpia de cada valor que es serveix. Si cau una màquina no passa res perquè hi haurà alguna altre màquina que també té aquest valor. Lògicament gastem més espai del necessari, però és el preu a pagar.
- Particionat: No és una tècnica en si sola, sino que és una millora del mètode anterior, si els valors són grans (fitxers, mp3, imatges) podem partir el fitxer en diversos trossos i repartir-los (amb redundància o replicació) per diverses màquines.
Persistència: Normalment aquests mecanismes tenen totes les dades a memòria RAM. Amb això ens estalviem tot el temps d'I/O a disc. Lògicament fa que quedi poca RAM per altres coses, però és el preu de la velocitat. Ara bé, de nou, què passa si hem d'apagar la màquina?. N'hi ha que guarden els valors en una base de dades relacional, ja sigui Mysql, Berkeley, etc. Així, al engegar agafen tota la informació de la base de dades i la posen a memòria. Treballen en memòria i finalment, quan s'apaga la màquina es guarda de nou a la base de dades. N'hi ha d'altres que ho serialitzen utilitzant llibreries natives dels llenguatges de programació en que estan implementades i fins i tot n'hi ha que _no_ guarden res. Quan s'apaguen es perd tot!, normalment són utlitzades com a caches.

Accés: Molt bé, tenim molta informació, però com hi accedim?. N'hi ha que porten les seves pròpies llibreries en diversos llenguatges, n'hi ha que utilitzen HTTP (sempre REST, mai SOAP) i n'hi ha d'altres que ofereixen interficies de thrift o protocol buffers (hi haurà tot un post sobre aquests dos, no patiu, són mecanismes de serialització / RPC, el primer fet a facebook i el segon fet a google).

Eficiència: Lògicament, s'ha de parlar d'eficiència. Tant en temps d'accés a les dades (quan tardes en fer un GET, quan tardes en fer un PUT?) com en l'eficiència d'ús de recursos que utilitzen les màquines per servir l'informació.

En pròxims posts entraré una mica més en detall en implementacions concretes i en les key-values stores que considero més interessants.

Bittorrent

2009-03-04T21:22:00.017Z

Començo el nou blog amb un post sobre protocols, avui Bittorrent!

Suposo que tothom, més o menys coneix el Bittorrent, aquest "programa per descarregar pel·lícules". Doncs bé, bittorrent és el nom del protocol, també de l'empresa que el va fer i d'un programa que utilitza aquest protocol. Sí, realment poca imaginació.

Bàsicament és un protocol per distribuir fitxers, fa temps s'usa de forma popular, però últimament ha tingut bastant resó mediàtic pel judici que ha tingut lloc a Suècia contra la pàgina d'emmagatzemament de .torrents The Pirate Bay. Al final sembla ser que poca cosa han pogut fer perquè tal pàgina tant sols guardava els fitxers .torrent i només actuava de tracker, i això no és delicte oi ?, ara probablement algú es preguntarà què és un .torrent? què és un tracker ? ara anem a això!

Protocol

El gran avantate que té el bittorrent sobre l'HTTP clàssic és que quan hi ha diverses baixades del mateix fitxer de forma concurrent (diverses persones volen baixar-se el mateix fitxer alhora), aquests usuaris s'envien trossos del fitxer entre ells. Per tant, com més persones hi hagi baixant un fitxer millor.

Com funciona.

El funcionament de cara l'usuari és ben senzill.

Un usuari es baixa un fitxer amb extensió .torrent, és un fitxer petit, menys de 60ks. Tot seguit s'obre amb el client de bittorrent i el fitxer es comença a descarregar. Pim pam.

En resum i explicat d'una forma planera el que passa és el següent:

Quan l'usuari obre el fitxer .torrent amb el seu client, aquest contacta amb el tracker (la direcció del tracker està dins el fitxer .torrent) que és un programa instal·lat en un servidor d'internet, i s'identifica com un usuari que es vol baixar aquell fitxer en concret. Tot seguit el tracker contesta amb les IP's dels diferents peers (altres usuaris) que s'estan baixant el fitxer, i que per tant, en ténen trossos. Seguidament el client contacta amb aquesta llista d'usuaris i els hi comença a demanar trossos, més endavant aquest client també compartirà els trossos que ja té.

De tant en tant contactaran amb el tracker de nou per refrescar la llista d'usuaris connectats que comparteixen aquest fitxer.

Fitxer Torrent

El fitxer .torrent és un fitxer binari. Bàsicament és un diccionari amb els següents camps i valors:

announce: La URL del tracker.
info: És un altre diccionari que conté:

name: Nom suggerit per guardar el fitxer o el directori.
pieces length: Mida dels trossos en que es parteix el fitxer (o fitxers) en bytes. El protocol parteix el fitxer en trossos del mateix tamany, amb la única possible excepció de l'últim tros. Els trossos normalment són de 256Ks tot i que es veu que en versions del protocol anteriors els trossos eren de 1Mb.
pieces: És un string, la mida del qual és múltiple de 20. Cada 20 caràcters representa el hashing SHA1 del tros que representa, per tant hi haurà tants subtrossos de 20 com trossos tingui el fitxer, i a cada posició 20*i , sient 0 <= i < #trossos hi ha el hashing per a aquell tros en concret.
length/files: O bé hi ha length o bé hi ha files, però estrictament un (i només un) dels dos. En cas de que sigui length, significa que el que s'està baixant és un sol fitxer i en length és el tamany total d'aquest en bytes. En cas de que sigui files representa un conjunt de fitxers dins d'una estructura de directori.

path: Una llista d'strings que corresponen a noms de subdirectoris, en cas de que existeixin.

Tracker

El tracker és el software que comunica els usuaris amb altres usuaris, hi ha diverses implementacions, una de les més famoses és opentrack er, que és la que utilitzen entre d'altres The Pirate Bay i la Wikipedia. A destacar la seva llicència, beerware.

Quan un client fa un GET (demana informació) a un tracker, la comanda HTTP té els següents valors:

info_hash: És un string de 20 bytes amb el hash SHA1 de l'apartat info del fitxer de metainfomració (aka .torrent)
peer_id: Id de l'usuari que es vol baixar el fitxer, aquest id és totalment aleatori i és generat pel client cada vegada que comença a baixar-se un fitxer de nou.
ip: (Paràmetre opcional) IP del client.
port: És el port al qual escolta el client, normalment és el 6881, en cas de que estigui ocupat és el 6882 i anar pujant fins al 6889.
uploaded: Els bytes que s'han pujat d'aquest fitxer. Això són els bytes que aquest client en particular ha enviat a altres peers.
downloaded: Bytes que s'han baixat fins aquest moment.
left: Número de bytes que falten per completar la transferència del fitxer. Cal notar que no té perquè ser el mateix que el resultat de la mida del fitxer - downloaded, ja que pot ser que hi hagi hagut una corrupció de dades o problemes de transferència, i que per tant algun tros de fitxer s'hagi de tornar a baixar.
event: És l'estat del client, pot ser started, quan s'està començant a baixar des del començament, completed un cop té tot el fitxer o stopped, un cop es para de baixar.

La resposta del tracker al client també són diccionaris en binari. Pot ser que el tracker contesti amb una entrada de failure, amb un contingut que és un string llegible amb el missatge d'error. En cas de que tot hagi anat bé el diccionari conté dues claus, la primera interval, que són el número de segons en que el client hauria de tornar a fer una petició d'informació al tracker. La següent entrada serà peers, que conté una llista de id's, ips i ports dels peers que s'estan baixant el fitxer. En cas de que hi hagi algun aconteixement especial un client pot fer una requesta d'informació al tracker encara que no hagi passat el temps indicat per aquest.

Comunicació entre peers

La comunicació entre peers és simètrica. Els missatges que s'envien d'un peer a l'altre són del mateix format i les dades (del fitxer que s'està compartint) poden anar també en els dos sentits.

Els peers es refereixen als diferents trossos del fitxer compartit amb indexs, que són exactament els mateixos indexs que hi ha al fitxer de metainformació. Un cop un client s'ha baixat un tros del fitxer i n'ha comprovat l'integritat amb el mapa SHA1 ho comunica a la resta de peers.

Les connexions entre peer i peer contenen dos bits d'estat. El primer, choked (tapat), si o no, i el segon, interessat, si o no. El bit the choked indica que el client està tapat, això vol dir que no enviarà més informació fins que sigui "destapat".

Una transferència de dades entre dos peers té lloc quan un dels dos està interessat i l'altre no està tapat. En cas de que un client no estigui interessat en res que tingui un altre client (sempre que aquest últim estigui destapat) aquest ho ha de fer constar amb el bit de interessat a fals.

El protocol recomana que quan s'està enviant dades, els clients haurien de tenir encuades a memòria diverses peticions de trossos per tenir una bona rendiment TCP, per altra banda quan s'està enviant dades a un altre peer també haurien de tenir els trossos a enviar a memòria, i en cas de que s'anul·li per qualsevol motiu la transferència, probablement el client quedi tapat. aquests trossos es poden borrar fàcilment. Això com ja he dit són recomanacions del protocol, caldria mirar exactament com s'implementa en cada client.

Per tant, quan dos clients s'envien missatges tenim bàsicament que comencen amb un handshake seguit per un fluxe d'informació de mida prefixada.

El handshake comença amb el número 19 en decimal seguit de l'string 'BitTorrent protocol'. A partir d'aquí, tots els números seran enters codficats en 4 bytes en big-endian. Seguidament venen els 20 bytes de hash SHA1 de la taula info_value del fitxer de metainformació, en cas de que els dos clients no donguin exactament el mateix hash, es talla la comunicació entre ells. En cas de que tot vagi bé s'envien 20 bytes més amb l'identificació del clients, en cas de que aquesta informació (l'id del client amb qui s'està comunicant) no aparegui a la informació sobre clients que havia donat el tracker, es talla la comunicació.

Tot seguit tenim el que és la comunicació en si entre peers, els missatges amb mida de cos cero són pings per fer saber i mantenir l'estat dels peers i s'envien cada dos minuts. En cas de que el cos del missatge tingui més d'un byte llavors cal mirar quin tipus de missatge es tracte:

0 - Choke
1 - Unchoke
2 - Interested
3 - Not Interested
4 - Have: És un número que indica que s'ha acabat de transferir i comprovat la integritat d'un nou tros.
5 - Bitfield: És un mapa de bits on cadascun indica quins trossos de fitxer s'ha enviat.
6 - request: Bàsicament és una petició perquè li enviin un tros. De paràmetre té un index.
7 - piece: Les dades en si del fitxer.
8 - cancel: Demana per cancel·lar una transmissió.

A l'hora de baixar els trossos normalment els clients trien els trossos de forma aleatori, així s'aconsegueix que estranyament es donguin situacions d'inanició que són les quals en que hi ha alguns trossos del fitxer que només estiguin en un o poc clients, cosa que faria que en el cas que aquests paressin de pujar fitxers ningú podria tenir el fitxer complert. Això forma part del protocol oficial de Bittorrent, tot i que algunes implementacions intenten millorar aquest aspecte fent que els trossos menys continguts en global entre els clients siguin els que tenen més prioritat per ser enviats.

i bàsicament... és això :)

Jerga

Vinga va, una mica de paraulotes relacionades amb el tema:

p2p: Peer 2 Peer, d'un a l'altre, d'un punt a l'altre, d'una persona a una altre, bla bla bla
peer: Un punt (ordinador, màquina, persona...) que participa en una comunicació P2P
seed: En el món bittorrent seeder és una persona que permet que d'altres puguin obtenir el fitxer un cop ell/a ja el té. Per tant, que no borra el fitxer una vegada l'ha baixat, sinó que el continua compartint.
leecher: justament al revés que el seeder, una persona que no comparteix el fitxer, tant sols el baixa.

Links

Especificació del protocol. Bastant ben explicat i bastant planera.
Wikipedia Hi ha un gràfic molt interessant. Pago una cervesa a qui l'entengui!

Primer post i presentació.

2009-03-04T00:41:00.003Z

Bé, començo el nou blog sobre informàtica distribuïda.

Com suposo ja sabreu n'hi ha molts de blogs d'aquesta temàtica per la xarxa. El que passa és que la majoria són en anglés.

Per tant m'he decidit en obrir-ne un en català.

Aquí aniré traduint els diversos articles i posts d'altres blogs que em semblin interessants i aniré fent-ne de propis, lògicament.

Bàsicament parlaré de protocols de comunicació, mecanismes de RPC, de serialització, de diverses eines i dissenys per arquitectures i sistemes distribuïts.

apa doncs.