Hej, Habr! Jag presenterar för din uppmärksamhet en översättning av artikeln av Burak Yavuz, Brenner Heintz och Denny Lee, vilket utarbetades inför kurslanseringen från OTUS.
Data, liksom våra erfarenheter, ackumuleras och utvecklas ständigt. För att hänga med måste våra mentala modeller av världen anpassa sig till ny data, av vilka en del innehåller nya dimensioner – nya sätt att se saker vi inte hade någon aning om tidigare. Dessa mentala modeller är inte olikt de kalkylblad som avgör hur vi kategoriserar och bearbetar ny information.
Detta leder oss till ämnet schemahantering. I takt med att affärsbehov och krav förändras över tid, gör även strukturen för dina data det. Delta Lake gör det enkelt att introducera nya dimensioner allt eftersom data ändras. Användare har tillgång till enkel semantik för att hantera schemat för sina tabeller. Dessa verktyg inkluderar Schema Enforcement, som skyddar användare från att oavsiktligt förorena sina tabeller med fel eller onödiga data, och Schema Evolution, som låter dig automatiskt lägga till nya kolumner med värdefull data på rätt ställen. I den här artikeln ska vi fördjupa oss i hur man använder dessa verktyg.
Förstå tabellscheman
Varje DataFrame i Apache Spark innehåller ett schema som definierar formen på data, såsom datatyper, kolumner och metadata. Med Delta Lake lagras tabellschemat i JSON-format i transaktionsloggen.
Vad är systemtillämpning?
Schema Enforcement, även känt som Schema Validation, är en säkerhetsmekanism i Delta Lake som säkerställer datakvalitet genom att avvisa poster som inte överensstämmer med tabellens schema. Precis som värdinnan i receptionen på en populär restaurang som bara accepterar bokningar, kontrollerar den om varje kolumn med data som matas in i tabellen finns på en motsvarande lista över förväntade kolumner (med andra ord, om det finns en "bokning" för var och en), och avvisar alla poster med kolumner som inte finns med i listan.
Hur fungerar schematillämpning?
Delta Lake använder schemakontroll vid skrivning, vilket innebär att alla nya skrivningar till en tabell kontrolleras för kompatibilitet med måltabellens schema vid skrivtillfället. Om schemat är inkompatibelt återställer Delta Lake transaktionen helt (inga data skrivs) och genererar ett undantag för att meddela användaren om inkonsekvensen.
Delta Lake använder följande regler för att avgöra om en post är kompatibel med en tabell. DataFramen som skrivs:
- får inte innehålla ytterligare kolumner som inte finns i måltabellens schema. Omvänt är det okej om inkommande data inte innehåller absolut alla kolumner från tabellen - dessa kolumner kommer helt enkelt att tilldelas nullvärden.
- kan inte ha kolumndatatyper som skiljer sig från datatyperna för kolumnerna i måltabellen. Om en kolumn i måltabellen innehåller StringType-data, men motsvarande kolumn i DataFrame innehåller IntegerType-data, kommer schematillämpningen att generera ett undantag och förhindra att skrivåtgärden utförs.
- får inte innehålla kolumnnamn som bara skiljer sig åt i skiftläge. Det betyder att du inte kan ha kolumner med namnet "Foo" och "foo" definierade i samma tabell. Medan Spark kan användas skiftlägeskänsligt eller skiftlägesokänsligt (standard), är Delta Lake skiftlägesbevarande men skiftlägesokänsligt inom schemalagringen. Parquet är skiftlägeskänsligt vid lagring och hämtning av kolumninformation. För att undvika potentiella fel, datakorruption eller dataförlust (vilket vi personligen har upplevt på Databricks) beslutade vi att lägga till denna begränsning.
För att illustrera detta, låt oss ta en titt på vad som händer i koden nedan när man försöker lägga till några nyligen genererade kolumner i en Delta Lake-tabell som ännu inte är konfigurerad för att acceptera dem.
# Сгенерируем 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.Istället för att automatiskt lägga till nya kolumner inför Delta Lake ett schema och stoppar skrivningen. För att hjälpa till att avgöra vilken kolumn (eller uppsättning) som orsakar avvikelsen, matar Spark ut båda schemana från stackspårningen för jämförelse.
Vad är fördelen med att tillämpa systemet?
Eftersom schematillämpning är en ganska rigorös kontroll är det ett utmärkt verktyg att använda som grindvakt till en ren, helt transformerad datamängd som är redo för produktion eller konsumtion. Vanligtvis tillämpat på tabeller som direkt matar data:
- Maskininlärningsalgoritmer
- BI-instrumentpaneler
- Dataanalys- och visualiseringsverktyg
- Alla produktionssystem som kräver strikt strukturerade, strikt typade semantiska scheman.
För att förbereda sina data för detta sista hinder använder många användare en enkel "multi-hop"-arkitektur som gradvis introducerar struktur i sina tabeller. För mer information om detta kan du läsa artikeln.
Naturligtvis kan du använda schematillämpning var som helst i din pipeline, men kom ihåg att det kan vara frustrerande att skriva till en tabell i det här fallet, till exempel för att du glömde att du lade till ytterligare en kolumn i den inkommande datan.
Förhindra datakondensering
Vid det här laget kanske du undrar vad allt ståhej handlar om? Ibland kan ett oväntat felmeddelande om "schemamatchning" störa ditt arbetsflöde, särskilt om du är nybörjare på Delta Lake. Varför inte bara låta schemat ändras efter behov så att jag kan skriva min DataFrame oavsett vad?
Som det gamla ordspråket säger: ”Lite förebyggande är värt ett kilo botemedel.” Om du inte ser till att upprätthålla ditt schema kommer problem med datatypkompatibilitet att visa sig – till synes homogena rådatakällor kan innehålla kantfall, korrupta kolumner, felaktiga mappningar eller andra mardrömmar. Det bästa tillvägagångssättet är att stoppa dessa fiender vid grinden – med schematillämpning – och hantera dem i ljuset, snarare än senare, när de börjar lura i de mörka djupen av din produktionskod.
Schematillämpning säkerställer att din tabells schema inte ändras om du inte uttryckligen godkänner ändringen. Detta förhindrar datautspädning, vilket kan inträffa när nya kolumner läggs till så ofta att tidigare värdefulla, kompakta tabeller förlorar sin mening och användbarhet på grund av dataflödet. Genom att uppmuntra dig att vara avsiktlig, sätta höga krav och förvänta dig hög kvalitet gör schematillämpningen exakt vad den var avsedd att göra – hålla dig samvetsgrann och dina tabeller rena.
Om du, efter närmare övervägande, bestämmer dig för att du verkligen gör det till Lägg till ny kolumn - inga problem, nedan är en enradslösning. Lösning - schemautveckling!
Vad är schemautveckling?
Schemautveckling är en funktion som gör det möjligt för användare att enkelt ändra det aktuella tabellschemat för att hantera data som ändras över tid. Den används oftast när man utför en tilläggs- eller omskrivningsoperation för att automatiskt anpassa schemat för att inkludera en eller flera nya kolumner.
Hur fungerar schemautveckling?
Genom att följa exemplet i föregående avsnitt kan utvecklare enkelt använda schemautveckling för att lägga till nya kolumner som tidigare avvisades på grund av schemaavvikelser. Schemautveckling aktiveras genom att lägga till .option('mergeSchema', 'true') till ditt Spark-team .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)För att visa grafen, kör följande Spark SQL-fråga
# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10 
Alternativt kan du ställa in det här alternativet för hela Spark-sessionen genom att lägga till spark.databricks.delta.schema.autoMerge = True till Spark-konfigurationen. Men använd detta med försiktighet, eftersom schematillämpning inte längre kommer att varna dig om oavsiktliga schemainkonsekvenser.
Genom att inkludera en parameter i begäran mergeSchema, alla kolumner som finns i DataFrame men inte i måltabellen läggs automatiskt till i slutet av schemat som en del av skrivtransaktionen. Kapslade fält kan också läggas till, och de kommer också att läggas till i slutet av motsvarande strukturkolumner.
Dataingenjörer och forskare kan använda det här alternativet för att lägga till nya kolumner (kanske ett nyligen spårat mätvärde eller en kolumn med försäljningssiffror för den här månaden) till sina befintliga produktionstabeller för maskininlärning utan att förstöra befintliga modeller baserade på de gamla kolumnerna.
Följande typer av schemaändringar är tillåtna som en del av schemautvecklingen vid tillägg eller omskrivning av tabeller:
- Lägga till nya kolumner (detta är det vanligaste scenariot)
- Ändra datatyper från NullType -> någon annan typ eller uppgradera från ByteType -> ShortType -> IntegerType
Andra ändringar som inte är tillåtna inom schemautveckling kräver att schemat och data skrivs över genom att lägga till .option("overwriteSchema", "true")Om till exempel kolumnen "Foo" ursprungligen var ett heltal och det nya schemat var en strängdatatyp, skulle alla Parquet-filer (datafiler) behöva skrivas om. Sådana ändringar inkluderar:
- ta bort kolumnen
- ändra datatyp för befintlig kolumn (på plats)
- byta namn på kolumner som bara skiljer sig åt i gemener och versaler (t.ex. "Foo" och "foo")
Slutligen, med nästa version av Spark 3.0, kommer explicit DDL (med ALTER TABLE) att stödjas fullt ut, vilket gör det möjligt för användare att utföra följande åtgärder på tabellscheman:
- lägga till kolumner
- ändra kolumnkommentarer
- Konfigurera tabellegenskaper som avgör tabellens beteende, till exempel hur länge transaktionsloggen sparas.
Vad är fördelen med schemautveckling?
Schemautveckling kan användas när du avser att ändra schemat för din tabell (i motsats till de fall där du av misstag lade till kolumner i din DataFrame som inte borde finnas där). Detta är det enklaste sättet att migrera ditt schema eftersom det automatiskt lägger till rätt kolumnnamn och datatyper utan att du behöver deklarera dem explicit.
Slutsats
Schematillämpning avvisar alla nya kolumner eller andra schemaändringar som är inkompatibla med din tabell. Genom att sätta och upprätthålla dessa höga standarder kan analytiker och ingenjörer lita på att deras data har högsta möjliga integritetsnivå, och resonera tydligt och korrekt kring den, vilket gör att de kan fatta bättre affärsbeslut.
Å andra sidan kompletterar systemets utveckling verkställigheten genom att förenkla förment automatiska schemaändringar. Det borde trots allt inte vara så svårt att lägga till en kolumn.
Kretsförstärkning är yang för kretsutvecklingens yin. När dessa funktioner används tillsammans gör de brusreducering och signaljustering enklare än någonsin.
Vi vill också tacka Mukul Murthy och Pranav Anand för deras bidrag till den här artikeln.
Andra artiklar i den här serien:
relaterade artiklar
Källa: will.com
