Questo è il secondo post della serie tratta dal whitepaper di Mark Madsen: Il Data Lake affogherà il Data Warehouse? Nel primo postMark ha illustrato le differenze tra il data lake e il data warehouse tradizionale, concludendo: "La capacità principale di un data lake, e la fonte di gran parte del suo valore, è la capacità di elaborare dati arbitrari".
In questo post, Mark esamina il nuovo ambiente e i nuovi requisiti:
"Gli ambienti precedenti a Hadoop, compresi gli strumenti di integrazione costruiti per gestire righe e colonne strutturate, limitano il tipo di dati che possono essere elaborati. I requisiti del nuovo ecosistema che tendono a causare i maggiori problemi agli ambienti tradizionali sono la struttura variabile dei dati, i dati in streaming e i set di dati non relazionali.
Strutture dati: JSON è il nuovo CSV
Il formato di interscambio più comune tra le applicazioni non è costituito da connettori di database, ma da file piatti in formato CSV (comma-separated value), spesso scambiati via FTP. Uno dei grandi cambiamenti nella progettazione delle applicazioni negli ultimi dieci anni è stato il passaggio alle API REST con payload formattati in JSON, un formato di dati sempre più comune. Se combinato con l'infrastruttura di streaming, questo cambiamento di progettazione riduce la necessità di integrare i file vecchio stile. JSON e le API stanno diventando i nuovi CSV e FTP.
La maggior parte degli strumenti di integrazione dei dati aziendali è stata costruita presupponendo l'uso di un database relazionale. Ciò funziona bene per i dati provenienti da applicazioni transazionali. Funziona meno bene per i log, i flussi di eventi e i dati creati dall'uomo. Questi non hanno la stessa struttura regolare di righe, colonne e tabelle che i database e gli strumenti di integrazione richiedono. Questi strumenti hanno difficoltà a lavorare con JSON e devono svolgere un lavoro supplementare per elaborarlo e memorizzarlo.
Non è vero il contrario. I più recenti strumenti di integrazione dei dati possono facilmente rappresentare tabelle in JSON, mentre le strutture annidate in JSON sono difficili da rappresentare in tabelle. La rappresentazione flessibile dei dati consente il binding tardivo delle strutture e dei tipi di dati.
Questo è un vantaggio fondamentale di JSON rispetto al binding e alla tipizzazione statica utilizzati dai vecchi strumenti di integrazione dei dati. Un semplice cambiamento di campo a monte può interrompere un flusso di dati nei vecchi strumenti, mentre il nuovo ambiente, più flessibile, può essere in grado di continuare senza interruzioni.
Tuttavia, JSON non è il formato migliore per l'archiviazione dei dati. Ciò significa che sono necessari strumenti per tradurre i dati da JSON a formati di archiviazione più efficienti in Hadoop e da questi formati a JSON per le applicazioni. Gran parte dei dati web e non transazionali vengono oggi inviati come messaggi JSON. Le tecnologie più flessibili di Hadoop e di streaming sono più adatte al trasporto e all'elaborazione di questi dati rispetto agli strumenti convenzionali di integrazione dei dati.
I flussi sono il nuovo batch
Spesso le fonti iniziali di dati in un data lake provengono da flussi di eventi e possono essere elaborati in modo continuo piuttosto che in batch. Di norma, un data warehouse non è un luogo adatto per elaborare dati che devono essere disponibili in meno di qualche minuto. L'architettura è stata progettata per carichi incrementali periodici, non per un flusso continuo di dati. Un data lake dovrebbe supportare diverse velocità, dal tempo quasi reale al batch ad alta latenza.
L'elaborazione in batch è in realtà un sottoinsieme dell'elaborazione in flusso. È facile conservare i dati per un certo periodo di tempo e poi eseguire un lavoro per elaborarli come batch. Non è altrettanto facile prendere un sistema batch e renderlo efficiente nell'elaborazione dei dati un messaggio alla volta. Un motore batch non può tenere il passo con i requisiti dello streaming, ma gli strumenti progettati per elaborare i dati in streaming possono comportarsi come un motore batch.
Lo streaming dei dati implica anche che il volume dei dati può fluttuare, passando da un piccolo rivolo in un'ora a un'inondazione in quella successiva. I modelli di server fissi e la pianificazione della capacità di un'architettura tradizionale non si traducono bene in una scalatura dinamica dei server, in quanto il volume dei messaggi cresce e si riduce. Ciò richiede un ripensamento delle modalità di scalabilità della raccolta e dell'integrazione dei dati".
--
Il documento Will the Data Lake Drown the Data Warehouse? prosegue osservando che "dataset diversi spingono nuovi motori". Nel prossimo post di questa serie, Mark descriverà la nuova architettura del data lake, approfondendo alcuni dei concetti trattati nel whitepaper sul data lake: Come costruire un data lake aziendale: Important Considerations Before You Jump In. Non dimenticate di consultare la presentazione e la registrazione del recente webinar con SnapLogic qui e di saperne di più su SnapLogic per l'integrazione dei big data qui.
