La spiegazione della casa sul lago semantica

Ripubblicato da Platone

Seguaci: 0

Data Lake e strati semantici sono in circolazione da molto tempo, ognuno vive nei propri giardini recintati, strettamente accoppiati a casi d'uso piuttosto ristretti. Man mano che l'infrastruttura di dati e analisi migra verso il cloud, molti mettono in dubbio il modo in cui questi componenti tecnologici di base si inseriscono nel moderno stack di dati e analisi. In questo articolo, ci addentreremo nel modo in cui un data lakehouse e uno strato semantico insieme ribaltano la relazione tradizionale tra data lake e infrastruttura di analisi. Impareremo come una casa sul lago semantica può semplificare drasticamente architetture di dati cloud, eliminare lo spostamento di dati non necessari e ridurre il time-to-value e i costi del cloud.

L'architettura tradizionale di dati e analisi

Nel 2006, Amazon ha introdotto Amazon Web Services (AWS) come un nuovo modo per scaricare il data center locale nel cloud. Un servizio principale di AWS era il suo file data store e con esso è nato il primo data lake nel cloud, Amazon S3. Successivamente, altri fornitori di servizi cloud introdurranno le proprie versioni dell'infrastruttura del data lake cloud.

Per la maggior parte della sua vita, il cloud data lake è stato relegato a svolgere il ruolo di stupido, economico memorizzazione dei dati - Un messa in scena area per i dati grezzi, fino a quando i dati non potrebbero essere elaborati in qualcosa di utile. Per l'analisi, il data lake fungeva da penna per trattenere i dati fino a quando non potevano essere copiati e caricati in una piattaforma di analisi ottimizzata, in genere un data warehouse relazionale nel cloud che alimentava cubi OLAP, estrazioni di dati di strumenti proprietari di business intelligence (BI) come Tableau Hyper o Power BI Premium o tutto quanto sopra. Come risultato di questo modello di elaborazione, i dati dovevano essere archiviati almeno due volte, una volta nella loro forma grezza e una volta nella loro forma "analytics ottimizzata".

Non sorprende che la maggior parte delle tradizionali architetture di cloud analytics assomigli al diagramma seguente:

*Immagine 1: stack di analisi e dati tradizionali*

Come puoi vedere, il "magazzino di analisi" è responsabile della maggior parte delle funzioni che forniscono analisi ai consumatori. Il problema con questa architettura è il seguente:

I dati vengono archiviati due volte, il che aumenta i costi e crea complessità operativa.
I dati nell'analytics warehouse sono un'istantanea, il che significa che i dati sono istantaneamente obsoleti.
I dati nell'analytics warehouse sono in genere un sottoinsieme dei dati nel data lake, il che limita le domande che i consumatori possono porre.
Il magazzino di analisi si ridimensiona separatamente e in modo diverso dalla piattaforma dati cloud, introducendo costi aggiuntivi, problemi di sicurezza e complessità operativa.

Dati questi inconvenienti, potresti chiedere "Perché gli architetti di dati cloud dovrebbero scegliere questo modello di progettazione?" La risposta sta nelle richieste dei consumatori di analisi. Mentre il data lake potrebbe teoricamente servire query analitiche direttamente ai consumatori, in pratica il data lake è troppo lento e incompatibile con i più diffusi strumenti di analisi.

Se solo il data lake potesse offrire i vantaggi di un magazzino di analisi e potessimo evitare di archiviare i dati due volte!

La nascita della Data Lakehouse

Il termine "Lakehouse" ha visto il suo debutto nel 2020 con il seminale white paper Databricks "Cos'è una casa sul lago?" di Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia e Ali Ghodsi. Gli autori hanno introdotto l'idea che il data lake potrebbe fungere da motore per la fornitura di analisi, non solo un archivio di file statici.

I fornitori di data lakehouse hanno realizzato la loro visione introducendo motori di query scalabili ad alta velocità che lavorano su file di dati non elaborati nel data lake ed espongono un'interfaccia SQL standard ANSI. Con questa innovazione chiave, i sostenitori di questa architettura sostengono che i data lake possono comportarsi come un magazzino di analisi, senza la necessità di duplicare i dati.

Tuttavia, risulta che l'analytics warehouse svolge altre funzioni vitali che non sono soddisfatte dalla sola architettura del data lakehouse, tra cui:

Fornire query "velocità di pensiero" (query in meno di 2 secondi) in modo coerente su un'ampia gamma di query.
Presentazione di un livello semantico di facile utilizzo che consente ai consumatori di porre domande senza dover scrivere SQL.
Applicazione della governance e della sicurezza dei dati al momento della query.

Quindi, affinché un data lakehouse sostituisca veramente il magazzino di analisi, abbiamo bisogno di qualcos'altro.

Il ruolo dello strato semantico

Ho scritto molto sul ruolo del strato semantico nel moderno stack di dati. Per riassumere, un livello semantico è una visione logica dei dati aziendali che sfrutta la tecnologia di virtualizzazione dei dati per tradurre i dati fisici in dati business-friendly al momento della query.

Aggiungendo una piattaforma a livello semantico in cima a un data lakehouse, possiamo eliminare del tutto le funzioni di analytics warehouse perché la piattaforma a livello semantico:

Fornisce "query di velocità di pensiero" sul data lakehouse utilizzando la virtualizzazione dei dati e l'ottimizzazione automatica delle prestazioni delle query.
Fornisce un livello semantico di facile utilizzo che sostituisce le viste semantiche proprietarie incorporate in ogni strumento BI e consente agli utenti aziendali di porre domande senza dover scrivere query SQL.
Fornisce governance e sicurezza dei dati al momento della query.

Una piattaforma a livello semantico fornisce i pezzi mancanti che mancano al data lakehouse. Combinando uno strato semantico con un data lakehouse, le organizzazioni possono:

Elimina le copie dei dati e semplifica le pipeline di dati.
Consolida la governance e la sicurezza dei dati.
Offri una "singola fonte di verità" per le metriche aziendali.
Riduci la complessità operativa mantenendo i dati nel data lake.
Fornire l'accesso a più dati e dati più tempestivi ai consumatori di analisi.

*Immagine 2: nuovo stack Data Lakehouse con un livello semantico*

The Semantic Lakehouse: tutti vincono

Tutti vincono con questa architettura. I consumatori ottengono l'accesso a dati più granulari senza latenza. I team IT e di ingegneria dei dati hanno meno dati da spostare e trasformare. La finanza spende meno soldi per i costi dell'infrastruttura cloud.

Come puoi vedere, combinando un livello semantico con un data lakehouse, le organizzazioni possono semplificare le loro operazioni di dati e analisi e fornire più dati, più velocemente, a più consumatori, con costi inferiori.