Kako shranite 100 milijonov log dogodkov na dan?

Question

IT Interview Practice · Accepted Answer

Zgradite **append-only cevovod: agenti → Kafka → večnivojska shramba (vroča v ClickHouse/ELK, hladna v objektni shrambi)** s politiko hrambe (retention), ki indeksira nedavne podatke in poceni arhivira ostalo. 100M dogodkov/dan je ~1.200/s povprečno (konice precej višje) in deset-do-sto GB dnevno — optimizirate za poceni zapise in omejen strošek poizvedb, ne za OLTP semantiko.

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

Logi se zapišejo enkrat, nikoli posodobijo — zato je pot zajema **append**. Agenti, kot sta **Fluent Bit / Vector**, pošiljajo vrstice v **Kafko**, ki medpomni sunke in razklopi producente od shrambe. Če je ClickHouse zaradi vzdrževanja dol, se dogodki uvrstijo v Kafko in ponovno predvajajo (replay) — logov ne izgubite. Paketno zapisujte (tisoče vrstic na insert), ker per-row inserti uničijo throughput na stolpčnih shrambah.

## Vroča shramba: indeks za iskanje

Nedavni logi potrebujejo hitro iskanje ("napake v zadnji uri za storitev X"). **ClickHouse** (stolpčni, komprimira 10x, skenira milijarde vrstic/s) ali **ELK stack** (Elasticsearch obrnjeni indeks) to strežeta. Particionirajte po dnevu/storitvi, tako da se poizvedbe obrežejo na nekaj particij. Ta nivo je drag na GB, zato ga ohranjajte majhen — le zadnjih 7–30 dni.

## Hladna shramba: objektna shramba + večnivojskost (tiering)

Starejši logi se premaknejo v **S3 kot Parquet** — poceni, trajni, poizvedljivi na zahtevo prek Athena/Trino. **Politika življenjskega cikla (lifecycle policy)** prehaja S3 → Glacier → izbris ob vaši meji hrambe (npr. 1 leto). Ta *tiering* je osrednji vzvod stroškov: vroča shramba je lahko 50x cena arhivske.

## Pogled s stališča razgovora

Izpraševalci preverjajo **kompromis indeks-proti-strošku**: indeksiranje vsega daje odlično iskanje, a razstreli proračun; indeksiranje ničesar je poceni, a nepoizvedljivo. Dobro: "uporabi ELK." Odlično: nivojite — indeksirajte nedavno vročo rezino, arhivirajte ostalo hladno — in poimenujete Kafko kot medpomnilnik, ki naredi zajem odporen na izpade nižje v toku.

**Pogosta past:** dajanje vseh logov v Elasticsearch za vedno. To je najdražja možnost in njegov cluster se prevrne pri kardinalnosti/hrambi, ki je niste načrtovali.

## Kompromisi in načini odpovedi

- **Hramba proti strošku:** daljša hramba = linearna rast shrambe; nivojite agresivno.
- **Kafka protipritisk (backpressure):** če consumerji zaostanejo, se disk napolni — dimenzionirajte hrambo in nadzorujte zaostanek (lag).
- **Eksplozija kardinalnosti:** polja visoke kardinalnosti (user_id) napihnejo ES indekse; vzorčite ali jih zavrzite.
- **Strošek poizvedb na hladnih podatkih:** Athena skeniranja stanejo na TB — particionirajte Parquet po datumu/storitvi, da skeniranja ostanejo omejena.
- **At-least-once dvojniki:** dedup na event id, če so natančna štetja pomembna.

Append cevovod

Vroča shramba: indeks za iskanje

Hladna shramba: objektna shramba + večnivojskost (tiering)

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja