Arquitectura Lambda
L'Arquitectura Lambda (LA) és una arquitectura de processament de grans quantitats de dades (és a dir, Dades massives) que utilitza els mètodes de Batch processing i Processament de fluxos. Els seus objectius són reduir la latència, augmentar la tolerància a errors, millorar la escalabilitat i tenir una coherència de les dades.
L'Arquitectura Lambda depèn d'un model de dades amb append-only, font de dades immutable que serveix com a sistema de registre.[1] Només es pot inserir noves dades i processar-les sense sobreescriure les existents. L'estat es determina a partir de l'ordenació natural de les dades basada en el temps.
Història modifica
L'Arquitectura Lambda va ser introduïda per primera vegada per Nathan Marz. La va idear per crear una arquitectura de processament de dades genèrica, escalable i que pogués tolerar els errors, basada en la seva experiència com a treballador en sistema de processament de dades distribuïdes a BackType i Twitter. La necessitat de crear aquesta arquitectura va ser deguda al gran creixement de les grans dades i la realització d'anàlisis en temps real.
Estructura modifica
.png)
L'Arquitectura Lambda es compon de tres capes:
Batch layer modifica
Aquesta capa prediu els resultats mitjançant un sistema de processament distribuït i gestiona el conjunt de dades mestre. Analitza totes les dades alhora i corregeix els error recalculant-los tenint en compte el conjunt de dades complert. A continuació actualitza les visualitzacions ja existents. Normalment, la sortida s'emmagatzema en una base de dades de només lectura.
Apache Hadoop és un entorn de treball que s'utilitza sovint per inserir les dades i emmagatzemar-les d'una manera rendible. En el 2014, Apache Hadoop va ser líder de processament per batch.[2] Més tard, també es van utilitzar altres entorns com Snowflake, Redshift, Synapse i BigQuery.
Speed layer modifica
Les dades que lliuren a batch layer també es transmeten a aquesta capa. El speed layer processa fluxos de dades en temps real. El seu objectiu és minimitzar la latència proporcionant visualitzacions en temps real de les dades més recents. És a dir, només tracta dades recents. S'encarrega d'omplir el "buit" causat pel retard de batch layer a l'hora de proporcionar visualitzacions. Les visualitzacions proporcionades no són tan precises ni completes com les que finalment produeix batch layer, però aquestes es substitueixen un cop són produïdes les de batch layer. Normalment, la sortida s'emmagatzema en bases de dades NoSQL ràpides.
Els entorns de treball que s'acostumen a utilitzar en aquesta capa són Apache Kafka, Amazon Kinesis, Apache Storm, SQLstream, Apache Samza, Apache Spark i Azure Stream Analytics.
Serving layer modifica
Serving layer respon a les consultes de només lectura dels usuaris, proporcionant respostes. Combina els resultats, sortides, de batch i speed layer i crea visualitzacions a partir de les dades processades. S'encarrega d'indexà les visualitzacions perquè es puguin consultar amb una latència baixa i en temps real.
Optimitzacions modifica
Per tal de poder optimitzar les dades i millorar l'eficiència de la query, s'utilitzen diferents tècniques d'agregació i fusió de dades encara no treballades, alhora que es realitzen tècniques d'estimació per reduir els costos de càlculs.[3] A més, també es poden afegir algorismes de càlcul incremental per augmentar l'eficiència, i fer càlculs parcials i optimitzar l'ús de recursos poden ajudar a reduir la latència.
Desavantatge de l'Arquitectura Lambda modifica
Tot i ser una arquitectura amb molt beneficis, també té alguns desavantatges que és important tenir-los presents. El més important és el cost. Com que el conjunt de dades és només append-only i no s'eliminen dades en el batch layer, necessàriament aquesta capa haurà d'expandir-se en funció del temps. De la mateixa manera passarà amb el cost.[4]
Normalment, el batch i speed layer en guarden en dues bases de codi separades. Fet que pot dificultar la depuració.[5]
Diferències entre l'Arquitectura Lambda i l'Arquitectura Kappa modifica
Com s'ha dit anteriorment, un desavatatge considerable de l'Arquitectura Lambda és mantenir dues bases de codi separades per gestionar un processament similar. L'Arquitectura Kappa pretén abordar aquesta preocupació eliminant completament el batch layer. En canvi, el funcionament del speed layer de LA es conserven a AK, tot proporcionant les visualitzacions de baixa latència amb càlculs aproximats.
Aquesta diferència en l'Arquitectura Kappa permet mantenir un únic sistema per generar visualitzacions, la qual cosa simplifica considerablement la base de codi del sistema.[4]
El problema de l'Arquitectura Kappa és que no sempre es pot emmagatzemar totes les dades necessaries.[6]
A l'hora de decidir en les arquitectures, s'ha de tenir en compte diferents coses. S'haurà d'escollir l'Arquitectura Lambda, si es necessita una arquitectura capaç d'actualitzar constantment el conjunt de dades, capaç de desenvolupar models d'aprenentatge automàtics a partir del les dades i que sigui més fiable. D'altra banda, si es vol una arquitectura amb un maquinari menys costós, s'haurà de considerar l'Arquitectura Kappa.[7]
Referències modifica
- ↑ «A real-time architecture using Hadoop and Storm». [Consulta: 15 gener 2023].
- ↑ «Hadoop Sector will Have Annual Growth of 58% for 2013-2020 – Cloud Times» (en anglès americà). [Consulta: 15 gener 2023].
- ↑ «The art of Approximating Distributions: Histograms and Quantiles at Scale» (en anglès americà). [Consulta: 12 gener 2023].
- ↑ 4,0 4,1 «An Overview of Lambda Architecture - DZone» (en anglès). [Consulta: 16 gener 2023].
- ↑ «What Is Lambda Architecture» (en anglès americà). [Consulta: 16 gener 2023].
- ↑ «Lambda Architecture» (en anglès americà). [Consulta: 16 gener 2023].
- ↑ Kanjilal, Joydip. «An Introduction to The Lambda Architecture» (en anglès americà), 26-07-2021. [Consulta: 16 gener 2023].