Real-time Analytics

Kdy batch processing nestačí¶

Batch processing (denní/hodinový ETL) je správná volba pro většinu analytických use cases. Ale existují scénáře, kde zpoždění stojí reálné peníze:

Fraud Detection¶

Podvodná transakce musí být detekována v sekundách, ne v hodinách. Real-time scoring: transakce → enrichment (historie zákazníka, geolokace, device fingerprint) → ML model → approve/decline. Latence >5s = schválený podvod.

Dynamic Pricing¶

E-commerce, ride-sharing, hospitality — cena se mění podle poptávky, konkurence, zásob. Batch pricing s hodinovým update znamená hodinu suboptimálních cen. Real-time pricing reaguje na události okamžitě.

IoT & Telemetrie¶

Tisíce senzorů generují miliony eventů za minutu. Anomaly detection na streaming datech — pokud teplota stroje překročí threshold, alert přijde za sekundy, ne za hodiny. Prediktivní údržba vyžaduje real-time feature engineering.

Operativní dashboardy¶

Live přehled objednávek, zásilek, SLA, throughputu. Supply chain visibility — kde je každá zásilka teď, ne kde byla včera. Operátoři potřebují aktuální stav, ne historický snapshot.

Architektura real-time platformy¶

Apache Kafka — event streaming backbone¶

Kafka není jen message broker. Je to distribuovaný commit log, event streaming platforma a integrační páteř v jednom:

• Guaranteed delivery: At-least-once (default) nebo exactly-once (transactional)
• Ordering: Per-partition ordering garantuje sekvenční zpracování
• Replay: Consumer může číst od libovolného offsetu — reprocessing, debugging, nový consumer
• Retention: Konfigurovatelná (hodiny až neomezeně) — Kafka jako source of truth
• Schema Registry: Schema evolution (Avro, Protobuf) — producent a consumer se dohodnou na formátu

Stream Processing¶

Apache Flink — náš primární stream processor: - Stateful processing s exactly-once semantics - Event time processing — správné výsledky i při out-of-order eventech - Windowing: tumbling, sliding, session windows - Complex Event Processing (CEP) — pattern matching přes stream eventů - Savepoints a checkpoints pro fault tolerance

Kafka Streams — pro jednodušší transformace: - Library, ne cluster — běží jako součást vaší aplikace - Filtering, mapping, aggregace, joins - State stores pro lokální stav - Ideální pro microservice-based architektury

ksqlDB — SQL nad streaming daty: - SELECT, WHERE, GROUP BY, JOIN — jako SQL, ale nad nekonečným streamem - Materialized views aktualizované v reálném čase - Ideální pro prototyping a jednoduché use cases

Change Data Capture (CDC)¶

Debezium zachytává změny v databázi a posílá je do Kafky v reálném čase:

• PostgreSQL, MySQL, SQL Server, MongoDB — podporované zdroje
• Log-based CDC — čte z WAL/binlog, žádný impact na zdrojovou databázi
• Schema propagace — změny schématu se propagují automaticky
• Initial snapshot — první load celé tabulky, pak inkrementální změny

Real-time sinking¶

Data z Kafky do cílových systémů: - Elasticsearch — full-text search, real-time indexing - ClickHouse — OLAP dotazy nad streaming daty - Redis — cache pro real-time feature store - Snowflake/Databricks — streaming ingestion do warehouse/lakehouse - S3/ADLS — archivace raw eventů

Monitoring a operations¶

Kafka monitoring¶

• Consumer lag — jak daleko je consumer za producerem. Rostoucí lag = processing bottleneck
• Throughput — messages/s per topic, partition balance
• Broker health — ISR (in-sync replicas), under-replicated partitions
• Storage — disk usage, retention vs. capacity

Stream processing monitoring¶

• Backpressure — processing je pomalejší než input rate
• Checkpoint duration — jak dlouho trvá checkpoint (Flink)
• Watermark lag — zpoždění event time vs. processing time
• State size — rostoucí state = potenciální memory issue

Alerting¶

• Consumer lag > threshold → scale up consumers
• Broker offline → immediate alert + automatic rebalance
• Processing latency > SLA → investigate bottleneck
• Error rate spike → circuit breaker + dead letter queue

Implementační přístup¶

1. Use case assessment (1 týden): Identifikace use cases, kde real-time přináší měřitelnou hodnotu. Ne všechno potřebuje být real-time.
2. Kafka cluster setup (1-2 týdny): Provisioning (Confluent Cloud nebo self-managed), topic design, security (mTLS, SASL), Schema Registry.
3. MVP streaming pipeline (2-4 týdny): CDC z primárního zdroje → Kafka → stream processing → cílový systém. End-to-end monitoring.
4. Škálování a optimalizace (ongoing): Další zdroje a consumers, performance tuning, partitioning strategie, cost optimalizace.

Souvisí s