Kaixo, Habr! Artikuluaren itzulpena aurkezten dizuet Burak Yavuz, Brenner Heintz eta Denny Lee egileak, kurtsoaren hasierari begira prestatutakoa OTUSetik.
Datuak, gure esperientzia bezala, etengabe pilatzen eta eboluzionatzen ari dira. Berdin jarraitzeko, gure munduaren eredu mentalak datu berrietara egokitu behar dira, horietako batzuk dimentsio berriak dituztenak —lehen ideiarik ez genekien gauzak behatzeko modu berriak—. Eredu mental hauek ez dira oso desberdinak informazio berria nola sailkatu eta prozesatzen dugun zehazten duten taula-eskemetatik.
Horrek eskemaren kudeaketaren gaira garamatza. Negozioen erronkak eta eskakizunak denboran zehar aldatzen diren heinean, zure datuen egitura ere aldatzen da. Delta Lake-k neurketa berriak sartzea errazten du datuak aldatzen diren heinean. Erabiltzaileek semantika sinplerako sarbidea dute beren taula eskemak kudeatzeko. Tresna horien artean daude Schema Enforcement, erabiltzaileak beren taulak akatsekin edo beharrezkoak ez diren datuekin nahi gabe kutsatzetik babesten dituena, eta Schema Evolution, datu baliotsuen zutabe berriak automatikoki gehitzeko aukera ematen dion kokapen egokietan. Artikulu honetan, tresna hauek erabiltzen sakonduko dugu.
Taulen eskemak ulertzea
Apache Spark-eko DataFrame bakoitzak datuen forma definitzen duen eskema bat dauka, hala nola datu motak, zutabeak eta metadatuak. Delta Lake-rekin, taula-eskema JSON formatuan gordetzen da transakzioen erregistroaren barruan.
Zer da eskema betearaztea?
Schema Enforcement, Schema Validation izenez ere ezaguna, Delta Lake-ko segurtasun mekanismo bat da, datuen kalitatea bermatzen duena, taularen eskemarekin bat ez datozen erregistroak baztertuz. Erreserbarako soilik diren jatetxe ezagun bateko azafatak bezala, taulan sartutako datu-zutabe bakoitza espero den zutabeen zerrendan dagoen egiaztatzen du (hau da, horietako bakoitzarentzat "erreserba" dagoen ala ez). ), eta zerrendan ez dauden zutabeak dituzten erregistroak baztertzen ditu.
Nola funtzionatzen du eskemak betearaztea?
Delta Lake-k eskema-idazketan egiaztatzea erabiltzen du, hau da, taulako idazketa berri guztiak xede-taularen eskemarekin bateragarritasuna egiaztatzen dela idazteko unean. Eskema koherentea ez bada, Delta Lake-k transakzioa erabat bertan behera uzten du (ez da daturik idazten) eta salbuespen bat planteatzen du erabiltzaileari inkoherentziaren berri emateko.
Delta Lake-k honako arau hauek erabiltzen ditu erregistro bat taula batekin bateragarria den zehazteko. Idatzi daitekeen datu-markoa:
- ezin ditu helburu-taularen eskeman ez dauden zutabe gehigarririk eduki. Alderantziz, dena ondo dago sarrerako datuek taulako zutabe guztiak ez badituzte - zutabe horiei balio nuluak esleituko zaizkie.
- ezin ditu zutabeen datu-mota izan xede-taulan dauden zutabeen datu-motetatik desberdinak. Xede-taularen zutabeak StringType datuak baditu, baina DataFrame-ko dagokion zutabeak IntegerType datuak baditu, eskema betetzeak salbuespen bat botako du eta idazketa eragiketa egitea eragotziko du.
- ezin du izan maiuskulak eta minuskulak bakarrik desberdinak diren zutabe-izenak. Horrek esan nahi du ezin duzula 'Foo' eta 'foo' izeneko zutabeak taula berean definitu. Spark maiuskulak eta minuskulak bereizten ditu edo maiuskulak eta minuskulak bereizten ez dituen moduan (lehenetsia), Delta Lake-k maiuskulak eta minuskulak gordetzen ditu, baina eskemaren biltegiratzean ez du bereizten. Parquet-ek maiuskulak eta minuskulak bereizten ditu zutabeen informazioa gorde eta itzultzerakoan. Akats posibleak, datuak hondatzea edo datuak galtzea (Databricks-en pertsonalki bizi izan dugun zerbait) ekiditeko, muga hori gehitzea erabaki dugu.
Hau ilustratzeko, ikus dezagun zer gertatzen den beheko kodean, sortu berri diren zutabe batzuk gehitzen saiatzen garenean oraindik horiek onartzeko konfiguratuta ez dagoen Delta Lake taula batean.
# Сгенерируем 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.Zutabe berriak automatikoki gehitu beharrean, Delta Lake-k eskema bat ezartzen du eta idazteari uzten dio. Desadostasuna eragiten duen zutabea (edo zutabe-multzo) zehazten laguntzeko, Spark-ek bi eskemak ateratzen ditu pilaren arrastotik alderatzeko.
Zein da eskema bat betetzearen onura?
Eskema betearaztea nahiko egiaztapen zorrotza denez, tresna bikaina da ekoizteko edo kontsumitzeko prest dagoen datu-multzo garbi eta guztiz eraldatu baten atezain gisa erabiltzeko. Normalean datuak zuzenean elikatzen dituzten tauletan aplikatzen da:
- Ikaskuntza automatikoko algoritmoak
- BI aginte-panelak
- Datuak aztertzeko eta bistaratzeko tresnak
- Eskema semantiko oso egituratuak eta tipifikatuak behar dituen edozein produkzio-sistema.
Azken oztopo honetarako euren datuak prestatzeko, erabiltzaile askok "salto anitzeko" arkitektura soil bat erabiltzen dute, eta pixkanaka egitura sartzen dute beren tauletan. Honi buruz gehiago jakiteko, ikusi dezakezu artikulua
Jakina, eskemaren betearazpena zure kanalizazioko edozein lekutan erabil daiteke, baina gogoratu kasu honetan taula batera igortzea frustragarria izan daitekeela, adibidez, sarrerako datuei beste zutabe bat gehitu duzula ahaztu duzulako.
Datuak diluitzea saihestea
Honezkero galdetzen ari zara, zertan datza zalaparta guztia? Azken finean, batzuetan ustekabeko "eskema desegokitze" errore batek zure lan-fluxuan estropezu egin dezake, batez ere Delta Lake-n berria bazara. Zergatik ez utzi eskema behar den moduan aldatzen, nire DataFrame edozein dela ere idatzi ahal izateko?
Esaera zaharrak dioen bezala, "prebentzio ontza batek sendatzea merezi du". Noizbait, zure eskema betearazteaz arduratzen ez bazara, datu-moten bateragarritasun-arazoek beren buru itsusiak piztuko dituzte - itxuraz homogeneoa den datu-iturri gordinak ertz-kasuak, hondatutako zutabeak, gaizki formatutako mapak edo amets egiteko beste gauza beldurgarriak izan ditzakete. amesgaiztoak. Planteamendu onena etsai hauek atean geldiaraztea da - eskema betearaztearekin - eta argian aurre egitea, zure produkzio-kodearen sakonera ilunean ezkutatzen hasten direnean geroago baino.
Eskema bat betetzeak ziurtatzen dizu zure taularen eskema ez dela aldatuko aldaketa onartzen ez baduzu. Horrek datuen diluizioa ekiditen du, zutabe berriak hain maiz gehitzen direnean gerta daitekeena, non lehenago baliotsuak ziren taula konprimituak beren esanahia eta erabilgarritasuna galtzen baitituzte datuen uholdearen ondorioz. Nahita izatera, estandar altuak ezartzera eta kalitate handikoa itxarotera bultzatuz, eskemak betearazteak diseinatutakoa egiten du zehazki: kontzientziatuta egoten eta zure kalkulu-orriak garbi izaten laguntzen dizu.
Gehiago aztertuz gero benetan erabakitzen baduzu behar gehitu zutabe berri bat - ez dago arazorik, behean lerro bakarreko konponketa dago. Irtenbidea zirkuituaren bilakaera da!
Zer da eskemaren bilakaera?
Eskemaren bilakaera erabiltzaileek uneko taula-eskema erraz alda dezakete denboran zehar aldatzen diren datuen arabera. Gehienetan gehitzeko edo berridazteko eragiketa bat egitean erabiltzen da eskema automatikoki egokitzeko zutabe berri bat edo gehiago sartzeko.
Nola funtzionatzen du eskemaren bilakaerak?
Aurreko ataleko adibideari jarraituz, garatzaileek erraz erabil dezakete eskemaren bilakaera eskemaren koherentziaren ondorioz aldez aurretik baztertu ziren zutabe berriak gehitzeko. Zirkuituaren bilakaera gehituz aktibatzen da .option('mergeSchema', 'true') zure Spark taldeari .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)Grafikoa ikusteko, exekutatu Spark SQL kontsulta hau
# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10 
Bestela, Spark saio osorako aukera hau ezar dezakezu gehituz spark.databricks.delta.schema.autoMerge = True Spark konfiguraziora. Baina erabili hau kontu handiz, eskemak betearazteak ez baitizu ohartaraziko nahi gabeko eskemaren inkoherentziak.
Parametroa eskaeran sartuz mergeSchema, DataFrame-n baina xede-taulan ez dauden zutabe guztiak automatikoki gehitzen dira eskemaren amaieran idazketa-transakzio baten zati gisa. Habiaraturiko eremuak ere gehi daitezke eta horiek dagozkien egitura-zutabeen amaieran ere gehituko dira.
Data-ingeniariek eta datu-zientzialariek aukera hau erabil dezakete zutabe berriak gehitzeko (agian duela gutxi jarraitutako neurketa bat edo hilabete honetako salmenten errendimenduaren zutabea) lehendik dauden ikaskuntza automatikoaren ekoizpen-tauletan zutabe zaharretan oinarrituta dauden ereduak hautsi gabe.
Taulen gehikuntzan edo berridazketan eskemaren bilakaeraren parte gisa eskema-aldaketa mota hauek onartzen dira:
- Zutabe berriak gehitzea (hau da agertokirik ohikoena)
- Datu motak aldatzea NullTypetik -> beste edozein motatik edo ByteTypetik sustatu -> ShortType -> IntegerType
Eskemaren bilakaeran onartzen ez diren beste aldaketa batzuek eskema eta datuak gehituz berridatzi behar dituzte .option("overwriteSchema", "true"). Adibidez, "Foo" zutabea jatorriz zenbaki oso bat zen eta eskema berria kate datu-mota izan zenean, Parquet(datuak) fitxategi guztiak berridatzi beharko lirateke. Aldaketa horiek honako hauek dira:
- zutabe bat ezabatuz
- lehendik dagoen zutabe baten datu-mota aldatzea (tokian)
- maiuskulak eta minuskulak soilik desberdinak diren zutabeei izena aldatzea (adibidez, "Foo" eta "foo")
Azkenik, Spark 3.0-ren hurrengo bertsioarekin, DDL esplizitua guztiz onartuko da (ALTER TABLE erabiliz), erabiltzaileek taula eskemetan ekintza hauek egiteko aukera emanez:
- zutabeak gehituz
- zutabeen iruzkinak aldatzea
- taularen portaera kontrolatzen duten taula-propietateak ezartzea, hala nola transakzioen erregistroa gordetzeko denbora-tartea ezartzea.
Zein da zirkuituaren bilakaeraren onura?
Eskemaren eboluzioa zuk edonoiz erabil daiteke asmoa aldatu zure taularen eskema (hor egon beharko ez luketen zutabeak ustekabean gehitu dituzunean ez bezala). Hau da zure eskema migratzeko modurik errazena zutabe-izen eta datu-mota zuzenak automatikoki gehitzen dituelako esplizituki deklaratu beharrik gabe.
Ondorioa
Eskema betetzeak zure taularekin bateragarriak ez diren zutabe berriak edo eskema-aldaketak baztertzen ditu. Estandar altu hauek ezarriz eta mantenduz, analistek eta ingeniariek beren datuek osotasun-maila handiena dutela fida dezakete, argi eta garbi komunikatuz, negozio-erabaki hobeak hartzeko aukera emanez.
Bestalde, eskemaren bilakaerak betearazpena osatzen du sinplifikatuz ustez eskema aldaketa automatikoak. Azken finean, ez luke zaila izan behar zutabe bat gehitzea.
Eskemaren behartutako aplikazioa yang da, non eskemaren bilakaera yin den. Elkarrekin erabiltzen direnean, ezaugarri hauek zarata kentzea eta seinalearen sintonizazioa inoiz baino errazagoa egiten dute.
Era berean, eskerrak eman nahi dizkiegu Mukul Murthy eta Pranav Anand artikulu honetan egindako ekarpenengatik.
Serie honetako beste artikulu batzuk:
Lotutako artikuluak
Iturria: www.habr.com
