Come memorizzi 100M di eventi di log al giorno?

Question

IT Interview Practice · Accepted Answer

Costruisci una **pipeline append-only: agenti → Kafka → storage a tier (caldo in ClickHouse/ELK, freddo in object storage)** con una retention policy che indicizza i dati recenti e archivia il resto a basso costo. 100M di eventi/giorno sono ~1.200/sec in media (picchi molto più alti) e da decine a centinaia di GB al giorno — ottimizzi per scritture economiche e costo di query limitato, non per semantica 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

I log sono write-once, mai aggiornati — quindi il percorso di ingest è un **append**. Agenti come **Fluent Bit / Vector** inviano le righe a **Kafka**, che bufferizza i burst e disaccoppia i producer dallo storage. Se ClickHouse è down per manutenzione, gli eventi si accodano in Kafka e vengono ripetuti — non perdi log. Fai batch delle scritture (migliaia di righe per insert) perché gli insert per-riga distruggono il throughput sui columnar store.

## Store caldo: indicizza per la ricerca

I log recenti richiedono ricerca veloce ("errori nell'ultima ora per il servizio X"). **ClickHouse** (columnar, comprime 10x, fa scan di miliardi di righe/sec) o lo **stack ELK** (inverted index di Elasticsearch) servono a questo. Partiziona per giorno/servizio così che le query facciano pruning a poche partizioni. Questo tier è costoso per GB, quindi mantienilo piccolo — solo gli ultimi 7–30 giorni.

## Store freddo: object storage + tiering

I log più vecchi si spostano su **S3 come Parquet** — economico, durevole, interrogabile on demand via Athena/Trino. Una **lifecycle policy** fa transitare S3 → Glacier → cancellazione al tuo limite di retention (es. 1 anno). Questo *tiering* è la leva di costo centrale: lo storage caldo potrebbe costare 50x quello di archivio.

## Prospettiva del colloquio

Gli intervistatori sondano il **compromesso index-vs-costo**: indicizzare tutto dà ottima ricerca ma fa esplodere il budget; indicizzare nulla è economico ma non interrogabile. Buono: "usa ELK." Eccellente: fai tiering — indicizza la fetta calda recente, archivia il resto a freddo — e nomini Kafka come il buffer che rende l'ingestione resiliente alle interruzioni a valle.

**Trappola comune:** mettere tutti i log in Elasticsearch per sempre. È l'opzione più costosa e il suo cluster cede su cardinalità/retention che non hai pianificato.

## Compromessi e modalità di guasto

- **Retention vs costo:** retention più lunga = crescita lineare dello storage; fai tiering aggressivo.
- **Backpressure di Kafka:** se i consumer restano indietro, il disco si riempie — dimensiona la retention e monitora il lag.
- **Esplosione di cardinalità:** i campi ad alta cardinalità (user_id) gonfiano gli indici ES; campionali o scartali.
- **Costo di query sui dati freddi:** gli scan di Athena costano per TB — partiziona il Parquet per data/servizio così che gli scan restino limitati.
- **Doppioni at-least-once:** fai dedup su un event id se i conteggi esatti contano.

Pipeline append

Store caldo: indicizza per la ricerca

Store freddo: object storage + tiering

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate