Arquitecturas Lambda en Azure

Publicado el 14 de agosto de 2017

Esta es la primera entrada, espero que de muchas, en la que veremos los principales desafíos a los que nos enfrentamos cuando tenemos que desarrollar soluciones de procesamiento de datos masivos en sistemas de Big Data. Mostraré el enfoque y tecnologías utilizadas para dar respuesta a esos desafíos y cómo implementamos estas soluciones basadas en servicios de Azure: HDInsight, Stream Analytics, EventHub, Data Lake, etc. Antes de entrar en materia, aprovecho esta primera entrada para introducir el concepto de Arquitectura Lambda, en la que veremos las técnicas de Big Data en contraposición a los sistemas tradicionales.

Una Arquitectura Lambda es una arquitectura de procesamiento de datos diseñada para manejar cantidades masivas de datos utilizando procesamiento en batch y en tiempo real. Muchas veces nos referimos a estos dos modos de procesar los datos como cold path y hot path respectivamente. Uno de los objetivos de este tipo de arquitecturas es que podamos consultar y preguntar a los datos de una forma consistente, independientemente del camino que utilicemos, ya sea consultando los datos en reposo o en movimiento.

El término Arquitectura Lambda fue acuñado por Nathan Marz, el creador de Storm, en el libro Big Data de Manning. A grandes rasgos, la idea detrás de esta arquitectura es la de poder ofrecer un sistema más intuitivo y sencillo que el ofrecido por las arquitecturas tradicionales, caracterizadas por utilizar bases de datos de lectura y escritura que mantienen el estado de forma incremental, presentando ciertas complejidades tanto a nivel operacional como al querer aumentar la disponibilidad mediante consistencia eventual o réplicas. Además, las arquitecturas incrementales presentan como último inconveniente la falta de tolerancia a fallos humanos, ya que modificando el estado de la base de datos y entendiendo que los errores son inevitables, estamos casi garantizando que los datos en algún momento se corromperán.

«Las arquitecturas Lambda pueden producir soluciones con mejor rendimiento evitando las complejidades de las arquitecturas incrementales.»

En la práctica veremos que no existe una solución única para implementar una Arquitectura Lambda, esto significa que tendremos que hacer uso de un conjunto de distintas tecnologías y técnicas para construir un sistema completo de Big Data. En las siguientes entradas veremos en detalle cada una de estas tecnologías, basadas en servicios de Azure, y distintos enfoques para afrontar el diseño de una Arquitectura Lambda.

La idea de las Arquitecturas Lambda es crear un sistema de Big Data diferenciando tres capas, cada una basada en la funcionalidad proporcionada por las capas inferiores.

Batch Layer - Es la responsable de guardar una copia inmutable de los datos en constante crecimiento y de precalcular una serie de vistas sobre esos datos.

Serving Layer - Normalmente consiste en una base de datos distribuida que carga las vistas generadas por la batch layer y permite realizar lecturas aleatorias. Cuando existen nuevas vistas batch disponibles la serving layer intercambia automáticamente para que los datos más recientes estén disponibles. Una base de datos serving layer debe soportar actualizaciones en lote y lecturas aleatorias, pero no necesita soportar escrituras aleatorias.

Speed Layer - La serving layer se actualiza tan pronto la batch layer termina de precalcular una vista. Esto significa que los datos que no están disponibles en la batch view son los datos que llegaron mientras se estaba procesando la vista. El propósito de la speed layer es asegurar que los nuevos datos están representados tan pronto la aplicación los necesita, consiguiendo de esta forma un sistema de datos en tiempo real.

Layers of a Lambda Architectures

La speed layer y la batch layer son similares en cuanto a funcionalidad ya que son las encargadas de generar las vistas, ya sea en tiempo real o mediante procesos batch a medida que se reciben nuevos datos. Sin embargo, existen dos diferencias en cuanto a la forma de procesar los datos. La speed layer solo utiliza los datos más recientes y realiza cálculos incrementales para obtener las menores latencias posibles. Esto significa que la speed layer debe generar las vistas en tiempo real basándose en los datos nuevos y otras vistas en tiempo real existentes.

Resumen

Cuando hablamos de sistemas de procesamiento masivo de datos no debemos preocuparnos exclusivamente de que la solución sea altamente eficiente, hay otras propiedades que tenemos que poner en valor: robustez, tolerancia a fallos, escalabilidad, extensibilidad… Las Arquitecturas Lambda definen cómo deben construirse estos sistemas basándose en tres capas, que establecen la forma en la que los datos deben procesarse y a la vez satisfacen todas las propiedades necesarias en un sistema de Big Data.

Referencias

Analytics on Large Scale, Unstructured, Dynamic Data using Lambda Architecture
Vehicle telemetry analytics solution playbook
Lambda Architecture
Lambda Architecture for Connected Car Fleet Management
Nathan Marz on Storm, Immutability in the Lambda Architecture, Clojure

Esta entrada es parte de una serie dedicada a las Arquitecturas Lambda en Azure:

  1. Arquitecturas Lambda en Azure
  2. Arquitecturas Lambda en Azure: recopilando eventos

Tags : Lambda Architecture, Azure, Big Data