Analityka przychodów w czasie rzeczywistym po milionach transakcji dziennie: jak?

Question

IT Interview Practice · Accepted Answer

**Strumieniuj transakcje przez Kafkę do procesora strumieniowego, który wstępnie agreguje je do magazynu OLAP, tak aby dashboardy czytały maleńkie prekomputowane rollupy zamiast skanować surowe zdarzenia.** Przy milionach transakcji/dzień nigdy nie uruchamiasz `SUM()` po surowej tabeli przy każdym załadowaniu strony — agregujesz raz, przy zapisie.

## Architektura

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

## Jak to działa

- **Kafka** to trwały log. Każda płatność publikuje zdarzenie (`amount`, `currency`, `ts`, `merchant`). Buforuje skoki, odseparowuje producentów od konsumentów i pozwala **odtwarzać (replay)** historię, aby przebudować agregaty.
- **Procesor strumieniowy (Flink / Kafka Streams)** utrzymuje **okna tumbling/sliding** (per minuta/godzina) i składa każde zdarzenie w bieżącą sumę w swoim **state store**. Wyjściem jest prekomputowany wiersz per (minuta, wymiar).
- **Magazyn OLAP (ClickHouse, Druid, Pinot)** przechowuje te rollupy kolumnowo. Dashboard odpytujący „przychód z ostatnich 24 h" skanuje ~1440 wierszy, nie miliony — poniżej sekundy.
- **Materialized views** w ClickHouse mogą wykonać ten sam rollup wewnątrz DB (`AggregatingMergeTree`), jeśli chcesz mniej ruchomych części.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje, czy **agregujesz przy zapisie vs skanujesz przy odczycie** oraz czy rozumiesz **exactly-once**. Dobre odpowiedzi nazywają Kafkę + OLAP; świetne wyjaśniają, **dlaczego spóźnione/zduplikowane zdarzenia psują sumy** i jak to naprawić: klucze idempotentne, **checkpointing Flinka + transakcyjny sink** dla exactly-once oraz **watermarki** zamykające okna mimo spóźnionych przybyć. Częstą pułapką jest proponowanie `SELECT SUM()` na Postgres — OK przy tysiącach/dzień, zawala się przy milionach.

## Kompromisy i awarie

- **Lambda vs Kappa.** Lambda uruchamia warstwę wsadową (nocny Spark uzgadnia źródło prawdy) obok warstwy strumieniowej (szybkiej, ale przybliżonej) — dokładne, ale dwie bazy kodu. **Kappa** używa tylko warstwy strumieniowej i **odtwarza Kafkę**, aby naprawiać błędy — prostsza, jedna baza kodu, teraz częsty domyślny wybór.
- **Exactly-once nie jest darmowe.** Transakcyjne sinki dodają latency i koszt throughputu; wiele zespołów akceptuje **at-least-once + idempotentne upserty** kluczowane po `txn_id`.
- **Spóźnione dane.** Płatność rozliczająca się 2 h później ląduje po zamknięciu okna. Watermarki + dozwolone opóźnienie ponownie otwierają okna, albo nocne zadanie wsadowe koryguje wczorajsze liczby.
- **Wiele walut / zwroty** trzeba modelować jako zdarzenia ze znakiem, inaczej „przychód" dryfuje.
- **Kiedy nie:** kilka tysięcy transakcji/dzień nie potrzebuje niczego z tego — tabela rollup w Postgres aktualizowana cronem bije klaster Kafka+Flink, który musisz utrzymywać.

Architektura

Jak to działa

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania