Transformera data
Den här artikeln innehåller en introduktion och översikt över transformering av data med Azure Databricks. Att transformera data eller förbereda data är ett viktigt steg i alla arbetsbelastningar för datateknik, analys och ML.
Exempelmönster och rekommendationer i den här artikeln fokuserar på att arbeta med lakehouse-tabeller, som backas upp av Delta Lake. Eftersom Delta Lake ger ACID-garantierna för ett Databricks lakehouse kan du observera olika beteenden när du arbetar med data i andra format eller datasystem.
Databricks rekommenderar att du matar in data i ett sjöhus i ett rådata eller nästan obearbetat tillstånd och sedan tillämpar transformeringar och berikning som ett separat bearbetningssteg. Det här mönstret kallas för medaljongarkitekturen. Se Vad är medallion lakehouse arkitektur?.
Om du vet att de data som du behöver transformera ännu inte har lästs in i ett sjöhus läser du Mata in data i ett Databricks-sjöhus. Om du försöker hitta lakehouse-data att skriva transformeringar mot läser du Identifiera data.
Alla transformeringar börjar med att skriva antingen en batchfråga eller en direktuppspelningsfråga mot en datakälla. Om du inte är bekant med att fråga efter data kan du läsa Frågedata.
När du har sparat transformerade data till en Delta-tabell kan du använda tabellen som funktionstabell för ML. Se Funktionsutveckling och servering.
Kommentar
Artiklar här beskriver omvandlingar i Azure Databricks. Azure Databricks har också stöd för anslutningar till många vanliga plattformar för förberedelse av data. Se Ansluta till dataförberedelsepartner med partneranslutning.
Spark-omvandlingar jämfört med lakehouse-omvandlingar
Den här artikeln fokuserar på att definiera transformationer eftersom de relaterar till T i ETL eller ELT. Apache Spark-bearbetningsmodellen använder också ordet transformering på ett relaterat sätt. Kort sagt: i Apache Spark definieras alla åtgärder som antingen transformeringar eller åtgärder.
- Transformeringar: lägg till viss bearbetningslogik i planen. Exempel är läsning av data, kopplingar, sammansättningar och typgjutning.
- Åtgärder: utlösa bearbetningslogik för att utvärdera och mata ut ett resultat. Exempel är skrivningar, visning eller förhandsgranskning av resultat, manuell cachelagring eller att få antalet rader.
Apache Spark använder en modell för lat körning , vilket innebär att ingen av logiken som definieras av en samling åtgärder utvärderas förrän en åtgärd utlöses. Den här modellen har en viktig förgrening när du definierar pipelines för databearbetning: använd endast åtgärder för att spara resultat tillbaka till en måltabell.
Eftersom åtgärder representerar en flaskhals för bearbetning för att optimera logiken har Azure Databricks lagt till flera optimeringar utöver de som redan finns i Apache Spark för att säkerställa optimal körning av logik. Dessa optimeringar beaktar alla transformeringar som utlöses av en viss åtgärd samtidigt och hittar den optimala planen baserat på den fysiska layouten för data. Om du cachelagrar data manuellt eller returnerar förhandsgranskningsresultat i produktionspipelines kan dessa optimeringar avbrytas och leda till betydande ökningar av kostnader och svarstider.
Därför kan vi definiera en lakehouse-transformering till att vara en samling operationer som tillämpas på en eller flera lakehouse-tabeller och resulterar i en ny lakehouse-tabell. Observera att även om transformeringar som kopplingar och aggregeringar diskuteras separat kan du kombinera många av dessa mönster i ett enda bearbetningssteg och lita på att optimerarna på Azure Databricks hittar den mest effektiva planen.
Vilka är skillnaderna mellan strömning och batchbearbetning?
Strömning och batchbearbetning använder ungefär samma syntax på Azure Databricks, men var och en har sina egna specifika semantik.
Med batchbearbetning kan du definiera explicita instruktioner för att bearbeta en fast mängd statiska, icke-föränderliga data som en enda åtgärd.
Med dataströmbearbetning kan du definiera en fråga mot en obundna, kontinuerligt växande datamängd och sedan bearbeta data i små, inkrementella batchar.
Batch-åtgärder på Azure Databricks använder Spark SQL eller DataFrames, medan dataströmbearbetning utnyttjar strukturerad direktuppspelning.
Du kan särskilja Apache Spark-kommandon för batch från strukturerad direktuppspelning genom att titta på läs- och skrivåtgärder, som du ser i följande tabell:
| Apache Spark | Strukturerad direktuppspelning | |
|---|---|---|
| Läs | spark.read.load() |
spark.readStream.load() |
| Skriva | spark.write.save() |
spark.writeStream.start() |
Materialiserade vyer överensstämmer vanligtvis med garantier för batchbearbetning, även om Delta Live Tables används för att beräkna resultat stegvis när det är möjligt. Resultaten som returneras av en materialiserad vy motsvarar alltid batchutvärdering av logik, men Azure Databricks försöker bearbeta dessa resultat stegvis när det är möjligt.
Strömmande tabeller beräknar alltid resultat stegvis. Eftersom många strömmande datakällor endast behåller poster under en period av timmar eller dagar förutsätter bearbetningsmodellen som används av strömmande tabeller att varje batch med poster från en datakälla endast bearbetas en gång.
Azure Databricks stöder användning av SQL för att skriva strömmande frågor i följande användningsfall:
- Definiera strömmande tabeller i Unity Catalog med databricks SQL.
- Definiera källkod för Delta Live Tables-pipelines.
Kommentar
Du kan också deklarera strömmande tabeller i Delta Live Tables med hjälp av Python Structured Streaming-kod.
Batchtransformeringar
Batchtransformeringar körs på en väldefinierad uppsättning datatillgångar vid en viss tidpunkt. Batchtransformeringar kan vara engångsåtgärder, men är ofta en del av schemalagda jobb eller pipelines som körs regelbundet för att hålla produktionssystemen uppdaterade.
Inkrementella omvandlingar
Inkrementella mönster förutsätter vanligtvis att datakällan endast är tilläggsbaserad och har ett stabilt schema. Följande artiklar innehåller information om nyanser för inkrementella transformeringar i tabeller som upplever uppdateringar, borttagningar eller schemaändringar:
- API:er för TILLÄMPA ÄNDRINGAR: Förenkla insamling av ändringsdata med Delta Live Tables
- Använda Delta Lake-ändringsdataflöde i Azure Databricks
- Uppdatera Delta Lake-tabellschemat
- Delta-tabellens strömmande läsningar och skrivningar
Realtidstransformeringar
Delta Lake utmärker sig för att ge nästan realtidsåtkomst till stora mängder data för alla användare och program som frågar din lakehouse, men på grund av omkostnaderna med att skriva filer och metadata till molnobjektlagring kan sann realtidsfördröjning inte nås för många arbetsbelastningar som skriver till Delta Lake-mottagare.
Databricks rekommenderar att du väljer käll- och mottagarsystem som är utformade för realtidsarbetsbelastningar som Kafka för program med extremt låg latens. Du kan använda Azure Databricks för att berika data, inklusive aggregeringar, kopplingar mellan strömmar och sammankoppling av strömmande data med långsamt föränderliga dimensionsdata som lagras i lakehouse.