Valós idejű bevétel-analitika napi milliónyi tranzakció felett: hogyan?

Question

IT Interview Practice · Accepted Answer

**Streameld a tranzakciókat Kafkán át egy stream processzorba, amely előaggregál egy OLAP store-ba, így a dashboardok apró előre kiszámított rollupokat olvasnak ahelyett, hogy nyers eseményeket szkennelnének.** Napi milliónyi tranzakciónál sosem futtatsz `SUM()`-ot a nyers táblán minden oldalbetöltéskor — egyszer aggregálsz, íráskor.

## Architektúra

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Hogyan működik

- **Kafka** a tartós log. Minden fizetés publikál egy eseményt (`amount`, `currency`, `ts`, `merchant`). Pufferelí a csúcsokat, szétcsatolja a producereket a consumerektől, és lehetővé teszi a történelem **replayjét** az aggregációk újraépítéséhez.
- **Stream processzor (Flink / Kafka Streams)** **tumbling/sliding ablakokat** tart (percenként/óránként) és minden eseményt egy futó összegbe hajtogat a **state store-jában**. A kimenet egy előaggregált sor (perc, dimenzió)-nként.
- **OLAP store (ClickHouse, Druid, Pinot)** oszloposan tárolja ezeket a rollupokat. Egy "utolsó 24 óra bevétele" lekérdezés dashboard ~1440 sort szkennel, nem milliókat — szubszekundum.
- **Materialized view-k** a ClickHouse-ban ugyanezt a rollupot elvégezhetik az adatbázison belül (`AggregatingMergeTree`), ha kevesebb mozgó alkatrészt akarsz.

## Interjú szemszög

Az interjúztató azt vizsgálja, **íráskor előaggregálsz-e vs olvasáskor szkennelsz**, és érted-e az **exactly-once**-t. A jó válaszok megnevezik a Kafka + OLAP-ot; a kiváló válaszok megmagyarázzák, **miért rontják el a késői/duplikált események az összegeket** és hogyan javítsd őket: idempotencia kulcsok, Flink **checkpointing + tranzakcionális sink** az exactly-once-hoz, és **watermarkok** az ablakok lezárásához a késői érkezések ellenére. Gyakori csapda a `SELECT SUM()`-ot javasolni Postgresen — rendben van napi ezreknél, összeomlik napi millióknál.

## Kompromisszumok és hibák

- **Lambda vs Kappa.** A Lambda egy batch réteget futtat (éjszakai Spark egyezteti az igazságforrást) a stream réteg (gyors de közelítő) mellett — pontos de két kódbázis. A **Kappa** csak a stream réteget használja és **replayeli a Kafkát** a hibák javításához — egyszerűbb, egy kódbázis, ma a gyakori default.
- **Az exactly-once nem ingyenes.** A tranzakcionális sinkek latenciát és throughput költséget adnak; sok csapat inkább **at-least-once + idempotens upserteket** fogad el `txn_id`-re kulcsolva.
- **Késői adat.** Egy 2 órát késve elszámoló fizetés az ablaka lezárása után érkezik. A watermarkok + megengedett késés újranyitják az ablakokat, vagy egy éjszakai batch job kijavítja a tegnapi számokat.
- **Több pénznem / visszatérítések** előjeles eseményekként modellezendők, különben a "bevétel" elsodródik.
- **Mikor ne:** napi néhány ezer tranzakciónak semmi ilyesmi nem kell — egy cronnal frissített Postgres rollup tábla veri a Kafka+Flink fürtöt, amit üzemeltetned kell.

Architektúra

Hogyan működik

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések