Haai Habr! Ek bied die vertaling van die artikel aan u aandag skrywers Burak Yavuz, Brenner Heintz en Denny Lee, wat voorberei is in afwagting van die begin van die kursus van OTUS.
Data, soos ons ervaring, versamel en ontwikkel voortdurend. Om tred te hou, moet ons geestelike modelle van die wêreld aanpas by nuwe data, waarvan sommige nuwe dimensies bevat—nuwe maniere om dinge waar te neem waarvan ons voorheen geen idee gehad het nie. Hierdie verstandelike modelle verskil nie veel van die tabelskemas wat bepaal hoe ons nuwe inligting kategoriseer en verwerk nie.
Dit bring ons by die kwessie van skemabestuur. Soos besigheidsuitdagings en vereistes met verloop van tyd verander, verander die struktuur van jou data ook. Delta Lake maak dit maklik om nuwe metings bekend te stel soos data verander. Gebruikers het toegang tot eenvoudige semantiek om hul tabelskemas te bestuur. Hierdie instrumente sluit in Skema Enforcement, wat gebruikers beskerm teen onbedoelde besoedeling van hul tabelle met foute of onnodige data, en Schema Evolution, wat toelaat dat nuwe kolomme van waardevolle data outomaties by die toepaslike liggings gevoeg word. In hierdie artikel sal ons dieper ingaan op die gebruik van hierdie gereedskap.
Verstaan tabelskemas
Elke DataFrame in Apache Spark bevat 'n skema wat die vorm van die data definieer, soos datatipes, kolomme en metadata. Met Delta Lake word die tabelskema in JSON-formaat in die transaksielogboek gestoor.
Wat is skema-afdwinging?
Skema Enforcement, ook bekend as Skema Validation, is 'n sekuriteitsmeganisme in Delta Lake wat datakwaliteit verseker deur rekords te verwerp wat nie by die tabel se skema pas nie. Soos die gasvrou by die ontvangstoonbank van 'n gewilde restaurant wat slegs bespreek word, kyk sy of elke kolom data wat in die tabel ingevoer word in die ooreenstemmende lys verwagte kolomme is (met ander woorde of daar 'n "bespreking" vir elkeen van hulle is ), en verwerp enige rekords met kolomme wat nie in die lys is nie.
Hoe werk skema-afdwinging?
Delta Lake gebruik skema-op-skryf-kontrolering, wat beteken dat alle nuwe skryfwerk na die tabel gekontroleer word vir versoenbaarheid met die teikentabel se skema tydens skryftyd. As die skema inkonsekwent is, staak Delta Lake die transaksie heeltemal (geen data word geskryf nie) en maak 'n uitsondering om die gebruiker van die teenstrydigheid in kennis te stel.
Delta Lake gebruik die volgende reëls om te bepaal of 'n rekord versoenbaar is met 'n tabel. Skryfbare dataraam:
- kan nie bykomende kolomme bevat wat nie in die teikentabel se skema is nie. Omgekeerd is alles in orde as die inkomende data nie absoluut al die kolomme van die tabel bevat nie - hierdie kolomme sal bloot nulwaardes toegeken word.
- kan nie kolomdatatipes hê wat verskil van die datatipes van die kolomme in die teikentabel nie. As die teikentabelkolom StringType-data bevat, maar die ooreenstemmende kolom in die DataFrame bevat IntegerType-data, sal skema-afdwinging 'n uitsondering skep en verhoed dat die skryfbewerking plaasvind.
- kan nie kolomname bevat wat slegs in geval verskil nie. Dit beteken dat u nie kolomme met die naam 'Foo' en 'foo' in dieselfde tabel kan definieer nie. Terwyl Spark in hooflettersensitiewe of hoofletteronsensitiewe (verstek) modus gebruik kan word, bewaar Delta Lake hoofletters, maar is onsensitief binne die skemaberging. Parket is hooflettersensitief wanneer kolominligting gestoor en teruggestuur word. Om moontlike foute, datakorrupsie of dataverlies (wat ons persoonlik by Databricks ervaar het) te vermy, het ons besluit om hierdie beperking by te voeg.
Om dit te illustreer, kom ons kyk na wat in die kode hieronder gebeur wanneer ons probeer om 'n paar nuutgegenereerde kolomme by 'n Delta Lake-tabel te voeg wat nog nie opgestel is om dit te aanvaar nie.
# Сгенерируем 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.In plaas daarvan om outomaties nuwe kolomme by te voeg, lê Delta Lake 'n skema op en hou op om te skryf. Om te help bepaal watter kolom (of stel kolomme) die teenstrydigheid veroorsaak, voer Spark beide skemas uit die stapelspoor af vir vergelyking.
Wat is die voordeel daarvan om 'n skema af te dwing?
Omdat skema-afdwinging 'n redelik streng kontrole is, is dit 'n uitstekende hulpmiddel om te gebruik as 'n hekwagter na 'n skoon, volledig getransformeerde datastel wat gereed is vir produksie of verbruik. Tipies toegepas op tabelle wat data direk voer:
- Masjienleeralgoritmes
- BI dashboards
- Data-analise en visualisering gereedskap
- Enige produksiestelsel wat hoogs gestruktureerde, sterk getikte semantiese skemas vereis.
Om hul data vir hierdie laaste struikelblok voor te berei, gebruik baie gebruikers 'n eenvoudige "multi-hop" argitektuur wat geleidelik struktuur in hul tabelle inbring. Om meer hieroor te wete te kom, kan u die artikel nagaan
Natuurlik kan skema-afdwinging enige plek in jou pyplyn gebruik word, maar onthou dat stroom na 'n tabel in hierdie geval frustrerend kan wees omdat jy byvoorbeeld vergeet het dat jy nog 'n kolom by die inkomende data gevoeg het.
Voorkoming van dataverdunning
Teen hierdie tyd wonder jy dalk, waaroor gaan al die bohaai? Per slot van rekening kan 'n onverwagte "skema-mismatch"-fout jou in jou werkstroom laat struikel, veral as jy nuut is by Delta Lake. Waarom nie net die skema laat verander soos nodig nie, sodat ek my DataFrame kan skryf, maak nie saak wat nie?
Soos die ou gesegde sê, "'n greintjie voorkoming is 'n pond genesing werd." Op 'n sekere punt, as jy nie sorg om jou skema af te dwing nie, sal datatipe-versoenbaarheidskwessies hul lelike koppe na vore bring - oënskynlik homogene rou databronne kan randgevalle, korrupte kolomme, misvormde kartering of ander skrikwekkende dinge bevat om oor te droom in nagmerries. Die beste benadering is om hierdie vyande by die hek te stop - met skema-afdwinging - en hulle in die lig te hanteer, eerder as later wanneer hulle in die donker dieptes van jou produksiekode begin skuil.
Die toepassing van 'n skema gee jou die versekering dat jou tabel se skema nie sal verander tensy jy die verandering goedkeur nie. Dit voorkom dataverdunning, wat kan voorkom wanneer nuwe kolomme so gereeld bygevoeg word dat voorheen waardevolle, saamgeperste tabelle hul betekenis en bruikbaarheid verloor as gevolg van data-oorstroming. Deur jou aan te moedig om opsetlik te wees, hoë standaarde te stel en hoë gehalte te verwag, doen skema-afdwinging presies wat dit ontwerp is om te doen – help jou om pligsgetrou te bly en jou sigblaaie skoon te bly.
As jy by verdere oorweging besluit dat jy regtig moet voeg 'n nuwe kolom by - geen probleem nie, hieronder is 'n eenreëloplossing. Die oplossing is die evolusie van die stroombaan!
Wat is skema-evolusie?
Skema-evolusie is 'n kenmerk wat gebruikers toelaat om die huidige tabelskema maklik te verander volgens data wat oor tyd verander. Dit word meestal gebruik wanneer 'n byvoeg- of herskryfbewerking uitgevoer word om die skema outomaties aan te pas om een of meer nuwe kolomme in te sluit.
Hoe werk skema-evolusie?
Na aanleiding van die voorbeeld van die vorige afdeling, kan ontwikkelaars maklik skema-evolusie gebruik om nuwe kolomme by te voeg wat voorheen verwerp is weens skema-teenstrydigheid. Kringevolusie word geaktiveer deur by te voeg .option('mergeSchema', 'true') aan jou Spark-span .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)Om die grafiek te sien, voer die volgende Spark SQL-navraag uit
# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10
Alternatiewelik kan jy hierdie opsie vir die hele Spark-sessie stel deur by te voeg spark.databricks.delta.schema.autoMerge = True na die Spark-konfigurasie. Maar gebruik dit met omsigtigheid, aangesien skema-afdwinging jou nie meer sal waarsku teen onbedoelde skema-teenstrydighede nie.
Deur die parameter in die versoek in te sluit mergeSchema, word alle kolomme wat in die DataFrame teenwoordig is, maar nie in die teikentabel nie, outomaties aan die einde van die skema bygevoeg as deel van 'n skryftransaksie. Geneste velde kan ook bygevoeg word en dit sal ook aan die einde van die ooreenstemmende struktuurkolomme bygevoeg word.
Datumingenieurs en datawetenskaplikes kan hierdie opsie gebruik om nuwe kolomme (dalk 'n onlangs nagespoorde maatstaf of hierdie maand se verkoopsprestasiekolom) by hul bestaande masjienleerproduksietabelle by te voeg sonder om bestaande modelle op grond van ou kolomme te breek.
Die volgende tipes skemaveranderings word toegelaat as deel van skema-evolusie tydens 'n tabelbyvoeging of -herskryf:
- Voeg nuwe kolomme by (dit is die mees algemene scenario)
- Verander datatipes vanaf NullType -> enige ander tipe of bevordering vanaf ByteType -> ShortType -> IntegerType
Ander veranderinge wat nie binne skema-evolusie toegelaat word nie, vereis dat die skema en data herskryf word deur by te voeg .option("overwriteSchema", "true"). Byvoorbeeld, in die geval waar die kolom "Foo" oorspronklik 'n heelgetal was en die nuwe skema 'n stringdatatipe was, dan sal alle Parquet(data)-lêers herskryf moet word. Sulke veranderinge sluit in:
- die verwydering van 'n kolom
- verander die datatipe van 'n bestaande kolom (in plek)
- hernoem kolomme wat slegs verskil in geval (byvoorbeeld "Foo" en "foo")
Ten slotte, met die volgende weergawe van Spark 3.0, sal eksplisiete DDL ten volle ondersteun word (met ALTER TABLE), wat gebruikers in staat stel om die volgende aksies op tabelskemas uit te voer:
- kolomme by te voeg
- kolomopmerkings te verander
- stel tabeleienskappe wat die tabel se gedrag beheer, soos die tydsduur wat 'n transaksielogboek gestoor word.
Wat is die voordeel van kringevolusie?
Skema-evolusie kan gebruik word wanneer jy ook al beoog verander die skema van jou tabel (in teenstelling met wanneer jy per ongeluk kolomme by jou DataFrame gevoeg het wat nie daar behoort te wees nie). Dit is die maklikste manier om jou skema te migreer omdat dit outomaties die korrekte kolomname en datatipes byvoeg sonder om dit uitdruklik te verklaar.
Gevolgtrekking
Skema-afdwinging verwerp enige nuwe kolomme of ander skemaveranderings wat nie met jou tabel versoenbaar is nie. Deur hierdie hoë standaarde te stel en te handhaaf, kan ontleders en ingenieurs vertrou dat hul data die hoogste vlak van integriteit het, dit duidelik en duidelik kommunikeer, sodat hulle beter besigheidsbesluite kan neem.
Aan die ander kant komplementeer skema-evolusie handhawing deur te vereenvoudig beweer outomatiese skema veranderinge. Dit behoort tog nie moeilik te wees om 'n kolom by te voeg nie.
Die gedwonge toepassing van die skema is yang, waar die evolusie van die skema yin is. Wanneer dit saam gebruik word, maak hierdie kenmerke ruisonderdrukking en seininstelling makliker as ooit.
Ons wil ook vir Mukul Murthy en Pranav Anand bedank vir hul bydraes tot hierdie artikel.
Ander artikels in hierdie reeks:
verwante artikels
Bron: will.com