Approfondimento su Delta Lake: applicazione e sviluppo dello schema

Prova questa serie di notebook in Databricks

I dati, come le nostre esperienze, sono in continua evoluzione e si accumulano costantemente. Per stare al passo, i nostri modelli mentali del mondo devono adattarsi ai nuovi dati, alcuni dei quali contengono nuove dimensioni: nuovi modi di vedere le cose che prima non avevamo idea. Questi modelli mentali non sono diversi dallo schema di una tabella, che definisce come categorizziamo ed elaboriamo le nuove informazioni.

Questo ci porta alla gestione dello schema. Poiché i problemi e i requisiti aziendali si evolvono nel tempo, così fa anche la struttura dei tuoi dati. Con Delta Lake, man mano che i dati cambiano, incorporare nuove dimensioni è facile. Gli utenti hanno accesso a una semantica semplice per controllare lo schema delle loro tabelle. Questi strumenti includono l'imposizione dello schema, che impedisce agli utenti di contaminare accidentalmente le proprie tabelle con errori o dati spazzatura, nonché l'evoluzione dello schema, che consente loro di aggiungere automaticamente nuove colonne di dati complessi quando tali colonne appartengono. In questo blog, approfondiremo l'uso di questi strumenti.

Informazioni sugli schemi delle tabelle

Ogni DataFrame in Apache Spark™ contiene uno schema, un progetto che definisce la forma dei dati, come i tipi di dati e le colonne, e i metadati. Con Delta Lake, lo schema della tabella viene salvato in formato JSON all'interno del log delle transazioni.

Che cos'è l'imposizione dello schema?

L'imposizione dello schema, nota anche come convalida dello schema, è una protezione in Delta Lake che garantisce la qualità dei dati rifiutando le scritture in una tabella che non corrispondono allo schema della tabella. Come il responsabile della reception in un ristorante affollato che accetta solo prenotazioni, controlla se ogni colonna nei dati inseriti nella tabella è presente nel suo elenco di colonne previste (in altre parole, se ognuna ha una "prenotazione") e rifiuta qualsiasi scrittura con colonne che non sono nell'elenco.

Come funziona l'imposizione dello schema?

Delta Lake utilizza la convalida dello schema in scrittura, il che significa che tutte le nuove scritture in una tabella vengono controllate per la compatibilità con lo schema della tabella di destinazione al momento della scrittura. Se lo schema non è compatibile, Delta Lake annulla completamente la transazione (nessun dato viene scritto) e genera un'eccezione per informare l'utente della mancata corrispondenza.

Per determinare se una scrittura in una tabella è compatibile, Delta Lake utilizza le seguenti regole. Il DataFrame da scrivere:

• Non può contenere colonne aggiuntive che non sono presenti nello schema della tabella di destinazione. Al contrario, va bene se i dati in entrata non contengono tutte le colonne nella tabella: a tali colonne verranno semplicemente assegnati valori null.
• Non può avere tipi di dati di colonna diversi dai tipi di dati di colonna nella tabella di destinazione. Se la colonna di una tabella di destinazione contiene dati StringType, ma la colonna corrispondente nel DataFrame contiene dati IntegerType, l'imposizione dello schema genererà un'eccezione e impedirà l'esecuzione dell'operazione di scrittura.
• Non può contenere nomi di colonna che differiscono solo per il caso. Ciò significa che non puoi avere colonne come 'Foo' e 'foo' definite nella stessa tabella. Sebbene Spark possa essere utilizzato in modalità case sensitive o insensitive (impostazione predefinita), Delta Lake conserva il caso ma è insensitive quando si memorizza lo schema. Parquet è case sensitive quando si memorizzano e si restituiscono le informazioni sulle colonne. Per evitare potenziali errori, danneggiamenti dei dati o problemi di perdita (che abbiamo personalmente riscontrato in Databricks), abbiamo deciso di aggiungere questa restrizione.

Per illustrare, dai un'occhiata a cosa succede nel codice seguente quando si tenta di aggiungere alcune colonne appena calcolate a una tabella Delta Lake che non è ancora impostata per accettarle.

Invece di aggiungere automaticamente le nuove colonne, Delta Lake impone lo schema e impedisce che la scrittura avvenga. Per aiutare a identificare quale/i colonna/e ha/hanno causato la mancata corrispondenza, Spark stampa entrambi gli schemi nello stack trace per il confronto.

In che modo l'imposizione dello schema è utile?

Poiché è un controllo così rigoroso, l'imposizione dello schema è uno strumento eccellente da utilizzare come gatekeeper di un set di dati pulito e completamente trasformato, pronto per la produzione o il consumo. In genere viene applicato alle tabelle che alimentano direttamente:

• Algoritmi di machine learning
• Dashboard di BI
• Strumenti di analisi e visualizzazione dei dati
• Qualsiasi sistema di produzione che richieda schemi semantici altamente strutturati, fortemente tipizzati

Per preparare i propri dati per questo ostacolo finale, molti utenti utilizzano una semplice architettura "multi-hop" che aggiunge progressivamente struttura alle proprie tabelle. Per saperne di più, dai un'occhiata al post intitolato Productionizing Machine Learning With Delta Lake.

Naturalmente, l'imposizione dello schema può essere utilizzata ovunque nella tua pipeline, ma tieni presente che può essere un po' frustrante far fallire la tua scrittura in streaming in una tabella perché hai dimenticato di aver aggiunto una singola colonna ai dati in entrata, ad esempio.

Prevenzione della diluizione dei dati

A questo punto, potresti chiederti, di cosa si tratta? Dopotutto, a volte un errore imprevisto di "mancata corrispondenza dello schema" può farti inciampare nel tuo flusso di lavoro, soprattutto se sei nuovo di Delta Lake. Perché non lasciare che lo schema cambi come deve in modo che io possa scrivere il mio DataFrame qualunque cosa accada?

Come dice il vecchio detto, "prevenire è meglio che curare". Ad un certo punto, se non imponi il tuo schema, i problemi con la compatibilità dei tipi di dati solleveranno le loro brutte teste: fonti apparentemente omogenee di dati grezzi possono contenere casi limite, colonne corrotte, mappature errate o altre cose spaventose che accadono nella notte. Un approccio molto migliore è fermare questi nemici alle porte, utilizzando l'imposizione dello schema, e affrontarli alla luce del giorno piuttosto che più tardi, quando si nasconderanno nei recessi oscuri del tuo codice di produzione.

L'imposizione dello schema offre la tranquillità che lo schema della tua tabella non cambierà a meno che tu non prenda la decisione affermativa di cambiarlo. Impedisce la "diluizione" dei dati, che può verificarsi quando nuove colonne vengono aggiunte così frequentemente che le tabelle precedentemente ricche e concise perdono il loro significato e la loro utilità a causa del diluvio di dati. Incoraggiandoti a essere intenzionale, a stabilire standard elevati e ad aspettarti un'alta qualità, l'imposizione dello schema sta facendo esattamente ciò per cui è stato progettato: mantenerti onesto e le tue tabelle pulite.

Se, dopo un'ulteriore revisione, decidi che volevi davvero aggiungere quella nuova colonna, è una correzione facile, su una riga, come discusso di seguito. La soluzione è l'evoluzione dello schema!

Che cos'è l'evoluzione dello schema?

L'evoluzione dello schema è una funzionalità che consente agli utenti di modificare facilmente lo schema corrente di una tabella per adattarsi ai dati che cambiano nel tempo. Più comunemente, viene utilizzato quando si esegue un'operazione di aggiunta o sovrascrittura, per adattare automaticamente lo schema per includere una o più nuove colonne.

Come funziona l'evoluzione dello schema?

Facendo seguito all'esempio della sezione precedente, gli sviluppatori possono facilmente utilizzare l'evoluzione dello schema per aggiungere le nuove colonne che in precedenza erano state rifiutate a causa di una mancata corrispondenza dello schema. L'evoluzione dello schema viene attivata aggiungendo .option('mergeSchema', 'true') al tuo comando Spark .write o .writeStream.

Per visualizzare il grafico, esegui la seguente istruzione Spark SQL.

In alternativa, puoi impostare questa opzione per l'intera sessione Spark aggiungendo spark.databricks.delta.schema.autoMerge = True alla tua configurazione Spark. Usare con cautela, poiché l'imposizione dello schema non ti avviserà più di mancate corrispondenze dello schema non intenzionali.

Includendo l'opzione mergeSchema nella tua query, tutte le colonne presenti nel DataFrame ma non nella tabella di destinazione vengono automaticamente aggiunte alla fine dello schema come parte di una transazione di scrittura. È anche possibile aggiungere campi nidificati e questi campi verranno aggiunti anche alla fine delle rispettive colonne struct.

Data engineer e data scientist possono utilizzare questa opzione per aggiungere nuove colonne (forse una metrica appena tracciata o una colonna delle cifre di vendita di questo mese) alle loro tabelle di produzione di machine learning esistenti senza interrompere i modelli esistenti che si basano sulle vecchie colonne.

I seguenti tipi di modifiche dello schema sono idonei per l'evoluzione dello schema durante le aggiunte o le sovrascritture della tabella:

• Aggiunta di nuove colonne (questo è lo scenario più comune)
• Modifica dei tipi di dati da NullType -> qualsiasi altro tipo o upcast da ByteType -> ShortType -> IntegerType

Altre modifiche, che non sono idonee per l'evoluzione dello schema, richiedono che lo schema e i dati vengano sovrascritti aggiungendo .option("overwriteSchema", "true"). Ad esempio, nel caso in cui la colonna "Foo" fosse originariamente un tipo di dati integer e il nuovo schema sarebbe un tipo di dati stringa, tutti i file Parquet (dati) dovrebbero essere riscritti. Tali modifiche includono:

• Eliminazione di una colonna
• Modifica del tipo di dati di una colonna esistente (sul posto)
• Ridenominazione dei nomi delle colonne che differiscono solo per il caso (ad esempio, "Foo" e "foo")

Infine, con l'imminente rilascio di Spark 3.0, il DDL esplicito (utilizzando ALTER TABLE) sarà pienamente supportato, consentendo agli utenti di eseguire le seguenti azioni sugli schemi delle tabelle:

• Aggiunta di colonne
• Modifica dei commenti delle colonne
• Impostazione delle proprietà della tabella che definiscono il comportamento della tabella, come l'impostazione della durata di conservazione del log delle transazioni

In che modo l'evoluzione dello schema è utile?

L'evoluzione dello schema può essere utilizzata ogni volta che intendi modificare lo schema della tua tabella (al contrario di dove hai aggiunto accidentalmente colonne al tuo DataFrame che non dovrebbero essere lì). È il modo più semplice per migrare il tuo schema perché aggiunge automaticamente i nomi delle colonne e i tipi di dati corretti, senza doverli dichiarare esplicitamente.

Riepilogo

L'imposizione dello schema rifiuta qualsiasi nuova colonna o altre modifiche dello schema che non sono compatibili con la tua tabella. Impostando e sostenendo questi standard elevati, analisti e ingegneri possono fidarsi che i loro dati abbiano i più alti livelli di integrità e ragionare su di essi con chiarezza, consentendo loro di prendere decisioni aziendali migliori.

D'altra parte, l'evoluzione dello schema integra l'imposizione rendendo facile l'esecuzione automatica delle modifiche dello schema previste. Dopotutto, non dovrebbe essere difficile aggiungere una colonna.

L'imposizione dello schema è lo yin dell'evoluzione dello schema. Se utilizzate insieme, queste funzionalità rendono più facile che mai bloccare il rumore e sintonizzarsi sul segnale.

Vorremmo anche ringraziare Mukul Murthy e Pranav Anand per il loro contributo a questo blog.

Correlati

Articoli in questa serie:
Diving Into Delta Lake #1: Disimballaggio del log delle transazioni
Diving Into Delta Lake #2: Imposizione ed evoluzione dello schema
Diving Into Delta Lake #3: Internals DML (Aggiornamento, Eliminazione, Unione)

Productionizing Machine Learning With Delta Lake
Che cos'è un data lake?

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale