Immergete in Delta Lake: Skema Enforcement and Evolution

Ehi Habr! Prestu à a vostra attenzione a traduzzione di l'articulu "Immersione in Delta Lake: Imputazione di Schema è Evoluzione" l'autori Burak Yavuz, Brenner Heintz è Denny Lee, chì era preparatu in anticipazione di l'iniziu di u cursu Ingegnere di dati da OTUS.

Immergete in Delta Lake: Skema Enforcement and Evolution

I dati, cum'è a nostra sperienza, sò constantemente accumulendu è evoluzione. Per mantene, i nostri mudelli mentali di u mondu devenu adattà à novi dati, alcuni di i quali cuntenenu novi dimensioni - novi modi di osservà e cose chì ùn avemu micca idea di prima. Questi mudelli mentali ùn sò micca assai diffirenti da i schemi di tavulinu chì determinanu cumu categurizà è processà a nova infurmazione.

Questu ci porta à u prublema di a gestione di schema. Cume i sfidi è i bisogni di l'affari cambianu cù u tempu, cusì a struttura di i vostri dati. Delta Lake facilita l'introduzione di novi misurazioni cum'è cambiamenti di dati. L'utilizatori anu accessu à una semantica simplice per gestisce i so schemi di tabella. Questi arnesi includenu Schema Enforcement, chì prutege l'utilizatori da a contaminazione involontaria di e so tavule cù errori o dati innecessarii, è Schema Evolution, chì permette à novi culonni di dati preziosi per esse aghjuntu automaticamente à i lochi appropritati. In questu articulu, andemu più in profondità in l'usu di sti strumenti.

Capisce i schemi di tavule

Ogni DataFrame in Apache Spark cuntene un schema chì definisce a forma di e dati, cum'è tipi di dati, colonne è metadata. Cù Delta Lake, u schema di a tavola hè almacenatu in formatu JSON in u logu di transazzione.

Chì ghjè l'applicazione di u schema?

Schema Enforcement, cunnisciutu ancu Schema Validation, hè un mecanismu di sicurezza in Delta Lake chì assicura a qualità di dati rifiutendu i registri chì ùn currispondenu micca à u schema di a tavola. Cum'è l'hostess à a reception di un ristorante populari solu di riservazione, verifica se ogni culonna di dati inserita in a tavula hè in a lista currispondente di colonne previste (in altre parolle, s'ellu ci hè una "riservazione" per ognuna di elli). ), è rifiuta tutti i registri cù colonne chì ùn sò micca in a lista.

Cumu funziona l'applicazione di schema?

Delta Lake usa a verificazione di schema-on-write, chì significa chì tutti i novi scritti à a tavula sò verificati per a cumpatibilità cù u schema di a tavola di destinazione à u tempu di scrittura. Se u schema hè inconsistente, Delta Lake abortisce a transazzione sanu (senza dati hè scrittu) è suscita una eccezzioni per avvisà l'utilizatori di l'inconsistenza.
Delta Lake usa e regule seguenti per stabilisce se un registru hè cumpatibile cù una tavola. DataFrame scrivibile:

  • ùn pò micca cuntene colonne supplementari chì ùn sò micca in u schema di a tabella di destinazione. À u cuntrariu, tuttu hè bè se i dati entranti ùn cuntenenu micca assolutamente tutte e culonni da a tavula - sti culonni seranu simpliciamente attribuiti valori nulli.
  • ùn pò micca avè tipi di dati di colonna chì sò diffirenti da i tipi di dati di e colonne in a tavola di destinazione. Se a colonna di a tavola di destinazione cuntene dati StringType, ma a colonna currispundente in u DataFrame cuntene dati IntegerType, l'infurzazioni di schema lancerà una eccezzioni è impedisce l'operazione di scrittura.
  • ùn pò micca cuntene i nomi di colonna chì sò diffirenti solu in casu. Questu significa chì ùn pudete micca avè colonne chjamate "Foo" è "foo" definite in a listessa tavola. Mentre Spark pò esse aduprata in u modu case-sensitive o case-insensitive (predefinitu), Delta Lake hè a preservazione di casu, ma hè insensibile in u almacenamentu di schema. Parquet hè sensible à maiuscule di minuscule quandu almacenà è rinvia l'infurmazioni di a colonna. Per evitari pussibuli errori, corruzzione di dati, o perdita di dati (qualcosa chì avemu avutu personalmente in Databricks), avemu decisu di aghjunghje sta limitazione.

Per illustrà questu, fighjemu un'occhiata à ciò chì succede in u codice sottu quandu pruvemu à aghjunghje alcune colonne di novu generatu à una tavola di Delta Lake chì ùn hè ancu cunfigurata per accettà.

# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
            SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
            CAST(rand(10) * 10000 * count AS double) AS amount
            FROM loan_by_state_delta
            """)

# Вывести исходную схему DataFrame
original_loans.printSchema()

root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
 
# Вывести новую схему DataFrame
loans.printSchema()
 
root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
  |-- amount: double (nullable = true) # new column
 
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta") 
           .mode("append") 
           .save(DELTALAKE_PATH)

Returns:

A schema mismatch detected when writing to the Delta table.
 
To enable schema migration, please set:
'.option("mergeSchema", "true")'
 
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
 
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
 
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.

Invece di aghjunghje automaticamente novi colonne, Delta Lake impone un schema è ferma a scrittura. Per aiutà à determinà quale colonna (o inseme di colonne) causa a discrepanza, Spark produce i dui schemi da a traccia di stack per paragunà.

Chì ci hè u benefiziu di rinfurzà un schema?

Perchè l'applicazione di schema hè un cuntrollu abbastanza strettu, hè un strumentu eccellente per aduprà cum'è un guardianu à un settore di dati puliti, cumpletamente trasformatu chì hè prontu per a produzzione o u cunsumu. Tipicamente applicata à e tavule chì alimentanu direttamente i dati:

  • Algoritmi di machine learning
  • Dashboards BI
  • Strumenti di analisi di dati è visualizazione
  • Ogni sistema di pruduzzione chì richiede schemi semantici altamente strutturati, forti tipati.

Per preparà e so dati per questu ostaculu finali, assai utilizatori utilizanu una architettura simplice "multi-hop" chì introduce gradualmente struttura in i so tavulini. Per sapè di più nantu à questu, pudete cunsultà l'articulu Apprendimentu automaticu di produzzione cù Delta Lake.

Di sicuru, l'infurzazione di schema pò esse usata in ogni locu in u vostru pipeline, ma ricordate chì u streaming à una tavula in questu casu pò esse frustrante perchè, per esempiu, vi scurdate chì aghjunghje una altra colonna à i dati entranti.

Impedisce a diluzione di dati

A oramai vi vi dumandate, chì hè tuttu u rumore? Dopu tuttu, qualchì volta un errore inesperu di "discordanza di schema" pò scaccià in u vostru flussu di travagliu, soprattuttu se site novu in Delta Lake. Perchè ùn lasciate micca solu u schema cambià quantu necessariu per pudè scrive u mo DataFrame ùn importa ciò chì?

Cume dice u vechju dittu, "un grammu di prevenzione vale a pena una libbra di cura". À un certu puntu, sè ùn avete micca cura di rinfurzà u vostru schema, i prublemi di cumpatibilità di u tipu di dati susciteranu a so testa brutta - fonti di dati crudi apparentemente omogenei ponu cuntene casi di punta, colonne corrotte, mappings malformati, o altre cose spaventose per sognu. incubi. U megliu approcciu hè di piantà questi nemici à a porta - cù l'infurzazioni di schema - è trattà cun elli in a luce, piuttostu chè più tardi quandu cumincianu à lurking in a prufundità scura di u vostru codice di produzzione.

Infurzà un schema vi dà l'assicuranza chì u schema di a vostra tavula ùn cambierà micca, salvu chì avete appruvatu u cambiamentu. Questu impedisce a diluzione di dati, chì pò accade quandu e colonne novi sò aghjunte cusì freti chì i tavulini cumpressi previamente preziosi perde u so significatu è utilità per via di l'inundazione di dati. Incuraghjenduvi à esse intenzionale, stabilisce standard elevati, è aspettate di alta qualità, l'infurzazione di schema faci esattamente ciò chì hè stata cuncepita per fà - aiutavi à mantene a cuscenza è i vostri fogli di calculu puliti.

Se dopu à più cunsiderazione decide chì veramente bisognu aghjunghje una nova colonna - senza prublema, quì sottu hè una correzione in una linea. A suluzione hè l'evoluzione di u circuitu !

Chì ghjè l'evoluzione di schema?

L'evoluzione di u schema hè una funzione chì permette à l'utilizatori di cambià facilmente l'schema di a tabella attuale secondu e dati chì cambianu cù u tempu. Hè u più spessu usatu quandu eseguisce una operazione di append o riscrittura per adattà automaticamente u schema per include una o più colonne novi.

Cumu funziona l'evoluzione di schema?

In seguitu à l'esempiu di a sezione precedente, i sviluppatori ponu facilmente aduprà l'evoluzione di schema per aghjunghje novi culonni chì sò stati rifiutati prima per l'inconsistenza di schema. L'evoluzione di u circuitu hè attivatu aghjunghjendu .option('mergeSchema', 'true') à a vostra squadra Spark .write или .writeStream.

# Добавьте параметр mergeSchema
loans.write.format("delta") 
           .option("mergeSchema", "true") 
           .mode("append") 
           .save(DELTALAKE_SILVER_PATH)

Per vede u graficu, eseguite a seguente query Spark SQL

# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10

Immergete in Delta Lake: Skema Enforcement and Evolution
In alternativa, pudete stabilisce sta opzione per tutta a sessione Spark aghjustendu spark.databricks.delta.schema.autoMerge = True à a cunfigurazione Spark. Ma aduprate questu cun prudenza, postu chì l'applicazione di schema ùn vi avviserà più per inconsistenzi di schema involontariu.

Cumprendu u paràmetru in a dumanda mergeSchema, tutti i culonni chì sò prisenti in u DataFrame ma micca in a tavula di destinazione sò automaticamente aghjuntu à a fine di u schema cum'è parte di una transazzione di scrittura. I campi nidificati ponu ancu esse aghjuntu è questi seranu ancu aghjuntu à a fine di e colonne di struttura currispundenti.

L'ingegneri di dati è i scientisti di dati ponu aduprà sta opzione per aghjunghje colonne novi (forse una metrica tracciata di pocu tempu o a colonna di u rendiment di vendita di u mese) à e so tabelle di produzzione di apprendimentu automaticu esistenti senza rompe i mudelli esistenti basati nantu à e colonne antiche.

I seguenti tipi di cambiamenti di schema sò permessi cum'è parte di l'evoluzione di schema durante una aghjunta di tabella o riscrittura:

  • Adding new columns (questu hè u scenariu più cumuni)
  • Cambia tipi di dati da NullType -> qualsiasi altru tipu o prumove da ByteType -> ShortType -> IntegerType

L'altri cambiamenti chì ùn sò micca permessi in l'evoluzione di u schema necessitanu chì u schema è i dati sò riscritti per aghjunghje .option("overwriteSchema", "true"). Per esempiu, in u casu induve a colonna "Foo" era urigginariamente un integer è u novu schema era un tipu di dati di stringa, allora tutti i schedarii Parquet (dati) anu da esse riscritti. Tali cambiamenti includenu:

  • sguassà una colonna
  • cambià u tipu di dati di una colonna esistente (in situ)
  • rinominà e colonne chì sò diffirenti solu in casu (per esempiu, "Foo" è "foo")

Infine, cù a prossima versione di Spark 3.0, DDL esplicitu serà cumplettamente supportatu (aduprendu ALTER TABLE), chì permette à l'utilizatori di realizà e seguenti azzioni nantu à schemi di tabella:

  • aghjunghje culonni
  • mudificà i cumenti di a colonna
  • stabilisce e pruprietà di a tavola chì cuntrollanu u cumpurtamentu di a tavola, cum'è stabilisce a durata di u tempu chì un logu di transazzione hè almacenatu.

Chì ghjè u benefiziu di l'evoluzione di u circuitu?

L'evoluzione di schema pò esse usata ogni volta intende cambià u schema di a vostra tavula (in uppusizione à quandu avete aghjustatu accidentalmente colonne à u vostru DataFrame chì ùn deve micca esse quì). Questu hè u modu più faciule per migrà u vostru schema perchè aghjunghje automaticamente i nomi di colonna curretti è i tipi di dati senza avè da esse dichjarà esplicitamente.

cunchiusioni

L'applicazione di u schema rifiuta ogni nova colonna o altri cambiamenti di schema chì ùn sò micca cumpatibili cù a vostra tavola. Fixendu è mantenendu sti standard elevati, l'analista è l'ingegneri ponu cunfidenza chì i so dati anu u più altu livellu di integrità, cumunicanu chjaramente è chjaramente, chì li permettenu di fà megliu decisioni cummerciale.

Per d 'altra banda, l'evoluzione di schema cumplementa l'infurzazioni simplificendu presunta cambiamenti automatichi di schema. Dopu tuttu, ùn deve esse difficiule di aghjunghje una colonna.

L'applicazione forzata di u schema hè yang, induve l'evoluzione di u schema hè yin. Quandu s'utilice inseme, queste caratteristiche facenu a suppressione di u rumore è a sintonizazione di u signale più faciule ch'è mai.

Vulemu ancu ringrazià Mukul Murthy è Pranav Anand per i so cuntributi à questu articulu.

Altri articuli in questa serie:

Immergete in Delta Lake: Unpacking the Transaction Log

Articuli cunnessi

Apprendimentu automaticu di produzzione cù Delta Lake

Chì ghjè un lacu di dati?

Scopri di più nantu à u corsu

Source: www.habr.com

Add a comment