Arquitectures Big Data: Lambda, Kappa i Delta

Introducció

Una arquitectura de Big Data es dissenya per gestionar la ingesta, el processament i l'anàlisi de dades massa grans o complexes per a un sistema tradicional de base de dades. Entenem el concepte d'arquitectura de dades com el disseny dels sistemes que donen suport a les necessitats de dades d'una empresa, facilitant-ne l'evolució i el manteniment.

Totes les arquitectures que dissenyem han de complir les característiques següents:

Escalabilitat: permet augmentar fàcilment les capacitats de processament i emmagatzematge.
Tolerància a fallades: garanteix la disponibilitat del sistema encara que fallin algunes màquines, evitant la pèrdua de dades.
Dades distribuïdes: emmagatzemades entre diferents màquines, evitant el problema d'un únic node central (SPOF).
Processament distribuït: el tractament de les dades es realitza entre diferents màquines per millorar els temps d'execució.
Localitat de la dada: les dades i els processos que les tracten han d'estar a prop, per evitar latències de xarxa.

Principis abans de triar una arquitectura

Abans de conèixer les arquitectures més utilitzades, cal tenir present sempre quin és l'objectiu que ha de complir la solució: és fàcil caure en la sobreenginyeria i muntar una arquitectura amb una amalgama de productes difícils de configurar i mantenir. Alguns principis útils (alineats amb el Well-Architected Framework):

Escollir els components comuns amb cura (emmagatzematge d'objectes, control de versions, eines de monitoratge i orquestració, motors de processament).
"Everything fails, all the time" (Werner Vogels, CTO d'AWS): planificar per a la fallada, tenint en compte RTO i RPO de recuperació.
Definir l'arquitectura per a l'escalabilitat, elàstica en ambdós sentits.
L'arquitectura és viva: sempre ha d'evolucionar amb els canvis tecnològics i de negoci.
Buscar el baix acoblament entre sistemes (pas de missatges, microserveis amb APIs REST).
Facilitar tornar a un punt anterior desfent una decisió errònia (principi de les dues portes de Jeff Bezos).
Prioritzar la seguretat: principi de mínim privilegi i model de responsabilitat compartida.

Processament batch vs streaming

Batch: procés en què intervé un conjunt de dades i que té un inici i un final en el temps (processament per lots), executat sense control directe de l'usuari. És el processament clàssic de bases de dades i Data Warehouses, i el que ha impulsat l'ecosistema Hadoop amb els seus processos ETL.

Streaming: processament que rep i tracta contínuament nova informació a mesura que arriba, sense un final temporal definit. S'utilitzen sistemes basats en cues de missatges.

No tot és temps real

No s'ha de confondre temps real amb immediatesa. Un sistema de temps real és aquell que respon en un període de temps finit, normalment molt petit, però no necessàriament instantani.

Arquitectura Lambda

Representada per la lletra grega λ, va aparèixer el 2012 i s'atribueix a Nathan Marz, arran de la seva experiència en sistemes de tractament de dades distribuïdes a BackType i Twitter. El seu objectiu era muntar un sistema robust i tolerant a fallades (humanes i de maquinari), linealment escalable, que permetés escriptures i lectures amb baixa latència.

Totes les dades que arriben al sistema segueixen dos camins —un de lent (capa batch) i un de ràpid (capa streaming)— que conflueixen a la capa de consultes:

flowchart LR
    F[Font de dades] --> BL["Capa Batch\n(historic, precisa)"]
    F --> SL["Capa Speed/Streaming\n(increments, baixa latencia)"]
    BL --> SV[Capa Serving]
    SL --> SV
    SV --> Q[Consultes]

Capa batch: gestiona les dades històriques i recalcula els resultats. Rep totes les dades en cru, les emmagatzema de forma immutable (les dades prèvies mai se sobreescriuen) i en recalcula els resultats (Batch Views) iterant sobre tot el conjunt combinat. Produeix els resultats més precisos, a costa d'una latència alta.
Capa de streaming/speed: ofereix resultats amb latència molt baixa, propera al temps real, aplicant modificacions incrementals sobre els resultats de la capa batch (Real-time Views), a costa de perdre una mica de precisió.
Capa de serving: indexa les Batch Views per a permetre consultes amb temps de resposta molt baixos, combinant-les amb les vistes en temps real per a construir la resposta final.

Temperatura de les dades: segons la freqüència d'accés, l'emmagatzematge es divideix en calent (SSD/RAM, molt freqüent, cost d'emmagatzematge alt però de recuperació baix — p. ex. paginació de resultats), temperat (S3 poc freqüent, cost mitjà — p. ex. generació de nòmines) i fred (HDD/cinta/Glacier, molt poc freqüent, cost d'emmagatzematge baix però de recuperació alt — p. ex. còpies de seguretat).

Pas a pas

La nova informació s'envia tant a la capa batch com a la capa de streaming.
La capa batch gestiona la informació en cru: les dades noves s'afegeixen a les existents i, mitjançant un procés batch, es generen les Batch Views.
La capa de serving indexa les Batch Views perquè es puguin consultar amb temps de resposta molt baixos.
La capa de streaming compensa l'alta latència de la capa batch, tenint en compte només les dades noves (increments des de l'últim procés batch).
Es combinen els resultats de les Batch Views i de les Real-time Views per a construir la resposta a les consultes.

Arquitectura Kappa

El terme el va introduir Jay Kreps el 2014 a l'article Questioning the Lambda Architecture, assenyalant-hi el principal punt feble de Lambda: la seva complexitat, en duplicar la lògica de computació i la gestió de l'arquitectura en dos camins diferenciats.

La proposta de Kreps és que totes les dades flueixin per un únic camí, eliminant la capa batch i deixant només la capa de streaming (sense principi ni final temporal), substituint les fonts de dades per cues de missatges (per exemple, Apache Kafka):

flowchart LR
    F[Font de dades] --> KAF["Kafka\n(log unificat, immutable)"]
    KAF --> SP["Motor de streaming\n(Spark Streaming, Flink...)"]
    SP --> SV[Capa Serving]
    SV --> Q[Consultes]
    KAF --> HIST[(Historial\nreprocessable)]

Els quatre pilars de Kappa:

Tot és un stream: les operacions batch són un subconjunt de les operacions de streaming.
Les dades de partida no es modifiquen: s'emmagatzemen sense transformar (immutables); les vistes se'n deriven i es poden recalcular.
Només hi ha un flux de processament: es redueix considerablement el codi, el manteniment i l'actualització.
Es pot rellançar un processament: modificant un processament concret i la seva configuració per a variar els resultats, partint de les mateixes dades d'entrada.

Com a requisit previ, cal garantir que els esdeveniments es llegeixen i s'emmagatzemen en l'ordre en què s'han generat.

Arquitectura Delta

L'arquitectura Delta és, per a molts, el pas següent al voltant de les dades, i es basa en el concepte de Delta Lake: un marc d'emmagatzematge de codi obert que aporta compatibilitat amb transaccions ACID i aplicació d'esquemes a llacs de dades impulsats per Apache Spark, permetent construir una arquitectura "Data Lakehouse" amb dades estructurades, semiestructurades i no estructurades.

Delta Lake amplia els fitxers Parquet amb un registre de transaccions basat en fitxers (_delta_log) per a transaccions ACID i gestió escalable de metadades. La separació entre capes de l'arquitectura Delta és mínima comparada amb Lambda, per la qual cosa no cal tractar les dades de forma diferent segons el seu origen: tot el processament, des de Bronze (dades sense processar) fins a Silver (filtrades) i Gold (llestes per a l'anàlisi), es produeix dins de Delta Lake.

Promeses de l'arquitectura Delta:

Redueix costos: menys dades a moure, menys temps de processament, menys reexecucions per errors.
Menys codi: les transaccions ACID eviten codi manual per a garantir la coherència de les dades.
Indexació millorada: filtres de Bloom que milloren el rendiment de les consultes.
Una font de dades: evita la còpia de dades entre magatzems, que genera problemes de coherència i control de versions.
Afegir noves fonts sense dificultat: l'evolució de l'esquema fa senzill agregar noves fonts o canviar formats existents.

Arquitectura per capes

Una altra manera de dissenyar una arquitectura Big Data és separar les diferents fases del cicle de vida de la dada en capes diferenciades, donant suport tant a processament batch com streaming:

Capa d'ingesta: recull les dades de fonts diverses, categoritzant-les i prioritzant-les.
Capa de col·lecció: transporta les dades des de la ingesta cap a la resta del pipeline.
Capa de processament: processa les dades (batch, streaming o models híbrids) i decideix cap a quina capa es dirigeixen.
Capa d'emmagatzematge: decideix on emmagatzemar eficientment el volum de dades (típicament un sistema d'arxius distribuït, donant lloc al Data Lake).
Capa de consulta: processament analític per a obtenir valor de les dades.
Capa de visualització (o presentació): amb la qual interactuen els usuaris finals.

Tecnologies associades

