Reaaliaikainen liikevaihtoanalytiikka miljoonien transaktioiden/päivä yli: miten?

Question

IT Interview Practice · Accepted Answer

**Striimaa transaktiot Kafkan läpi stream-prosessoriin, joka esiaggregoi OLAP-storeen, jotta dashboardit lukevat pieniä esilaskettuja rollupeja raakatapahtumien skannaamisen sijaan.** Miljoonilla txn/päivä et koskaan aja `SUM()`:ia raakataulun yli joka sivunlatauksella — aggregoit kerran, kirjoitushetkellä.

## Arkkitehtuuri

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

## Miten se toimii

- **Kafka** on kestävä loki. Jokainen maksu julkaisee tapahtuman (`amount`, `currency`, `ts`, `merchant`). Se puskuroi piikit, irtikytkee tuottajat consumereista ja antaa sinun **toistaa** historian aggregaattien uudelleenrakentamiseksi.
- **Stream-prosessori (Flink / Kafka Streams)** pitää **tumbling/sliding-ikkunoita** (per minuutti/tunti) ja laskee jokaisen tapahtuman juoksevaan kokonaissummaan **state storessaan**. Ulostulo on esiaggregoitu rivi per (minuutti, dimensio).
- **OLAP-store (ClickHouse, Druid, Pinot)** tallentaa nuo rollupit kolumnaarisesti. Dashboard, joka kyselee "liikevaihto viimeiset 24 h", skannaa ~1 440 riviä, ei miljoonia — alle sekunnin.
- **Materialized viewt** ClickHousessa voivat tehdä saman rollupin DB:n sisällä (`AggregatingMergeTree`), jos haluat vähemmän liikkuvia osia.

## Haastattelunäkökulma

Haastattelija tutkii, **esiaggregoitko kirjoitushetkellä vai skannaatko lukuhetkellä**, ja ymmärrätkö **exactly-oncen**. Hyvät vastaukset nimeävät Kafka + OLAP; loistavat vastaukset selittävät **miksi myöhäiset/duplikaattitapahtumat korruptoivat kokonaissummat** ja miten korjata ne: idempotenssiavaimet, Flinkin **checkpointing + transaktionaalinen sink** exactly-oncelle ja **watermarkit** ikkunoiden sulkemiseksi myöhäisistä saapumisista huolimatta. Yleinen ansa on ehdottaa `SELECT SUM()`:ia Postgresissa — hyvä tuhansilla/päivä, se romahtaa miljoonilla.

## Kompromissit ja virhetilanteet

- **Lambda vs Kappa.** Lambda ajaa batch-kerroksen (yöllinen Spark täsmäyttää totuuden lähteen) stream-kerroksen (nopea mutta likimääräinen) rinnalla — tarkka mutta kaksi koodikantaa. **Kappa** käyttää vain stream-kerrosta ja **toistaa Kafkan** virheiden korjaamiseksi — yksinkertaisempi, yksi koodikanta, nyt yleinen oletus.
- **Exactly-once ei ole ilmaista.** Transaktionaaliset sinkit lisäävät latenssia ja throughput-kustannusta; monet tiimit hyväksyvät sen sijaan **at-least-once + idempotentit upsertit** avainnettuna `txn_id`:hen.
- **Myöhäinen data.** 2 h myöhässä selviävä maksu saapuu ikkunansa sulkeuduttua. Watermarkit + sallittu myöhäisyys avaavat ikkunat uudelleen, tai yöllinen batch-työ korjaa eilisen luvut.
- **Monivaluutta / hyvitykset** on mallinnettava etumerkillisiksi tapahtumiksi, muuten "liikevaihto" ryömii.
- **Milloin ei:** muutama tuhat txn/päivä ei tarvitse mitään tästä — cronilla päivitetty Postgres-rollup-taulu voittaa Kafka+Flink-klusterin, jota joudut operoimaan.

Arkkitehtuuri

Miten se toimii

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset