Arquitectura Lambda

La arquitectura Lambda es una arquitectura de procesamiento de datos diseñada para manejar cantidades masivas de datos aprovechando los métodos de procesamiento por lotes y por flujo . Este enfoque de la arquitectura intenta equilibrar la latencia , el rendimiento y la tolerancia a fallas mediante el uso del procesamiento por lotes para proporcionar vistas completas y precisas de los datos por lotes, mientras que al mismo tiempo se utiliza el procesamiento por flujo en tiempo real para proporcionar vistas de los datos en línea. Las dos salidas de vista se pueden unir antes de la presentación. El auge de la arquitectura Lambda está correlacionado con el crecimiento de los macrodatos , los análisis en tiempo real y el impulso para mitigar las latencias de map-reduce . ^[1]

La arquitectura Lambda depende de un modelo de datos con una fuente de datos inmutable y de solo anexión que funciona como un sistema de registro. ^{[2] : 32} Está destinada a ingerir y procesar eventos con marca de tiempo que se agregan a eventos existentes en lugar de sobrescribirlos. El estado se determina a partir del orden natural de los datos basado en el tiempo.

La arquitectura Lambda describe un sistema que consta de tres capas: procesamiento por lotes, procesamiento de velocidad (o en tiempo real) y una capa de servicio para responder a las consultas. ^{[3] : 13} Las capas de procesamiento ingieren desde una copia maestra inmutable de todo el conjunto de datos. Este paradigma fue descrito por primera vez por Nathan Marz en una publicación de blog titulada "Cómo superar el teorema CAP ", en la que originalmente lo denominó "arquitectura por lotes/en tiempo real". ^[4]

La capa por lotes precalcula los resultados utilizando un sistema de procesamiento distribuido que puede manejar cantidades muy grandes de datos. La capa por lotes apunta a una precisión perfecta al poder procesar todos los datos disponibles al generar vistas. Esto significa que puede corregir cualquier error al volver a calcular en función del conjunto de datos completo y luego actualizar las vistas existentes. El resultado generalmente se almacena en una base de datos de solo lectura, y las actualizaciones reemplazan por completo las vistas precalculadas existentes. ^{[3] : 18}

En 2014, se estimó que Apache Hadoop era un sistema de procesamiento por lotes líder. ^[5] Más tarde, otras bases de datos relacionales como Snowflake , Redshift, Synapse y Big Query también se utilizaron en esta función.

La capa de velocidad procesa los flujos de datos en tiempo real y sin los requisitos de correcciones o integridad. Esta capa sacrifica el rendimiento ya que apunta a minimizar la latencia al proporcionar vistas en tiempo real de los datos más recientes. Básicamente, la capa de velocidad es responsable de llenar el "vacío" causado por el retraso de la capa de lotes en proporcionar vistas basadas en los datos más recientes. Las vistas de esta capa pueden no ser tan precisas o completas como las que finalmente produce la capa de lotes, pero están disponibles casi inmediatamente después de que se reciben los datos y pueden reemplazarse cuando las vistas de la capa de lotes para los mismos datos estén disponibles. ^{[3] : 203}

Las tecnologías de procesamiento de flujo que se suelen utilizar en esta capa incluyen Apache Kafka , Amazon Kinesis , Apache Storm , SQLstream, Apache Samza , Apache Spark , Azure Stream Analytics y Apache Flink . La salida se almacena normalmente en bases de datos NoSQL rápidas, ^{[6] [7]} o como un registro de confirmación. ^[8]

La salida de las capas de lote y velocidad se almacena en la capa de servicio, que responde a consultas ad hoc devolviendo vistas precalculadas o creando vistas a partir de los datos procesados.

Entre los ejemplos de tecnologías utilizadas en la capa de servicio se incluyen Apache Druid , Apache Pinot , ClickHouse y Tinybird, que proporcionan una única plataforma para gestionar la salida de ambas capas. ^[9] Entre los almacenes dedicados utilizados en la capa de servicio se incluyen Apache Cassandra , Apache HBase , Azure Cosmos DB , MongoDB , VoltDB o Elasticsearch para la salida de la capa de velocidad, y Elephant DB, Apache Impala , SAP HANA o Apache Hive para la salida de la capa de lotes. ^{[2] : 45  [6]}

Para optimizar el conjunto de datos y mejorar la eficiencia de las consultas, se ejecutan varias técnicas de acumulación y agregación en los datos sin procesar, ^{[9] : 23} mientras que se emplean técnicas de estimación para reducir aún más los costos de cálculo. ^[10] Y si bien se requiere un recálculo completo costoso para la tolerancia a fallas, se pueden agregar selectivamente algoritmos de cálculo incremental para aumentar la eficiencia, y técnicas como el cálculo parcial y las optimizaciones del uso de recursos pueden ayudar de manera efectiva a reducir la latencia. ^{[3] : 93, 287, 293}

Metamarkets, que ofrece análisis para empresas en el ámbito de la publicidad programática, emplea una versión de la arquitectura lambda que utiliza Druid para almacenar y servir tanto los datos transmitidos como los procesados ​​por lotes. ^{[9] : 42}

Para ejecutar análisis en su almacén de datos publicitarios, Yahoo ha adoptado un enfoque similar, utilizando también Apache Storm , Apache Hadoop y Druid . ^{[11] : 9, 16}

El proyecto Netflix Suro tiene rutas de procesamiento independientes para los datos, pero no sigue estrictamente la arquitectura lambda, ya que las rutas pueden estar pensadas para distintos propósitos y no necesariamente para proporcionar el mismo tipo de vistas. ^[12] Sin embargo, la idea general es hacer que los datos de eventos en tiempo real seleccionados estén disponibles para consultas con una latencia muy baja, mientras que todo el conjunto de datos también se procesa a través de una canalización por lotes. Esto último está pensado para aplicaciones que son menos sensibles a la latencia y requieren un tipo de procesamiento de mapeo-reducción.

Las críticas a la arquitectura lambda se han centrado en su complejidad inherente y su influencia limitante. Los procesos por lotes y en tiempo real requieren cada uno una base de código diferente que debe mantenerse sincronizada para que los datos procesados ​​produzcan el mismo resultado en ambas rutas. Sin embargo, intentar abstraer las bases de código en un único marco pone fuera de alcance muchas de las herramientas especializadas de los ecosistemas de procesamiento por lotes y en tiempo real. ^[13]

Jay Kreps introdujo la arquitectura kappa para utilizar un enfoque de streaming puro con una única base de código. ^[13] En una discusión técnica sobre los méritos de emplear un enfoque de streaming puro, se observó que el uso de un marco de streaming flexible como Apache Samza podría proporcionar algunos de los mismos beneficios que el procesamiento por lotes sin la latencia. ^[14] Un marco de streaming de este tipo podría permitir la recopilación y el procesamiento de ventanas de datos arbitrariamente grandes, la adaptación al bloqueo y el manejo del estado.

• Procesamiento de flujo de eventos
• AWS Lambda , un servicio específico de Amazon Web Services, en el que solo se cobra el tiempo de ejecución real

^[1]