Hvordan gemmer du 100M log-events om dagen?

Question

IT Interview Practice · Accepted Answer

Byg en **append-only pipeline: agents → Kafka → tiered storage (hot i ClickHouse/ELK, cold i object storage)** med en retention-politik der indekserer nylige data og billigt arkiverer resten. 100M events/dag er ~1.200/sek i gennemsnit (spikes langt højere) og titusinder-til-hundreder af GB dagligt — du optimerer for billige writes og afgrænset query-omkostning, ikke OLTP-semantik.

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

## Append-pipeline

Logs er write-once, opdateres aldrig — så ingest-pathen er en **append**. Agents som **Fluent Bit / Vector** sender linjer til **Kafka**, som buffer bursts og decoupler producers fra storage. Hvis ClickHouse er nede til vedligeholdelse, køer events i Kafka og replayer — du dropper ikke logs. Batch writes (tusindvis af rows pr. insert), fordi per-row inserts ødelægger throughput på columnar stores.

## Hot store: indeksér for søgning

Nylige logs kræver hurtig søgning ("fejl i sidste time for service X"). **ClickHouse** (columnar, komprimerer 10x, scanner milliarder af rows/sek) eller **ELK-stakken** (Elasticsearch inverted index) serverer dette. Partitionér efter dag/service, så forespørgsler beskærer til nogle få partitioner. Denne tier er dyr pr. GB, så hold den lille — kun de sidste 7–30 dage.

## Cold store: object storage + tiering

Ældre logs flytter til **S3 som Parquet** — billigt, holdbart, forespørgbart on demand via Athena/Trino. En **lifecycle-politik** overfører S3 → Glacier → sletning ved din retention-grænse (fx 1 år). Denne *tiering* er den centrale omkostningsgreb: hot storage kan være 50x prisen af arkiv.

## Interview-perspektiv

Interviewere undersøger **index-vs-cost-trade-off'et**: at indeksere alt giver fantastisk søgning men sprænger budgettet; at indeksere intet er billigt men uforespørgbart. Godt: "brug ELK." Fremragende: du tierer — indeksér den nylige hotte skive, arkivér resten koldt — og navngiver Kafka som bufferen, der gør ingestion modstandsdygtig over for downstream-udfald.

**Almindelig fælde:** at putte alle logs i Elasticsearch for evigt. Det er den dyreste mulighed, og dens cluster vælter på kardinalitet/retention, du ikke planlagde for.

## Trade-offs & fejlmåder

- **Retention vs omkostning:** længere retention = lineær storage-vækst; tier aggressivt.
- **Kafka backpressure:** hvis consumers sakker, fyldes disk — dimensionér retention og monitorér lag.
- **Kardinalitets-eksplosion:** høj-kardinalitets-felter (user_id) opsvulmer ES-indekser; sampl eller drop dem.
- **Query-omkostning på cold data:** Athena-scans koster pr. TB — partitionér Parquet efter dato/service, så scans forbliver afgrænsede.
- **At-least-once-dubletter:** dedup på et event-id hvis nøjagtige tællere betyder noget.

Append-pipeline

Hot store: indeksér for søgning

Cold store: object storage + tiering

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål