Realtidsanalytik med Apache Flink och Kafka: Streaming pipelines i produktion

De flesta dataplattformar jobbar i batch, och det är oftast helt rätt. Men ibland duger det inte att vänta till nästa körning. När bedrägeri ska stoppas medan transaktionen pågår, eller ett larm ska gå direkt, behöver du realtid. Då blir Kafka och Flink mina verktyg. Här beskriver jag hur jag bygger streaming pipelines som faktiskt håller i produktion, och varför realtid kostar mer än många tror.

Jag vill börja med en varning, för den är viktigare än något tekniskt råd jag kan ge. Realtid är förföriskt. Det låter modernt och imponerande att säga att man bearbetar data i samma ögonblick som den uppstår, och många bygger streaming-lösningar mest för att de kan, inte för att de behöver. Resultatet blir en pipeline som är dyrare att drifta, svårare att felsöka och mer benägen att gå sönder, allt för att lösa ett problem som batch hade klarat alldeles utmärkt. Min första fråga är därför alltid om realtid verkligen behövs, och förvånansvärt ofta är svaret nej.

När realtid faktiskt behövs

Jag börjar alltid med att ifrågasätta behovet. Realtid är dyrare och svårare att drifta än batch, så det måste löna sig. Det gör det när ett beslut förlorar värde med varje sekund: bedrägeridetektering, operativa larm, eller funktioner där användaren förväntar sig en omedelbar reaktion. Är fördröjningen på minuter eller timmar acceptabel väljer jag batch.

Kafka: ryggraden för händelser

Kafka är navet där händelser strömmar in och kan konsumeras av flera system. Det fungerar som en hållbar logg som lagrar händelserna i ordning, så att olika konsumenter kan läsa i sin egen takt. Den frikopplingen är vad som gör en streaming-arkitektur robust, eftersom producenter och konsumenter inte behöver känna till varandra.

Flink: bearbetning i rörelse

Flink behandlar strömmen medan den rör sig. Det kan aggregera över tidsfönster, slå ihop strömmar och hålla tillstånd över tid, allt medan nya händelser fortsätter komma. Det är där den verkliga logiken bor: att förvandla en ström av råa händelser till något meningsfullt i samma ögonblick som de inträffar.

• Fönsterbaserade aggregeringar som räknar över glidande tidsintervall.
• Tillståndshantering så att beräkningar minns vad som hänt tidigare.
• Hantering av sena händelser, eftersom verkligheten sällan kommer i perfekt ordning.

Att avgöra om realtid är värt komplexiteten är ett av de viktigaste råden jag ger i vårt arbete med dataplattform, eftersom det är lätt att bygga något mer avancerat än verksamheten faktiskt behöver.

Tidsbegrepp: när hände något egentligen

En av de mest förbisedda svårigheterna i streaming är tid. Det låter trivialt men är det inte. Menar du tiden då händelsen faktiskt inträffade, eller tiden då den nådde ditt system? De två kan skilja sig avsevärt, särskilt när en mobil enhet varit offline och skickar sina händelser försenat. Om du aggregerar fel tidsbegrepp får du felaktiga resultat som är svåra att upptäcka. Flink ger dig verktyg för att hantera detta, med vattenstämplar som spårar hur långt fram i tiden du rimligen kommit och hur länge du ska vänta på eftersläntrare. Att tänka igenom tidsfrågan ordentligt är ofta det som skiljer en streaming-lösning som ger korrekta svar från en som ser ut att fungera men tyst räknar fel.

Det svåra är driften

Att få en streaming-pipeline att fungera i en demo är lätt. Att hålla den igång dygnet runt är något helt annat. Tillstånd måste sparas så att jobbet kan återstarta utan att tappa minnet, sena och dubbla händelser måste hanteras, och övervakningen måste fånga när strömmen halkar efter. Det är här de flesta underskattar arbetet.

Backpressure och när strömmen svämmar över

Ett produktionsproblem som batch aldrig stöter på är vad som händer när data kommer in snabbare än systemet hinner bearbeta den. I en streaming-pipeline byggs då en kö upp, och om inget hanterar det riskerar systemet att antingen krascha eller tappa data. Begreppet backpressure handlar om hur systemet signalerar uppströms att det behöver sakta ner. Flink och Kafka har mekanismer för det, men du måste förstå dem och dimensionera systemet så att det klarar topparna, inte bara den genomsnittliga lasten. Jag ser till att övervaka eftersläpningen, alltså hur långt efter realtid bearbetningen ligger, eftersom en växande eftersläpning är den tidigaste signalen på att något håller på att gå fel.

Exakt en gång, eller minst en gång

En central fråga är vilka garantier du behöver. Att varje händelse behandlas exakt en gång är svårare och dyrare än att den behandlas minst en gång. För en räknare kan dubbletter vara förödande, för annat helt acceptabelt. Jag bestämmer alltid den nivån medvetet i stället för att hoppas på det bästa.

Hur jag närmar mig det

Jag börjar litet och med ett tydligt avgränsat realtidsbehov, inte med att bygga om hela plattformen till streaming. Ofta lever batch och streaming sida vid sida, där batch sköter merparten och streaming bara de delar som verkligen kräver det. Den pragmatiska blandningen är nästan alltid rätt svar. Fler exempel finns i vår casebook.

Relaterat

• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag
• BI-val: Looker vs Power BI vs Metabase vs Lightdash
• Data quality-ramverk: Great Expectations + dbt tests i CI/CD

Vill du ta det vidare?

Om du tror att din verksamhet behöver realtid men inte är säker på var gränsen går, hör av dig via kontaktsidan. Jag hjälper dig skilja det som verkligen kräver streaming från det som batch löser billigare.