La ingesta cap a arquitectures Lambda i Kappa es realitza sovint amb un sistema de missatgeria publicador/subscriptor com Apache Kafka i/o un servei de flux de dades com Apache NiFi. L'emmagatzematge es fa amb HDFS o S3. En una arquitectura Lambda, la capa batch pot generar models amb MapReduce o consultes Hive, mentre que la capa streaming (a Lambda i Kappa) pot usar Apache Storm, Apache Samza o Spark Streaming. De manera alternativa, Apache Spark es pot usar com a plataforma comuna per a les capes batch i streaming de Lambda: es codifica una vegada i es comparteix en ambdues capes, la qual cosa explica la seva àmplia adopció.

La capa de serving es pot implementar amb una base de dades NoSQL (Apache HBase, MongoDB, Redis, DynamoDB) o motors de consulta com Apache Drill o Presto.

Informe Matt Turck

Cada any, Matt Turck publica el MAD (Machine Learning, AI and Data) Landscape, un mapa de referència de l'amalgama d'eines i tecnologies del sector. És recomanable consultar-ne l'edició més recent per situar cada eina d'aquest mòdul dins de l'ecosistema global.

El principi SCV

En la sessió de bases de dades no relacionals es va estudiar el Teorema de CAP (Consistència, Disponibilitat, Tolerància a la Partició), centrat en l'emmagatzematge de dades distribuïdes. Si ens centrem en el processament distribuït de les dades, el principi anàleg és el principi SCV: un sistema de processament distribuït només pot suportar, com a màxim, 2 de les 3 característiques següents:

Velocitat (Speed): temps que triguen a processar-se les dades des que arriben al sistema analític (sense comptar la captura). Més alta en un sistema d'analítica en temps real que en un de batch.
Consistència (Consistency): precisió dels resultats de l'analítica, segons si s'usen totes les dades disponibles (alta precisió) o tècniques de mostreig (menor precisió, menor temps).
Volum (Volume): quantitat de dades que es poden processar — sempre alta en entorns Big Data.

graph TD
    SCV["Principi SCV"] --> SC["S + C -> NO V\n(alt volum augmenta el temps de resposta)"]
    SCV --> CV["C + V -> NO S\n(no es pot processar a alta velocitat)"]
    SCV --> SV2["S + V -> NO C\n(cal mostreig, perdent precisio)"]

Si es requereixen velocitat (S) i consistència (C), no es pot processar un alt volum (V): augmentaria el temps de resposta.
Si es requereixen consistència (C) i un alt volum (V), no és possible fer-ho a alta velocitat (S).
Si es requereix processar un alt volum (V) a alta velocitat (S), calen tècniques de mostreig, produint un resultat no consistent (C).

Casos d'ús: Lambda o Kappa?

Depèn. Lambda és més versàtil i cobreix més casos, incloent-hi processament en temps real. Una pregunta clau: l'anàlisi que es fa a les capes batch i streaming és el mateix algorisme? Si és així, Kappa és l'opció més encertada. Si cal accedir a tot el conjunt de dades sense penalitzar el rendiment, o si els algorismes batch i streaming generen resultats molt diferents (per exemple, en Machine Learning, on el batch es pot optimitzar accedint al dataset històric complet), Lambda pot ser més apropiada.

Casos reals:

Lambda: un sistema que recomana pel·lícules segons els gustos dels usuaris — una capa batch entrena el model i en millora les prediccions, i una capa streaming s'encarrega de les valoracions en temps real.
Kappa: un sistema de geolocalització d'usuaris prop d'antenes de telefonia mòbil — cada aproximació genera un esdeveniment que la capa de streaming processa per a actualitzar un mapa de desplaçament.

Bones pràctiques

Ingesta: avaluar els tipus de fonts de dades; sovint cal combinar diverses eines per a cobrir tot el ventall.
Processament: analitzar si el sistema ha de ser streaming o batch (o micro-batch, que sovint es descriu col·loquialment com a "streaming").
Monitoratge: amb multitud de tecnologies durant la ingesta, cal una eina per a controlar, monitoritzar i gestionar l'arquitectura (vegeu Monitorització).

Decisions clau a l'hora de triar l'arquitectura: enfocar bé els casos d'ús (volum, varietat, velocitat?), definir si cal suport streaming, avaluar l'heterogeneïtat de les fonts de dades, i buscar sempre unificar-les en un únic lloc que sigui la font veraç de les dades.

Miniactivitat — AC5075/01/02

Per a un sistema de detecció de frau bancari en temps real, justifica si triaries una arquitectura Lambda, Kappa o Delta. Argumenta la resposta aplicant el principi SCV: quina de les tres característiques (velocitat, consistència, volum) estàs disposat a sacrificar i per què.

RA1 | Mòdul 5075 Big Data Aplicat | Institut Sa Palomera (Blanes) | Curs IABD 2026-2027