Apache Kafka

Wat is Apache Kafka?

Apache Kafka is een open-source platform dat stromen van events opvangt, bewaart en doorgeeft aan de systemen die ze nodig hebben. Producenten schrijven berichten naar Kafka, afnemers lezen ze eruit, en Kafka houdt alles een tijd bij zodat meerdere afnemers dezelfde stroom op hun eigen tempo verwerken. Het draait niet op één machine maar verdeelt zich over een cluster, zodat het meegroeit met het volume en overeind blijft als een server uitvalt.

De kern van Kafka is een commit log: een bestand waar berichten enkel achteraan bijkomen en nooit tussenin veranderen. Elk nieuw event krijgt een vaste plek achteraan de rij en blijft daar staan tot de bewaartermijn verloopt. Wie leest, onthoudt tot waar hij geraakt is en gaat de volgende keer verder. Dat ene idee, een log waar je enkel aan toevoegt, verklaart bijna alles wat Kafka anders doet dan een klassieke wachtrij.

Anders dan bij een klassiek berichtensysteem verdwijnt een event niet zodra het gelezen is: elke afnemer kan het binnen de bewaartermijn opnieuw lezen of terugspoelen. Zo is dezelfde stroom tegelijk een live-doorgeefluik en een herspeelbare historiek.

De kernbegrippen van Kafka

Kafka heeft een handvol begrippen die je samen moet zien om te snappen hoe het werkt.

Topic
Een topic is de naam van een stroom, bijvoorbeeld "bestellingen" of "sensormetingen". Producenten schrijven naar een topic, afnemers lezen eruit. Je kan het vergelijken met een kanaal waarop één soort gebeurtenissen binnenkomt.

Partition
Elk topic wordt opgesplitst in partitions, en die worden verdeeld over de brokers in het cluster. Dat is wat Kafka laat schalen: hoe meer partitions, hoe meer afnemers parallel kunnen lezen. Kafka garandeert de volgorde alleen binnen één partition, niet over het hele topic. Events met dezelfde sleutel, bijvoorbeeld hetzelfde klantnummer, landen altijd in dezelfde partition en blijven dus in volgorde.

Offset
Binnen een partition krijgt elk event een oplopend nummer: de offset. Een afnemer onthoudt welke offset hij als laatste verwerkt heeft. Wil hij een uur data opnieuw verwerken, dan zet hij zijn offset gewoon terug. Die bladwijzer is het enige wat Kafka per afnemer bijhoudt.

Producer en consumer
Een producer schrijft events naar een topic, een consumer leest ze eruit. Ze kennen elkaar niet en hoeven niet even snel te werken: valt een consumer even weg, dan leest hij nadien verder waar hij gebleven was.

Consumer group
Zet je meerdere consumers in dezelfde consumer group, dan verdeelt Kafka de partitions onder hen: elk event gaat naar precies één lid van de groep. Zo verwerk je een drukke stroom met meerdere machines samen. Wil je dezelfde stroom door twee losstaande toepassingen laten lezen, dan geef je ze elk een eigen group.

Broker
Een broker is één server in het Kafka-cluster. Hij bewaart de partitions en bedient de lees- en schrijfverzoeken. Een cluster bestaat uit meerdere brokers, zodat het werk verdeeld raakt en er reservecapaciteit is.

Replication
Elke partition kan gekopieerd worden naar meerdere brokers. Valt de broker met het origineel uit, dan neemt een kopie het over zonder dataverlies. In productie is drie kopieën (replication factor 3) een courante keuze.

Retention
Je stelt per topic in hoelang Kafka events bewaart, bijvoorbeeld zeven dagen. Zolang die termijn loopt kan elke afnemer ze opnieuw lezen. Daarna ruimt Kafka de oudste vanzelf op.

Hoe past Kafka in een moderne datastack?

Kafka zit meestal in het midden van een datastack, als de laag waar alle events passeren voor ze naar hun bestemming gaan. Drie rollen zie je telkens terugkomen.

Transportlaag voor Change Data Capture
Bij Change Data Capture wordt elke insert, update en delete in een database als event doorgestuurd. Kafka is vaak de laag die die wijzigingen vervoert. Een tool als Debezium leest het transactielog van de database en publiceert elke wijziging naar een Kafka-topic, waarna een lakehouse of data warehouse zich erop abonneert en bijna live meebeweegt met de bron.

Ruggengraat voor event-driven microservices
In plaats van dat services elkaar rechtstreeks aanroepen, schrijft de ene een event naar Kafka en pikken de andere het daar op. De bestelservice schrijft "bestelling geplaatst", de voorraad- en de facturatieservice lezen mee. Valt een service even uit, dan werkt hij de gemiste events later gewoon bij.

Aanvoer naar een lakehouse of warehouse
Een consumer schrijft de events in kleine pakketjes weg als tabellen, bijvoorbeeld als Delta-tabellen in een lakehouse. Verwerkingsmotoren zoals Apache Spark lezen rechtstreeks van Kafka via Structured Streaming en zetten de stroom om in tabellen waarop je nadien rustig rapporteert.

Achter elkaar gezet vormen die events een event log: het volledige verslag van wat er gebeurde, in de juiste volgorde. Kafka is bij uitstek de plek waar zo'n log leeft.

Leveringsgaranties: at-least-once en exactly-once

Hoe zeker weet je dat een event precies één keer aankomt? Kafka kent daar drie niveaus voor, en de keuze bepaalt mee hoe je je verwerking bouwt.

At-least-once is de standaard: een event gaat nooit verloren, maar kan bij een herstart of netwerkfout twee keer aankomen. At-most-once draait dat om: nooit dubbel, maar bij een fout kan een event wegvallen. Exactly-once belooft precies één keer, zonder verlies en zonder dubbels.

Omdat at-least-once de standaard is, wil je je afnemers idempotent maken: geef elk event een unieke sleutel en zorg dat het twee keer verwerken hetzelfde resultaat geeft als één keer.

Wil je echt exactly-once, dan biedt Kafka dat sinds versie 0.11 aan met twee bouwstenen. De idempotente producer zorgt dat een opnieuw verstuurd bericht geen dubbele regel in het log maakt. Transacties laten je meerdere schrijfacties als één geheel doorvoeren of samen terugdraaien. Samen geven ze de sterkste garantie, tegen wat meer vertraging.

Kafka zelf draaien of een managed dienst?

Kafka kan veel aan, maar een eigen cluster draaien vraagt werk: brokers opzetten, partitions balanceren, upgrades en beveiliging opvolgen. Dat vraagt een technisch profiel dat er permanent op let. Voor veel organisaties, zeker een KMO, geeft een managed dienst dezelfde bouwstenen zonder de servers te beheren.

Azure Event Hubs
Een volledig managed dienst met een Kafka-endpoint. Toepassingen die al Kafka spreken, wijzigen enkel hun verbindingsstring en sturen hun events naar Event Hubs zonder codewijziging. Er zijn geen brokers om op te zetten of te configureren. Event Hubs ondersteunt het Kafka-protocol vanaf Kafka-versie 1.0.

Microsoft Fabric Eventstream
Binnen Microsoft Fabric is Eventstream de streaming-laag, gebouwd bovenop Event Hubs en dus ook met een Kafka-endpoint. Je klikt bronnen en bestemmingen aan, past zonder code transformaties toe, en stuurt het resultaat naar een lakehouse of eventhouse. Handig als je toch al in Fabric werkt. Een eventstream levert net als Kafka at-least-once af, bewaart events tot 90 dagen en verwerkt berichten tot 1 MB.

Confluent Cloud
De managed dienst van Confluent, opgericht door de originele makers van Kafka. Draait op AWS, Azure en Google Cloud en voegt zaken toe zoals een schema registry en kant-en-klare connectoren. Fabric Eventstream kan Confluent Cloud rechtstreeks als bron aankoppelen.

Wanneer je Kafka beter niet inzet

Kafka lost een echt probleem op, maar het is zwaar geschut. Grijp er niet naar uit gewoonte.

Bij rapportering die per nacht of per uur ververst
Als een refresh per nacht of per kwartier volstaat, heb je geen streaming-laag nodig. Een gewone batch-pijplijn is eenvoudiger te bouwen en te bewaken. Zit je daar net tussen, dan brengt Change Data Capture je bijna-live zonder de volle Kafka-complexiteit.

Voor een handvol koppelingen tussen apps
Moet er af en toe een bericht van de ene app naar de andere, dan is een webhook lichter. Kafka loont pas bij veel events, veel afnemers, of wanneer je events wil kunnen terugspoelen.

Als klassieke wachtrij met opvolging per bericht
Kafka is geen vervanger voor een berichtenwachtrij die elk bericht apart opvolgt, mislukte berichten opzij zet en per bericht een taak bewaakt. Voor dat soort patroon zijn diensten als Azure Service Bus beter geschikt.

Zonder iemand die de stroom bewaakt
Een stille stream valt niet op: er komt gewoon niets meer binnen, zonder foutmelding. Zet per bron een alert op "geen events in de laatste x minuten", anders merk je een probleem pas als iemand de cijfers niet meer vertrouwt.