Apache Kafka 4.0: konec éry ZooKeeper

Kafka 4.0 (vydán Q1 2025) přinesl nejzásadnější architektonickou změnu za dekádu: kompletní odstranění ZooKeeper. KRaft (Kafka Raft) je teď jediný způsob správy metadata. Pro provoz to znamená jednodušší deployment (žádný ZooKeeper cluster na údržbu), rychlejší partition recovery a lepší škálovatelnost — Kafka cluster s milionem partitions už není edge case.

Proč KRaft mění hru

• Jednodušší operace — místo dvou distribuovaných systémů (Kafka + ZooKeeper) provozujete jeden. Méně moving parts = méně incidentů. Upgrade window se zkrátil z hodin na desítky minut.
• Rychlejší controller failover — KRaft controller election v řádu sekund vs. desítky sekund u ZooKeeper. Pro high-availability clustery zásadní rozdíl.
• Škálovatelnost metadata — KRaft zvládá metadata pro miliony partitions bez degradace. ZooKeeper byl hard limit na ~200K partitions per cluster.
• Next-gen consumer group protocol — nový rebalance protocol snižuje rebalance čas z minut na sekundy, což eliminuje „stop-the-world" momenty pro konzumenty.

Schema management a data contracts

V enterprise prostředí je Kafka jen tak dobrý, jak dobrý je kontrakt mezi producenty a konzumenty. Confluent Schema Registry s Avro nebo Protobuf schématy je náš standard. Každá změna schématu prochází compatibility check (backward/forward/full) — žádný breaking change se nedostane do produkce bez explicitního review.

Pro kritické toky implementujeme data contracts: formalizovaný popis schématu, SLA, ownership a quality expectations. Data contract je verzovaný artefakt v Git — změna prochází stejným review procesem jako kód.

Stream processing: Flink vs. Spark Structured Streaming

Volba mezi Flink a Spark Structured Streaming není dogmatická — závisí na use case:

Proč dbt (a ne čistý Spark/SQL)

dbt není execution engine — je to transformační framework nad vaším warehouse/lakehouse enginem. Přináší software engineering best practices do světa dat: version control (Git), code review, automatizované testy, dokumentace jako kód a dependency management.

Od verze dbt Core 1.9 je k dispozici microbatch strategie — inkrementální modely zpracovávají data v diskrétních časových oknech, každé s vlastním SQL query. Pro velké event-driven datasety to znamená dramatické snížení compute cost a processing time. V dbt Core 1.11 (konec 2025) přibyla Fusion engine pro rychlejší lokální development.

Náš dbt stack

• dbt Core (ne dbt Cloud) — provozujeme na vlastní infrastruktuře, scheduling přes Airflow nebo Dagster. Plná kontrola nad prostředím, secrets a networking.
• dbt-spark / dbt-databricks — adaptéry pro lakehouse engine. Optimalizace: incremental models s merge strategií, partition pruning hints.
• dbt packages — dbt_utils, dbt_expectations (Great Expectations-style testy), dbt_project_evaluator pro linting projektu.
• Slim CI — v CI/CD pipeline buildujeme jen modely ovlivněné změnou (dbt build --select state:modified+). Typická úspora: 80 % build time.
• Documentation as code — každý model má description, column descriptions a data tests. dbt docs generate produkuje interaktivní data catalog s lineage grafem.

Data quality framework

Data quality není volitelný krok — je integrální součást pipeline. Každý dbt model má:

• Schema testy — unique, not_null, accepted_values, relationships (referenční integrita)
• Custom testy — business pravidla jako SQL query (např. „suma transakcí per den musí souhlasit s kontrolním součtem ze source systému")
• Freshness checks — dbt source freshness kontroluje, zda zdrojová data nejsou starší než definované SLA. Alert přes PagerDuty pokud SLA prošvihnuto.
• Row count monitoring — anomaly detection na počtu řádků: pokud denní increment odchýlí od moving average o více než 3 σ, automaticky alert.