Hur lagrar du 100M logghändelser per dag?

Question

IT Interview Practice · Accepted Answer

Bygg en **append-only-pipeline: agenter → Kafka → nivåindelad lagring (het i ClickHouse/ELK, kall i objektlagring)** med en retention-policy som indexerar färsk data och billigt arkiverar resten. 100M händelser/dag är ~1 200/sek i snitt (toppar långt högre) och tiotals-till-hundratals GB dagligen — du optimerar för billiga skrivningar och begränsad frågekostnad, inte 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

Loggar är write-once, uppdateras aldrig — så ingest-vägen är ett **append**. Agenter som **Fluent Bit / Vector** skeppar rader till **Kafka**, som buffrar toppar och frikopplar producenter från lagring. Om ClickHouse är nere för underhåll köas händelser i Kafka och replayas — du tappar inte loggar. Batcha skrivningar (tusentals rader per insert) eftersom per-rad-inserts förstör throughput på columnar stores.

## Het store: indexera för sökning

Färska loggar behöver snabb sökning ("fel senaste timmen för service X"). **ClickHouse** (columnar, komprimerar 10x, scannar miljarder rader/sek) eller **ELK-stacken** (Elasticsearch inverted index) betjänar detta. Partitionera på dag/service så att frågor beskär till några partitioner. Denna nivå är dyr per GB, så håll den liten — bara de senaste 7–30 dagarna.

## Kall store: objektlagring + nivåindelning

Äldre loggar flyttas till **S3 som Parquet** — billigt, hållbart, frågebart on demand via Athena/Trino. En **lifecycle-policy** överför S3 → Glacier → radering vid din retention-gräns (t.ex. 1 år). Denna *nivåindelning* är den centrala kostnadshävstången: het lagring kan vara 50x priset av arkivering.

## Intervjuperspektiv

Intervjuare undersöker **avvägningen index-vs-kostnad**: att indexera allt ger utmärkt sökning men spränger budgeten; att indexera inget är billigt men ofrågebart. Bra: "använd ELK." Utmärkt: du nivåindelar — indexera den senaste heta delen, arkivera resten kallt — och namnger Kafka som bufferten som gör ingestion motståndskraftig mot nedströmsavbrott.

**Vanlig fälla:** att lägga alla loggar i Elasticsearch för evigt. Det är det dyraste alternativet och dess kluster faller omkull på kardinalitet/retention du inte planerade för.

## Avvägningar & felmoder

- **Retention vs kostnad:** längre retention = linjär lagringstillväxt; nivåindela aggressivt.
- **Kafka backpressure:** om consumers ligger efter fylls disken — dimensionera retention och övervaka lag.
- **Kardinalitetsexplosion:** högkardinalitetsfält (user_id) sväller ES-index; sampla eller släpp dem.
- **Frågekostnad på kall data:** Athena-scanner kostar per TB — partitionera Parquet på datum/service så att scanner förblir begränsade.
- **At-least-once-dubbletter:** dedupa på ett event id om exakta antal spelar roll.

Append-pipeline

Het store: indexera för sökning

Kall store: objektlagring + nivåindelning

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor