Tag Archives: BigData

Hadoop, Hive, Pig, Sqoop, Impala, a vista de pájaro

Estoy asistiendo al curso de “Desarrollo de aplicaciones Big Data con Apache Spark y Apache Hadoop” en el COIICV que está impartiendo Mario Renau de una forma magistral. El curso está resultando bastante interesante, y sobre todo estoy consiguiendo hacerme una fotografía de todo, o por lo menos de gran parte, el universo Hadoop.

Hadoop, como parte de fundamental del Big Data, es algo que me ha interesado desde hace tiempo, y a lo que he intentado acercarme en varias ocasiones, tengo que confesar, sin demasiado éxito. Ahora me doy cuenta que el problema que tenía era que no conseguía percibir la “big picture” de todo esto. En seguida empezaba a aparecer mucho software adicional que se integraba con Hadoop, que te vendían que si eran capas de abstracción, que si la solución definitiva, que si con esto lo conseguirás todo … como siempre en estos casos, todo es relativo.

En esta entrada quiero dar una visión muy sencilla de lo que es Hadoop y alguno de estos componentes, y tiene que ser muy sencilla porque en estos momentos, mis conocimientos son muy limitados, los de alguien que está empezando a jugar con todo esto, pero quizás, ahora sea el momento ideal para poder dar este enfoque sencillo, ya que seguramente, cuanto más avance, más complicado se vuelva.

hadoop-bird

Soy consciente de que para un experto, las líneas de conexión no serán exactamente así, que serán mucho más complejas y que habrá toda una serie de condicionantes y circunstancias que quedan fuera del gráfico anterior, pero de nuevo, quiero decir que es una simplificación de y para principiantes.

En el centro de todo está HDFS, que es el Sistema de Ficheros Distribuido de Hadoop. Gracias a él Hadoop puede guardar tanta cantidad de datos para su procesamiento, de forma distribuida, segura y eficiente. HDFS gestiona todas las necesidades de lectura y escritura de una forma transparente, nosotros no nos preocupamos de que nodo guarda tal o cual, trabajamos directamente con el fichero y HDFS se encarga de obtener de los nodos distribuidos lo que le pedimos.

Hadoop Map Reduce es la implementación del modelo teórico Map – Reduce, y que es la base de cualquier proceso en Hadoop. En Hadoop, al final, cualquier tarea se traduce en procesos Map Reduce.

Siguiendo en el centro de la imagen, acabamos con Hadoop YARN que es el encargado de orquestar todo el cluster Hadoop, de asegurar la disponibilidad, rendimiento, acceso óptimo a los datos, etc.

Hasta aquí lo que sería el core de Hadoop, y “simplemente” con esto ya podríamos funcionar, pero si algo hay que reconocer es que Hadoop es complejo y farragoso, de ahí que aparezca software que intenta darle una cara más amable, más parecida a herramientas a las que estamos más acostumbrados, como consultas SQL o lenguajes de scripting. Estas son las cajas en rojo que he dibujado para Hive, HCatalog, Impala, Pig y Scoop.

Hive en mi opinión es realmente interesante, su función principal es hacer que podamos trabajar con todos los ficheros almacenados en el sistema HDFS como si fueran tablas de una base de datos relacional. Muy a groso modo, nos permite definir estructura en forma de tabla para los ficheros, soportando múltiples formatos, para posteriormente poder consultar esa tabla (y otras) con sentencias SQL que seguro conocemos bien. Hive se encarga de traducir las sentencias SQL en procesos Map – Reduce, que se ejecutan directamente en Hadoop para darnos el resultado.

HCatalog es un API Rest sobre Hive cuyo objetivo es facilitar la integración de otras herramientas con Hive mediante el uso de dicho API.

Impala ofrece la misma función que Hive, ofrecer un interfaz SQL sobre Hadoop, pero la diferencia fundamental es que intenta que las consultas se ejecuten más rápidamente mediante un consumo adicional (parece que realmente alto) de memoria. Impala guarda en memoria gran parte de los datos para ofrecer este alto rendimiento.

