🥇Delta Lake Dive: Zbatimi dhe Evolucioni i Skemës

Përshëndetje, Habr! Unë paraqes në vëmendjen tuaj një përkthim të artikullit " Zhytja në liqenin Delta: Zbatimi dhe Evolucioni i Skemës" autorët Burak Yavuz, Brenner Heintz dhe Denny Lee, i cili u përgatit në pritje të fillimit të kursit "Inxhinier i të dhënave" nga OTUS.

Të dhënat, si përvoja jonë, po grumbullohen dhe zhvillohen vazhdimisht. Për të vazhduar, modelet tona mendore të botës duhet t'i përshtaten të dhënave të reja, disa prej të cilave përmbajnë dimensione të reja - mënyra të reja për të vëzhguar gjërat për të cilat nuk kishim asnjë ide më parë. Këto modele mendore nuk janë shumë të ndryshme nga skemat e tabelave që përcaktojnë se si ne i kategorizojmë dhe përpunojmë informacionet e reja.

Kjo na sjell te çështja e menaxhimit të skemave. Ndërsa sfidat dhe kërkesat e biznesit ndryshojnë me kalimin e kohës, kështu ndryshon edhe struktura e të dhënave tuaja. Liqeni Delta e bën të lehtë prezantimin e matjeve të reja ndërsa të dhënat ndryshojnë. Përdoruesit kanë qasje në semantikë të thjeshtë për të menaxhuar skemat e tabelave të tyre. Këto mjete përfshijnë Schema Enforcement, i cili mbron përdoruesit nga ndotja e paqëllimshme e tabelave të tyre me gabime ose të dhëna të panevojshme, dhe Schema Evolution, i cili lejon që kolonat e reja të të dhënave të vlefshme të shtohen automatikisht në vendndodhjet e duhura. Në këtë artikull, ne do të zhytemi më thellë në përdorimin e këtyre mjeteve.

Kuptimi i skemave të tabelave

Çdo DataFrame në Apache Spark përmban një skemë që përcakton formën e të dhënave, siç janë llojet e të dhënave, kolonat dhe metadatat. Me Delta Lake, skema e tabelës ruhet në formatin JSON brenda regjistrit të transaksioneve.

Çfarë është zbatimi i skemës?

Zbatimi i skemës, i njohur gjithashtu si Vlefshmëria e skemës, është një mekanizëm sigurie në Delta Lake që siguron cilësinë e të dhënave duke refuzuar të dhënat që nuk përputhen me skemën e tabelës. Ashtu si zonja në tavolinën e pritjes së një restoranti popullor vetëm me rezervime, ajo kontrollon nëse secila kolonë e të dhënave të futura në tabelë është në listën përkatëse të kolonave të pritura (me fjalë të tjera, nëse ka një "rezervim" për secilën prej tyre ), dhe refuzon çdo regjistrim me kolona që nuk janë në listë.

Si funksionon zbatimi i skemës?

Delta Lake përdor kontrollin e skemës në shkrim, që do të thotë se të gjitha shkrimet e reja në tabelë kontrollohen për pajtueshmëri me skemën e tabelës së synuar në kohën e shkrimit. Nëse skema është e papajtueshme, Delta Lake anulon transaksionin tërësisht (nuk janë shkruar të dhëna) dhe ngre një përjashtim për të njoftuar përdoruesin për mospërputhjen.
Delta Lake përdor rregullat e mëposhtme për të përcaktuar nëse një rekord është i pajtueshëm me një tabelë. Korniza e të dhënave që mund të shkruhet:

nuk mund të përmbajë kolona shtesë që nuk janë në skemën e tabelës së synuar. Në të kundërt, gjithçka është në rregull nëse të dhënat hyrëse nuk përmbajnë absolutisht të gjitha kolonat nga tabela - këtyre kolonave thjesht do t'u caktohen vlera zero.
nuk mund të ketë lloje të të dhënave të kolonave që janë të ndryshme nga llojet e të dhënave të kolonave në tabelën e synuar. Nëse kolona e tabelës së synuar përmban të dhëna StringType, por kolona përkatëse në DataFrame përmban të dhëna IntegerType, zbatimi i skemës do të bëjë një përjashtim dhe do të parandalojë kryerjen e operacionit të shkrimit.
nuk mund të përmbajë emra kolonash që ndryshojnë vetëm sipas rastit. Kjo do të thotë që nuk mund të keni kolona me emrin 'Foo' dhe 'foo' të përcaktuara në të njëjtën tabelë. Ndërsa Shkëndija mund të përdoret në modalitetin e ndjeshëm ndaj shkronjave të vogla ose të vogla (parazgjedhur), Delta Lake ruan numrin e rasteve, por është i pandjeshëm brenda ruajtjes së skemës. Parketi është i ndjeshëm kur ruan dhe kthen informacionin e kolonës. Për të shmangur gabimet e mundshme, prishjen e të dhënave ose humbjen e të dhënave (diçka që e kemi përjetuar personalisht në Databricks), vendosëm të shtojmë këtë kufizim.

Për ta ilustruar këtë, le të hedhim një vështrim se çfarë ndodh në kodin e mëposhtëm kur përpiqemi të shtojmë disa kolona të krijuara rishtazi në një tabelë Delta Lake që ende nuk është konfiguruar për t'i pranuar ato.

# Сгенерируем 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.

Në vend që të shtojë automatikisht kolona të reja, Delta Lake imponon një skemë dhe ndalon së shkruari. Për të ndihmuar në përcaktimin se cila kolonë (ose grup kolonash) po shkakton mospërputhjen, Spark nxjerr të dyja skemat nga gjurma e stivit për krahasim.

Cili është përfitimi i zbatimit të një skeme?

Për shkak se zbatimi i skemës është një kontroll mjaft i rreptë, ai është një mjet i shkëlqyer për t'u përdorur si një derëtar i një grupi të dhënash të pastër, plotësisht të transformuar që është gati për prodhim ose konsum. Zakonisht zbatohet për tabelat që ushqejnë drejtpërdrejt të dhënat:

Algoritmet e mësimit të makinerisë
Paneli i BI
Mjetet e analizës dhe vizualizimit të të dhënave
Çdo sistem prodhimi që kërkon skema semantike shumë të strukturuara dhe të shtypura fort.

Për të përgatitur të dhënat e tyre për këtë pengesë përfundimtare, shumë përdorues përdorin një arkitekturë të thjeshtë "multi-hop" që gradualisht fut strukturën në tabelat e tyre. Për të mësuar më shumë rreth kësaj, mund të shikoni artikullin Mësimi i makinerive të nivelit të prodhimit me Delta Lake.

Sigurisht, zbatimi i skemës mund të përdoret kudo në tubacionin tuaj, por mbani mend se transmetimi në një tabelë në këtë rast mund të jetë zhgënjyes sepse, për shembull, keni harruar se keni shtuar një kolonë tjetër në të dhënat hyrëse.

Parandalimi i hollimit të të dhënave

Deri tani ju mund të pyesni veten, për çfarë është gjithë bujë? Në fund të fundit, ndonjëherë një gabim i papritur "mospërputhje skeme" mund t'ju pengojë në rrjedhën tuaj të punës, veçanërisht nëse jeni i ri në Delta Lake. Pse të mos lejoni që skema të ndryshojë sipas nevojës, në mënyrë që të mund të shkruaj DataFrame-in tim pa marrë parasysh çfarë?

Siç thotë thënia e vjetër, "një ons parandalimi vlen një kile kurimi". Në një moment, nëse nuk kujdeseni për të zbatuar skemën tuaj, problemet e përputhshmërisë së tipit të të dhënave do të ngrenë kokën e tyre të shëmtuar - burimet e të dhënave të papërpunuara në dukje homogjene mund të përmbajnë raste të skajeve, kolona të korruptuara, harta të keqformuara ose gjëra të tjera të frikshme për të ëndërruar. makthet. Qasja më e mirë është t'i ndaloni këta armiq në portë - me zbatimin e skemës - dhe t'i trajtoni ata në dritë, dhe jo më vonë kur të fillojnë të përgjojnë në thellësitë e errëta të kodit tuaj të prodhimit.

Zbatimi i një skeme ju jep sigurinë se skema e tabelës suaj nuk do të ndryshojë nëse nuk e miratoni ndryshimin. Kjo parandalon hollimin e të dhënave, që mund të ndodhë kur kolonat e reja shtohen aq shpesh sa tabelat e ngjeshura më parë të vlefshme humbasin kuptimin dhe dobinë e tyre për shkak të përmbytjes së të dhënave. Duke ju inkurajuar të jeni të qëllimshëm, të vendosni standarde të larta dhe të prisni cilësi të lartë, zbatimi i skemës bën pikërisht atë që ishte krijuar për të bërë - ju ndihmon të qëndroni të ndërgjegjshëm dhe tabelat tuaja të pastra.

Nëse pas shqyrtimit të mëtejshëm ju vendosni se ju me të vërtetë нужно shtoni një kolonë të re - nuk ka problem, më poshtë është një rregullim me një rresht. Zgjidhja është evolucioni i qarkut!

Çfarë është evolucioni i skemës?

Evolucioni i skemës është një veçori që lejon përdoruesit të ndryshojnë lehtësisht skemën aktuale të tabelës sipas të dhënave që ndryshojnë me kalimin e kohës. Më shpesh përdoret kur kryen një operacion shtojce ose rishkrimi për të përshtatur automatikisht skemën për të përfshirë një ose më shumë kolona të reja.

Si funksionon evolucioni i skemës?

