HPCC Systems alternativa Open Source a Hadoop

Ayer apareció en todos los medios de comunicación, aunque yo me enteré por el grupo de escalabilidad en español (toma promo gratuita). Una compañía de Miami, LexisNexis ha anunciado que hará Open Source su tecnología de computación y análisis de datos HPCC Systems (High Performance Computing Cluster) a la que la prensa no ha dudado en tildar como el Hadoop Killer.

Construyendo un motor de recomendaciones al estilo FourSquare

En el blog del departamento de ingeniería de FourSquare han publicado un post realmente interesante sobre como han construido su motor de recomendaciones de lugares.

Lo primero que comentan básicamente es la dificultad de este tipo de motores al tener gran cantidad de datos, en su caso 10 millones de locales, y necesitar por una parte computar la similitud de estos lugares, es decir agrupar los lugares en los que se come Sushi, o Churrasco, o donde se toca Jazz, y por otra parte ponderar estos resultados con las preferencias personales de los usuarios, es decir como los han puntuado o cuantas veces los han visitado y con que frecuencia, y las preferencias de sus amigos, es decir si tus amigos suelen ir a restaurantes Indios hay una gran posibilidad de que a ti también te interesen estos restaurantes.

Grupo sobre escalabilidad en español

Tal y como os comentaba ayer, los últimos días había estado comentando con Marc y Miguel Ángel Pastor la posibilidad de crear un grupo sobre escalabilidad, Hadoop, NoSQL, computación distribuida, etc.

La cosa ha surgido así como de casualidad. Miguel se pone en contacto conmigo preguntándome por listas o grupos sobre el tema; por otra parte, conozco a Marc que me cuenta que le gustaría potenciar la comunidad Hadoop en España, y ya lo demás es el poner en práctica mis habilidades de liante para que entre ellos dos monten un grupo en Google para ver si arranca esta comunidad :)

Hadoop y Hbase en Last.fm

La pasada semana este blog estuvo parado ya que estuve casi todos los días en Londres. Allí tuve la oportunidad de tomarme unas pintas con David Hernandez y Marc de Palol, ambos unos cracks que se encuentran viviendo y trabajando en la city.

El blog de David ya lo conocía. El que no conocía era el de Marc. Entre pinta y pinta estuvimos comentando como estaba la situación de los dos países, y muchos otros temas. Uno de ellos era como todos veíamos que Hadoop estaba dando fuerte y como se empezaba a usar más y más, también en España.

Retrospectiva sobre Hadoop y el Open Source

Eric Baldeschwieler, VP Hadoop Development en Yahoo, analiza en el blog de desarrolladores de Yahoo como ha sido la evolución de Hadoop durante sus cuatro años de vida y como ha influido la decisión de haberlo hecho Open Source en lugar de mantenerlo como un proyecto privado. ¿Fue una buena decisión?

La verdad es que atendiendo a sus comentarios parece que fue la mejor decisión que pudieron haber tomado. Yahoo nace en el 2006 y en su momento pensaron que no podía ser un producto de demasiado interés para sus competidores así que decidieron hacerlo Open Source simplemente para que se crease una comunidad de usuarios con itnereses relacionados. Con el tiempo todas sus expectativas se han disparado:

Fotos del Centro de datos de Hadoop

En un artículo en InformationWeek de hace unos meses tienen algunas de las fotos del centro de datos y el equipo de Hadoop. Las imágenes son bastante impresionantes. Hace nada Yahoo lanzó S4, muy relacionado también con el tema de Hadoop.

Yahoo lanza S4

Con un dominio muy molón Yahoo acaba de lanzar hace nada S4. Se trata de una "Distributed Stream Computer Platform" o para que nos entendamos, una librería/plataforma para procesar grandes cantidades de datos que van llegando continuamente en tiempo real.

Hace nada acaban de publicar una entrada en su blog presentando el proyecto. Se trata de llevar la filosofía que MapReduce y Hadoop han popularizado para el procesado de trabajos en batch al procesado de datos que fluyen en tiempo real. Ellos ponen el ejemplo del análisis mediante técnicas de aprendizaje por computador de miles de búsquedas por segundo realizadas por millones de usuarios diariamente en el buscador de Yahoo.

Todo esto de manera que sea distribuido, es decir que haya múltiples nodos que se dividan el procesado de ese flujo de datos; que sea escalable, es decir que para soportar el procesado de más información sólo sea necesario introducir más máquinas; y que sea tolerante a fallos, es decir que si algún nodo se cae, haya otro que sea capaz de procesar esos datos.

La plataforma es Open Source, la han liberado bajo la licencia Apache y está desarrollada completamente en Java.

Más sobre Facebook. Esta vez, Hadoop y datawarehousing.

Hoy, repasando los feeds pendientes de leer, me he encontrado con este artículo sobre Facebook y Hadoop.

El artículo está muy bien hecho y todo su contenido vale la pena, así que recomiendo su lectura. Básicamente comenta como en el 2007 Facebook decidió migrar un datawarehouse (de un vendedor que no menciona) de 15 terabytes a Hadoop. Las razones eran varias: precio de las licencias, menor coste de hardware, más rendimiento al no tener necesidad de transacciones, o la capacidad del equipo de Facebook para contribuir al Open Source.

Para el sistema de datawarehouse utilizaron Hive. Es interesante mencionar que la estabilidad del sistema no es perfecta, pero que parece que a los usuarios no les importan que se caigan nodos o que las consultas puedan tardar hasta 1 hora en devolver datos siempre y cuando no tengan que enviarlas de nuevo.

Por cierto que en otra nota en el mismo blog hablan del uso de compresión gzip que hace Facebook. Me apunto este blog de DBMS2. Parece un gran recurso.

Por cierto que por si os interesa, os dejo enlaces a estos dos posts que ya había escrito anteriormente sobre la arquitectura de Facebook y el uso que Facebook hace de Hadoop:

Notas sobre la arquitectura de Facebook.
Hadoop@Facebook.

Hadoop@Facebook

Los que trabajan en el mundillo de Hadoop seguro que ya conocen que Facebook hacía bastante uso de esta herramienta. Yo, por mi parte, me encontré la semana pasada con un conjunto de notas en las que se comenta el uso que Facebook esta haciendo de esta herramientas. Las notas son ya de Junio de este año, asi que como comento, alguno ya las tendrá más que vistas.

La verdad es que las notas son bastante impresionantes. Aquí va un pequeño resumen:

• Facebook tiene una enorme cantidad de datos históricos, fruto de las decenas de millones de usuarios y el mas de un billón(americano) de páginas vistas por día, que necesita almacenar y procesar.


• Comenzaron a utilizarlo en el 2007 con cierto escepticismo, pero parece que pronto se probó útil tras realizar algunas aplicaciones internas de proceso de datos. Alguna como Facebook Lexicon, una herramienta para contar la ocurrencia de palabras en los muros de los usuarios, ha visto la luz externamente.


• Facebook tiene ahora mismo desplegados múltiples clusters de Hadoop, constando el más grande de 250 núcleos y 1 Petabyte de espacio en disco.


• Cada día cargan sobre 250Gb de datos comprimidos (2 Terabytes descomprimidos) en Hadoop, y hay cientos de trabajos que se encargan de explotar estos datos.


• Las aplicaciones realizadas han ido evolucionando de aplicaciones estadísticas hacia aplicaciones más interesantes como la detección de spam o el determinar la calidad de las aplicaciones de terceros.


• Hadoop se ha mostrado como simple de utilizar y de aprender. En Facebook, los desarrolladores son libres de elegir el lenguaje que quieran para sus aplicaciones con Hadoop. El acceso a datos lo realizan utilizando un subconjunto del lenguaje SQL, lo que hace mas sencillo su manejo.


• Con el tiempo han ido añadiendo algunas funcionalidades propias de un sistema de data warehousing que han desembocado en un framework llamado Hive desarrollado por Facebook pero que ahora es un subproyecto de Hadoop.

Otras notas mias sobre Hadoop.

Domingo de escalabilidad

Cuanta información y que poco tiempo para poder empaparse de ella. Dos de los sitios que leo frecuentemente han dedicado sus últimos post a recopilar información sobre charlas de escalabilidad en tres eventos relacionados muy con el tema: Hadoop Summit 2008, Data-Intensive Computing Symposium 2008 y la MySQL Conference 2008.

Por una parte High-Scalability hace una excepcional recopilación de charlas y enlaces a información interesante presentada en la MySQL Conference. La lista es enorme: "Scaling MySQL and Java in High Write Throughput Environments", "scaling heavy concurrent writes in real time", "Exploring Amazon EC2 for Scale-out Applications", y mucho más. ¡Fenomenal recopilación!

Por otra parte, en el blog de Yahoo Developer Network anuncian la disponibilidad de las transparencias de la Hadoop Summit 2008 (y de bonus las del Data-Intensive Computing Symposium 2008 que también están por ahí). "Hadoop Overview" o "GrepTheWeb- Hadoop on AWS" entre otras que parecen interesantes. Lo mejor de estas transparencias es que los videos están disponibles.

Pues si alguien buscaba algo sobre escalabilidad para leer u ojear para la semana da la impresión de que alguna de estas presentaciones pueden ser una buena opción.

Yahoo! despliega en producción la mayor aplicación basada en Hadoop

Justamente hace un rato que Yahoo! ha anunciado el despliegue en producción de la aplicación más importante desarrollada con Hadoop hasta el momento.

Se trata de Yahoo! WebMap una aplicación que se ejecuta sobre un cluster Linux de más de 10.000 núcleos y que se utiliza desde ahora mismo en cualquier búsqueda que se haga en la web de Yahoo. Aquí está como lo describen en el blog:

The Webmap build starts with every Web page crawled by Yahoo! and produces a database of all known Web pages and sites on the internet and a vast array of data about every page and site. This derived data feeds the Machine Learned Ranking algorithms at the heart of Yahoo! Search.


Las estadísticas que proporcionan son de vértigo (traduzco):

• Número de links: un trillón, aproximádamente.
• Tamaño de la salida: 300 Tb, comprimidos.
• Número de núcleos utilizados para ejecutar ún único trabajo map-Reduce: sobre 10.000
• Espacio en disco utilizado en el cluster de producción: 5 Petabytes.

Mucha más información en la entrada en el blog de Yahoo!. Creo que nos ha quedado a todos definitivamente claro que Hadoop es apto para producción :-)

¿Es MapReduce un paso atrás?

La gripe que inevitablemente estoy incubando sumado a que llevo unos días un poco desconectado debido al esfuerzo de arrancar algo del que probablemente pronto tengáis noticia y que me tiene muy ilusionado, me ha hecho mantenerme un poco apartado del blog estos días y también de las noticias blogosféricas. Y claro, hoy al ir repasando mis feeds me he encontrado con el tremendo lio que se ha montado debido al último artículo de Michael Stonebraker: MapReduce: A major step backwards.

StoneBraker es una referencia dentro del mundo de la base de datos. Recientemente, uno de sus artículos tubo enorme aceptación al cuestionarse si las bases de datos relacionales habían quedado obsoletas en un mundo en el que las bases de datos especializadas tenían cada vez más éxito. Sin embargo, parece que ahora ha dado con un hueso muy duro de roer con la comunidad de la computación distribuida.

StoneBraker afirma en su artículo que MapReduce es un enorme paso atrás en la computación distribuida, en base a los siguientes argumentos:

• Representación de datos anticuada. No aprovecha los conocimientos adquiridos en los últimos años y las ventajas de utilizar esquemas y lenguajes de acceso a datos de alto nivel.
• Una aproximación menos que óptima basada en fuerza bruta.
• Nada nuevo, ya existía hace 25 años.
• Adolece de la falta de la mayor parte de funcionalidades disponibles dentro de las bases de datos relacionales.
• Es incompatible con todas las herramientas disponibles para bases de datos, es decir generadores de informes, herramientas de BI, data mining, data warehousing, etc.

Prácticamente todos los medios de noticias y bloggers están de acuerdo en que StoneBraker ha cometido un error muy básico, que es comparar peras con naranjas, bases de datos con algoritmos de computación distribuida.

Hay quien trata de exponer todos los errores del artículo y opina que los autores (David J. DeWitt es coautor) es que los autores se han despistado y que si en lugar de hablar de MapReduce hubiesen hablado de Amazon SimpleDB el artículo hubiera tenido sentido. Hay también es más drástico y opina que StoneBraker ya no es una referencia para él.

Hay quien también apunta que el propio Google es consciente que el algoritmo no es lo mejor que podría ser pero que cumple su objetivo perfectamente. Otras comunidades y blogs como High Scalability, InfoQ o YComb se han hecho también eco del tema.

Lo cierto es que a mi también me ha chocado bastante la comparación entre MapReduce y una base de datos. Leyendo el artículo, la verdad es que uno sigue el hilo y hasta puede estar de acuerdo en algún punto de los puntos uno, y dos; pero es en los siguientes puntos, tres, cuatro y cinco, donde el artículo pierde definitivamente el norte.

A mi me da la impresión de como si durante estos años un montón de gente hubiese acudido a estas personas con preguntas del estilo "¿Por qué necesito una base de datos si Google no la usa?", "¿Tienen alguna base de datos como BigTable?", "¿Por qué va Google tan rápido sin base de datos y la que ústedes nos han recomendado va tan lenta?", y se hayan querido despachar a gusto. Realmente me suena a esto. A un "estamos hartos de tantos emails sobre BigTable y vamos a dejar las cosas claras".

En fin, la verdad es que los que nos manejamos a niveles muchísimo más modestos, pues por lo menos podemos intentar aprovechar estos lios para pillar un poco de aquí y otro poco de allá en los comentarios y aprender los entresijos de algunas tecnologías. Que al final es lo que vamos a sacar en limpio :-)

Granjas, fábricas y nubes, el futuro de la computación

Según Julio Guijarro y Steve Loughan ambos miembros del grupo de investigación que tiene HP en Bristol ese es el futuro de la computación distribuida. Julio y Steve han publicado el pasado Diciembre una presentación muy interesante en la que hablan de como los modelos de servidor único y de un cluster de servidores han quedado obsoletos en favor de un modelo de granja con cientos de servidores donde el sistema de ficheros es distribuido y el almacenamiento y la CPU se alquila. Se trata de una infraestructura ágil, como ellos la denominan, y que tenderá en el futuro a una gran fábrica de grids con decenas de miles de servidores



Esta evolución se sustenta en la base de que las arquitecturas actuales han anulado ciertas asunciones que en el pasado eran verdaderas pero que Julio y Steve afirman que ya no lo son. Pongo la lista a continuación ya que aunque es posible que no se esté de acuerdo de todo me parece un buen resumen sobre las consecuencias arquitectónicas que tienen algunas tendencias actuales.

Arquitectura: Virtualización. Asunciones que ya no son ciertas:

• Los sistemas permanecen activos por enormes espacios de tiempo.


• Crear un nuevo sistema es caro y lento.


• Duplicar un sistema existente es algo muy caro.


• Los sistemas deben controlarse manualmente.


• Los relojes están sincronizados.


• La RAM nunca se "swappea".


• Las máquinas que están en ejecución no pueden ser movidas y/o clonadas.

Arquitectura: Granjas de servidores. Asunciones que ya no son ciertas:

• El fallo en un sistema es un evento inusual.


• El 100% de disponibilidad se puede conseguir.


• Los datos siempre están cerca del servidor.


• Se necesita acceso físico al servidor.


• Las bases de datos son la mejor forma de almacenamiento.


• Necesitas tener millones de euros para ser un competidor en tu rama.

Arquitectura: Map/Reduce. Asunciones que ya no son ciertas:

• Es difícil trabajar con terabytes de datos.


• El código se ejecuta siempre en una única máquina.


• El código ejecutado secuencialmente es mejor que el código ejecutado en paralelo.


• La mejor forma para almacenar los datos es con sistemas RAID.


• Las bases de datos son mejores que los sistemas de ficheros.

Arquitectura: Sharding. Asunciones que ya no son ciertas:

• Una única granja puede escalar hasta el infinito.


• Necesitas proporcionar 100% de disponibilidad al 100% de tus usuarios.


• Cambios en la aplicación cambian la totalidad del esquema de base de datos.

El análisis realizado me ha parecido muy interesante. El argumento central de la presentación es que la computación poco a poco se está conviertiendo en una commodity, como las granjas que nos preparan la comida o las fábricas que nos hacen la ropa.

