Abbiamo bisogno di un lago di dati? E cosa fare con il data warehouse?

Questo articolo è la traduzione del mio articolo su Medium — Introduzione al Data Lake, che si è rivelato piuttosto popolare, probabilmente per la sua semplicità. Perciò ho deciso di scriverlo in russo e ampliare un po' il contenuto, in modo che una persona comune, che non è esperta di gestione dei dati, capisca cosa sia un data warehouse (DW) e cosa sia un lago di dati (Data Lake), e come coesistano.

Perché ho voluto scrivere riguardo al lago di dati? Lavoro con dati e analisi da oltre 10 anni, e attualmente lavoro con Big Data in Amazon Alexa AI a Cambridge, che si trova a Boston, anche se vivo a Victoria, nell'isola di Vancouver e visito spesso Boston, Seattle e Vancouver, e a volte parlo anche a conferenze a Mosca. Scrivo anche di tanto in tanto, ma principalmente in inglese, e ho già scritto alcuni libri, inoltre ho la necessità di condividere le tendenze analitiche dal Nord America, e a volte scrivo su Telegram.

Ho sempre lavorato con data warehouse, e dal 2015 ho iniziato a lavorare intensamente con Amazon Web Services, e in generale mi sono orientato verso l'analisi basata sul cloud (AWS, Azure, GCP). Ho osservato l'evoluzione delle soluzioni analitiche dal 2007 e ho anche lavorato in un fornitore di data warehouse, Teradata, implementandolo in Sberbank, e quello è stato il momento in cui è emersa la Big Data con Hadoop. Tutti hanno cominciato a dire che l'era dei data warehouse era finita e che ora tutto era su Hadoop, e poi hanno cominciato a parlare di Data Lake, di nuovo dicendo che era giunto davvero il momento della fine per i data warehouse. Ma fortunatamente (forse per alcuni sfortunatamente, per coloro che guadagnavano molto a configurare Hadoop), il data warehouse non è scomparso.

In questo articolo esamineremo cosa sia un lago di dati. L'articolo è destinato a persone che hanno poca esperienza con i data warehouse o nessuna.

Nella foto c'è il lago di Bled, è uno dei miei laghi preferiti, anche se ci sono stato solo una volta, ma l'ho ricordato per tutta la vita. Ma parleremo di un altro tipo di lago — il lago di dati. Forse molti di voi avranno già sentito questo termine più di una volta, ma un'altra definizione non farà male.

Innanzitutto ecco le definizioni più popolari di Lago di Dati:

«un archivio di tutti i tipi di dati grezzi, disponibili per l'analisi da chiunque nell'organizzazione» — Martin Fowler.

«Se pensate che il lago dei dati sia una bottiglia d'acqua — purificata, imballata e confezionata per un uso comodo, allora il lago dei dati è un grande serbatoio d'acqua nella sua forma naturale. Gli utenti possono prelevare acqua per se stessi, immergersi in profondità, esplorare» — James Dickson.

Ora sappiamo con certezza che il lago dei dati riguarda l'analisi; consente di archiviare grandi volumi di dati nella loro forma originale e abbiamo un accesso comodo e necessario ai dati.

Mi piace spesso semplificare le cose; se riesco a spiegare un termine complesso con parole semplici, significa che per me l'ho capito e so a cosa serve. Una volta, mentre navigavo nell'iPhone nella galleria fotografica, mi è venuta in mente una cosa: questo è proprio un vero lago di dati, tanto che ho anche creato una diapositiva per le conferenze.

È molto semplice. Scattiamo una foto con il telefono, la foto viene salvata sul telefono e può essere archiviata su iCloud (spazio di archiviazione cloud). Inoltre, il telefono raccoglie i metadati della foto: cosa è ritratto, geolocalizzazione, tempo. Di conseguenza, possiamo utilizzare l'interfaccia comoda dell'iPhone per trovare la nostra foto e possiamo anche vedere i parametri; ad esempio, quando cerco foto con la parola fuoco (fire), trovo 3 foto con l'immagine di un falò. Per me è proprio come uno strumento di Business Intelligence che funziona molto rapidamente e con precisione.

E naturalmente, non possiamo dimenticare la sicurezza (autenticazione e autorizzazione), altrimenti i nostri dati possono facilmente diventare accessibili al pubblico. Ci sono molte notizie riguardo a grandi aziende e startup che hanno avuto dati esposti al pubblico a causa della negligenza degli sviluppatori e della mancata osservanza di semplici regole.

Anche un'immagine così semplice ci aiuta a immaginare cos'è un lago di dati, le sue differenze rispetto a un tradizionale magazzino di dati e i suoi principali elementi:

1. Caricamento dati (Ingestione) — componente chiave del lago dei dati. I dati possono entrare nel magazzino dati in due modi: batch (caricamento a intervalli) e streaming (flusso di dati).
2. Archiviazione file (Storage) — componente principale del Lago dei Dati. Abbiamo bisogno che il magazzino sia facilmente scalabile, estremamente affidabile e a basso costo. Ad esempio, in AWS è S3.
3. Catalogo e Ricerca (Catalogo e Ricerca) — per evitare la Palude dei Dati (quando mettiamo tutti i dati in un unico posto, rendendo impossibile lavorarci), è necessario creare uno strato di meta-dati per classificare i dati, in modo che gli utenti possano trovare facilmente le informazioni di cui hanno bisogno per l'analisi. Inoltre, è possibile utilizzare soluzioni aggiuntive per la ricerca, come ElasticSearch. La ricerca aiuta l'utente a trovare i dati necessari attraverso un'interfaccia intuitiva.
4. Elaborazione (Processo) — questo passo è responsabile dell'elaborazione e trasformazione dei dati. Possiamo trasformare i dati, modificare le loro strutture, pulirli e molto altro.
5. Sicurezza (Sicurezza) — è importante dedicare tempo alla progettazione della sicurezza della soluzione. Ad esempio, la crittografia dei dati durante l'archiviazione, l'elaborazione e il caricamento. È essenziale utilizzare metodi di autenticazione e autorizzazione. Infine, è necessario uno strumento di audit.

Dal punto di vista pratico, possiamo caratterizzare il lago dei dati con tre attributi:

1. Raccogli e archivia qualsiasi cosa — il lago dei dati contiene tutti i dati, sia le informazioni grezze e non elaborate su qualsiasi periodo di tempo, sia i dati elaborati/puliti.
2. Analisi approfondita — il lago dei dati consente agli utenti di esplorare e analizzare i dati.
3. Accesso flessibile — il lago dei dati offre un accesso flessibile a diversi dati e scenari.

Ora possiamo parlare della differenza tra un data warehouse e un lago di dati. Di solito, le persone chiedono:

• E il data warehouse?
• Sostituiamo il data warehouse con un lago di dati o lo espandiamo?
• Possiamo davvero fare a meno del lago di dati?

In breve, non esiste una risposta chiara. Dipende dalla situazione specifica, dalle competenze nel team e dal budget. Ad esempio, la migrazione di un data warehouse su Oracle in AWS e la creazione di un lago di dati da parte della sussidiaria di Amazon — Woot — La nostra storia sul lago di dati: come Woot.com ha costruito un lago di dati senza server su AWS.

D'altra parte, il fornitore Snowflake afferma che non è più necessario pensare a un lago di dati, poiché la loro piattaforma dati (fino al 2020 era un data warehouse) consente di combinare lago di dati e data warehouse. Ho lavorato un po' con Snowflake, ed è davvero un prodotto unico che può fare così. Il costo della questione è un'altra questione.

In conclusione, la mia opinione personale è che abbiamo ancora bisogno di un data warehouse come principale fonte di dati per il nostro reporting, mentre tutto ciò che non vi rientra lo memorizziamo in un data lake. Il ruolo dell'analitica è fornire un facile accesso alle informazioni per le decisioni aziendali. In effetti, gli utenti aziendali lavorano in modo più efficiente con un data warehouse piuttosto che con un data lake; per esempio, in Amazon abbiamo Redshift (data warehouse analitico) e Redshift Spectrum/Athena (interfaccia SQL per il data lake in S3 basata su Hive/Presto). Lo stesso vale anche per altri moderni data warehouse analitici.

Esaminiamo un'architettura tipica di un data warehouse:

Questa è una soluzione classica. Abbiamo dei sistemi sorgente, attraverso ETL/ELT trasferiamo i dati nel data warehouse analitico e ci colleghiamo a una soluzione di Business Intelligence (il mio preferito è Tableau, e il tuo?).

Questa soluzione presenta i seguenti svantaggi:

• Le operazioni ETL/ELT richiedono tempo e risorse.
• Di norma, la memoria per la memorizzazione dei dati in un data warehouse analitico non è economica (ad esempio Redshift, BigQuery, Teradata), poiché dobbiamo acquistare un intero cluster.
• Gli utenti aziendali hanno accesso a dati puliti e spesso aggregati, ma non possono ottenere i dati grezzi.

Certo, tutto dipende dal tuo caso specifico. Se non hai problemi con il tuo data warehouse, non hai affatto bisogno di un data lake. Tuttavia, quando sorgono problemi di spazio, potenza o il costo diventa un fattore cruciale, allora potresti considerare un data lake. È proprio per questo che il data lake è molto popolare. Ecco un esempio di architettura di un data lake:

Utilizzando l'approccio del data lake, carichiamo i dati grezzi nel nostro data lake (batch o streaming), e poi elaboriamo i dati secondo necessità. Il data lake consente agli utenti aziendali di creare le proprie trasformazioni dei dati (ETL/ELT) o analizzare i dati in soluzioni di Business Intelligence (se c'è il driver necessario).

L'obiettivo di qualsiasi soluzione analitica è servire gli utenti aziendali. Pertanto, dobbiamo sempre lavorare partendo dalle esigenze del business. (In Amazon, questo è uno dei principi: lavorare all'indietro).

Lavorando sia con il data warehouse sia con il data lake, possiamo confrontare entrambe le soluzioni:

La conclusione principale che si può trarre è che il data warehouse non è in competizione con il data lake, ma lo completa. Ma spetta a voi decidere cosa si adatta meglio al vostro caso. È sempre interessante provare da soli e trarre le conclusioni giuste.

Vorrei anche raccontare uno dei casi in cui ho iniziato a utilizzare l'approccio del data lake. Tutto è abbastanza banale, ho cercato di utilizzare uno strumento ELT (avevamo Matillion ETL) e Amazon Redshift, la mia soluzione funzionava, ma non soddisfaceva i requisiti.

Avevo bisogno di prendere i log web, trasformarli e aggregarli per fornire dati per 2 casi:

1. Il team marketing voleva analizzare l'attività dei bot per la SEO
2. L'IT voleva monitorare le metriche delle prestazioni dei siti

Log molto semplici, ecco un esempio:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Un file pesava 1-4 megabyte.

Ma c'era una difficoltà. Avevamo 7 domini in tutto il mondo e in un giorno venivano creati 7000 file. Non è un volume eccessivo, solo 50 gigabyte. Ma anche la dimensione del nostro cluster Redshift era piuttosto piccola (4 nodi). Il caricamento tradizionale di un file richiedeva circa un minuto. Quindi, il problema non si risolveva in modo diretto. E questo è stato il caso in cui ho deciso di utilizzare l'approccio del data lake. La soluzione appariva più o meno così:

Era abbastanza semplice (voglio notare che il vantaggio di lavorare nel cloud è la semplicità). Ho utilizzato:

• AWS Elastic Map Reduce (Hadoop) come potenza di calcolo
• AWS S3 come archivio file con possibilità di crittografia dei dati e controllo degli accessi
• Spark come potenza di calcolo InMemory e PySpark per la logica e la trasformazione dei dati
• Parquet come risultato dell'elaborazione di Spark
• AWS Glue Crawler come raccoglitore di metadati sui nuovi dati e partizioni
• Redshift Spectrum come interfaccia SQL per il data lake per gli utenti esistenti di Redshift

Il cluster EMR+Spark più piccolo elaborava tutti i file in 30 minuti. Ci sono anche altri casi per AWS, in particolare molti relativi ad Alexa, dove ci sono moltissimi dati.

Recentemente ho scoperto uno dei difetti del data lake: il GDPR. Il problema è che quando un cliente chiede di cancellare i propri dati e questi sono in uno dei file, non possiamo utilizzare il Data Manipulation Language e l'operazione DELETE come facciamo con un database.

Spero che l'articolo abbia chiarito la differenza tra data warehouse e data lake. Se ti è piaciuto, posso tradurre altre mie articoli o quelli di professionisti che leggo. Posso anche parlare delle soluzioni con cui lavoro e della loro architettura.

Fonte: habr.com