Il modo in cui le organizzazioni architetto e gestiscono le loro piattaforme di dati ha subito un cambiamento sismico nel corso degli ultimi dieci anni.Centrano a questa trasformazione è l'adozione di Event Driven Architecture (EDA), un paradigma di progettazione software che cambia fondamentalmente come i flussi di dati tra i sistemi.Quando applicato all'integrazione di Data Lakes e Data Warehouses, EDA sblocca le capacità che erano in precedenza difficili o impossibili da raggiungere con gli approcci tradizionali orientati a lotti.

Comprendere i laghi e i data Warehouse

Prima di immergersi nell'impatto dell'EDA, è essenziale apprezzare i ruoli distinti che Data Lakes e Data Warehouses giocano in uno stack di dati moderno.

Laghi dati

Un Data Lake è un repository centralizzato progettato per memorizzare enormi quantità di dati grezzi e non elaborati nel suo formato nativo. Questo include i dati strutturati da sistemi transazionali, i dati semistrutturati come i log e i file JSON, e i dati non strutturati come immagini e video.

Magazzini di dati

Un Data Warehouse, al contrario, memorizza dati elaborati, strutturati e puliti ottimizzati per l'intelligenza aziendale (BI) e la segnalazione. I Data Warehouse utilizzano un approccio di schema-on-write, dove i dati vengono trasformati e organizzati in modelli dimensionali (ad esempio, schemi stellari) prima del caricamento.

Tradizionalmente, le organizzazioni hanno mantenuto questi due sistemi come silos separati, con pipeline di ETL/ELT in batch che spostano i dati tra loro. Tuttavia, la crescente necessità di analisi in tempo reale e la crescente velocità dei dati hanno esposto i limiti del processo di batch, portando all'aumento di architetture basate su eventi.

Cos'è l'architettura guidata evento?

Event Driven Architecture è un modello di progettazione software in cui i componenti comunicano producendo e consumando [events] – notifiche che qualcosa di interesse è avvenuto. Un evento contiene tipicamente un carico di pagamento che descrive il cambiamento e i metadati come un timestamp e un identificatore unico.

Componenti chiave di EDA

  • Produttori di eventi:[[] Servizi o applicazioni che rilevano un cambiamento di stato e pubblicano un evento. Ad esempio, uno strumento di acquisizione dati di cambiamento (CDC) che pubblica i cambiamenti della riga del database.
  • Event Broker:[] Il middleware che riceve, memorizza e indirizza gli eventi ai consumatori interessati.
  • Consumatori di evento:[] Servizi o processi che si abbonano a tipi specifici di eventi e agiscono su di loro, come l'aggiornamento di un Data Warehouse o l'attivazione di un data pipeline.

L'EDA promuove l'accoppiamento sciolto, il che significa che i produttori e i consumatori possono evolversi in modo indipendente. Questa architettura eccelle negli scenari che richiedono un'elaborazione in tempo reale, una scalabilità elevata e la capacità di gestire diverse fonti di dati.

Il passaggio da Batch all'integrazione dei dati basata su eventi

L'integrazione dei dati tradizionali si basa su lavori periodici di lotto, spesso programmati ogni giorno o ogni ora, per estrarre, trasformare e caricare i dati da fonti nel Data Lake e successivamente nel Data Warehouse. Mentre il processo di batch è semplice e deterministico, introduce la latenza significativa. I dati possono essere di ore prima che raggiunga i sistemi di segnalazione, rendendolo inadatto per decisioni sensibili al tempo come la rilevazione delle frodi o la personalizzazione del cliente.

Quando si verifica un cambiamento in un sistema sorgente (ad esempio, viene posto un nuovo ordine o un utente aggiorna il proprio profilo), un evento viene pubblicato e immediatamente ingerito nel Data Lake. I consumatori a valle, come il Data Warehouse, possono quindi reagire all'evento per aggiornare le viste materializzate o tabelle aggregate in tempi quasi reali.

Tuttavia, passare a modelli organizzativi non è senza complessità, richiede infrastrutture robuste per l'ordinazione di eventi, la semantica di elaborazione di esattamente una volta e la gestione degli schemi.

Impatto dell'ED sull'integrazione dei Data Lake

Il Data Lake, come archivio dati grezzo, è un primo beneficiario naturale dell'ingestione guidata da eventi.

Ingestione dei dati in tempo reale

Invece di aspettare una finestra notturna, i nuovi dati sono disponibili per la querying in pochi secondi. Questo è fondamentale per casi di utilizzo come il monitoraggio del sensore IoT, l'analisi clickstream e i motori di personalizzazione in tempo reale. Strumenti come Apache Kafka Connect e Amazon Kinesis Firehose consentono lo streaming diretto di eventi event-to-Data Lake, memorizzando eventi in formati come Parquet o Avro efficiente.

Flessibilità schema-on-Read

Gli schemi di eventi possono evolversi senza rompere il Data Lake. Poiché il Data Lake memorizza eventi grezzi, i consumatori possono applicare diversi schemi o trasformazioni secondo le necessità. Questo si allinea perfettamente con l'accoppiamento sciolto di EDA — un produttore può cambiare il suo schema di eventi (seguendo le migliori pratiche di versione), e i consumatori a valle possono adattare i registri dello schema indipendentemente (ad esempio, Confluent Schema Registry) aiutano a gestire la compatibilità e prevenire la corruzione silenziosa.

Supporto per la Sourcing e la Mesh di dati

EDA consente di effettuare sourcing eventi, dove il Data Lake diventa il sistema di record per tutti i cambiamenti di stato. Memorizzando ogni evento, le organizzazioni possono ricostruire lo stato attuale in qualsiasi momento o eseguire analisi storiche. Inoltre, EDA facilita un'architettura mesh dati consentendo ai team di dominio di pubblicare i propri dati come eventi, che altre squadre possono consumare tramite il broker eventi.

Impatto dell'ED sull'integrazione dei Data Warehouse

I Data Warehouse sono stati tradizionalmente aggiornati tramite i lavori ETL in batch. EDA lo trasforma consentendo aggiornamenti incrementali, quasi reali, senza sacrificare le prestazioni e la consistenza che i magazzini richiedono.

Modificare l'acquisizione dati e gli aggiornamenti di streaming

Gli strumenti CDC (CDC) possono catturare i cambiamenti del database (inserti, aggiornamenti, cancellazioni) come eventi e pubblicarli a un broker. I consumatori di magazzino applicano queste modifiche alle tabelle corrispondenti utilizzando operazioni di fusione o upsert. Questo mantiene il magazzino sincronizzato continuamente con i sistemi transazionali, supportando la segnalazione up-to-the-minute.

Incrementale Vista materializzata

Le moderne piattaforme di magazzino supportano le viste materializzate che possono essere aggiornate in modo incrementale. Quando un evento indica un cambiamento dei dati sottostanti, il magazzino può ricomputere solo le partizioni interessate. L'EDA può innescare questi rinfreschi automaticamente, riducendo i costi di calcolo e i tempi di aggiornamento rispetto alle ricostruzioni complete. Questo modello è particolarmente potente in combinazione con l'ingestione di streaming nel Data Lake, dove il magazzino legge da tavoli derivati da eventi.

Consistenza e ordinazione dei dati

Mantenere la coerenza in un magazzino organizzato per eventi è difficile perché gli eventi possono arrivare fuori ordine o essere duplicati. Per affrontare questo, i magazzini devono implementare logica di aggiornamento idempotent e utilizzare metadati evento (come timestamp o numeri di sequenza) per ordinare le modifiche correttamente. Molte piattaforme ora supportano le garanzie transazionali quando si elaborano flussi di eventi, permettendo ai magazzini di mantenere una forte coerenza, beneficiando di aggiornamenti a bassa latenza.

Architettura dei dati unificata con EDA: Il modello Lakehouse

La convergenza dei Data Lakes e dei Data Warehouses in un lakehouse[] l'architettura è accelerata dall'integrazione con l'organizzazione di eventi. Una Lakehouse utilizza un Data Lake come unico strato di archiviazione e aggiunge caratteristiche simili a magazzino - operazioni ACID, querying SQL e l'applicazione degli schemi - in cima.

In una Lakehouse gli eventi si riversano direttamente in un tavolo Delta Lake o Iceberg, dove sono immediatamente disponibili sia per i carichi di lavoro di BI che per l'apprendimento automatico. Le viste materiali o gli strati di servizio possono essere aggiornati tramite funzioni di tipo eventi.

Sfide e considerazioni

Mentre i vantaggi dell'EDA per l'integrazione dei data lake e dei magazzini sono significativi, le organizzazioni devono navigare diverse sfide per raggiungere il successo.

Ordinazione e tempo di vivere

Senza un corretto ordinazione, i dati del magazzino possono diventare inconsistenti. Le soluzioni includono l'utilizzo di partizioni di eventi chiave da un identificatore aziendale, sfruttando il tempo dell'evento (non il tempo di elaborazione) per l'ordinazione, e impiegando strutture di dati tolleranti alla latenza come log versioned. Inoltre, gli eventi possono essere conservati indefinitamente nei broker, portando ai costi di archiviazione.

Esattamente-una volta Semantica

La consegna di un'ora all'aria è comune nei broker degli eventi, il che significa che i consumatori possono vedere eventi duplicati. I Data Warehouse richiedono esattamente una volta semantica per evitare il doppio conteggio in metriche. Ciò può essere raggiunto facendo idempotent dei consumatori - utilizzando chiavi di deduplica (ad esempio, ID eventi) e l'esecuzione di upserts - o facendo affidamento su lavabi transazionali che supportano esattamente l'elaborazione di un'once, come Kafnce.

Qualità dei dati e governance dello schema

Gli schemi degli eventi cambiano spesso nel tempo in cui si evolvono i requisiti aziendali. Senza governance, i consumatori a valle possono rompere. Le best practice includono l'utilizzo di un registro di schema con controlli di compatibilità, eventi di versione e l'attuazione di politiche di evoluzione degli schemi (ad esempio, compatibili con il retro, compatibili con il futuro).

Complessità operativa e monitoraggio

Una piattaforma di dati basata su eventi coinvolge molti parti in movimento: produttori, broker, processori di flusso e consumatori. Il monitoraggio della latenza, del throughput e dei tassi di errore in tutta la pipeline è impegnativo. Le organizzazioni dovrebbero investire in strumenti di osservazione che tracciano l'allineamento degli eventi, l'avviso sulla backpressure e fornire dashboard di latenza end-to-end.

Migliori Pratiche per l'implementazione di EDA in Piattaforme di dati

Per massimizzare i vantaggi dell'integrazione guidata dagli eventi, al minimo il rischio, seguire questi modelli provati.

Inizia con Cambiare la Cattura dei Dati

CDC è un punto di ingresso a bassa frizione per EDA. Con lo streaming di dati da sistemi transazionali, è possibile portare immediatamente i dati in tempo reale nel vostro Data Lake e Magazzino senza modificare le applicazioni di origine.

Scegli il broker giusto evento

Apache Kafka è lo standard de facto per lo streaming di eventi ad alta produttività e duraturo. Per i casi di utilizzo più semplici o ambienti cloud-native, considerare Amazon Kinesis, Google Pub/Sub o Azure Event Hubs. Valutare i fattori come scalabilità, requisiti di latenza, integrazione con tooling esistenti e overhead operativo.

Abbracciare i consumatori idemponti

Progettare tutti i consumatori per gestire con grazia gli eventi duplicati. Utilizzare una combinazione di operazioni UPSERT e logica di deduplicazione. Nei magazzini SQL-based, utilizzare le dichiarazioni MERGE con ID eventi. In ambienti data lake, utilizzare idempotency di livello file (ad esempio, la scrittura a percorsi file unici) o registri delle transazioni.

Implementare la governance dello schema

Adottare un Registro di schema (ad esempio, Confluent, AWS Glue Schema Registry) per applicare le regole di compatibilità tra la produzione e il consumo di applicazioni.

Monitorare latenza end-to-End

Impostare metriche per la latenza della produzione di eventi, tempo di consegna di broker e tempo di elaborazione del consumatore. Mirare per un loop di feedback in cui la latenza aumenta gli allarmi di trigger e la scalatura automatica.

Il ruolo delle piattaforme di dati flessibili in un mondo organizzato da eventi

Come le organizzazioni adottano EDA per l'integrazione dei dati, le piattaforme che si collegano a questi flussi di eventi diventano critiche. Una piattaforma di dati flessibile come Directus agisce sia come consumatore di eventi che come produttore, consentendo una connettività senza soluzione di continuità tra broker di eventi, database e sistemi di analisi.

Con l'esposizione di un API unificata in cima a fonti di dati eterogenee, Directus riduce la complessità dell'integrazione degli strumenti EDA con logica aziendale.

Conclusioni

Event Driven Architecture sta modificando in modo fondamentale come i Data Lakes e i Data Warehouses sono integrati e gestiti. Passando da lotto a modelli in tempo reale, organizzativi conducono a una minore latenza, una maggiore scalabilità e sistemi di dati più reattivi. Data Lakes diventa flussi continui di eventi raw, mentre Data Warehouses riceve aggiornamenti incrementali che tengono freschi i dashboard BI. Il modello Lakehouse, abilitato da EDA, unifica questi due mondi in una piattaforma.

Con la giusta architettura e strumenti - tra cui CDC, registri di schemi, consumatori idempotenti e piattaforme flessibili come Directus - le organizzazioni possono sfruttare la piena potenza dell'integrazione dei dati in corso di eventi.

Link esterno:[