Pig es un lenguaje de scripting sobre Hadoop con funciones de alto nivel que facilita la programación, reduciendo drásticamente la complejidad y las líneas de código. Cargar datos, filtrar, recorrer, agrupar, son algunos ejemplos. De la misma forma que Hive, traduce las instrucciones de más alto nivel a procesos Map Reduce que se ejecutan en Hadoop.

Por último Sqoop, es una herramienta para importar y exportar datos entre bases de datos relacionales y HDFS.

El universo Hadoop tiene muchísimas más herramientas satélite que ofrecen funcionalidades muy interesantes, pero mi limitada visión llega hasta aquí.

Advertisements

Como optimizar procesos de inserción masiva en MongoDB

Mongo DB es un document storage NoSql que tiene una capacidad de escritura muy alta, y realmente la tiene, por mi experiencia mucho más que por ejemplo MySql. Pero cuando empiezas a cargarlo de verdad, con procesos de inserción masiva, del orden de millones de documentos, la cosa ya no va sola, y necesitas empezar a desarrollar de una forma determinada para conseguir que tus procesos sigan yendo a toda pastilla. Aquí te cuento algunos de los que he descubierto a base de leer en algunos casos, y de tortas en otros.

No gestionar las transacciones

Ni se te ocurra gestionar las transacciones en este tipo de procesos. Mongo tiene la virtud de poder “insertar y olvidar”, es decir, de enviar los datos a insertar al servidor, y no esperar ningún tipo de respuesta, ni de confirmación por su parte. Esto lo consigues especificando un WriteConcern.UNACKNOWLEDGED, que quiere decir eso, que no te interesa si la inserción ha ido bien o mal. Eso si, para utilizar esto, ya te tienes que haber preocupado previamente de asegurarte que tus inserciones no van a fallar, sino, mal lo tendrás para poder verificar lo que ha ido bien o mal.

Ejecuta un único save para cada documento, nunca update

El método save es mucho más rápido que el método update, ya que directamente escribe, sin verificar si previamente existe el registro o no. Nunca, repito, nunca desarrolles procesos de inserción masiva que quieras que vayan rápido y que no se degraden al crecer las colecciones en los que hagas uno o varios updates. Nuevamente, en este proceso, tendrás que preocuparte de tener a tu alcance toda la información que quieres guardar para cada documento, júntala durante N procesos e inserta una única vez.

Contra colecciones vacías

El tiempo de inserción en colecciones vacías en Mongo es mas bajo que cuando tiene datos. Plantéate en tu proceso si es posible al inicio del mismo borrar completamente la colección y volver a generarla de nuevo con los datos que vas a insertar. Aunque parezca mentira, en muchos casos puede ser más rápido hacer de nuevo una inserción completa que N parciales.

Contra colecciones sin índices

Si tus colecciones tienen índices, bórralos con dropIndex antes de empezar a insertar, ejecutas, y al finalizar vuelves a crear el indice con ensureIndex. El tiempo de creación del índice global es mucho menor que el tiempo que se tiene que invertir en actualizar el mismo índice ya creado en cada inserción de cada documento.

En colecciones más pequeñas

Trocea tus colecciones, tanto la inserción como la recuperación de datos van a ir más rápidas contra diez colecciones de 2 millones de documentos, que contra una única colección de 20 millones. Además, esto te permitirá paralelizar tus procesos y reducir la duración total.

Utiliza diferentes databases

Es incluso preferible utilizar diferentes databases para datos temporales o que vayas a regenerar por completo en ese ciclo, que diferentes colecciones en la misma base de datos. Esto te permitirá incluso hacer dropDatabase que liberará el espacio en disco que Mongo reserva para la db, cosa que no hace si eliminas la colección.

Y hasta aquí mis pequeños trucos para optimizar la inserción masiva en Mongo. Si tienes algún truco que no haya dicho, no dudes en comentármelo.