Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

Apache Kafka — real-time data streaming v praxi

18. 05. 2020 4 min čtení CORE SYSTEMSdata

Batch ETL běží jednou denně a váš dashboard ukazuje včerejší data? V roce 2020 je to pro mnoho byznysů příliš pomalu. Apache Kafka umožňuje zpracovávat miliony událostí za sekundu v reálném čase. Podívejme se, jak a kdy ji nasadit.

Co je Kafka a proč ji potřebujete

Apache Kafka je distribuovaná streamovací platforma. Původně vznikla v LinkedIn pro zpracování activity logů, dnes je de facto standard pro event-driven architektury. Kafka není message queue (i když se tak často používá) — je to distribuovaný commit log s garancí pořadí, perzistencí a replay schopností.

Hlavní vlastnosti, které ji odlišují od RabbitMQ nebo ActiveMQ:

  • Retence: zprávy zůstávají v topicu i po přečtení — consumer groups je mohou číst nezávisle, replay kdykoliv
  • Horizontální škálování: partitioning umožňuje paralelní zpracování — přidáte brokery, zvýšíte throughput
  • Ordering guarantee: zprávy v rámci jedné partition jsou striktně seřazené
  • Throughput: miliony zpráv za sekundu na commodity hardware — LinkedIn zpracovává 7 trilionů zpráv denně

Architektura: brokeři, topics a partitions

Kafka cluster se skládá z brokerů (serverů). Data se organizují do topics (logické kanály) a každý topic se dělí na partitions (fyzické logy). Replication factor určuje, kolik kopií každé partition existuje — typicky 3 pro produkci.

Pro naše nasazení v bankovním sektoru jsme zvolili 5 brokerů, replication factor 3, a partitioning podle customer ID. To zaručuje, že všechny události jednoho klienta jsou v jedné partition — striktní ordering bez kompromisů.

Kafka Connect — integrace bez kódu

Kafka Connect je framework pro streaming dat mezi Kafka a externími systémy. Source connectory čtou data do Kafky, sink connectory je zapisují ven. Pro většinu databází existují hotové connectory:

  • Debezium: CDC (Change Data Capture) pro PostgreSQL, MySQL, SQL Server, Oracle — zachytí každou změnu v databázi jako event
  • JDBC Source/Sink: polling-based, jednodušší ale bez real-time garance
  • Elasticsearch Sink: automatická indexace do Elasticsearch pro full-text search
  • S3 Sink: archivace do S3 pro long-term storage a analytics

Na projektu pro pojišťovnu jsme pomocí Debezium CDC zachytávali změny v Oracle databázi pojistných smluv a streamovali je do data lake na Azure Blob Storage. Z denního batch ETL na real-time — latence pod 5 sekund.

Schema Registry — evoluce bez chaosu

Bez schema managementu je Kafka jen glorifikovaný byte pipe. Confluent Schema Registry ukládá Avro/JSON/Protobuf schémata a vynucuje kompatibilitu. Backward compatible změna (přidání optional pole) projde, breaking change (odstranění povinného pole) se zamítne.

V praxi to znamená, že producer tým může přidat nové pole do eventu bez koordinace se všemi consumer týmy. Staří consumers ho prostě ignorují, noví ho mohou využít. Schema evolution místo big-bang migrace.

Pro stream processing v roce 2020 máte dvě hlavní volby:

  • Kafka Streams: Java knihovna, žádný cluster navíc, ideální pro jednodušší transformace, filtrování, agregace. Běží jako běžná Java aplikace
  • Apache Flink: plnohodnotný streaming engine, vlastní cluster, výrazně silnější pro komplexní event processing, windowing, pattern detection

Naše doporučení: začněte s Kafka Streams. Pokud potřebujete complex event processing (CEP), sliding windows přes miliony eventů, nebo exactly-once processing napříč systémy — přejděte na Flink.

Produkční provoz — lessons learned

Po dvou letech provozu Kafka clusterů v produkci máme několik poučení:

  • Monitoring je kritický: Kafka JMX metriky do Prometheus + Grafana. Sledujte consumer lag, under-replicated partitions, request latency
  • Partition count nenastavujte příliš vysoký: víc partitions = víc file handles, pomalejší leader election. 12 partitions na topic je dobrý výchozí bod
  • Retence plánujte dopředu: 7 dní default retence × 100 MB/s = 60 TB storage. Počítejte s tím
  • ZooKeeper je single point of failure: dedikovaný ZooKeeper ensemble, ne na stejných nodech jako brokeři (v roce 2020 ještě potřebujete ZK, KRaft přijde později)
  • Consumer group rebalancing: při deployi nových consumers může nastat storm — používejte cooperative rebalancing (Kafka 2.4+)

Managed vs. self-hosted

Confluent Cloud, AWS MSK, Azure Event Hubs (Kafka compatible) — managed služby snižují provozní zátěž, ale za cenu. Pro klienta s 50 GB/den je Confluent Cloud výrazně dražší než self-hosted. Pro startup s jedním DevOps inženýrem je managed služba no-brainer.

Kafka jako páteř event-driven architektury

Apache Kafka v roce 2020 není experimentální technologie — je to produkčně prověřený základ pro real-time data platformy. Klíč k úspěchu není samotná Kafka, ale promyšlený event design, schema management a monitoring. Bez nich je to jen rychlý chaos.

apache kafkastreamingdata platformevent-driven