Articolo liberamente tradotto in italiano dal blog di MongoDB: Unlocking Operational Intelligence from the Data Lake: Part 1 - The Rise of the Data Lake
Introduzione
I data lake basati su Hadoop permettono alle aziende e alle pubbliche amministrazioni di catturare e analizzare efficientemente volumi di dati senza precedenti, generati dalle loro iniziative di trasformazione digitale. Ma senza essere in grado di esporre questi dati alle applicazioni operative, gli utenti hanno difficoltà a massimizzare i ricavi dai loro investimenti su Hadoop. Più tempo si impiega ad elaborare gli insights dei processi operativi, meno vale quello stesso insight, perdendo in competitività. In questi 3 articoli parleremo di:
Sul sito di MongoDB è disponibile il white paper sull'argomento (in inglese).
L'ascesa dei data lake
Una cosa che sicuramente non manca al giorno d'oggi nelle aziende sono i dati. Dagli stream di dati letti dai sensori, ai dati social, ai log, le app mobile e molto altro. Gli analisti stimano che i volumi di dati aumenteranno del 40% per anno, di cui il 90% sarà composto da dati non strutturati. I nuovi insights scoperti raccogliendo e analizzando questi dati promettono di portare vantaggi competitivi e risparmi in efficienza. Inoltre, i tradizionali Data Warehouse Enterprise (EDW) iniziano a soffrire per l'aumento del carico di lavoro, sopraffatti dal volume e dalla varietà di dati che arrivano e dall'essere poi in grado di archiviarli in modo efficiente. Il risultato è che molte aziende sono passate ad Hadoop come repository centralizzata per questi nuovi dati, creando ciò che molti chiamano un data lake.
Con la sua abilità di archiviare dati di qualunque struttura senza uno schema predefinito e di scalare facilimente sull'hardware, Hadoop offre livelli di performance, efficienza e Costo Totale di Ownership (TCO) mai raggiunti dagli EDW.
Il File System Distribuito di Hadoop (HDFS) è progettato per processi batch su larga scala. L'HDFS offre un modello di archiviazione write-once, read-many, append-only (scrivi una volta, leggi molte, aggiungi soltanto) per dati non indicizzati archiviati in file fino a 128MB ed è ottimizzato per scansioni a lungo termine e sequenziali su TB e PB di dati.
Questo rende Hadoop incredibilmente potente per analizzare grandi quantità di dati multi-strutturati, per creare analytics che le aziende possono usare per il loro business. Esempi di output possono includere:
Questi tipi di modelli sono tipicamente costruiti dalle query Hadoop, eseguite sul data lake con latenze che vanno da minuti a ore. Il data lake, che eccelle nel generare nuove forme di insights dai diversi data set, non è però progettato per offrire accesso in tempo reale alle applicazioni operative. Gli utenti hanno bisogno di rendere l'output delle analisi di Hadoop disponibile per le loro applicazioni online. Queste applicazioni hanno specifiche richieste di accesso che non possono essere soddisftatte dall'HDFS, fra queste:
Essere in grado di generare e offrire analytics dal data lake agli applicativi online e agli utenti in tempo reale può aiutare a risolvere queste sfide, che richiedono l'integrazione di un livello di database operativo molto scalabile e molto flessibile. Infine, le aziende vincenti in futuro non saranno quelle che hanno il data lake più grande, ma quelle che saranno più veloci nell'agire sugli insights e sull'intelligence che i dati stessi creano. I database operativi sono quindi essenziali per agire sulle viste del data lake.
Nella seconda parte di questa serie di post vedremo le capacità critiche necessarie da considerare quando si valuta e si sceglie un database operativo per il data lake.
Introduzione
I data lake basati su Hadoop permettono alle aziende e alle pubbliche amministrazioni di catturare e analizzare efficientemente volumi di dati senza precedenti, generati dalle loro iniziative di trasformazione digitale. Ma senza essere in grado di esporre questi dati alle applicazioni operative, gli utenti hanno difficoltà a massimizzare i ricavi dai loro investimenti su Hadoop. Più tempo si impiega ad elaborare gli insights dei processi operativi, meno vale quello stesso insight, perdendo in competitività. In questi 3 articoli parleremo di:
- L'ascesa del data lake, il ruolo di Hadoop e le sfide affrontate nell'integrare il data lake con le applicazioni operative.
- Nella seconda parte parleremo delle capacità critiche necessarie da valutare in un database operativo in base al data lake e di un pattern consigliato per integrare il database con il data lake.
- Concluderemo nella terza parte (la cui traduzione sarà disponibile prossimamente) parlando di esempi reali e best practices dalle aziende leader nel settore.
Sul sito di MongoDB è disponibile il white paper sull'argomento (in inglese).
L'ascesa dei data lake
Una cosa che sicuramente non manca al giorno d'oggi nelle aziende sono i dati. Dagli stream di dati letti dai sensori, ai dati social, ai log, le app mobile e molto altro. Gli analisti stimano che i volumi di dati aumenteranno del 40% per anno, di cui il 90% sarà composto da dati non strutturati. I nuovi insights scoperti raccogliendo e analizzando questi dati promettono di portare vantaggi competitivi e risparmi in efficienza. Inoltre, i tradizionali Data Warehouse Enterprise (EDW) iniziano a soffrire per l'aumento del carico di lavoro, sopraffatti dal volume e dalla varietà di dati che arrivano e dall'essere poi in grado di archiviarli in modo efficiente. Il risultato è che molte aziende sono passate ad Hadoop come repository centralizzata per questi nuovi dati, creando ciò che molti chiamano un data lake.
Con la sua abilità di archiviare dati di qualunque struttura senza uno schema predefinito e di scalare facilimente sull'hardware, Hadoop offre livelli di performance, efficienza e Costo Totale di Ownership (TCO) mai raggiunti dagli EDW.
Il File System Distribuito di Hadoop (HDFS) è progettato per processi batch su larga scala. L'HDFS offre un modello di archiviazione write-once, read-many, append-only (scrivi una volta, leggi molte, aggiungi soltanto) per dati non indicizzati archiviati in file fino a 128MB ed è ottimizzato per scansioni a lungo termine e sequenziali su TB e PB di dati.
Questo rende Hadoop incredibilmente potente per analizzare grandi quantità di dati multi-strutturati, per creare analytics che le aziende possono usare per il loro business. Esempi di output possono includere:
- Modelli di segmentazione dei clienti per campagne di marketing e raccomandazioni nell'eCommerce.
- Analisi dei churn per i servizi ai clienti.
- Analisi predittiva per manutenzione e ottimizzazione.
- Modellazione del rischio per scopi di sicurezza e anti-frode.
Questi tipi di modelli sono tipicamente costruiti dalle query Hadoop, eseguite sul data lake con latenze che vanno da minuti a ore. Il data lake, che eccelle nel generare nuove forme di insights dai diversi data set, non è però progettato per offrire accesso in tempo reale alle applicazioni operative. Gli utenti hanno bisogno di rendere l'output delle analisi di Hadoop disponibile per le loro applicazioni online. Queste applicazioni hanno specifiche richieste di accesso che non possono essere soddisftatte dall'HDFS, fra queste:
- Risposta alle query con bassa latenza (millisecondi).
- Accesso random a sottoinsiemi indicizzati di dati
- Sopporto per query ad-hoc e aggregazioni sui dati, per rendere gli applicativi online più intelligenti e contestuali
- Aggiornamento dei dati in tempo reale quando gli utenti interagiscono con le applicazioni online, senza dover riscrivere l'intero dataset.
Essere in grado di generare e offrire analytics dal data lake agli applicativi online e agli utenti in tempo reale può aiutare a risolvere queste sfide, che richiedono l'integrazione di un livello di database operativo molto scalabile e molto flessibile. Infine, le aziende vincenti in futuro non saranno quelle che hanno il data lake più grande, ma quelle che saranno più veloci nell'agire sugli insights e sull'intelligence che i dati stessi creano. I database operativi sono quindi essenziali per agire sulle viste del data lake.
Nella seconda parte di questa serie di post vedremo le capacità critiche necessarie da considerare quando si valuta e si sceglie un database operativo per il data lake.
Commenti
Posta un commento