🥇Zhytesh në Delta Lake: Zbatimi dhe evolucioni i detyrës

Përshëndetje, Habr! Ju prezantoj përkthimin e artikullit «Përkufizimi i Delta Lake: Zbatimi i Skemës & Evolucioni» nga autorët Burak Yavuz, Brenner Heintz dhe Denny Lee, i përgatitur para fillimit të kursit «Inxhiner i Të Dhënave» nga OTUS.

Të dhënat, si dhe përvoja jonë, vazhdimisht akumulohen dhe zhvillohen. Për të mos mbetur prapa, modelet tona mendore të botës duhet të adaptohen me të dhëna të reja, disa prej të cilave përmbajnë dimensione të reja — mënyra të reja për të vëzhguar gjëra për të cilat më parë nuk kishim ide. Këto modele mendore nuk dallohen shumë nga skemat e tabelave, të cilat përcaktojnë se si ne klasifikojmë dhe përpunojmë informacionin e ri.

Kjo na çon në çështjen e menaxhimit të skemave. Ndërsa detyrat dhe kërkesat e biznesit ndryshojnë me kalimin e kohës, ashtu ndryshon edhe struktura e të dhënave tuaja. Delta Lake lejon integrimin e lehtë të dimensioneve të reja kur ndodhin ndryshime në të dhëna. Përdoruesit kanë qasje në një semantikë të thjeshtë për të menaxhuar skemat e tabelave të tyre. Këto mjete përfshijnë forcimin e skemës (Schema Enforcement), i cili mbron përdoruesit nga ndotja e paqëllimtë të tabelave të tyre me gabime ose të dhëna të panevojshme, si dhe evolucionin e skemës (Schema Evolution), i cili lejon shtimin automatik të kolonave të reja me të dhëna të vlefshme në vende të përshtatshme. Në këtë artikull, ne do të thellohemi në përdorimin e këtyre mjeteve.

Kuptimi i skemave të tabelave

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

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

Принудительное применение схемы (Schema Enforcement), также известное как проверка схемы (Schema Validation), является защитным механизмом в Delta Lake, который гарантирует качество данных, отклоняя записи, которые не соответствуют схеме таблицы. Как и хостес на стойке регистрации в популярном ресторане, который принимает только по предварительной брони, он проверяет, есть ли каждый столбец данных, вводимых в таблицу, в соответствующем списке ожидаемых столбцов (другими словами, есть ли для каждого из них «бронь»), и отклоняет любые записи со столбцами, которых нет в списке.

Как работает принудительное применение схемы?

Delta Lake использует проверку схемы при записи, что означает, что все новые записи в таблицу проверяются на совместимость со схемой целевой таблицы во время записи. Если схема несовместима, Delta Lake полностью отменяет транзакцию (данные не записываются) и создает исключение, чтобы сообщить пользователю о несоответствии.
Для определения совместимости записи с таблицей Delta Lake использует следующие правила. Записываемый DataFrame:

nuk mund të përmbajë kolona shtesë që nuk janë në skemën e tabelës së synuar. Dhe përkundrazi, gjithçka është në rregull nëse të dhënat hyrëse nuk përmbajnë të gjitha kolonat nga tabela — këtyre kolonave thjesht do t'u jepen vlera zero.
nuk mund të ketë tipe të dhënash të kolonave që ndryshojnë nga tipet e dhënash të kolonave në tabelën e synuar. Nëse një kolone e tabelës së synuar përmban të dhëna StringType, por kolona përkatëse në DataFrame përmban të dhëna IntegerType, forcimi i aplikimit të skemës do të shkaktojë një përjashtim dhe do të parandalojë ekzekutimin e operacionit të shkrimit.
nuk mund të përmbajë emra kolonash që ndryshojnë vetëm në regjistrim. Kjo do të thotë se nuk mund të keni kolona me emrat ‘Foo’ dhe ‘foo’, të përcaktuara në një tabelë. Edhe pse Spark mund të përdoret në një modalitet të ndjeshëm ose të pa ndjeshëm ndaj regjistrimit (në parazgjedhje), Delta Lake ruan regjistrin, por është i pa ndjeshëm në kuadër të ruajtjes së skemës. Parquet është i ndjeshëm ndaj regjistrit gjatë ruajtjes dhe rikthimit të informacionit të kolonës. Për të shmangur mundësinë e gabimeve, dëmtimit të të dhënave ose humbjes së tyre (me të cilat ne vetë jemi përballur në Databricks), ne vendosëm të shtojmë këtë kufizim.

Për të ilustruar këtë, le të shohim se çfarë ndodh në kodin e dhënë më poshtë kur përpiqemi të shtojmë disa kolona të reja të gjeneruara në tabelën Delta Lake, e cila ende nuk është e konfigurueshme 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 shkrimin. Për të ndihmuar në identifikimin e cilës do kolonë (apo disa) është shkaku i mosmasë, Spark shfaq të dyja skemat nga stack trace për krahasim.

Cila është përfitimi i forcimit të skemës?

Duke qenë se forcimi i skemës përbën një kontroll mjaft strik, ai është një mjet i shkëlqyer për t'u përdorur si portier i një grumbulli të pastër dhe të plotësisht të transformuar të dhënash, i cili është gati për prodhim ose konsum. Në përgjithësi, aplikohet në tabelat që shërbejnë drejtpërdrejt të dhënat:

Algoritmet e mësimit të makinave
Dashboard-e BI
Analiza e të dhënave dhe mjetet e vizualizimit
Cilësdo sistem prodhimi që kërkon skema semantike strikt të strukturuara dhe tipizuara.

Për të përgatitur të dhënat e tua për këtë barrierë përfundimtare, shumë përdorues përdorin një arkitekturë të thjeshtë “multi-hop” që gradualisht i jep strukturë tabela të tyre. Për të mësuar më shumë rreth kësaj, mund të shqyrtosh artikullin Mësoni makinat e nivelit prodhues me Delta Lake.

Sigurisht, aplikimi i detyruar i skemës mund të përdoret në çdo vend të pipeline tuaj, por mbani mend se shkruajta në tabelë në këtë rast mund të jetë e frustrueshme, pasi për shembull, mund të keni harruar se keni shtuar një kolonë të re në të dhënat hyrëse.

Parandalimi i hollimit të të dhënave

Në këtë pikë, mund të pyesni vetën pse ka kaq shumë zhurmë? Në fund të fundit, ndonjëherë një gabim i papritur “mos përputhje skeme” mund t’ju vërë në një telashe në procesin tuaj të punës, veçanërisht nëse jeni fillestar me Delta Lake. Pse thjesht të mos lejojë skemën të ndryshojë siç është e nevojshme që unë të mund të shkruaj DataFrame tim, pavarësisht nga gjithçka?

Siç thotë një proverb i vjetër, "një onçë parandalim kushton një paund trajtim". Në një moment, nëse nuk kujdeseni për të zbatuar skemën tuaj, problemet me përputhshmërinë e llojeve të të dhënave do të ngrihen në mënyrë të pakëndshme — burimet e dukshme homogjene të të dhënave të papërpunuara mund të përmbajnë raste të skajshme, kolona të dëmtuara, përshkrime të formuara gabimisht ose gjëra të tjera të frikshme që shfaqen në makthet. Qasja më e mirë është të ndaloni këta armiq në portë — duke imponuar zbatimin e skemës — dhe t'i përballeni atyre në dritë, jo më vonë, kur ata fillojnë të rregullohen në thellësitë e errëta të kodit tuaj të punës.

Zbatja e detyrueshme e skemës jep siguri se skema e tabelës suaj nuk do të ndryshojë, përveç nëse ju vetë e konfirmoni opsionin e ndryshimit. Kjo parandalon "të hollimin" e të dhënave, që mund të ndodhë kur kolonat e reja shtohen me kaq shumë shpejtësi saqë tabelat e vjetra, të vlefshme dhe të përmbledhura, humbin vlerën dhe përdorshmërinë e tyre për shkak të ndotjes me të dhëna. Duke inkurajuar që të jeni të qëllimshëm, të vendosni standarde të larta dhe të prisni cilësi të lartë, zbatimi i detyrueshëm i skemës bën pikërisht atë për të cilën ishte menduar - të ndihmojë që të mbeteni të ndershëm dhe tabelat tuaja të mbeten të pastra.

Nëse, pas shqyrtimit të mëtejshëm, vendosni se në të vërtetë nevojitet të shtoni një kolonë të re - asnjë problem, më poshtë është një zgjidhje një-linjë. Zgjidhja është evolucioni i skemës!

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

Evolucioni i skemës është një funksion që lejon përdoruesit të ndryshojnë lehtësisht skemën aktuale të tabelës në përputhje me të dhënat që ndryshojnë me kalimin e kohës. Përdoret më së shpeshti gjatë operacioneve të shtimit ose përshkrimit, për të adaptuar automatikisht skemën për të përfshirë një ose disa 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, të cilat më parë ishin refuzuar për shkak të mos përputhshmërisë me skemën. Evolucioni i skemës aktivizohet duke shtuar .option('mergeSchema', 'true') në komandën tuaj të Spark .write ose .writeStream.

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

Për të parë grafikun, kryeni këtë kërkesë 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

Alternativisht, mund të vendosni këtë opsion për të gjithë seancën e Spark, duke shtuar spark.databricks.delta.schema.autoMerge = True në konfigurimin e Spark. Por, përdoreni këtë me kujdes, pasi zbatimi i detyrueshëm i skemës nuk do t'ju paralajmërojë më për mos përputhshmëritë e papara me skemën.

Duke përfshirë në kërkesë parametrin mergeSchema, gjithë kolumnat që janë në DataFrame, por mungojnë në tabelën e destinacionit, automatikisht shtohen në fund të skemës në kuadër të transaksionit të shkruar. Po ashtu, mund të shtohen fusha të ngulitura, dhe ato gjithashtu do të shtohen në fund të kolumnave përkatëse të strukturës.

Inxhinierët dhe shkencëtarët e të dhënave mund të përdorin këtë opsion për të shtuar kolona të reja (ndoshta një metrikë që është monitoruar së fundmi ose një kolona treguesish shitjesh për këtë muaj) në tabelat e tyre ekzistuese të prodhimit për mësimin e makinerisë, pa prishur modelet ekzistuese të bazuara në kolona të vjetra.

Llojet e ardhshme të ndryshimeve të skemës janë të pranuara brenda evolucionit të skemës gjatë shtimit ose rinovimit të tabelës:

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

Ndryshime të tjera, që janë të papranueshme brenda evolucionit të skemës, kërkojnë që skema dhe të dhënat të rivendosen duke shtuar .option("overwriteSchema", "true"). Për shembull, në rastin kur kolona «Foo» fillimisht ishte integer, dhe skema e re do të ishte e tipit string, atëherë të gjithë skedarët Parquet (të dhënat) do të duhej të shkruheshin përsëri. Ndryshime të tilla përfshijnë:

heqjen e kolonës
ndryshimin e tipit të të dhënave të kolonës ekzistuese (në vend)
rilindjen e kolonave që ndryshojnë vetëm në regjistër (p.sh., «Foo» dhe «foo»)

Më në fund, me rilindjen e ardhshme Spark 3.0 do të mbështetet plotësisht DDL e qartë (duke përdorur ALTER TABLE), e cila do t'u lejojë përdoruesve të kryejnë veprimet e mëposhtme mbi skemat e tabelave:

shtimin e kolonave
ndryshimin e komenteve të kolonave
konfigurimin e pronave të tabelës që përcaktojnë sjelljen e tabelës, për shembull, caktimin e kohëzgjatjes së ruajtjes së regjistrit të transaksioneve.

Cila është përfitimi i evolucionit të skemës?

Evolucioni i skemës mund të përdoret gjithmonë kur ju keni ndërmend ndryshoni skemën e tabelës suaj (ndryshe nga rastet kur aksidentalisht keni shtuar në DataFrame tuaj kolona që nuk duhet të ishin aty). Kjo është mënyra më e lehtë për të migruar skemën tuaj, sepse automatikisht shton emrat e duhur të kolonave dhe llojet e të dhënave pa pasur nevojë për shpalljen e tyre të qartë.

Përfundimi

Zbatimi i detyrueshëm i skemës refuzon çdo kolonë të re ose ndryshime të tjera të skemës që nuk janë të përshtatshme me tabelën tuaj. Duke vendosur dhe ruajtur këto standarde të larta, analistët dhe inxhinierët mund të besojnë se të dhënat e tyre kanë një nivel të lartë integriteti, duke argumentuar për këtë qartë dhe ndryshe, duke u lejuar atyre të marrin vendime më efektive në biznes.

Nga ana tjetër, evolucioni i skemës plotëson zbatimin e detyrueshëm, duke thjeshtuar ndryshimet e supozuara automatik. Në fund të fundit, kjo nuk duhet të jetë komplekse — të shtosh një kolonë.

Zbatimi i detyrueshëm i skemës është yan, ndërsa evolucioni i skemës është yin. Kur përdoren së bashku, këto funksione e bëjnë më të lehtë se kurrë minimizimin e zhurmës dhe optimizimin e sinjalit.

Po ashtu dëshirojmë të falënderojmë Mukul Murti dhe Pranav Anand për kontributin e tyre në këtë artikull.

Artikujt e tjerë në këtë seri:

Zhytesh në Delta Lake: Zhbllokimi i regjistrit të transaksioneve