{"id":92837,"date":"2019-09-23T09:00:02","date_gmt":"2019-09-23T07:00:02","guid":{"rendered":"https:\/\/www.emagister.com\/blog\/?p=92837"},"modified":"2019-10-07T11:00:19","modified_gmt":"2019-10-07T09:00:19","slug":"arquitecturas-hibridas-lambda-kappa","status":"publish","type":"post","link":"https:\/\/www.emagister.com\/blog\/arquitecturas-hibridas-lambda-kappa\/","title":{"rendered":"Arquitecturas h\u00edbridas: Lambda y Kappa"},"content":{"rendered":"

Una vez que hemos resuelto los retos, vamos a analizar dos tipos de arquitecturas para procesamiento en tiempo real. Es importante mencionar que se construyen, generalmente, con componentes distribuidos desarrollados sobre la JVM\u00a0<\/em>y, por tanto, son soft real time systems<\/em>. La principal diferencia entre ambas son los flujos de tratamiento de datos que intervienen y el paradigma de programaci\u00f3n predominante. En su concepci\u00f3n juega un papel muy importante la madurez de las tecnolog\u00edas existentes en cada momento.<\/p>\n

Arquitectura Lambda<\/em><\/h3>\n

En su art\u00edculo\u00a0\u201cHow to beat the CAP theorem<\/em>\u201d<\/em> (2011) [1], Nathan Marz\u00a0<\/em>presenta la Arquitectura Lambda<\/em>. Una arquitectura capaz de obtener resultados en tiempo real en sistemas con ingesta continua de datos y tolerante a fallos, tanto humanos como de hardware<\/em>. Adem\u00e1s, pretende prevenir la complejidad que produce el teorema del\u00a0CAP<\/em> en los Sistemas Distribuidos y, con esta prevenci\u00f3n, \u201cvencerlo\u201d. Para Nathan<\/em>, un sistema de datos se define de forma muy sencilla:<\/p>\n

Consulta= Funci\u00f3n (todos los datos)<\/em><\/p>\n

El resultado de esta consulta es la combinaci\u00f3n de los datos procesados por los paradigmas streaming<\/em> y batch<\/em>. Aunque existen sistemas para realizar este tipo de consultas contra PetaBytes<\/em> de datos, son excesivamente costosos en recursos y no son el enfoque m\u00e1s eficaz. Para resolverlas de una forma m\u00e1s eficiente introduce la idea de calcular previamente los resultados con un conjunto de vistas y consultar estas vistas. La arquitectura est\u00e1 dividida en tres partes: batch layer<\/em> (capa de\u00a0batch processing<\/em>),\u00a0serving layer<\/em> (capa de consulta) y\u00a0speed layer\u00a0<\/em>(capa de stream processing<\/em>). El funcionamiento es el siguiente:<\/p>\n

\"\"
Arquitectura Lambda (tomado de: lambda-architecture.net)<\/figcaption><\/figure>\n
    \n
  1. Los nuevos datos ingestados por el sistema se env\u00edan tanto a la batch layer<\/em> como a la speed layer\u00a0<\/em>para su procesamiento. Para este cometido suele usarse Kafka<\/em>.<\/li>\n
  2. Batch layer<\/em>. Gestiona el conjunto de datos maestros en bruto y a\u00f1ade los nuevos datos a los ya existentes, que no se modifican. Mantiene, por tanto, una copia inmutable y creciente de todos los datos ingestados por el sistema. Al conjunto total de datos del sistema les aplica procesamiento batch<\/em> en un proceso que puede llevar horas. El resultado son las batch views<\/em>, que se usar\u00e1n en la serving layer<\/em> para ofrecer la informaci\u00f3n ya transformada al exterior. Estas vistas precalculadas se actualizan con cada iteraci\u00f3n del procesamiento batch<\/em>. La informaci\u00f3n suele almacenarse en HDFS<\/em> y procesarse con Hadoop<\/em>\/Spark<\/em>.<\/li>\n
  3. Serving layer<\/em>. Su misi\u00f3n es indexar las batch views\u00a0<\/em>(est\u00e1ticas) y exponerlas de forma que puedan ser consultadas de forma \u00f3ptima y en tiempo real. En esta capa suele haber una base de datos distribuida que responda a unas necesidades de escrituras c\u00edclicas y de lecturas aleatorias. Aparecen bases de datos como\u00a0HBase<\/em> y Cassandra<\/em>.<\/li>\n
  4. Speed Layer<\/em>. La batch layer<\/em> no soluciona totalmente las necesidades de procesamiento. La latencia que generan las batch views<\/em> hace que en el momento en el que finaliza su ejecuci\u00f3n, el sistema ya tiene nuevos datos que no est\u00e1n representados en los resultados de la serving layer<\/em> y, por tanto, las respuestas del sistema ante las consultas est\u00e1n desactualizadas. El an\u00e1lisis de la informaci\u00f3n que no est\u00e1 representada todav\u00eda en la serving layer\u00a0<\/em>es la misi\u00f3n de la speed layer<\/em>. Para conseguir tiempos de respuesta instant\u00e1neos aplica algoritmos r\u00e1pidos e incrementales a los datos recientes. Los resultados de estos c\u00e1lculos, stream views<\/em>, se actualizan en tiempo real a medida que se reciben nuevos datos. Una vez que los datos han sido procesados por la batch layer<\/em>, y por tanto los resultados est\u00e1n disponibles en la serving layer<\/em>, esa parte de la informaci\u00f3n de la stream view<\/em> ya no es necesaria y se puede eliminar. Esta caracter\u00edstica dota a la arquitectura de tolerancia a fallos funcionales de la speed layer<\/em> (la m\u00e1s compleja), descartando el estado de la stream view<\/em> y procesando todos los datos en la batch layer<\/em>. Suelen aparecer tecnolog\u00edas como Storm<\/em>, Spark Streaming<\/em>, Flink<\/em>, Redis<\/em> y Cassandra<\/em>.<\/li>\n
  5. Finalmente, la respuesta a las consultas realizadas al sistema se construye combinando los resultados de las batch views<\/em> y de las stream views<\/em>. Esta combinaci\u00f3n es espec\u00edfica de cada sistema que implementa la arquitectura. Por ejemplo, se pueden almacenar las vistas en dos bases de datos: una optimizada para el tiempo real y otra optimizada para las actualizaciones batch<\/em>. Ambas compartir\u00edan un registro \u00fanico de la informaci\u00f3n (y meta informaci\u00f3n) que gestionar\u00eda las respuestas del sistema a las consultas. La l\u00f3gica para combinar los datos de ambas vistas depende de las operaciones que implican las funciones a calcular para obtener las respuestas. Si las operaciones cumplen la propiedad asociativa (c\u00e1lculos como la suma, el m\u00e1ximo, filtros o agrupaciones), la capa de combinaci\u00f3n se limita a ejecutar las funciones sobre los datos agregados. Si las funciones requieren operaciones m\u00e1s complejas, debe utilizarse la meta informaci\u00f3n generada en los procesamientos anteriores.\n

    \"\"
    Actualizaci\u00f3n serving layer<\/em> y speed layer<\/em><\/figcaption><\/figure><\/li>\n<\/ol>\n

    La Arquitectura Lambda<\/em> incide en dos conceptos fundamentales en los sistemas de procesamiento intensivo de datos en tiempo real: la inmutabilidad de los datos hist\u00f3ricos y la capacidad de reprocesar los datos almacenados en el sistema. Es b\u00e1sico que el sistema siempre genere sus resultados a partir del dato en bruto y que tenga la capacidad de recomputar la informaci\u00f3n existente. La necesidad de reprocesar los datos puede ser motivada por una optimizaci\u00f3n del proceso, solucionar un fallo o simplemente porque cambien las consultas al sistema y se necesiten nuevos c\u00e1lculos. Como principal desventaja presenta el problema de administrar y monitorizar dos sistemas distribuidos complejos: batch<\/em> y streaming<\/em>. Obliga a mantener la l\u00f3gica de la aplicaci\u00f3n en dos paradigmas de programaci\u00f3n diferentes y divergentes.<\/p>\n

    Arquitectura Kappa<\/em><\/h3>\n

    El t\u00e9rmino Arquitectura Kappa<\/em> fue introducido en 2014 por Jay Kreps<\/em> en su art\u00edculo \u201cQuestioning the Lambda Architecture<\/em>\u201d [2]. En este art\u00edculo, Jay<\/em> comenta sus pensamientos sobre la Arquitectura Lambda<\/em>, con sus pros y sus contras, y describe su experiencia implementando la arquitectura de procesamiento en tiempo real de LinkedIn<\/em>. La visi\u00f3n de Jay<\/em> parte de una premisa: el paradigma principal de procesamiento es el streaming<\/em> y las operaciones batch<\/em>, son un subconjunto de las operaciones de streaming<\/em>. Recordemos que un flujo de datos en stream<\/em> no tiene ni un comienzo ni un fin desde un punto de vista temporal\u00a0(unbounded)<\/em>. Es necesario acotarlo para obtener un flujo batch (bounded)<\/em>. Apoy\u00e1ndose en el paralelismo de los sistemas de procesamiento en streaming<\/em>, propone una arquitectura en cuatro pasos:<\/p>\n

      \n
    1. Kafka<\/em> o una aplicaci\u00f3n similar para la ingesta de datos y el almacenamiento de los datos susceptibles de ser reprocesados. Se pueden volcar los datos a HDFS<\/em> (disco) si hay limitaciones de memoria.<\/li>\n
    2. Un flujo de procesamiento en streaming<\/em> cuyos resultados se almacenan en una tabla asociada. La aplicaci\u00f3n cliente realiza consultas a esta tabla. Si es necesario reprocesar los datos, se inicia un segundo flujo de procesamiento para obtener una nueva tabla con los datos recomputados.<\/li>\n
    3. Cuando la nueva tabla est\u00e1 lista, la aplicaci\u00f3n empieza a leer de dicha tabla, que es alimentada por el segundo flujo de procesamiento.<\/li>\n
    4. Se eliminan tanto el primer flujo de procesamiento como su tabla asociada.<\/li>\n<\/ol>\n
      \"\"
      Arquitectura Kappa (tomado de: oreilly.com\/ideas\/questioning-the-lambda-architecture)<\/figcaption><\/figure>\n

      Esta visi\u00f3n subsana los posibles puntos \u201cd\u00e9biles\u201d de la Arquitectura Lambda<\/em> y la simplifica eliminando la capa batch<\/em>. Podemos afirmar que sus tres pilares principales son los siguientes:<\/p>\n