Wat is Apache Kafka?
Apache Kafka is een open source, gedistribueerd event streaming platform dat gebeurtenissen als een duurzaam, herspeelbaar logboek opslaat en in realtime doorgeeft van producerende naar consumerende systemen. Kafka werd bij LinkedIn ontwikkeld door Jay Kreps, Neha Narkhede en Jun Rao, begin 2011 open source gemaakt en is sinds oktober 2012 een top-level project van de Apache Software Foundation, onder de Apache License 2.0. Binnen OT-convergentie dient Kafka vooral als centrale databus tussen OT-systemen zoals SCADA en historians en IT-systemen zoals MES, ERP, cloudplatformen en analytics, boven de besturingslaag.
🧠 Hoe werkt Apache Kafka?
Kafka is gebaseerd op een gedistribueerd publish-subscribe-model met een append-only log als kern. Producers schrijven berichten naar een topic; consumers lezen die in hun eigen tempo terug. Anders dan bij een klassieke message broker verdwijnt een bericht niet na het lezen: het blijft staan tot de bewaartermijn verloopt.
| Component | Functie |
|---|---|
| Producer | Publiceert berichten (events) naar een topic |
| Broker | Server die berichten ontvangt, op schijf bewaart en uitlevert |
| Topic | Logische datastroom, bijvoorbeeld machine.telemetry |
| Partition | Geordend deel van een topic; eenheid van parallelisatie en replicatie |
| Offset | Volgnummer van een bericht binnen een partition; de consumer onthoudt zijn positie |
| Consumer group | Groep consumers die samen de partitions van een topic verdelen |
| Cluster | Verzameling brokers, beheerd door de KRaft-controllers |
Volgorde is alleen gegarandeerd binnen één partition. Daarom kiest u een sleutel (bijvoorbeeld het asset-ID) zodat alle events van één machine in dezelfde partition en dus in de juiste volgorde terechtkomen. Rondom de kern bestaan twee standaardonderdelen: Kafka Connect (sinds versie 0.9) voor koppelingen met databases en andere systemen, en Kafka Streams (sinds versie 0.10), een Java-bibliotheek voor streamverwerking. Waar een klassieke SCADA-omgeving data vooral cyclisch uitleest (polling) en beperkt bewaart, werkt Kafka event-gedreven: elke statuswijziging, alarm of meetwaarde is een event dat meerdere afnemers onafhankelijk van elkaar kunnen lezen.
🔄 Waarin verschilt Kafka van MQTT en een historian?
In industriële architecturen wordt Kafka vaak verward met MQTT of een historian. Ze vullen elkaar juist aan:
| Eigenschap | MQTT-broker | Apache Kafka | Historian |
|---|---|---|---|
| Doel | Lichte telemetrie van veel apparaten | Event backbone en integratie tussen systemen | Langdurige opslag van procesdata voor trends |
| Typische plek | Edge en apparaatniveau | Datacenter, IDMZ of cloud | Site- en bedrijfsniveau |
| Berichten na lezen | Weg (behalve retained message) | Blijven bewaard volgens retentie | Blijven bewaard en gecomprimeerd |
| Replay van historie | Nee | Ja, vanaf elke offset | Ja, via tijdreeksquery’s |
| Typische clients | Veel kleine apparaten, soms op onstabiele verbindingen | Backend-applicaties, connectors en streamverwerking | HMI’s, rapportage- en analysetools |
Een gangbaar patroon is daarom: machines publiceren via MQTT of Sparkplug B naar een broker in een Unified Namespace, een connector zet de relevante topics door naar Kafka, en Kafka verdeelt ze naar analytics, tijdreeksdatabases, data lakes en AI-toepassingen. Data uit PLC’s en sensoren komt vaak via OPC UA en een edge gateway binnen.
🏭 Waar staat Kafka in de Purdue-architectuur?
Data ontstaat op de lagere niveaus van het Purdue Model, maar Kafka zelf hoort daar niet.
| Purdue-niveau | Rol rond Kafka |
|---|---|
| Level 0-1 | Bron van sensor- en PLC-data; geen Kafka |
| Level 2 | SCADA-events en alarmen, uitgelezen door een edge gateway |
| Level 3 | Lokale Kafka-cluster of edge-broker op siteniveau, koppeling met MES |
| Level 3.5 (IDMZ) | Replicatie of doorgifte naar IT, vaak eenrichting |
| Level 4-5 | Centrale Kafka-cluster voor enterprise analytics en ERP |
| Cloud | Beheerde Kafka-diensten, data lakes en AI-platformen |
Kafka is niet geschikt voor hard realtime besturing, motion control of safety loops. Daarvoor blijven EtherCAT, ProfiNET, Ethernet IP en veldbussen nodig. Typische eind-tot-eindlatency ligt in de orde van milliseconden tot tientallen milliseconden en is niet deterministisch. Industriële realtime-netwerken werken met vaste cyclustijden van tientallen microseconden tot enkele milliseconden, met een voorspelbare latency.
⚙️ Welke instellingen zijn belangrijk voor betrouwbaarheid?
De standaardwaarden van Kafka zijn gericht op een eenvoudige start, niet op productie. In de broker-configuratie van Kafka 4.x geldt onder meer:
| Instelling | Standaard | Advies voor productie |
|---|---|---|
log.retention.hours |
168 (7 dagen) | Afstemmen op herstel- en replay-behoefte, bijvoorbeeld 14-30 dagen |
log.retention.bytes |
-1 (geen limiet) | Limiet per partition als schijfruimte beperkt is |
default.replication.factor |
1 | 3 brokers en replicatiefactor 3 |
min.insync.replicas |
1 | 2, zodat een schrijfactie op minstens twee brokers staat |
acks (producer) |
all |
Laten staan; combineren met idempotentie (standaard aan) |
message.max.bytes |
circa 1 MB | Grote bestanden niet via Kafka sturen, maar verwijzen naar opslag |
listeners |
PLAINTEXT://:9092 |
Alleen versleutelde, geauthenticeerde listeners |
Kafka bewaart data uren, dagen, weken of onbeperkt. Met log compaction (cleanup.policy=compact) houdt Kafka per sleutel alleen de laatste waarde, handig voor de actuele
status van elk asset. Dankzij retentie kunnen consumers historische events opnieuw lezen voor forensisch onderzoek, monitoring, het hertrainen van modellen of voorspellend onderhoud. Voor hoge beschikbaarheid repliceert Kafka elke partition naar meerdere brokers; valt de leider uit, dan
neemt een in-sync replica het over.
De hoge doorvoer van Kafka komt uit sequentieel schrijven naar schijf, het bundelen van berichten in batches, compressie (gzip, Snappy, LZ4 of zstd) en zero-copy-overdracht van schijf naar netwerk. De werkelijke prestaties hangen af van het aantal partitions, de snelheid van de opslag, de netwerkcapaciteit, de replicatiefactor en de CPU-belasting door compressie. Meet daarom met uw eigen berichtgrootte en volumes in plaats van te vertrouwen op benchmarkcijfers.
🕰️ Wat veranderde er met Kafka 4.0?
Kafka 4.0 verscheen op 18 maart 2025 en is de eerste versie die volledig zonder Apache ZooKeeper draait. De metadata wordt nu beheerd door Kafka’s eigen Raft-protocol (KRaft), wat één component minder betekent om te beheren en te beveiligen. Verder werd het nieuwe consumer-rebalanceprotocol (KIP-848) algemeen beschikbaar en kwam Queues for Kafka (KIP-932) als early access. Brokers vragen sinds 4.0 Java 17, clients Java 11. Bestaande clusters met ZooKeeper moeten eerst op een 3.x-versie naar KRaft migreren voordat ze naar 4.x kunnen. In oktober 2026 verscheen versie 4.4.
🔐 Hoe beveiligt u Kafka in een OT-omgeving?
Een belangrijk aandachtspunt: beveiliging staat in Kafka standaard uit. Een niet-beveiligd cluster is toegestaan en de standaardlistener is PLAINTEXT, zonder versleuteling en zonder authenticatie. Wie toegang heeft tot poort 9092, kan dan topics lezen en schrijven.
Belangrijke risico’s zijn ongeautoriseerde toegang, manipulatie van procesdata, misbruik van credentials, laterale beweging, denial-of-service en ketenrisico’s via connectors en plug-ins van derden. Maatregelen:
- Versleuteling - TLS op alle listeners, ook tussen brokers, met goed certificaatbeheer
- Authenticatie - mutual TLS of SASL met SCRAM-SHA-256/512, Kerberos (GSSAPI) of OAUTHBEARER; vermijd SASL/PLAIN zonder TLS
- Autorisatie - ACL’s per topic en per consumer group; commerciële distributies bieden daarnaast RBAC
- Beheertoegang - MFA op beheerconsoles, cloudportalen en jump hosts
- Segmentatie - plaats Kafka in een DMZ of IDMZ volgens het zones-en-conduits-model van IEC 62443; laat OT-systemen alleen naar buiten publiceren, of gebruik een datadiode voor strikte eenrichting
- Patchen - Kafka Connect kende bijvoorbeeld CVE-2023-25194 (versies 2.3.0 tot en met 3.3.2), waarbij een aanvaller met rechten om connectors te configureren code kon laten uitvoeren; opgelost in 3.4.0
- Logging en detectie - audit logs en brokermetrics naar een SIEM, met alarmering op afwijkende clients
Deze maatregelen sluiten aan op Defense in Depth en Zero Trust.
🧭 Hoe zet u Kafka stap voor stap in voor OT-data?
- Begin bij de use case - bijvoorbeeld OEE-rapportage, energiemonitoring of conditiebewaking, niet bij de technologie.
- Ontwerp de topics - naamgeving volgens de ISA-95-hiërarchie (site, area, lijn, asset), met het asset-ID als sleutel.
- Kies de ontsluiting - OPC UA of MQTT naar een edge gateway voor edge computing; Kafka Connect of een bridge naar Kafka.
- Plaats de cluster - drie brokers in een eigen zone boven Level 3, op Kubernetes met een operator, of een beheerde clouddienst zoals Amazon MSK of Azure Event Hubs (Kafka-endpoint vanaf de Standard-tier).
- Beveilig vóór ingebruikname - TLS, authenticatie en ACL’s aan, PLAINTEXT-listeners uit.
- Leg datagovernance vast - schema’s, eigenaarschap per topic en retentie per datatype.
- Test storingen - schakel een broker uit en controleer of producers bufferen en consumers zonder dataverlies verder gaan.
Een eenvoudig topicontwerp voor één fabriek kan er zo uitzien:
| Bron | Topic | Sleutel | Afnemer |
|---|---|---|---|
| PLC via edge gateway | site1.lijn2.telemetry |
asset-ID | Tijdreeksdatabase, analytics |
| SCADA | site1.alarms |
alarm-ID | SOC, monitoring |
| Energiemeters | site1.energy |
meter-ID | Energiedashboard |
| MES | site1.production.events |
ordernummer | ERP, AI-modellen |
Voor Nederlandse organisaties die onder de Cyberbeveiligingswet (de Nederlandse invulling van NIS2, van kracht sinds 15 augustus 2026) vallen, is een Kafka-cluster die OT-data verwerkt onderdeel van de netwerk- en informatiesystemen waarvoor zorgplicht geldt. Richtlijnen als NIST SP 800-82, ISO 27001 en het NIST CSF helpen bij het inrichten van beheer en monitoring.
❓ Veelgestelde vragen
Is Apache Kafka geschikt voor realtime besturing?
Nee, Apache Kafka is niet ontworpen voor deterministische, hard realtime besturing van machines of safety-functies. De latency is laag maar niet gegarandeerd. Kafka hoort daarom boven de besturingslaag, als integratie- en analyseplatform, terwijl PLC’s en veldbussen de besturing doen.
Heeft Apache Kafka nog ZooKeeper nodig?
Nee, sinds Kafka 4.0 (maart 2025) draait Apache Kafka uitsluitend in KRaft-modus zonder ZooKeeper. De metadata wordt beheerd door controllers binnen het Kafka-cluster zelf. Oudere clusters moeten eerst naar KRaft migreren voordat ze naar versie 4 kunnen upgraden.
Hoe lang bewaart Apache Kafka berichten?
Apache Kafka bewaart berichten standaard 7 dagen (168 uur), maar de bewaartermijn is per topic in te stellen op uren, weken of onbeperkt. Met log compaction bewaart Kafka per sleutel alleen de laatste waarde. Zo kunnen consumers historische events herspelen voor analyse of onderzoek.
Wat is het verschil tussen Kafka en MQTT?
MQTT is een licht protocol voor veel kleine apparaten op soms onstabiele verbindingen, terwijl Apache Kafka een gedistribueerd log is voor grote datastromen tussen backend-systemen. MQTT-berichten verdwijnen na aflevering, Kafka bewaart ze en ondersteunt replay. In de industrie worden ze vaak gecombineerd: MQTT aan de edge, Kafka als backbone.
Is Apache Kafka standaard beveiligd?
Nee, Apache Kafka staat standaard een PLAINTEXT-listener op poort 9092 toe, zonder versleuteling en authenticatie. Voor productie zet u TLS, SASL- of mTLS-authenticatie en ACL’s aan. In OT-omgevingen plaatst u Kafka bovendien in een gescheiden zone zoals de IDMZ.
Welke clouddiensten bieden Apache Kafka aan?
Grote cloudaanbieders hebben beheerde varianten van Apache Kafka, zoals Amazon MSK (Managed Streaming for Apache Kafka), een beheerde Kafka-dienst van Google Cloud en een Kafka-compatibel endpoint in Azure Event Hubs. Daarnaast levert onder meer Confluent een commercieel Kafka-platform. U beheert dan zelf geen brokers, maar blijft verantwoordelijk voor toegang en datastromen.
📌 Samengevat
Apache Kafka is een gedistribueerd, herspeelbaar eventlog dat OT-data schaalbaar en betrouwbaar naar IT, cloud en analytics brengt, boven de besturingslaag. Gebruik Kafka als backbone naast MQTT en historians, plaats het in de IDMZ of hoger, zet beveiliging expliciet aan en kies replicatie en retentie bewust. Dan wordt Kafka een stevige bouwsteen voor IIoT, digital twins en veilige IT/OT-integratie met hoge schaalbaarheid en duidelijke segmentatie.