Realaus laiko pajamų analitika per milijonus transakcijų per dieną: kaip?

Question

IT Interview Practice · Accepted Answer

**Perduokite transakcijas srautu per Kafka į stream procesorių, kuris iš anksto agreguoja į OLAP saugyklą, kad ataskaitų skydeliai skaitytų mažyčius iš anksto apskaičiuotus rollups, o ne skenuotų neapdorotus įvykius.** Esant milijonams transakcijų/dieną niekada nevykdote `SUM()` per neapdorotą lentelę kiekvieno puslapio įkėlimo metu — agreguojate vieną kartą, įrašant.

## 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)
```

## Kaip tai veikia

- **Kafka** yra patvarus žurnalas. Kiekvienas mokėjimas publikuoja įvykį (`amount`, `currency`, `ts`, `merchant`). Jis buferizuoja smaigalius, atsieja gamintojus nuo consumerių ir leidžia **pakartoti** istoriją agregatams perkurti.
- **Stream procesorius (Flink / Kafka Streams)** laiko **tumbling/sliding windows** (per minutę/valandą) ir sulydo kiekvieną įvykį į bėgančią sumą savo **state store**. Išvestis yra iš anksto agreguota eilutė kiekvienam (minutė, dimensija).
- **OLAP saugykla (ClickHouse, Druid, Pinot)** saugo tuos rollups stulpeliškai. Ataskaitų skydelis, užklausiantis „pajamos per paskutines 24h", skenuoja ~1 440 eilučių, ne milijonus — mažiau nei sekundė.
- **Materialized views** ClickHouse gali atlikti tą patį rollup DB viduje (`AggregatingMergeTree`), jei norite mažiau judančių dalių.

## Interviu perspektyva

Interviuotojas tiria, ar **iš anksto agreguojate įrašant vs skenuojate skaitant**, ir ar suprantate **exactly-once**. Geri atsakymai įvardija Kafka + OLAP; puikūs paaiškina, **kodėl pavėluoti/dubliuoti įvykiai gadina sumas** ir kaip tai pataisyti: idempotentiškumo raktai, Flink **checkpointing + transactional sink** exactly-once, ir **watermarks** langams uždaryti nepaisant pavėluotų atvykimų. Dažni spąstai — siūlyti `SELECT SUM()` Postgres — tinka esant tūkstančiams/dieną, bet griūva esant milijonams.

## Kompromisai ir gedimai

- **Lambda vs Kappa.** Lambda vykdo batch sluoksnį (naktinis Spark suderina tiesos šaltinį) šalia stream sluoksnio (greitas, bet apytikslis) — tikslu, bet dvi kodų bazės. **Kappa** naudoja tik stream sluoksnį ir **pakartoja Kafka** klaidoms taisyti — paprasčiau, viena kodų bazė, dabar dažnas nutylėjimas.
- **Exactly-once nėra nemokamas.** Transactional sinks prideda latency ir throughput kainą; daugelis komandų vietoj to priima **at-least-once + idempotentiškus upserts**, raktuotus pagal `txn_id`.
- **Pavėluoti duomenys.** Mokėjimas, atsiskaitantis 2h vėliau, patenka po lango uždarymo. Watermarks + allowed-lateness atidaro langus iš naujo, arba naktinis batch job pataiso vakarykščius skaičius.
- **Kelios valiutos / grąžinimai** turi būti modeliuojami kaip ženkluoti įvykiai, kitaip „pajamos" nukrypsta.
- **Kada ne:** keliems tūkstančiams transakcijų/dieną nereikia nieko iš to — Postgres rollup lentelė, atnaujinama cron, pranoksta Kafka+Flink klasterį, kurį reikia eksploatuoti.

Architektūra

Kaip tai veikia

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai