Cos'è Delta Lake?

Sviluppato per la prima volta da Databricks nel 2016, Delta Lake è un framework open source per dati tabellari che crea un livello di metadati sopra i formati di file esistenti. Delta Lake utilizza in modo specifico le tabelle Parquet per il data storage. Altri formati di tabelle aperte includono Apache Iceberg e Apache Hudi.

Il livello di metadati consente a Delta Lake e ad altre tabelle aperte di ottimizzare le query di ricerca e supportare operazioni avanzate sui dati che molti formati di tabella standard non possono supportare. Le organizzazioni utilizzano spesso Delta Lake per rendere i propri data lake più affidabili e intuitivi.

La creazione di Delta Lake ha rappresentato un passaggio critico nello sviluppo dell'architettura del data lakehouse, che abbina lo storage di un data lake alle prestazioni di un data warehouse.

Delta Lake e i data lake vengono spesso discussi insieme, tuttavia è importante sapere che queste tecnologie sono distinte l'una dall'altra.

Un data lake è un ambiente di data storage a basso costo, progettato per gestire enormi set di dati di qualsiasi tipo e formato. La maggior parte dei data lake utilizza piattaforme di cloud object storage come Amazon Simple Storage Service (S3), Microsoft Azure Blob Storage o IBM Cloud Object Storage.

Delta Lake è un formato di data storage tabellare che un'organizzazione può utilizzare in un data lake o in un altro data store.

Delta Lake non è un tipo di data lake, né un'alternativa a un data lake. Piuttosto, si può pensare a un data lake come al “dove” e a Delta Lake come al “come”:

• Dove vengono memorizzati i dati? In a data lake.
• Come vengono memorizzati i dati? Sotto forma di tabella Delta Lake.

Il formato Delta Lake può contribuire a rendere i data lake più gestibili ed efficienti.

I data lake offrono molti benefici, ma in genere non dispongono di controlli di qualità dei dati integrati e interrogare direttamente i data lake può essere difficile. Le organizzazioni devono spesso prelevare dati da un lake, ripulirli e caricarli in data warehouse e data mart separati prima che possano essere utilizzati.

Introducendo un livello di metadati, Delta Lake offre alle organizzazioni un modo per applicare schemi, tracciare e ripristinare modifiche e supportare le transazioni ACID.

Gli utenti possono eseguire SQL query, workload di analytics e altre attività direttamente su un data lake, semplificando la business intelligence (BI), ladata intelligence (DI), l'intelligenza artificiale (AI) e il machine learning (ML).

Delta Lake ha due componenti principali: i file di dati che contengono i dati e il log delle transazioni che contiene i metadati relativi a quei file di dati.

• I file di dati in Delta Lake sono chiamati "tabelle Delta Lake" o "tabelle Delta" e utilizzano il formato di file colonnare Parquet.
  
  
• Il log delle transazioni memorizza l'attività recente nei file di log JSON e i metadati meno recenti nei file Parquet. Il log viene memorizzato nel data lake insieme ai file di dati.

Il log delle transazioni registra le informazioni riguardanti i file di dati (ad esempio i nomi delle colonne e i valori minimi e massimi) e le modifiche apportate ai file (cosa è stato modificato, quando, come e da chi).

Il registro è ciò che rende Delta Lake diverso da un file Parquet standard. Il registro delle transazioni funge essenzialmente da livello di gestione e insieme di istruzioni per tutte le attività nel data lake, abilitando funzionalità come transazioni ACID, time travel ed evoluzione degli schemi.

I normali file Parquet sono immutabili, il che significa che non possono essere modificati dopo la creazione; possono solo essere riscritti. Il log delle transazioni di Delta Lake rende i file Parquet funzionalmente, se non letteralmente, mutabili separando le azioni fisiche (azioni eseguite direttamente sui dati) dalle azioni logiche (azioni eseguite sui metadati).

Ad esempio, un utente non può rimuovere una singola colonna da una tabella Parquet senza riscrivere l'intero file. In Delta Lake, l'utente può rimuovere efficacemente quella colonna modificando i metadati della tabella per contrassegnarla come eliminata. La colonna rimane nel file, ma tutte le query, gli aggiornamenti e le scritture successive visualizzano i metadati e considerano la colonna come inesistente.  

"ACID" sta per "atomicità, coerenza, isolamento e durabilità" tutte proprietà chiave di una transazione dati affidabile.

• Atomicità significa che tutte le modifiche ai dati vengono eseguite come se fossero un'unica operazione.
  
  
• Coerenza significa che i dati si trovano in uno stato coerente all'inizio e alla fine di una transazione.
  
  
• Isolamento significa che lo stato intermedio di una transazione è invisibile alle altre transazioni.
  
  
• Durabilità significa che le modifiche apportate ai dati vengono mantenute e non annullate.

I data lake standard non sono in grado di supportare le transazioni ACID. Senza le garanzie ACID, i data lake sono soggetti al fallimento delle transazioni, a scritture parziali e ad altri problemi che possono danneggiare i dati. 

Il log delle transazioni di Delta Lake può registrare le informazioni sulle transazioni in conformità con i principi ACID, rendendo i data lake più affidabili per lo streaming delle pipeline di dati, la business intelligence, l'analytics e altri casi d'uso. 

Gli amministratori possono impostare i requisiti dello schema nel log delle transazioni e questi requisiti si applicano a tutti i dati al momento dell'inserimento. I dati che non soddisfano i requisiti dello schema vengono rifiutati.

Gli amministratori possono anche utilizzare il log delle transazioni per modificare lo schema di un file esistente, come aggiungere nuove colonne o cambiare i tipi di colonna. Questo processo si chiama "evoluzione dello schema".

Sebbene non sia un indice tradizionale, il log delle transazioni può aiutare le query a recuperare i dati in modo più rapido ed efficiente.

Per esempio, supponiamo che un utente cerchi un determinato valore in una colonna; utilizzando i metadati nel registro delle transazioni, la query dell'utente può saltare qualsiasi file in cui il valore target non può esistere. Se il valore minimo è superiore o il valore massimo è inferiore al valore target, la query può ignorare il file.

Nel log delle transazioni vengono memorizzati anche i percorsi dei file. Invece di eseguire la scansione dell'intero data lake, le query possono utilizzare questi percorsi di file per accedere direttamente ai file pertinenti.

Delta Lake può utilizzare tecniche come l'ordinamento Z per memorizzare dati simili più vicini tra loro su disco, il che rende più facile saltare file irrilevanti e trovarne di pertinenti. 

I normali file Parquet sono immutabili, ma gli utenti possono manipolare le tabelle Delta attraverso il livello dei metadati. Delta Lake supporta tutti i tipi di operazioni sui dati, tra cui l'aggiunta o l'eliminazione di colonne, l'aggiornamento di voci e l'unione di file.

Poiché il log delle transazioni registra tutto ciò che accade nelle tabelle Delta, mantiene in modo efficace le cronologie delle versioni per ogni tabella. Gli utenti possono interrogare le versioni passate e persino viaggiare nel tempo, ovvero eseguire il rollback delle modifiche per ripristinare le versioni precedenti delle tabelle.

Delta Lake dispone di un solido ecosistema di connettori. Il formato può essere utilizzato con vari motori di calcolo, come Apache Spark, Apache Hive, Apache Flink o Trino. Delta Lake dispone anche di application programming interface (API) per Python, Java, Scala e altri linguaggi, che consentono agli sviluppatori di gestire e interrogare le tabelle Delta in modo programmatico.

Sebbene Delta Lake non imponga controlli di sicurezza in modo nativo, può integrarsi con strumenti di sicurezza dei dati e governance dei dati . Questi strumenti possono quindi utilizzare i metadati del registro delle transazioni per verificare l'attività, tenere traccia delle modifiche e applicare policy di controllo degli accessi basate sui ruoli (RBAC).

Delta Lake può accettare sia dati in streaming che in batch e i dati possono essere inviati dalle tabelle Delta ai servizi connessi come flusso o in batch.

Delta Lake 4.0, la prossima importante release di Delta Lake in programma, prevede di aggiungere ulteriori funzionalità, tra cui:

• Commit coordinati per semplificare il processo di scrittura in più tabelle e da più motori contemporaneamente.
  
  
• Un nuovo tipo di dati "variante" per memorizzare dati semistrutturati, tradizionalmente difficili da memorizzare in formato tabella.
  
  
• Ampliamento del tipo, che consente agli utenti di modificare il tipo di dati di una colonna. 

Apache Iceberg è un formato open source ad alte prestazioni per tabelle analitiche di grandi dimensioni. Come Delta Lake, Iceberg crea un livello di metadati sopra i formati di tabella esistenti per supportare le transazioni ACID e altre operazioni in un data lake.

Iceberg può memorizzare i dati in file Parquet, ORC o Avro, mentre Delta Lake utilizza esclusivamente Parquet. Iceberg utilizza anche uno strato di metadati a tre livelli anziché un singolo log delle transazioni come Delta Lake.

Iceberg si integra in modo nativo con molti motori di query ed è una scelta comune per l'analytics basata su SQL in un data lake. 

Come Delta Lake e Iceberg, Hudi mantiene uno strato di metadati sopra un livello di dati. Hudi può utilizzare i formati di file Parquet, HFile e ORC e il suo livello di metadati assume la forma di una "linea temporale" che registra tutto ciò che accade nel livello di dati.

Hudi è progettato per il elaborazione dei dati incrementale, in cui piccoli batch di dati vengono elaborati frequentemente. Questa attenzione all'elaborazione incrementale rende Hudi una scelta diffusa per la real-time analytics e la change data capture (CDC). 

Lo sviluppo del formato Delta Lake ha contribuito ad aprire la strada alla creazione dei data lakehouse.

Per molto tempo le organizzazioni hanno gestito i dati principalmente nei data warehouse. Sebbene siano utili per l'analytics e la BI, i data warehouse richiedono schemi rigorosi. Non funzionano bene con dati non strutturati o semistrutturati, che sono diventati sempre più diffusi e importanti via via che le organizzazioni aumentano i propri investimenti nell'AI e nell'ML.

L'avvento dei data lake intorno al 2010 ha offerto alle organizzazioni un modo per aggregare tutti i tipi di dati provenienti da tutti i tipi di fonti di dati in un unico luogo.

Tuttavia, i data lake presentano dei problemi. Spesso mancano i controlli di qualità. Non supportano le transazioni ACID e non è facile interrogarle direttamente.

Per rendere i dati utilizzabili, le organizzazioni spesso dovevano creare pipeline di dati ETL (Extract, Transform, Load) separati per spostare i dati da un data lake a un data warehouse.  

Delta Lake ha fatto la sua comparsa nel 2016, aggiungendo transazioni ACID, applicazione degli schemi e time travel ai data lake, rendendoli quindi più affidabili per le query dirette e l'analytics.

Rilasciato con licenza open source nel 2019, Delta Lake ha svolto un ruolo chiave nel dare forma all'architettura dei data lakehouse, che combina la flessibilità dei data lake con le prestazioni dei data warehouse.

Molte organizzazioni creano data lake costruendo un livello di storage Delta Lake sopra un data lake esistente e integrandolo con un motore di elaborazione dei dati come Spark o Hive.

I data lakehouse aiutano a supportare l'integrazione dei dati e a semplificare l'architettura dei dati eliminando la necessità di mantenere data lake e data warehouse separati, il che può creare silos di dati.

A loro volta, queste architetture semplificate aiutano a garantire che data scientist, data engineer e altri utenti possano accedere ai dati di cui hanno bisogno quando ne hanno bisogno. I workload di AI e ML sono casi d'uso comuni dei data lakehouse basati su Delta Lake.

I data lake sono già utili da soli per questi workload perché possono ospitare enormi quantità di dati strutturati, non strutturati e semistrutturati.

Aggiungendo funzionalità come le transazioni ACID e l'applicazione degli schemi, Delta Lake aiuta a garantire la qualità dei dati e l'affidabilità dei dati di addestramento in modalità impossibili per i data lake.