Sistemas sobre los que he estado hablando continuamente en los últimos meses, como S3, EC2, la nueva SimpleDB o Hadoop han cambiado la forma de entender la computación distribuida y, concretando en el caso de Amazon, proponen un modelo de renting muy atractivo que permite a pequeñas startups ponerse a la altura de grandes corporaciones.

Por cierto, que no lo había comentado, Julio Guijarro es el líder del proyecto SmartFrog, que personalmente no conocía y que tiene como objetivo el proporcionar una tecnología que describa sistemas de software distribuidos como colecciones de componentes manejables y activables. Por la descripción se me antoja como algo similar a Dryad de Microsoft. Eso sí, éste está liberado bajo licencia LGPL.

Hadoop, su "competencia", y un poco de verguenza ajena

Hace meses, solía echarle un vistazo muy de vez en cuando a un foro sobre CMS que parece que lo seguían bastantes comerciales. Cada vez que una persona hacía una pregunta, todos los comerciales iban poniendo una respuesta en la que en lugar de contestar a lo que el usuario preguntaba pues exponían las maravillas de su producto y dejaban sus datos de contacto.

Hoy, he recordado ese foro leyendo una entrada en InfoQ en la que destacan el momento del que parece disfrutar este producto Open Source y que ya comentaba hace unos días.

A mi, personalmente, me resulta bastante desagradable el que propongan un tópico para debatir en torno a Hadoop y que inmediatamente salten los banderas de otros productos comerciales a hablar de sus productos, sin siquiera ceñirse a lo que el editor ha propuesto en la entrada. Me parece una actitud un poco de mal gusto y propia de productos de segunda clase.

Sin embargo resulta bastante curioso que los productos que se anuncian en este caso sean tres de los más importantes en su sector: Terracotta, Oracle Coherence y GigaSpaces. y es que además la relación entre Hadoop y estos tres productos tampoco es clara. Mucho me temo que la competencia entre ellos ahora mismo es tran grande, que uno de ellos escribe algo e inmediatamente han saltado los otros dos a promocionar sus productos.

En fin, que a mi personalmente me hubiera gustado que alguien hablase sobre Hadoop y no tener que leer esa publicidad barata, por muy bueno que sea lo que se publicita.

Hadoop toma protagonismo

Parece que uno de los proyectos que han tenido bastante éxito en la OSCON 2007 ha sido Hadoop, un subproyecto de Apache Lucene que implementa el conocido algoritmo de MapReduce utilizando su propio sistema de ficheros distribuido.

Tim O'Reilly ha publicado un extenso artículo sobre esta librería y la importancia de que Yahoo esté detrás de ella. En particular destaca la importancia de que Yahoo escoja el camino de contribuir al Open Source y respaldar proyectos exitosos como Lucene como base para las herramientas que utiliza, en lugar de seguir el camino de hacer desarrollos internos, que es el aparente camino que sigue Google (no quita que haya liberado interesantes frameworks).

Aún así el creador de Lucene y Hadoop, y ahora empleado de Yahoo, Doug Cutting, destaca que Hadoop no está limitado a la búsqueda ni tiene porque ser ese el escenario en el que rinde mejor:


"Where Hadoop really shines, is in data exploration." Many problems, including tuning ad systems, personalization, learning what users need -- and for that matter, corporate or government data mining -- involve finding signal in a lot of noise.

Y el artículo termina con un ejemplo de como utilizar MapReduce para afrontar la explotación de ficheros de log gigantescos.

El caso es que en la Yahoo Developer Network han publicado las charlas, powerpoints, video y audio de la presentación realizada en la OSCON y una entrada antes también hablan sobre la evolución del proyecto.

High Availability ofrecía un análisis hace poco sobre este producto. Y bueno, en casi todas estas fuentes referencian al artículo de Julio sobre como integrar Hadoop con Amazon Web Services.

Desde luego, parece que suena bastante. Por cierto, ¿a alguien le interesa jugar con Hadoop y Amazon? Un proyecto realmente interesante sería integrarlo con Apache Jackrabbit de forma que pudieses almacenar contenido de cualquier repositorio en un sistema de ficheros distribuido, como por ejemplo el de Hadoop, y que a su vez se volcase en un servicio como Amazon S3. Y además sería una contribución espectacular para jLibrary :D