Analitik hasil masa nyata ke atas jutaan transaksi/hari: bagaimana?

Question

IT Interview Practice · Accepted Answer

**Alirkan transaksi melalui Kafka ke dalam stream processor yang pra-aggregate ke dalam OLAP store, supaya dashboard membaca rollup kecil yang telah dikira dan bukannya mengimbas peristiwa mentah.** Pada jutaan txn/hari anda tidak pernah menjalankan `SUM()` ke atas jadual mentah setiap kali halaman dimuat — anda aggregate sekali, semasa penulisan.

## Seni bina

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

## Cara ia berfungsi

- **Kafka** ialah log durable. Setiap pembayaran menerbitkan satu peristiwa (`amount`, `currency`, `ts`, `merchant`). Ia menampan lonjakan, men-decouple pengeluar daripada consumer, dan membenarkan anda **replay** sejarah untuk membina semula aggregate.
- **Stream processor (Flink / Kafka Streams)** mengekalkan **tumbling/sliding window** (setiap minit/jam) dan melipat setiap peristiwa ke dalam jumlah berjalan di dalam **state store**-nya. Output ialah satu baris pra-aggregate bagi setiap (minit, dimensi).
- **OLAP store (ClickHouse, Druid, Pinot)** menyimpan rollup itu secara columnar. Sebuah dashboard yang men-query "hasil 24j terakhir" mengimbas ~1,440 baris, bukan berjuta — sub-saat.
- **Materialized views** dalam ClickHouse boleh melakukan rollup yang sama di dalam DB (`AggregatingMergeTree`) jika anda mahu lebih sedikit bahagian bergerak.

## Perspektif temu duga

Penemu duga menyiasat sama ada anda **pra-aggregate semasa penulisan vs mengimbas semasa bacaan**, dan sama ada anda memahami **exactly-once**. Jawapan yang baik menyebut Kafka + OLAP; jawapan yang hebat menerangkan **mengapa peristiwa lewat/pendua merosakkan jumlah** dan cara membetulkannya: idempotency key, **checkpointing + transactional sink** Flink untuk exactly-once, dan **watermark** untuk menutup window walaupun ada ketibaan lewat. Perangkap biasa ialah mencadangkan `SELECT SUM()` pada Postgres — baik pada beribu/hari, ia runtuh pada jutaan.

## Pertukaran & mod kegagalan

- **Lambda vs Kappa.** Lambda menjalankan lapisan batch (Spark malam merekonsiliasi sumber kebenaran) di samping lapisan stream (pantas tetapi anggaran) — tepat tetapi dua codebase. **Kappa** hanya menggunakan lapisan stream dan **me-replay Kafka** untuk membetulkan pepijat — lebih mudah, satu codebase, kini lalai biasa.
- **Exactly-once bukan percuma.** Transactional sink menambah latency dan kos throughput; banyak pasukan menerima **at-least-once + idempotent upsert** berkunci pada `txn_id` sebaliknya.
- **Data lewat.** Sebuah pembayaran yang selesai 2j lewat mendarat selepas window-nya ditutup. Watermark + allowed-lateness membuka semula window, atau kerja batch malam membetulkan nombor semalam.
- **Multi-currency / refund** mesti dimodelkan sebagai peristiwa bertanda (signed events), jika tidak "hasil" tersasar.
- **Bila jangan:** beberapa ribu txn/hari tidak memerlukan apa-apa ini — jadual rollup Postgres yang dikemas kini oleh cron mengalahkan cluster Kafka+Flink yang perlu anda operasikan.

Seni bina

Cara ia berfungsi

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan