Vad är Lakeflow Spark deklarativa pipelines

Lakeflow Spark Declarative Pipelines (SDP) är ett deklarativt ramverk för att bygga dataflöden för batch- och strömbehandling i SQL och Python. Dess grundläggande begrepp är pipelines, flöden, strömmande tabeller, materialiserade vyer och mottagare, som arbetar tillsammans för att bearbeta data med automatisk orkestrering och inkrementella uppdateringar.

Vad är SDP?

Lakeflow Spark Deklarativa Pipelines är ett deklarativt ramverk för att utveckla och köra batch- och strömmande datapipelines i SQL och Python. Lakeflow SDP utökas och är samverkande med Apache Spark Deklarativa pipelines, samtidigt som den körs på den prestandaoptimerade Databricks Runtime, och Lakeflow Spark Deklarativa pipelines-API:et flows använder samma DataFrame-API som Apache Spark och Structured Streaming.

Vanliga användningsfall för SDP är:

• Inkrementell datainmatning från källor som molnlagring (Amazon S3, Azure ADLS Gen2 och Google Cloud Storage) och meddelandebussar (Apache Kafka, Amazon Kinesis, Google Pub/Sub, Azure EventHub och Apache Pulsar).
• Inkrementella batch- och strömningstransformeringar med tillståndslösa och tillståndskänsliga operatorer.
• Dataströmbearbetning i realtid mellan transaktionslager som meddelandebussar och databaser.

Mer information om deklarativ databehandling finns i Procedurell kontra deklarativ databearbetning i Databricks.

Vilka är fördelarna med SDP?

SDP:s deklarativa karaktär ger följande fördelar jämfört med att utveckla dataprocesser med Apache Spark - och Spark Structured Streaming-API :er och köra dem med Databricks Runtime med manuell orkestrering via Lakeflow-jobb.

• Automatisk orkestrering: SDP orkestrerar bearbetningssteg (kallas "flöden") automatiskt för att säkerställa rätt körningsordning och den maximala parallelliteten för optimal prestanda. Dessutom gör pipelines automatiskt och effektivt nya försök vid tillfälliga fel. Återförsöksprocessen börjar med den mest detaljerade och kostnadseffektiva enheten: Spark-uppgiften. Om återförsöket på aktivitetsnivå misslyckas fortsätter SDP att försöka flödet igen och slutligen hela pipelinen om det behövs.
• Deklarativ bearbetning: SDP tillhandahåller deklarativa funktioner som kan minska hundratals eller till och med tusentals rader med manuell Spark- och Structured Streaming-kod till endast några rader. SDP AUTO CDC API förenklar bearbetningen av CDC-händelser (Change Data Capture) med stöd för både SCD Typ 1 och SCD Typ 2. Det eliminerar behovet av manuell kod för att hantera out-of-order-händelser, och det kräver ingen förståelse för strömmande semantik eller begrepp som vattenstämplar.
• Inkrementell bearbetning: SDP tillhandahåller en inkrementell bearbetningsmotor för materialiserade vyer. Om du vill använda den skriver du omvandlingslogik med batchsemantik, och motorn bearbetar endast nya data och ändringar i datakällorna när det är möjligt. Inkrementell bearbetning minskar ineffektiv ombearbetning när nya data eller ändringar sker i källorna och eliminerar behovet av manuell kod för att hantera inkrementell bearbetning.

Viktiga begrepp

Diagrammet nedan illustrerar de viktigaste begreppen i Lakeflow Spark deklarativa pipelines.

Datauppsättningar

En pipeline producerar tre typer av datauppsättningar, var och en med olika bearbetningssemantik:

En strömmande tabell är en form av hanterad Unity Catalog-tabell som också är ett mål för strömmande data. En strömmande tabell kan ha ett eller flera strömmande flöden (Append, AUTO CDC) inskrivna i den. Du kan definiera strömningsflöden uttryckligen och separat från deras målströmningstabell, eller underförstått som en del av definitionen av en strömningstabell.

En materialiserad vy är också en form av hanterad tabell i Unity Catalog och är ett batchmål. En materialiserad vy kan ha ett eller flera materialiserade vyflöden inskrivna i den. Materialiserade vyer skiljer sig från strömmande tabeller eftersom du alltid definierar flödena implicit som en del av den materialiserade vydefinitionen.

Mer information finns i streamingtabeller och materialiserade vyer.

När du ska använda vyer, materialiserade vyer och strömmande tabeller

När du implementerar pipelinefrågor väljer du den datauppsättningstyp som passar bäst för ditt användningsfall.

Överväg att använda en vy för att:

• Dela upp en stor eller komplex fråga i enklare att hantera frågor.
• Verifiera mellanliggande resultat med hjälp av förväntningar.
• Minska lagrings- och beräkningskostnader för resultat som du inte behöver behålla. Eftersom tabeller materialiseras behöver de ytterligare beräknings- och lagringsresurser.

Överväg att använda en materialiserad vy när:

• Flera nedströmsförfrågningar använder tabellen. Eftersom en materialiserad vy cachelagrar resultatet läser underordnade frågor de förberäknade resultaten i stället för att beräkna frågan på nytt för varje åtkomst.
• Andra pipelines, jobb eller frågor konsumerar databastabellen. Eftersom en materialiserad vy materialiseras till en Unity Catalog-tabell kan konsumenter utanför pipelinen som definierar den köra frågor mot den. Vyer materialiseras inte, så du kan bara använda dem i samma pipeline.
• Du vill granska resultatet av en fråga under utvecklingen. Eftersom en materialiserad vy materialiseras och kan efterfrågas utanför pipelinen kan du verifiera korrektheten i beräkningar under utvecklingen. När du har verifierat konverterar du frågor som inte kräver materialisering till vyer.
• Din fråga utför aggregeringar eller kopplingar, eller så kan källdata ändras på grund av uppdateringar och borttagningar i stället för att bara växa. En materialiserad vy håller sina resultat i linje med det aktuella tillståndet för källdata, medan en strömmande tabell är utformad för källor som endast tillåter tillägg och bearbetar varje post endast en gång.

Överväg att använda en streamingtabell när:

• En fråga definieras mot en datakälla som växer kontinuerligt eller inkrementellt.
• Frågeresultat bör beräknas stegvis.
• Pipelinen behöver högt dataflöde och låg svarstid.

Flows

Ett flöde är det grundläggande databehandlingskonceptet i SDP som stöder både strömning och batchsemantik. Ett flöde läser data från en källa, tillämpar användardefinierad bearbetningslogik och skriver resultatet till ett mål. SDP delar samma typ av direktuppspelningsflöde (Tillägg, Uppdatering, Slutförd) som Spark Structured Streaming. (För närvarande är det bara tilläggs- och uppdateringsflödena som exponeras.) Mer information finns i utdatalägen i Strukturerad direktuppspelning.

Deklarativa pipelines i Lakeflow Spark erbjuder även ytterligare flödestyper:

• AUTO CDC är ett unikt strömningsflöde i Lakeflow SDP som hanterar CDC-händelser ur ordning och stöder både SCD Typ 1 och SCD Typ 2. Auto CDC är inte tillgängligt i Apache Spark deklarativa pipelines.
• Materialiserad vy är ett batchflöde i SDP som endast bearbetar nya data och ändringar i källtabellerna när det är möjligt.

Mer information finns i Läsa in och bearbeta data inkrementellt med flöden i Lakeflow Spark Declarative Pipelines.

Sinks

En sänkpunkt är ett strömningsmål för en pipeline och stöder Delta-tabeller, ämnesområden i Apache Kafka, ämnesområden i Azure EventHubs och anpassade Python-datakällor. En mottagare kan ha en eller flera direktuppspelningsflöden (Tillägg, Uppdatering) inskrivna i den.

Mer information finns i Sinkar i Lakeflow Spark deklarativa pipelines.

Pipelines

En pipeline är enheten för utveckling och körning i Lakeflow Spark Declarative Pipelines och innehåller de flöden, strömmande tabeller, materialiserade vyer och utdatamål som du definierar. Du använder SDP genom att definiera dessa objekt i din pipeline-källkod och sedan köra pipelinen. När pipelinen körs analyserar den beroendena för dina definierade objekt och samordnar deras körningsordning och parallellisering automatiskt.

Mer information finns i Vad är pipelines?.

Du kan också definiera fristående materialiserade vyer och strömmande tabeller utanför en pipeline, där Azure Databricks hanterar pipelinen åt dig. För att jämföra de två metoderna, se Fristående pipelines kontra Lakeflow Spark deklarativa pipelines.

Datainsamling

Pipelines stöder alla datakällor som är tillgängliga i Azure Databricks. Databricks rekommenderar att du använder strömningstabeller för de flesta inmatningsanvändningsfall. För filer i molnbaserad objektlagring erbjuder Auto Loader inkrementell och idempotent inläsning. För strömmande data kan pipelines hämta in data direkt från meddelandebussar som Apache Kafka, Azure Event Hubs, Amazon Kinesis och Google Pub/Sub. Se avsnittet Läsa in data i pipelines.

Datakvalitet

Förväntningar är valfria satser på datauppsättningar som validerar data när de flödar genom pipelinen. Du definierar en förväntan som en SQL-boolesk begränsning och anger vad som händer när en post misslyckas: varna, ta bort posten eller misslyckas med uppdateringen. Se avsnittet Hantera datakvalitet med pipeline-förväntningar.

Deltaintegrering

Alla tabeller som skapas och hanteras av pipelines är Delta-tabeller. De har samma garantier som Delta Lake, inklusive ACID-transaktioner, tidsresor och schematillämpning. Pipelines lägger till ytterligare tabellegenskaper och utför automatiskt underhåll med förutsägande optimering, inklusive OPTIMIZE och VACUUM åtgärder. Se Vad är Delta Lake i Azure Databricks?.

Ytterligare resurser

• Självstudie: Skapa en ETL-pipeline med hjälp av insamling av ändringsdata
• Vad är pipeliner?
• Pipelinebegränsningar
• Referens för pipelineutvecklare