Bagaimana anda menyimpan 100J peristiwa log setiap hari?

Question

IT Interview Practice · Accepted Answer

Bina sebuah **pipeline append-only: agent → Kafka → storan berperingkat (panas dalam ClickHouse/ELK, sejuk dalam object storage)** dengan polisi retention yang meng-index data terkini dan mengarkib selebihnya dengan murah. 100J peristiwa/hari ialah ~1,200/saat purata (lonjakan jauh lebih tinggi) dan berpuluh-ratus GB harian — anda mengoptimum untuk penulisan murah dan kos query yang terbatas, bukan semantik OLTP.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Pipeline append

Log ditulis sekali, tidak pernah dikemas kini — jadi laluan ingest ialah **append**. Agent seperti **Fluent Bit / Vector** menghantar baris ke **Kafka**, yang menampan lonjakan dan men-decouple pengeluar daripada storan. Jika ClickHouse tumbang untuk penyelenggaraan, peristiwa beratur dalam Kafka dan di-replay — anda tidak menggugurkan log. Batch penulisan (beribu baris setiap insert) kerana insert per-baris memusnahkan throughput pada columnar store.

## Store panas: index untuk carian

Log terkini memerlukan carian pantas ("ralat dalam sejam terakhir untuk perkhidmatan X"). **ClickHouse** (columnar, memampat 10x, mengimbas berbilion baris/saat) atau **ELK stack** (Elasticsearch inverted index) menyajikan ini. Partition mengikut hari/perkhidmatan supaya query menyunting kepada beberapa partition. Lapisan ini mahal setiap GB, jadi kekalkan ia kecil — hanya 7–30 hari terakhir.

## Store sejuk: object storage + tiering

Log lebih lama beralih ke **S3 sebagai Parquet** — murah, durable, boleh di-query atas permintaan melalui Athena/Trino. Sebuah **lifecycle policy** memindahkan S3 → Glacier → pemadaman pada had retention anda (cth. 1 tahun). *Tiering* ini ialah tuil kos teras: storan panas mungkin 50x harga arkib.

## Perspektif temu duga

Penemu duga menyiasat **pertukaran index-vs-kos**: meng-index segalanya memberi carian hebat tetapi memusnahkan bajet; meng-index apa-apa pun adalah murah tetapi tidak boleh di-query. Baik: "guna ELK." Hebat: anda ber-tier — index kepingan panas terkini, arkib selebihnya sejuk — dan menyebut Kafka sebagai penampan yang menjadikan ingestion berdaya tahan terhadap gangguan hiliran.

**Perangkap biasa:** meletakkan semua log dalam Elasticsearch selamanya. Ia pilihan paling mahal dan cluster-nya tumbang atas kardinaliti/retention yang tidak anda rancang.

## Pertukaran & mod kegagalan

- **Retention vs kos:** retention lebih lama = pertumbuhan storan linear; tier secara agresif.
- **Kafka backpressure:** jika consumer ketinggalan, disk penuh — saiz retention dan pantau lag.
- **Letupan kardinaliti:** medan kardinaliti tinggi (user_id) membengkakkan index ES; sampel atau gugurkannya.
- **Kos query pada data sejuk:** imbasan Athena berkos setiap TB — partition Parquet mengikut tarikh/perkhidmatan supaya imbasan kekal terbatas.
- **Pendua at-least-once:** dedup pada event id jika kiraan tepat penting.

Pipeline append

Store panas: index untuk carian

Store sejuk: object storage + tiering

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan