Arquitectura Lambda: Principios de Arquitectura para Sistemas Big Data en Tiempo Real

(Con Luis siempre tengo lecturas acumuladas :))

En este post James Kinley hace una interesante reseña sobre el MEAP “Big Data – Principles and best practices of scalable realtime data systems" de Nathan Marz y James Warren.

Me permite traducir una parte porque me ha parecido una lectura muy interesante!

Los autores definen la Arquitectura Lambda como un conjunto de principios para arquitecturar sistemas Big Data en Tiempo Real.

La premisa detrás de la arquitectura Lambda es que aunque con Big Data se pueden ejecutar consultas ad-hoc contra todos los datos para obtener resultados hacerlo es excesivamente costoso en recursos.

Técnicamente ya existen soluciones para ejecutar consultas a medida contra petabytes de datos (como Cloudera Impala) aunque en casos puede no ser el enfoque más eficaz. Así que la idea es calcular previamente los resultados como un conjunto de vistas y consultar estas vistas.

La Arquitectura Lambda se divide en 3 Capas:

· Batch layer

· Serving layer,

· Speed layer.

Batch layer (Apache Hadoop)

Es responsable de 2 cosas:

1. Almacenar en HDFS el dataset maestro que es inmutable y constantemente crece

2. Crear vistas arbitraries desde este dataset vía MapReduce (Hive, Pig,…). Esta computación se planifica y conforme llegan nuevos datos se agregan a las vistas en la siguiente iteración. Cada generación puede llevar horas.

Serving layer (Cloudera Impala)

· La Serving layer se encarga de indexar y exponer las vistas para que puedan ser consultadas.

· Como las Vistas Batch son estáticas esta Capa sólo necesita proveer lecturas y para eso puede usar Impala, Stinger,…

· Por ejemplo para exponer las vistas con Impala lo único a hacer es crear una tabla en el Metastore de HIVE que apunte a los ficheros HDFS y el usuario ya podrá consultar vía SQL

Speed layer (Storm, Apache HBase)

Con estas dos capas tenemos una Arquitectura Big Data completa, aunque no se satisface los requisitos de Tiempo Real (Near Real Time por supuesto) porque MapReduce es un proceso Batch y puede llevarse horas en crear las vistas y propagarlas a la Serving Layer. Aquí aparece la Speed Layer.

· En esencia esta Capa hace lo mismo que la Batch LAyer: ya que computa Vistas cuando llegan los datos.

· Esta Capa sirve para compensar la alta latencia de la Capa Batch generando vistas en tiempo real usando Storm (hay otras opciones, aunque los autores recomiendan esta como es normal siendo quienes son :D)

· Esta Vista en Tiempo Real contiene sólo los resultados delta que se añaden a las Vistas Batch.

· Esta Capa usa un modelo incrementar donde las vistas son incrementales

Esta Capa también exponer estas Vistas para que puedan ser consultadas y mergeadas con las Vistas Batch para conseguir el resultado completo, esta vista requiere tanto lectura como escritura random. En el artículo recomiendan HBase, que permite que Storm actualice continuamente las vistas en tiempo real y a su vez puede ser consultado por Impala para mergear con las Vistas Batch.

Leer más