Duke ndjekur shembullin nga seksioni i mëparshëm, zhvilluesit mund të përdorin lehtësisht evolucionin e skemës për të shtuar kolona të reja që më parë ishin refuzuar për shkak të mospërputhjes së skemës. Evolucioni i qarkut aktivizohet duke shtuar .option('mergeSchema', 'true') për ekipin tuaj Spark .write или .writeStream.

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

Për të parë grafikun, ekzekutoni pyetjen e mëposhtme të 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

Përndryshe, mund ta vendosni këtë opsion për të gjithë sesionin e Spark duke shtuar spark.databricks.delta.schema.autoMerge = True te konfigurimi Spark. Por përdorni këtë me kujdes, pasi zbatimi i skemës nuk do t'ju paralajmërojë më për mospërputhjet e paqëllimshme të skemës.

Duke përfshirë parametrin në kërkesë mergeSchema, të gjitha kolonat që janë të pranishme në DataFrame por jo në tabelën e synuar shtohen automatikisht në fund të skemës si pjesë e një transaksioni shkrimi. Mund të shtohen edhe fusha të mbivendosura dhe këto do të shtohen gjithashtu në fund të kolonave të strukturës përkatëse.

Inxhinierët e datave dhe shkencëtarët e të dhënave mund ta përdorin këtë opsion për të shtuar kolona të reja (ndoshta një metrikë të gjurmuar së fundmi ose kolonën e performancës së shitjeve të këtij muaji) në tabelat e tyre ekzistuese të prodhimit të mësimit të makinerive pa thyer modelet ekzistuese bazuar në kolonat e vjetra.

Llojet e mëposhtme të ndryshimeve të skemës lejohen si pjesë e evolucionit të skemës gjatë një shtimi ose rishkrimi të tabelës:

Shtimi i kolonave të reja (ky është skenari më i zakonshëm)
Ndryshimi i llojeve të të dhënave nga NullType -> çdo lloj tjetër ose promovimi nga ByteType -> ShortType -> IntegerType

Ndryshime të tjera që nuk lejohen brenda evolucionit të skemës kërkojnë që skema dhe të dhënat të rishkruhen duke shtuar .option("overwriteSchema", "true"). Për shembull, në rastin kur kolona "Foo" ishte fillimisht një numër i plotë dhe skema e re ishte një lloj i të dhënave vargu, atëherë të gjithë skedarët Parquet(data) do të duhej të rishkruheshin. Ndryshime të tilla përfshijnë:

fshirja e një kolone
ndryshimi i llojit të të dhënave të një kolone ekzistuese (në vend)
riemërtimi i kolonave që ndryshojnë vetëm sipas rastit (për shembull, "Foo" dhe "foo")

Së fundi, me lëshimin e ardhshëm të Spark 3.0, DDL eksplicite do të mbështetet plotësisht (duke përdorur ALTER TABLE), duke i lejuar përdoruesit të kryejnë veprimet e mëposhtme në skemat e tabelave:

duke shtuar kolona
ndryshimi i komenteve të kolonës
vendosja e vetive të tabelës që kontrollojnë sjelljen e tabelës, si p.sh. përcaktimi i kohëzgjatjes së kohës që ruhet një regjistër i transaksioneve.

Cili është përfitimi i evolucionit të qarkut?

Evolucioni i skemës mund të përdoret sa herë që ju synojnë ndryshoni skemën e tabelës suaj (në krahasim me rastin kur keni shtuar aksidentalisht kolona në DataFrame tuaj që nuk duhet të jenë aty). Kjo është mënyra më e lehtë për të migruar skemën tuaj, sepse ajo shton automatikisht emrat e duhur të kolonave dhe llojet e të dhënave, pa pasur nevojë t'i deklaroni ato në mënyrë eksplicite.

Përfundim

Zbatimi i skemës refuzon çdo kolonë të re ose ndryshim tjetër të skemës që nuk është në përputhje me tabelën tuaj. Duke vendosur dhe mbajtur këto standarde të larta, analistët dhe inxhinierët mund të besojnë se të dhënat e tyre kanë nivelin më të lartë të integritetit, duke i komunikuar qartë dhe qartë, duke i lejuar ata të marrin vendime më të mira biznesi.

Nga ana tjetër, evolucioni i skemës plotëson zbatimin duke e thjeshtuar i supozuar ndryshimet automatike të skemës. Në fund të fundit, nuk duhet të jetë e vështirë të shtosh një kolonë.

Zbatimi i detyruar i skemës është yang, ku evolucioni i skemës është yin. Kur përdoren së bashku, këto veçori e bëjnë më të lehtë se kurrë shtypjen e zhurmës dhe sintonizimin e sinjalit.

Ne gjithashtu dëshirojmë të falënderojmë Mukul Murthy dhe Pranav Anand për kontributin e tyre në këtë artikull.

Artikuj të tjerë në këtë seri:

Zhyt në Liqenin Delta: Shpaketimi i regjistrit të transaksioneve