Negli ultimi anni in Databricks, abbiamo assistito all'emergere di una nuova architettura di gestione dei dati, nata indipendentemente in molti clienti e casi d'uso: la lakehouse. In questo post descriviamo questa nuova architettura e i suoi vantaggi rispetto agli approcci precedenti.
I data warehouse hanno una lunga storia nelle applicazioni di supporto decisionale e business intelligence. Fin dalla loro nascita alla fine degli anni '80, la tecnologia dei data warehouse ha continuato ad evolversi e le architetture MPP hanno portato a sistemi in grado di gestire dimensioni di dati maggiori. Ma mentre i data warehouse erano ottimi per i dati strutturati, molte aziende moderne devono gestire dati non strutturati, semi-strutturati e dati con elevata varietà, velocità e volume. I data warehouse non sono adatti a molti di questi casi d'uso e certamente non sono i più convenienti.
Man mano che le aziende hanno iniziato a raccogliere grandi quantità di dati da molte fonti diverse, gli architetti hanno iniziato a immaginare un unico sistema per ospitare dati per molti prodotti analitici e carichi di lavoro diversi. Circa un decennio fa, le aziende hanno iniziato a costruire data lake - repository di dati grezzi in una varietà di formati. Sebbene adatti all'archiviazione dei dati, i data lake mancano di alcune funzionalità critiche: non supportano transazioni, non applicano la qualità dei dati e la loro mancanza di coerenza/isolamento rende quasi impossibile mescolare append e read, e job batch e streaming. Per questi motivi, molte delle promesse dei data lake non si sono concretizzate, portando in molti casi alla perdita di molti dei vantaggi dei data warehouse.
La necessità di un sistema flessibile e ad alte prestazioni non è diminuita. Le aziende richiedono sistemi per diverse applicazioni di dati, tra cui analisi SQL, monitoraggio in tempo reale, data science e machine learning. La maggior parte dei recenti progressi nell'AI sono stati in modelli migliori per elaborare dati non strutturati (testo, immagini, video, audio), ma questi sono precisamente i tipi di dati per cui un data warehouse non è ottimizzato. Un approccio comune è utilizzare più sistemi: un data lake, diversi data warehouse e altri sistemi specializzati come database per streaming, serie temporali, grafi e immagini. Avere una moltitudine di sistemi introduce complessità e, cosa più importante, introduce ritardi poiché i professionisti dei dati devono inevitabilmente spostare o copiare dati tra sistemi diversi.
Stanno emergendo nuovi sistemi che affrontano le limitazioni dei data lake. Una lakehouse è un'architettura nuova e aperta che combina i migliori elementi dei data lake e dei data warehouse. Le lakehouse sono abilitate da un nuovo design di sistema: implementando strutture dati e funzionalità di gestione dati simili a quelle di un data warehouse direttamente sopra storage cloud a basso costo in formati aperti. Sono ciò che otterresti se dovessi ridisegnare i data warehouse nel mondo moderno, ora che sono disponibili storage economici e altamente affidabili (sotto forma di object store).
Una lakehouse ha le seguenti caratteristiche chiave:
Questi sono gli attributi chiave delle lakehouse. I sistemi di livello enterprise richiedono funzionalità aggiuntive. Gli strumenti per la sicurezza e il controllo degli accessi sono requisiti di base. Le capacità di data governance, inclusi auditing, conservazione e lineage, sono diventate essenziali in particolare alla luce delle recenti normative sulla privacy. Sono necessari anche strumenti che abilitino la scoperta dei dati, come cataloghi dati e metriche di utilizzo dei dati. Con una lakehouse, tali funzionalità enterprise devono essere implementate, testate e amministrate solo per un singolo sistema.
Leggi il paper di ricerca completo sui funzionamenti interni della Lakehouse.
La Databricks Lakehouse Platform ha le caratteristiche architetturali di una lakehouse. Il servizio Azure Synapse Analytics di Microsoft, che si integra con Azure Databricks, abilita un pattern lakehouse simile. Altri servizi gestiti come BigQuery e Redshift Spectrum hanno alcune delle funzionalità lakehouse elencate sopra, ma sono esempi che si concentrano principalmente su BI e altre applicazioni SQL. Le aziende che desiderano creare e implementare i propri sistemi hanno accesso a formati di file open source (Delta Lake, Apache Spark, Apache Hudi) adatti alla creazione di una lakehouse.
Unire data lake e data warehouse in un unico sistema significa che i team di dati possono muoversi più velocemente poiché possono utilizzare i dati senza dover accedere a pi ù sistemi. Il livello di supporto SQL e l'integrazione con gli strumenti BI tra queste prime lakehouse sono generalmente sufficienti per la maggior parte dei data warehouse aziendali. Viste materializzate e stored procedure sono disponibili, ma gli utenti potrebbero dover impiegare altri meccanismi che non sono equivalenti a quelli trovati nei data warehouse tradizionali. Quest'ultimo è particolarmente importante per gli "scenari di lift and shift", che richiedono sistemi che raggiungano semantiche quasi identiche a quelle dei vecchi data warehouse commerciali.
E per quanto riguarda il supporto per altri tipi di applicazioni dati? Gli utenti di un lakehouse hanno accesso a una varietà di strumenti standard (Spark, Python, R, librerie di machine learning) per carichi di lavoro non BI come data science e machine learning. L'esplorazione e il perfezionamento dei dati sono standard per molte applicazioni analitiche e di data science. Delta Lake è progettato per consentire agli utenti di migliorare in modo incrementale la qualità dei dati nel loro lakehouse fino a quando non sarà pronto per il consumo.
Una nota sui blocchi di costruzione tecnici. Sebbene i file system distribuiti possano essere utilizzati per il livello di archiviazione, gli object store sono utilizzati più comunemente nei lakehouse. Gli object store forniscono archiviazione a basso costo e altamente disponibile, eccellente per letture massicciamente parallele, un requisito essenziale per i moderni data warehouse.
Il lakehouse è una nuova architettura di gestione dei dati che semplifica radicalmente l'infrastruttura dati aziendale e accelera l'innovazione in un'era in cui il machine learning è pronto a rivoluzionare ogni settore. In passato, la maggior parte dei dati che confluivano nei prodotti o nel processo decisionale di un'azienda erano dati strutturati provenienti da sistemi operativi, mentre oggi molti prodotti incorporano l'AI sotto forma di modelli di visione artificiale e vocale, text mining e altri. Perché usare un lakehouse invece di un data lake per l'AI? Un lakehouse offre versioning dei dati, governance, sicurezza e proprietà ACID necessarie anche per i dati non strutturati.
Gli attuali lakehouse riducono i costi, ma le loro prestazioni possono ancora essere inferiori rispetto a sistemi specializzati (come i data warehouse) che hanno anni di investimenti e implementazioni reali alle spalle. Gli utenti potrebbero preferire determinati strumenti (strumenti BI, IDE, notebook) rispetto ad altri, quindi i lakehouse dovranno anche migliorare la loro UX e i loro connettori agli strumenti più diffusi in modo da poter attrarre una varietà di utenti. Questi e altri problemi verranno affrontati man mano che la tecnologia continuerà a maturare e svilupparsi. Nel tempo, i lakehouse colmeranno queste lacune, mantenendo le proprietà fondamentali di essere più semplici, più convenienti e più capaci di servire diverse applicazioni dati.
Leggi le FAQ sul Data Lakehouse per maggiori dettagli.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
