Inicio / Blog / ARQUITECTURA BASADA EN LAMBDA PARA UNA PLATAFORMA BIG DATA
Imagen de Eros
Eros Perez M.
Comp. Science Engineer
23 Ene 2017
ARQUITECTURA
BASADA EN LAMBDA PARA UNA PLATAFORMA BIG DATA

Procesos analíticos de datos para extraer valor de los datos

Body: 

Introducción

En la última década, la cantidad de datos que se están creando se ha disparado. Más de 30.000 gigabytes de datos se generan cada segundo, y la tasa de creación de datos sólo se está acelerando. Los datos que tratamos son diversos. Los usuarios crean contenido como mensajes de blog, tweets, interacciones de redes sociales y fotos. Los servidores registran continuamente mensajes sobre lo que están haciendo. Este asombroso crecimiento de los datos ha afectado profundamente a las empresas. Los sistemas tradicionales de bases de datos, como las bases de datos relacionales, han sido empujados al límite. Los sistemas tradicionales y las técnicas de administración de datos asociados con ellos no han podido escalar a Big Data (Niño y Illarramendi, 2015).

Para abordar los retos de Big Data, una nueva generación de tecnologías ha surgido. Muchas de estas nuevas tecnologías se han agrupado bajo el término No SQL[1] (Vaish, 2013). En cierto modo, estas nuevas tecnologías son más complejas que las bases de datos tradicionales, y en otras formas, son más simples. Estos sistemas pueden escalar a conjuntos de datos mucho más grandes, pero el uso de estas tecnologías requiere efectivamente un conjunto fundamentalmente nuevo de técnicas. Con el fin de hacer frente a los retos de Big Data, se hace necesario repensar los sistemas de datos desde el principio. El enfoque más simple y alternativo es el paradigma para Big Data que Marz y Warren, (2015) han denominado la Arquitectura Lambda.

El objetivo general de este trabajo es desarrollar un prototipo funcional de una arquitectura para una plataforma Big Data, siguiendo el patrón de la Arquitectura Lambda. Para implementar y validar la plataforma se recurrirá a unos de los problemas más comunes que tienen las empresas cuando implementan una campaña de marketing digital. La validación se hará sobre un sitio implementado haciendo uso del sistema gestor de contenido Drupal, al cual se le implementará una campaña en Google Analytics. La información de los usuarios o clientes del sitio se obtendrá desde un fichero CSV generado por un sistema ERP/CRM (siglas en inglés de Enterprise Resource Planning), en este caso Salesforce. Se tiene como premisa que la interacción de los usuarios sobre el sitio irá generando un creciente volumen de datos en incremento cada segundo.

Desarrollo

Calcular funciones arbitrarias en un dataset arbitrario en el tiempo real es un problema intimidante. No hay una sola herramienta que provea una solución completa. En lugar de eso, tiene que usarse una variedad de herramientas y técnicas para construir un sistema Big Data completo. La tarea importante es cómo organizar estas herramientas para que puedan colaborar entre sí. [M1] La plataforma propuesta sigue una Arquitectura Lambda que puede producir soluciones de alto desempeño en todos los aspectos, mientras que también evita la complejidad que plaga a las arquitecturas incrementales. La clave es librarse de las ataduras de computación completamente incremental y aceptar técnicas diferentes. A continuación se describe los materiales y métodos empleados en el diseño y construcción de la plataforma propuesta.

Arquitectura Lambda [M2] 

La premisa principal de la Arquitectura Lambda, desarrollada en los últimos años y cuyo desarrollo se recoge en el libro publicado por Marz y Warren, (2015), es facilitar el diseño de sistemas Big Data que integren diferentes maneras de tratamientos de datos, que puedan concretarse en cada caso con las tecnologías específicas convenientes y organizadas en un grupo de capas. El hecho de replantear los sistemas de tratamiento de datos desde cero para que su diseño sea el apropiado para trabajar con Big Data da lugar a obtener una arquitectura genérica que integre todos los conceptos y que guíe el proceso de diseño del sistema y la elección de las tecnologías específicas a integrar en casa caso.

Arquitectura concreta basada en Lambda

La arquitectura concreta para la plataforma propuesta, consta de tres capas. A continuación se describen cada uno de sus componentes y las tecnologías a utilizar en cada caso:

Capa de recolección, ingestión y pre-procesado de datos. Se encarga de recibir y mantener datos que se recolectan principalmente de los siguientes orígenes de datos, logs de Drupal, datos de los clientes almacenados en un fichero CSV provenientes del ERP, información proveniente de Google Analytics. También se llevan a cabo servicios de normalización, evaluación e integración de datos con el objetivo de preparar de forma óptima los datos para la siguiente capa. Comprende las tecnologías que obtienen los datos en bruto. Se escogieron las tecnologías siguientes: Apache Kafka, se utiliza para construir tuberías de datos en tiempo real y aplicaciones de streaming. Es escalable horizontalmente, tolerante a fallas y rápido (Apache Software Foundation, 2017). Y, StreamSets Data Collector (SDC) es un motor ligero, potente para la ingestión de datos en tiempo real. Para definir el flujo de datos para SDC, se configura a una tubería o pipeline. Una tubería consiste en etapas que representan el origen y destino de la tubería, y cualquier procesamiento adicional que se quiera realizar (StreamSets, Inc, 2017). Esta capa puede resumirse en la siguiente ecuación: all data = function (row data).

Capa de análisis Big Data. En este nivel se engloban varias subcapas, la Arquitectura Lambda, en función del tipo de procesado que se lleva a cabo en cada una de ellas:

Capa por lotes o Batch layer: es la responsable de almacenar los datos provenientes del origen de datos, en este caso Kafka, en el dataset maestro, permitiendo realizar los cómputos necesarios para dar acceso a vistas concretas de los datos almacenados en ese dataset o a información arbitraria de los mismos. Esta capa, al decir de Marz y Warren, (2015) es la porción de la Arquitectura Lambda que implementa la ecuación siguiente: batch view = function (all data).

La batch layer necesita poder hacer dos cosas: almacenar un dataset maestro inmutable, constantemente creciente y calcular funciones arbitrarias en ese dataset. Este tipo de procesamiento es más conveniente hacerlo usando sistemas de procesos por lotes. Para almacenar el dataset maestro se seleccionó Hadoop (Schneider, 2012), una base de datos No SQL distribuida y fundamentada en un prototipo de almacenamiento de “clave-valor”. Una vez normalizados los datos, estos son almacenados en el dataset maestro y se emiten los batch view, como resultado de aplicar una función sobre estos datos, que serán usados por la capa de servicios.

Capa de servicios o Serving layer: se encarga de indexar y exponer las vistas de la capa anterior para que puedan ser buscadas a través de consultas. El procedimiento se describe a continuación: La batch layer emite los batch views como resultado de aplicar una función sobre estos datos. El siguiente paso es cargar las vistas en alguna parte a fin de que pueden ser consultados. Es aquí donde la capa de servicio entra. Esta capa es una base de datos distribuida especializada que carga en un batch view y posibilita hacer lecturas aleatorias en ella. Cuando los nuevos batch views están disponible, la capa de servicio intercambia automáticamente esos datos, a fin de que los resultados más actuales estén disponibles. La base de datos distribuida utilizada en esta capa fue ElasticSearch. Según Kuć y Rogoziński, (2013) es un servidor de búsqueda de código abierto, que, debido a su carácter distribuido y sus habilidades de tiempo real, muchas personas lo usan como una base de datos de documento.

Capa de velocidad o Speed layer: se encarga de realizar el cómputo en tiempo real. Esta capa da solución al problema de latencia baja en las actualizaciones. Como su nombre sugiere, su meta es asegurar que nuevos datos son representados en funciones de consulta tan rápido como sean necesitados por los requisitos de la aplicación. Puede formalizarse el flujo de datos en la capa de velocidad con la siguiente ecuación lo indica:  realtime view = function (realtime view, new data).

Una vista en tiempo real es actualizada basado en nuevos datos y la vista en tiempo real existente. Para el caso de la plataforma propuesta se usa Apache Storm. Storm es un sistema que tiene como función la recuperación de streams de datos en tiempo real. Se trata de una herramienta de código abierto que recoge datos de forma distribuida y en alta disponibilidad. Además, es tolerante a fallos, es decir, ofrece la posibilidad de reproducir los datos que no han sido procesados de forma correcta en la primera ocasión (Apache Software Fundation, 2017). Storm está compuesto principalmente por dos elementos fundamentales, el Spout y el Bolt. El Spout es el componente se encarga de recoger el tráfico de datos de entrada en el sistema. En el caso de este trabajo, se usaría para recolectar los mensajes de Apache Kafka. El Bolt, es el encargado de procesar las tuplas que emite el Spout y luego emitir vistas en tiempo real, almacenarlas en la base de datos ElasticSearch para ser consultadas por la capa de aplicación. Siguiendo así la arquitectura asincrónica para streams de datos.

Capa de aplicación. En esta última capa se desarrollan los servicios concretos en base a la información detectada, pre-procesada y analizada. La misma puede formalizase con la ecuación siguiente: query = function (batch view, realtime view).

Para la implementación de la ecuación anterior en la plataforma, se empleó la herramienta Kibana (ElasticSearch BV, 2017), una herramienta de visualización de datos, de propósito general, que facilita la explotación visual de información almacenada en una base de datos ElasticSearch haciendo uso de la representación de cualquier conjunto de datos con tablas y gráficas bastantes ricas. La información fue organizada en un dashboard con las visualizaciones de las consultas realizadas sobres los datos almacenados en los batch y realtime view.

Implementación concreta de la arquitectura basada en Lambda

En aras de comprobar el funcionamiento de la arquitectura propuesta fue necesario implementarla siguiendo los pasos que a continuación se describen:

  • Construcción de un entorno de desarrollo para StreamSets Data Collector, Apache Kafka, Apache Storm, Hadoop, ElasticSearch y Kibana y la creación de la tabla de destino HDFS[1] y los índices ElasticSearch usando Docker.

Individualmente, la instalación de estas herramientas y configurarlos para que se comuniquen entre sí, no es una tarea fácil. Afortunadamente, con Docker y Docker Compose  se pueden crear los contenedores con el stack[2] de forma fácil (Turnbull, 2014). Como se ha comentado anteriormente para crear el entorno con Docker, se crea el fichero docker-compose.yml donde se configuran las distintas herramientas que forman el stack. Pueden encontrarse en internet varios contenedores Docker para este fin (Endocode, 2015).

Una vez instaladas las herramientas es necesario configurar la topología en Storm que posibilitará el flujo de datos en tiempo real en la capa de velocidad. Cuando esta configuración esta hecha, ya se tiene el stack configurado, lo siguiente es alimentar ElasticSearch para poder usar Kibana y ver las principales funcionalidades que ofrece. Para lograrlo se ejecuta el stack con el siguiente comando:

docker-compose up

De esta forma se está en condiciones de ejecutar el siguiente paso en la implementación de la arquitectura, la ingestión de los datos.

  • Ingestión de datos desde Drupal, Google Analytics, los datos de los clientes del ERP en formato csv, el ruteo y la entrega a ElasticSearch y Hadoop en tiempo real.

Para ingerir los datos se hace uso de la herramienta Streamstes Data Collector. Para crear un flujo de datos en Streamstes es necesario configurar un "pipeline" en la interfaz gráfica. La Figura 4 muestra un pipeline para consumir los datos referentes a la interacción de usuario en el sitio Drupal, los cuales son proveídos por Google Analytics. En esta figura se puede observar las transformaciones que pasan los datos desde el origen hasta el destino final. El Jython Evaluator se encarga de completar la información faltante, los datos de los clientes; luego se eliminan campos innecesarios y se ponen en la cola de mensajes, representados en el pipeline por el Kafka Producer. En Kafka los datos son almacenados en tópicos que son consumidos por un Kafka Consumer, como se puede observar en la Figura 5, al mismo tiempo, estos datos pasan a la capa por lotes donde son creadas los batch view. Durante el proceso de la creación del batch view siguen llegando datos al pipeline los cuales son procesados en tiempo real por Storm, dando la posibilidad al usuario de tener en tiempo real la información disponible.

  • Diseño de dashboard en Kibana con datos en tiempo real.

En el paso anterior se recolectan y transforman los datos haciendo uso de varias herramientas, cada una de estas cumple un papel importante en la recolección y procesado de los datos. Estos datos normalizados se almacenan en un dataset maestro en Hadoop para luego obtener información y aplicar cualquier herramienta de analítica de datos. Sobre esos datos, también se crean vistas que son almacenadas en índices ElasticSearch, que aprovechando el complemento Kibana, una herramienta de visualización de datos se pueden construir cuadros de mandos (dashboards) con los cuales presentarle la información al usuario y facilitar el proceso de toma de decisiones. 

Conclusiones

A partir de la plataforma propuesta se concluye que la integración de diferentes herramientas permite construir la infraestructura que soporta la escalabilidad horizontal y los tiempos de respuesta adecuados según el proyecto concreto. Además, permite desarrollar el software capaz de gestionar grandes cantidades de datos (Volumen), datos que se generan en tiempo real y/o que necesitan ser procesados para dar una respuesta en tiempo real (Velocidad), y datos con una estructura diversa (Variedad). También la arquitectura facilita posteriores procesos analíticos de datos para extraer valor de los datos.

Referencias bibliográficas

Apache Software Foundation. (7 de Marzo de 2017). Documentation: Apache Kafka. Obtenido de Apache Kafka: http://kafka.apache.org/documentation

Apache Software Fundation. (3 de marzo de 2017). Obtenido de Apache Storm: http://storm.apache.org/

ElasticSearch BV. (22 de febrero de 2017). Kibana User Guide [5.1]. Obtenido de Elastic: https://www.elastic.co/guide/en/kibana/current/index.html

Endocode. (22 de abril de 2015). Building a Development Environment for Storm and Kafka Using Docker Container. Obtenido de https://endocode.com/blog/2015/04/22/building-a-stream-processing-pipeline-with-kafka-storm-and-cassandra-part-2-using-docker-containers/

Kuć, R., & Rogoziński, M. (2013). ElasticSearch Server. Create a fast, scalable, and flexible search solution with the emerging open source search server, ElasticSearch. Birmingham-Mumbai: Packt Publishing.

Marz, N., & Warren, J. (2015). Big Data. PRINCIPLES AND BEST PRACTICES OF SCALABLE REAL - TIME DATA SYSTEMS. New York, United States of America: Manning Publications.

Niño, M., & Illarramendi, A. (2015). ENTENDIENDO EL BIG DATA: ANTECEDENTES, ORIGEN Y DESARROLLO POSTERIOR. DYNA New Technologies, 1-8. doi:10.6036/NT7835

Schneider, R. D. (2012). Hadoop For Dummies. Mississauga: John Wiley & Sons Canada, Ltd.

StreamSets, Inc. (2 de marzo de 2017). Documentation: StreamSets Data Collector. Obtenido de Streamsets Data Collector: http://streamsets.com/docs

Turnbull, J. (2014). The Docker Book. Obtenido de http://www.dockerbook.com

Vaish, G. (2013). Getting Started with NoSQL. Your guide to the world and technology of NoSQL. Birmingham-Mumbai: Packt Publishing.


[1] Hadoop Distributed File System.

[2] Conjunto de herramientas que conforma la arquitectura.


 [M1]Agregar sobre otras arquitecturas para el Big data

 [M2]Mover epígrafe para el 2.2 y agregar diagrama original de la arquitectura Landa de Nathan Marz and James Warren.

 

[1] Es un término que describe las bases de datos no relacionales de alto desempeño.