Paradigmas BigData: El procesamiento Batch
noviembre 20, 2013
Llevamos hablando de BigData en el blog una temporada y creo que es hora de categorizar los tipos de "tecnologías BigData" que se utilizan en el mercado.
Hace un tiempo vimos que era eso del BigData, por otra parte vimos que implica tener toda nuestra vida monitorizada y últimamente hemos estado jugando con Cassandra y Hadoop.
Creo que es hora de hacer un mapa a alto nivel de los distintos tipos de categorías (dada su arquitectura) de tecnologías que han ido saliendo para el procesamiento de grandes volúmenes de datos.
A continuación tenéis la lista de Post:
- Paradigmas BigData: Arquitectura Lambda
Hoy nos vamos a situar en la zona de Batch Processing, que es la que más tiempo lleva en el mercado, que más se ha usado y que más estable se encuentra, con sus pros y sus contras.
El Batch processing ha sido la manera más eficiente de procesar grandes volúmenes de datos, donde el objetivo era acumular muchos datos, procesarlos y producir resultados por lotes (Hadoop se centra en ello). El procesamiento por lotes requiere el uso distintas tecnologías para la entrada de los datos, el procesamiento y la salida.
En el Batch Processing se puede decir que Hadoop ha sido la herramienta estrella que ha permitido almacenar cantidades gigantes de datos y escalarlos horizontalmente añadiendo más y más nodos (en el clúster se entiende). Han surgido multitud de herramientas alrededor de Hadoop, como HBase, Hive, Pig...que lo que hacen es ayudar a analizar esa cantidad ingente de datos.
El siguiente gráfico muestra como se comporta una arquitectura tipo Batch Processing:
Dentro del Batch Processing podemos distinguir distintas tecnologías que se unen para poder realizar el análisis de los grandes volúmenes de datos, a continuación un gráfico con las tecnologías que se han estado utilizando en sus distintas categorías:
En este post no voy a explicar cada una de las tecnologías, ya dedicaré tiempo a Flume, Pig, Cascading y Spark & Shark. Sobre todo a Spark & Shark que se basa en almacenamiento/procesamiento en memoria y es un concepto muy interesante porque además los chicos de Berkeley se lo han currado muchísimo y tenemos herramientas super chulas, como el poder desplegar un clúster de manera sencilla. Pero eso es algo que como os dije, veremos más adelante.
En el post de Real Time haré una comparación con Batch Processing y veremos su principales puntos débiles dado que hubo que buscar nuevos remedios a los problemas que iban reclamando los clientes.
Y hasta aquí llega la visión general del batch processing, y aunque podríamos hablar de más cosas, creo que ha sido una buena introducción y puesta en escena de la arquitectura y las tecnologías involucradas.
Nos vemos en el siguiente ;)
Fuentes:
· BigData Spain - TreeLogic - Rubén Casado (gracias)
4 comentarios
Cual seria el volumen de datos que marca la diferencia entre batch y realtime ... es la velocidad del origen de datos o el tiempo de respuesta necesario para el analisis o mas bien tiene que ver si el procesado/analitica de datos se realiza en el momento de la adquisicion del dato o mas bien con el dato en reposo ?
ResponderEliminarBuenas Desconodi@.
ResponderEliminarintento aclarar:
· Batch: tecnologías, métodos y procesos que se utilizan cuando queremos extraer información de un gran volumen de datos. Suelen ser operaciones pesadas y realizadas por un solo usuario que consume todos los registros de tu cluster. El volumen varía según sea tu cluster, desde gigas hasta petas. Suelen ser tecnologías bien conocidas como Hadoop o Spark.
Ejemplo: extraer el nombre de todos los cantantes de rock de los últimos 200 años de un fichero distribuido en HDFS con todas las canciones de los últimos 200 años a través de MapReduce.
· Real Time: tecnologías, métodos y procesos que se utilizan cuando queremos extraer información de un dato correlativo a un gran volumen de datos. Suelen ser operaciones ligeras y rápidas y se realizan por múltiples usuarios a través de sistemas de colas. El volumen varía según sea tu cluster con el que comparas tu tupla, desde gigas hasta petas pero la velocidad depende de las máquinas de tu cluster, de tu algoritmo y del volumen. Esto nos permite tener sistemas multi-usuario, mezclando por ejemplo tecnologías como Storm + Kafka.
Ejemplo: sistema recomendador. En base a la cuenta de un usuario (su carrito de la compra, etc) saber en el momento de pago si va a necesitar comprar otro elemento que no lleve en su cesta. Esto se realiza mediante algoritmia en la que se compara su carrito con el carrito de millones de personas. Suelen ser operaciones matemáticas con matrices. También se puede realizar en Batch, pero sería monousuario.
Te recomiendo el libro de Nathan Marz que sale en Marzo de 2015:
http://www.amazon.es/Big-Data-Principles-practices-scalable/dp/1617290343
Cualquier otra duda, aquí me tienes.
Saludos.
Cuando dices usuario o mutiples usuarios me pierdo un poco/mucho ...
EliminarUna duda un usuario de hadoop no puede lanzar varias consultas diferentes sobre el cluster de hadoop?
En el caso que pones del motor de recomendación , en el caso que lo que se quiera es hacer una recomendación de compra en base a un algoritmo de arbol de decision que ha generado una matriz de compras, ¿cuando puede tener sentido el tema multiusuario?
Estoy comenzando con el tema Hadoop y el tema de real time se me escapa un poco basicamente porque en las aplicaciones que analizo (que implica motor de recomendaciones y procesado de eventos de usuario) el numero de eventos por segundos que se reciben no llega ni a 1000 evento/seg aunque el volumen de datos sea de Terabytes ... no llego a ver esa necesidad tan grande de real time ... me imagino que es pura ignorancia
Primero, perdóname por tardar tanto en contestar.
EliminarAhora, hola de nuevo @Desconocido. Supongo que has resuelto la duda. Si, se puede ejecutar varios Jobs para un mismo usuario, pero el coste de procesamiento hará que vayan más lentas, ya que compartirán el mismo hardware.
Quizás no necesites un motor en tiempo real y te apañes con tus herramientas tradicionales. A veces lo malo conocido es mejor que lo bueno por conocer.
Si tienes alguna duda, pregúntame por email.
Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.