Da Lambda a Kappa: guida alle architetture per big data in tempo reale

Da Lambda a Kappa: guida alle architetture per big data in tempo reale

Quando si tratta di scegliere un'architettura per big data in tempo reale, oggi le opzioni sono più di una. Il menu offre molto di più della sola opzione Lambda e in questa serie di blog prenderò in esame un paio di queste possibilità, confrontandole sulla base di casi d'uso rilevanti. Come dobbiamo dunque procedere quando ci troviamo a scegliere un'architettura per i nostri progetti in tempo reale? Vediamo subito.

Requisiti di elaborazione dei dati in tempo reale

Prima di affrontare le varie architetture, analizziamo alcuni dei requisiti dei sistemi di elaborazione dei dati in tempo reale in scenari in cui vengono utilizzati i big data.

Il più ovvio dei requisiti ha a che fare con la natura dei dati stessi, che sono sempre in movimento. In altre parole, i dati sono un flusso ininterrotto e illimitato. Ciò che veramente importa è il momento in cui si analizzano i dati. Se cercate risposte da istantanee correnti dei dati o se avete particolari requisiti a bassa latenza, probabilmente vi trovate in uno scenario di dati in tempo reale.

Inoltre, spesso ci sono scadenze aziendali da rispettare. Dopo tutto, se il mancato rispetto delle scadenze per l'analisi in tempo reale non comportasse conseguenze, i processi potrebbero essere eseguiti in batch. Tali conseguenze possono andare dalla completa indisponibilità al semplice deterioramento del servizio.

Dal momento che parliamo di big data, siamo autorizzati a spingerci oltre i limiti anche in termini di volume, velocità e possibilmente varietà dei dati.

L'elaborazione dei dati in tempo reale spesso richiede caratteristiche come scalabilità, tolleranza d'errore, prevedibilità, resilienza rispetto alle imperfezioni del flusso ed estensibilità.

Nuove architetture per una nuova era dei dati

Per rispondere a questa esigenza, sono nate nuove architetture. Come si dice, la necessità aguzza l'ingegno.

L'architettura Lambda, attribuita a Nathan Marz, è una delle più comunemente utilizzate oggigiorno per l'elaborazione dei dati in tempo reale. È progettata per gestire letture e aggiornamenti a bassa latenza applicando scalabilità lineare e tolleranza d'errore.

Il flusso di dati che entra nel sistema viene immesso in un doppio livello, batch e velocità.

Nel livello batch vengono memorizzati i dati grezzi a mano a mano che arrivano e vengono elaborate le viste batch per il consumo. Naturalmente, i processi in batch vengono eseguiti a intervalli e durano a lungo. L'ambito di applicazione dei dati può andare da poche ore ad anni.

Il livello velocità viene usato per elaborare viste in tempo reale che vanno a completare le viste batch.

Per una qualsiasi query è possibile ottenere un quadro completo recuperando dati sia dalle viste batch che dalle viste in tempo reale. Le query vengono risolte utilizzando i dati migliori di entrambi i livelli. Le viste batch possono essere elaborate utilizzando regole più complesse e onerose e consentono di ottenere una qualità dei dati migliore, con minori distorsioni, mentre le viste in tempo reale offrono l'accesso momentaneo ai dati più recenti. Con il passare del tempo, i dati in tempo reale scadono e vengono sostituiti dai dati delle viste batch.

Un ulteriore vantaggio di questa architettura è che consente di riprodurre di nuovo gli stessi dati in arrivo e di creare nuove viste, nel caso il codice o le formule subiscano modifiche.

Il più grande svantaggio di questa architettura è la necessità di gestire due sistemi distinti (e complessi) per generare il livello batch e il livello velocità. Fortunatamente, con Spark Streaming (livello astrazione) o Talend (generatore di codice Streaming e Spark Batch), questo aspetto è stato notevolmente migliorato… anche se il carico operativo rimane ingente.

A questo punto, possiamo passare all'architettura Kappa.

L'architettura Kappa è stata descritta per la prima volta da Jay Kreps. Si concentra sull'esclusiva elaborazione dei dati come flusso. Non va a sostituire l'architettura Lambda, a meno che lo specifico caso d'uso non lo consenta. In questo tipo di architettura, i dati in ingresso vengono convogliati attraverso un livello in tempo reale e i relativi risultati vengono esposti nel livello di servizio per rispondere alle query.

L'idea è quella di gestire l'elaborazione dei dati in tempo reale e la continua rielaborazione in un unico motore di elaborazione del flusso. Proprio così, la rielaborazione viene eseguita a partire dal flusso di dati. Questo richiede che il flusso di dati in ingresso possa essere riprodotto di nuovo (molto velocemente), nella sua interezza o a partire da un punto specifico. Se intervengono delle modifiche al codice, una seconda elaborazione del flusso procede a una nuova riproduzione di tutti i dati precedenti tramite l'ultimo motore in tempo reale e alla sostituzione dei dati memorizzati nel livello di servizio.

Questa architettura punta alla semplificazione mantenendo una sola base di codice anziché gestirne una per ciascun livello, batch e velocità, come nell'architettura Lambda. Inoltre, le query devono effettuare le ricerche in una sola posizione di servizio, anziché accedere alle viste batch e velocità.

Lo svantaggio di questa architettura riguarda principalmente la necessità di dover elaborare i dati in un flusso, il che comporta la gestione di eventi duplicati, eventi con riferimenti incrociati o l'esecuzione di operazioni di ordinamento che in genere risultano più semplici nell'elaborazione in batch.

Non esiste un approccio ideale per tutti

Per molti scenari in tempo reale l'architettura Lambda è perfetta. Lo stesso non può dirsi per l'architettura Kappa. Se l'analisi in batch e in streaming sono allo stesso livello, l'architettura Kappa è probabilmente la soluzione migliore. In alcuni casi, tuttavia, l'accesso a un set completo di dati in una vista batch può portare a un livello di ottimizzazione che rende l'opzione Lambda più performante e forse anche più semplice da implementare.

Vi sono poi alcune situazioni estremamente complesse in cui gli algoritmi batch e di streaming producono risultati molto differenti (utilizzando modelli di apprendimento automatico, sistemi avanzati o operazioni per natura molto costose che devono essere eseguite diversamente in tempo reale) che richiedono l'uso dell'opzione Lambda.

Ecco dunque spiegate le due architetture di elaborazione dei dati in tempo reale più popolari. Nei prossimi articoli di questa serie di blog analizzeremo più nel dettaglio ciascuna di esse e affronteremo alcuni casi d'uso concreti, così come le tecnologie che spesso vengono utilizzate in queste architetture.

Riferimenti:

"How to beat the CAP theorem" di Nathan Marz
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

"Questioning the Lambda Architecture" di Jay Kreps
https://www.oreilly.com/ideas/questioning-the-lambda-architecture

"Big Data" di Nathan Marz, James Warren
https://www.manning.com/books/big-data

Partecipa alla discussione

0 Comments

Scrivi una risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *