Varför inkrementell dataströmbearbetning?

Dagens datadrivna företag producerar kontinuerligt data, vilket kräver tekniska datapipelines som kontinuerligt matar in och transformerar dessa data. Dessa pipelines bör kunna bearbeta och leverera data exakt en gång, ge resultat med svarstider som är mindre än 200 millisekunder och alltid försöka minimera kostnaderna.

Den här artikeln beskriver metoder för batch- och inkrementell dataströmbearbetning för tekniska datapipelines, varför inkrementell dataströmbearbetning är det bättre alternativet och nästa steg för att komma igång med Databricks inkrementella dataströmbearbetningserbjudanden, Streaming på Azure Databricks och Vad är Delta Live Tables?. Med de här funktionerna kan du snabbt skriva och köra pipelines som garanterar leveranssemantik, svarstid, kostnad med mera.

Fallgroparna för upprepade batchjobb

När du konfigurerar datapipelinen kan du först skriva upprepade batchjobb för att mata in dina data. Varje timme kan du till exempel köra ett Spark-jobb som läser från källan och skriver data till en mottagare som Delta Lake. Utmaningen med den här metoden är att stegvis bearbeta din källa, eftersom Spark-jobbet som körs varje timme måste börja där det sista slutade. Du kan registrera den senaste tidsstämpeln för de data som du har bearbetat och sedan välja alla rader med tidsstämplar som är nyare än tidsstämpeln, men det finns fallgropar:

Om du vill köra en kontinuerlig datapipeline kan du försöka schemalägga ett batchjobb per timme som inkrementellt läser från källan, gör transformeringar och skriver resultatet till en mottagare, till exempel Delta Lake. Den här metoden kan ha fallgropar:

• Ett Spark-jobb som frågar efter alla nya data efter en tidsstämpel missar sena data.
• Ett Spark-jobb som misslyckas kan leda till att garantier exakt en gång bryts, om de inte hanteras noggrant.
• Ett Spark-jobb som visar innehållet på molnlagringsplatser för att hitta nya filer blir dyrt.

Sedan behöver du fortfarande transformera dessa data upprepade gånger. Du kan skriva upprepade batchjobb som sedan aggregerar dina data eller tillämpar andra åtgärder, vilket ytterligare komplicerar och minskar effektiviteten i pipelinen.

Ett batchexempel

Om du vill förstå fallgroparna för batchinmatning och transformering för din pipeline kan du titta på följande exempel.

Missade data

Med ett Kafka-ämne med användningsdata som avgör hur mycket som ska debiteras dina kunder och din pipeline matas in i batchar kan händelsesekvensen se ut så här:

1. Din första batch har två poster kl. 08.00 och 08.30.
2. Du uppdaterar den senaste tidsstämpeln till 08:30.
3. Du får ett nytt rekord 08:15.
4. Din andra batch frågar efter allt efter 08:30, så du missar posten klockan 08:15.

Dessutom vill du inte överdebitera eller underdebitera dina användare, så du måste se till att du matar in varje post exakt en gång.

Redundant bearbetning

Anta sedan att dina data innehåller rader med användarköp och att du vill aggregera försäljningen per timme så att du vet de mest populära tiderna i din butik. Om inköp för samma timme tas emot i olika batchar har du flera batchar som producerar utdata för samma timme:

Har fönstret från 08:00 till 09:00 två element (utdata från batch 1), ett element (utdata från batch 2) eller tre (utdata från ingen av batcharna)? De data som krävs för att producera ett givet tidsfönster finns i flera transformationsbatches. För att lösa detta kan du partitionera dina data per dag och bearbeta hela partitionen igen när du behöver beräkna ett resultat. Sedan kan du skriva över resultatet i din mottagare:

Detta sker dock på bekostnad av svarstid och kostnad, eftersom den andra batchen måste utföra det onödiga arbetet med att bearbeta data som den kanske redan har bearbetat.

Inga fallgropar med inkrementell dataströmbearbetning

Inkrementell dataströmbearbetning gör det enkelt att undvika alla fallgropar för upprepade batchjobb för att mata in och transformera data. Databricks Structured Streaming och Delta Live Tables förvaltar implementeringskomplexiteter för strömning så att du kan fokusera på din affärslogik. Du behöver bara ange vilken källa du ska ansluta till, vilka omvandlingar som ska göras till data och var resultatet ska skrivas.

Inkrementell inmatning

Inkrementell inmatning i Databricks drivs av Apache Spark Structured Streaming, som inkrementellt kan använda en datakälla och skriva den till en mottagare. Structured Streaming-motorn kan använda data exakt en gång och motorn kan hantera oordnade data. Motorn kan köras antingen i notebook-filer eller med hjälp av strömmande tabeller i Delta Live Tables.

Structured Streaming-motorn på Databricks tillhandahåller egna strömningskällor, till exempel AutoLoader, som stegvis kan bearbeta molnfiler på ett kostnadseffektivt sätt. Databricks tillhandahåller även anslutningsappar för andra populära meddelandebussar som Apache Kafka, Amazon Kinesis, Apache Pulsar och Google Pub/Sub.

Inkrementell omvandling

Med inkrementell omvandling i Databricks med Structured Streaming kan du ange transformeringar till DataFrames med samma API som en batchfråga, men den spårar data över batchar och aggregerade värden över tid så att du inte behöver göra det. Den behöver aldrig bearbeta data igen, så det är snabbare och mer kostnadseffektivt än upprepade batchjobb. Strukturerad direktuppspelning genererar en dataström som den kan lägga till i din mottagare, till exempel Delta Lake, Kafka eller någon annan anslutning som stöds.

Materialiserade vyer i Delta Live Tables drivs av enzymmotorn. Enzymet bearbetar fortfarande inkrementellt källan, men istället för att producera en ström skapar det en materialiserad vy, som är en förberäknad tabell som lagrar resultaten av en fråga som du ger den. Enzymet kan effektivt avgöra hur nya data påverkar resultatet av din fråga, och det behåller den förberäknade tabellen up-to-date.

Materialiserade vyer skapar en vy över ditt aggregat som alltid effektivt uppdaterar sig själv så att du till exempel vet att fönstret 8:00 till 09:00 har tre element i scenariot som beskrivs ovan.

Strukturerad direktuppspelning eller Delta Live-tabeller?

Den stora skillnaden mellan Structured Streaming och Delta Live Tables är det sätt på vilket du operationaliserar dina strömningsfrågor. I Strukturerad direktuppspelning anger du manuellt många konfigurationer och du måste manuellt sammanfoga frågor. Du måste uttryckligen starta frågor, vänta tills de avslutas, avbryta dem vid fel och andra åtgärder. I Delta Live Tables anger du deklarativt de pipelines som ska köras, och de fortsätter att köras.

Delta Live Tables har också funktioner som materialiserade vyer, som effektivt och inkrementellt förberäknar omvandlingar av dina data.

Mer information om dessa funktioner finns i Streaming på Azure Databricks och Vad är Delta Live Tables?.

Nästa steg

• Skapa din första pipeline med Delta Live Tables. Se Tutorial: Kör din första Delta Live Tables-pipeline.

• Kör dina första frågor om strukturerad direktuppspelning på Databricks. Se Kör din första arbetsbelastning för strukturerad direktuppspelning.

• Använd en materialerad vy. Se Använd materialiserade vyer i Databricks SQL.