Realno-časovna analitika prihodkov čez milijone transakcij na dan: kako?

Question

IT Interview Practice · Accepted Answer

**Pretakajte transakcije skozi Kafko v stream procesor, ki pred-agregira v OLAP shrambo, tako da nadzorne plošče (dashboards) berejo drobne pred-izračunane rollupe namesto skeniranja surovih dogodkov.** Pri milijonih transakcij/dan nikoli ne zaganjate `SUM()` čez surovo tabelo ob vsakem nalaganju strani — agregirate enkrat, ob zapisu.

## Arhitektura

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

## Kako deluje

- **Kafka** je trajni dnevnik. Vsako plačilo objavi dogodek (`amount`, `currency`, `ts`, `merchant`). Medpomni konice, razklopi producente od consumerjev in omogoča **replay** zgodovine za ponovno gradnjo agregatov.
- **Stream procesor (Flink / Kafka Streams)** vzdržuje **tumbling/sliding okna** (na minuto/uro) in vsak dogodek zloži v tekočo vsoto v svoji **state store**. Izhod je pred-agregirana vrstica na (minuta, dimenzija).
- **OLAP shramba (ClickHouse, Druid, Pinot)** shranjuje te rollupe stolpčno. Nadzorna plošča, ki poizveduje "prihodek zadnjih 24 ur", skenira ~1.440 vrstic, ne milijonov — pod-sekundno.
- **Materializirani pogledi (materialized views)** v ClickHouse lahko naredijo isti rollup znotraj DB (`AggregatingMergeTree`), če želite manj premikajočih se delov.

## Pogled s stališča razgovora

Izpraševalec preverja, ali **pred-agregirate ob zapisu proti skeniranju ob branju** in ali razumete **exactly-once**. Dobri odgovori poimenujejo Kafka + OLAP; odlični pojasnijo, **zakaj zapozneli/podvojeni dogodki pokvarijo vsote** in kako to popraviti: idempotenčni ključi, Flink **checkpointing + transakcijski sink** za exactly-once in **watermarki (vodni žigi)** za zapiranje oken kljub zapoznelim prihodom. Pogosta past je predlaganje `SELECT SUM()` na Postgresu — v redu pri tisočih/dan, se sesuje pri milijonih.

## Kompromisi in odpovedi

- **Lambda proti Kappa.** Lambda zaganja batch sloj (nočni Spark usklajuje vir resnice) poleg stream sloja (hiter, a približen) — natančno, a dve kodni bazi. **Kappa** uporablja le stream sloj in **ponovno predvaja Kafko** za popravljanje napak — enostavneje, ena kodna baza, zdaj pogost privzetek.
- **Exactly-once ni zastonj.** Transakcijski sinki dodajo latenco in strošek throughputa; mnoge ekipe namesto tega sprejmejo **at-least-once + idempotentne upserte**, ključene na `txn_id`.
- **Zapozneli podatki.** Plačilo, ki se poravna 2h prepozno, pristane po zaprtju svojega okna. Watermarki + dovoljena zapoznelost (allowed-lateness) ponovno odprejo okna, ali nočni batch job popravi včerajšnje številke.
- **Večvalutnost / vračila** morajo biti modelirana kot predznačeni dogodki, sicer "prihodek" drsi.
- **Kdaj ne:** nekaj tisoč transakcij/dan ne potrebuje nič od tega — Postgres rollup tabela, posodobljena s cronom, premaga Kafka+Flink cluster, ki ga morate upravljati.

Arhitektura

Kako deluje

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja