Questo articolo è una traduzione del mio articolo su medium - , che si è rivelato piuttosto popolare, probabilmente per la sua semplicità. Pertanto, ho deciso di scriverlo in russo e di aggiungere qualcosa per far capire a una persona comune che non è uno specialista di dati cos'è un data warehouse (DW), cos'è un data Lake (Data Lake) e come funzionano andare d'accordo insieme.
Perché volevo scrivere del data Lake? Lavoro con dati e analisi da oltre 10 anni e ora sto sicuramente lavorando con i big data presso Amazon Alexa AI a Cambridge, che è a Boston, anche se vivo a Victoria sull'isola di Vancouver e visito spesso Boston, Seattle , e a Vancouver, e talvolta anche a Mosca, parlo a conferenze. Scrivo anche di tanto in tanto, ma scrivo principalmente in inglese, e ho già scritto , ho anche bisogno di condividere le tendenze analitiche del Nord America e talvolta scrivo .
Ho sempre lavorato con i data warehouse e dal 2015 ho iniziato a lavorare a stretto contatto con Amazon Web Services e in generale sono passato all'analisi del cloud (AWS, Azure, GCP). Ho osservato l'evoluzione delle soluzioni di analisi dal 2007 e ho anche lavorato per il fornitore di data warehouse Teradata e l'ho implementato presso Sberbank, ed è allora che sono apparsi Big Data con Hadoop. Tutti cominciarono a dire che l'era dello storage era passata e ora tutto era su Hadoop, e poi cominciarono a parlare di Data Lake, ancora, che ormai era definitivamente arrivata la fine dei data warehouse. Ma fortunatamente (forse sfortunatamente per alcuni che hanno guadagnato un sacco di soldi installando Hadoop), il data warehouse non è scomparso.
In questo articolo vedremo cos’è un data Lake. Questo articolo è destinato a persone che hanno poca o nessuna esperienza con i data warehouse.
Nella foto c'è il Lago di Bled, questo è uno dei miei laghi preferiti, anche se ci sono stato solo una volta, me lo ricorderò per il resto della mia vita. Ma parleremo di un altro tipo di lago: il data Lake. Forse molti di voi hanno già sentito parlare di questo termine più di una volta, ma un'altra definizione non danneggerà nessuno.
Innanzitutto ecco le definizioni più popolari di Data Lake:
"un file di archiviazione di tutti i tipi di dati grezzi che può essere analizzato da chiunque nell'organizzazione" - Martin Fowler.
“Se pensi che un data mart sia una bottiglia d'acqua purificata, confezionata e confezionata per un consumo conveniente, allora un data Lake è un enorme serbatoio d'acqua nella sua forma naturale. Utenti, posso raccogliere l'acqua per me stesso, immergermi in profondità, esplorare" - James Dixon.
Ora sappiamo per certo che un data Lake riguarda l'analisi, ci consente di archiviare grandi quantità di dati nella loro forma originale e abbiamo l'accesso necessario e conveniente ai dati.
Spesso mi piace semplificare le cose, se riesco a spiegare un termine complesso con parole semplici, allora capisco da solo come funziona e a cosa serve. Un giorno stavo frugando nella galleria fotografica dell'iPhone e mi sono reso conto che questo è un vero data lake, ho persino realizzato una diapositiva per le conferenze:
Tutto è molto semplice. Scattiamo una foto sul telefono, la foto viene salvata sul telefono e può essere salvata su iCloud (archiviazione di file cloud). Il telefono raccoglie anche i metadati delle foto: cosa viene mostrato, tag geografico, ora. Di conseguenza, possiamo utilizzare l'interfaccia user-friendly dell'iPhone per trovare la nostra foto e vediamo anche degli indicatori, ad esempio, quando cerco foto con la parola fuoco, trovo 3 foto con l'immagine di un fuoco. Per me è proprio come uno strumento di Business Intelligence che funziona in modo molto rapido e accurato.
Naturalmente non dobbiamo dimenticare la sicurezza (autorizzazione e autenticazione), altrimenti i nostri dati potrebbero facilmente diventare di pubblico dominio. Ci sono molte notizie su grandi aziende e startup i cui dati sono diventati disponibili al pubblico a causa della negligenza degli sviluppatori e del mancato rispetto di semplici regole.
Anche un'immagine così semplice ci aiuta a immaginare cos'è un data Lake, le sue differenze rispetto a un data warehouse tradizionale e i suoi elementi principali:
- Caricamento dati (L'acquisizione) è un componente chiave del data Lake. I dati possono entrare nel data warehouse in due modi: batch (caricamento a intervalli) e streaming (flusso di dati).
- Archiviazione file (Storage) è il componente principale del Data Lake. Avevamo bisogno che lo storage fosse facilmente scalabile, estremamente affidabile e a basso costo. Ad esempio, in AWS è S3.
- Catalogo e ricerca (Catalogo e ricerca) - per evitare la palude dei dati (questo è quando scarichiamo tutti i dati in una pila e quindi è impossibile lavorarci), dobbiamo creare un livello di metadati per classificare i dati in modo che gli utenti possano trovare facilmente i dati di cui hanno bisogno per l'analisi. Inoltre, puoi utilizzare soluzioni di ricerca aggiuntive come ElasticSearch. La ricerca aiuta l'utente a trovare i dati richiesti attraverso un'interfaccia intuitiva.
- lavorazione (Processo): questo passaggio è responsabile dell'elaborazione e della trasformazione dei dati. Possiamo trasformare i dati, cambiarne la struttura, pulirli e molto altro ancora.
- 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. È importante utilizzare metodi di autenticazione e autorizzazione. Infine, è necessario uno strumento di audit.
Da un punto di vista pratico, possiamo caratterizzare un data Lake mediante tre attributi:
- Raccogli e conserva qualsiasi cosa — il data Lake contiene tutti i dati, sia dati grezzi non elaborati per qualsiasi periodo di tempo sia dati elaborati/puliti.
- Scansione profonda — un data Lake consente agli utenti di esplorare e analizzare i dati.
- Accesso flessibile — Il data Lake fornisce un accesso flessibile a diversi dati e diversi scenari.
Ora possiamo parlare della differenza tra un data warehouse e un data Lake. Di solito le persone chiedono:
- E il data warehouse?
- Stiamo sostituendo il data warehouse con un data lake o lo stiamo espandendo?
- È ancora possibile fare a meno di un data Lake?
Insomma, non c’è una risposta chiara. Tutto dipende dalla situazione specifica, dalle capacità della squadra e dal budget. Ad esempio, la migrazione di un data warehouse da Oracle ad AWS e la creazione di un data Lake da parte di una filiale di Amazon - Woot - .
D’altro canto il fornitore Snowflake afferma che non è più necessario pensare a un data Lake, poiché la loro piattaforma dati (fino al 2020 era un data warehouse) consente di combinare sia un data Lake che un data warehouse. Non ho lavorato molto con Snowflake ed è davvero un prodotto unico in grado di farlo. Il prezzo dell’emissione è 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 e tutto ciò che non va lo archiviamo in un data Lake. L’intero ruolo dell’analisi è fornire alle aziende un facile accesso per prendere decisioni. Qualunque cosa si possa dire, gli utenti aziendali lavorano in modo più efficiente con un data warehouse che con un data Lake, ad esempio in Amazon: c'è Redshift (data warehouse analitico) e c'è Redshift Spectrum/Athena (interfaccia SQL per un data Lake in S3 basata su Alveare/Presto). Lo stesso vale per altri moderni data warehouse analitici.
Diamo un'occhiata ad una tipica architettura di data warehouse:
Questa è una soluzione classica. Disponiamo di sistemi sorgente, utilizzando ETL/ELT copiamo i dati in un data warehouse analitico e li 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 l'archiviazione 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 e non hanno accesso ai dati grezzi.
Ovviamente tutto dipende dal tuo caso. Se non hai problemi con il tuo data warehouse, non hai affatto bisogno di un data Lake. Ma quando sorgono problemi legati alla mancanza di spazio, energia o prezzo gioca un ruolo chiave, allora si può prendere in considerazione l’opzione di un data Lake. Questo è il motivo per cui il data Lake è molto popolare. Ecco un esempio di architettura di data Lake:
Utilizzando l'approccio data Lake, carichiamo i dati grezzi nel nostro data Lake (batch o streaming), quindi elaboriamo i dati secondo necessità. Il data Lake consente agli utenti aziendali di creare le proprie trasformazioni di dati (ETL/ELT) o di analizzare i dati in soluzioni di Business Intelligence (se è disponibile il driver necessario).
L'obiettivo di qualsiasi soluzione di analisi è servire gli utenti aziendali. Pertanto, dobbiamo sempre lavorare secondo le esigenze aziendali. (In Amazon questo è uno dei principi: lavorare all'indietro).
Lavorando sia con un data warehouse che con un data lake, possiamo confrontare entrambe le soluzioni:
La conclusione principale che si può trarre è che il data warehouse non è in concorrenza con il data Lake, ma piuttosto lo integra. Ma sta a te decidere cosa è giusto per il tuo caso. È sempre interessante provarlo tu stesso e trarre le giuste conclusioni.
Vorrei raccontarvi anche uno dei casi in cui ho iniziato ad utilizzare l'approccio data Lake. Tutto è abbastanza banale, ho provato a utilizzare uno strumento ELT (avevamo Matillion ETL) e Amazon Redshift, la mia soluzione ha funzionato, ma non soddisfaceva i requisiti.
Avevo bisogno di prendere i log web, trasformarli e aggregarli per fornire dati per 2 casi:
- Il team di marketing voleva analizzare l'attività dei bot per la SEO
- L'IT voleva esaminare le metriche sulle prestazioni del sito web
Registri molto semplici, 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 sono stati creati 7000mila file. Questo non è molto più volume, solo 50 gigabyte. Ma anche la dimensione del nostro cluster Redshift era piccola (4 nodi). Il caricamento di un file in modo tradizionale ha richiesto circa un minuto. Cioè, il problema non è stato risolto frontalmente. E questo è stato il caso quando ho deciso di utilizzare l’approccio del data Lake. La soluzione era più o meno questa:
È abbastanza semplice (voglio sottolineare che il vantaggio di lavorare nel cloud è la semplicità). Ero solito:
- AWS Elastic Map Reduce (Hadoop) per potenza di calcolo
- AWS S3 come storage di file con la possibilità di crittografare i dati e limitare l'accesso
- Spark come potenza di calcolo InMemory e PySpark per la trasformazione della logica e dei dati
- Parquet come risultato di Spark
- AWS Glue Crawler come raccoglitore di metadati su nuovi dati e partizioni
- Redshift Spectrum come interfaccia SQL per il data Lake per gli utenti Redshift esistenti
Il cluster EMR+Spark più piccolo ha elaborato l'intero stack di file in 30 minuti. Ci sono altri casi per AWS, soprattutto molti legati ad Alexa, dove ci sono molti dati.
Proprio di recente ho appreso che uno degli svantaggi di un data Lake è il GDPR. Il problema è che quando il client chiede di eliminarlo e i dati si trovano in uno dei file, non possiamo utilizzare il Data Manipulation Language e l'operazione DELETE come in un database.
Spero che questo articolo abbia chiarito la differenza tra un data warehouse e un data Lake. Se fossi interessato, posso tradurre altri miei articoli o articoli di professionisti che leggo. E raccontare anche le soluzioni con cui lavoro e la loro architettura.
Fonte: habr.com