Kako pohraniti 100 milijuna log događaja dnevno?

Question

IT Interview Practice · Accepted Answer

Izgradite **append-only pipeline: agenti → Kafka → slojevita pohrana (hot u ClickHouse/ELK, cold u object storageu)** s politikom zadržavanja koja indeksira nedavne podatke i jeftino arhivira ostatak. 100 milijuna događaja/dan je ~1.200/s u prosjeku (skokovi daleko veći) i desetci do stotine GB dnevno — optimizirate za jeftine upise i ograničen trošak upita, ne za OLTP semantiku.

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

Logovi se upisuju jednom, nikad ne ažuriraju — pa je put unosa **append**. Agenti poput **Fluent Bit / Vector** šalju linije u **Kafku**, koja bufferira nagle skokove i razdvaja producere od pohrane. Ako je ClickHouse nedostupan zbog održavanja, događaji čekaju u Kafki i replayaju se — ne gubite logove. Batchirajte upise (tisuće redaka po insertu) jer per-row inserti uništavaju throughput na columnar storeovima.

## Hot store: indeks za pretragu

Nedavni logovi trebaju brzu pretragu ("pogreške u zadnjem satu za servis X"). **ClickHouse** (columnar, komprimira 10x, skenira milijarde redaka/s) ili **ELK stack** (Elasticsearch inverted index) poslužuju ovo. Particionirajte po danu/servisu tako da upiti prune na nekoliko particija. Ovaj sloj je skup po GB, pa ga držite malenim — samo zadnjih 7–30 dana.

## Cold store: object storage + tiering

Stariji logovi sele u **S3 kao Parquet** — jeftino, trajno, upitno na zahtjev preko Athene/Trina. **Lifecycle politika** prebacuje S3 → Glacier → brisanje na vašem limitu zadržavanja (npr. 1 godina). Ovaj *tiering* je ključna poluga troška: hot pohrana može biti 50x cijena arhivske.

## Perspektiva intervjua

Ispitivači ispituju **kompromis indeks-vs-trošak**: indeksiranje svega daje odličnu pretragu ali razbija budžet; indeksiranje ničega je jeftino ali neupitno. Dobro: "koristi ELK." Odlično: slojevito — indeksirate nedavni hot dio, arhivirate ostatak hladno — i imenujete Kafku kao buffer koji čini unos otpornim na prekide u nizvodnim sustavima.

**Uobičajena zamka:** stavljanje svih logova u Elasticsearch zauvijek. To je najskuplja opcija i njegov cluster pada na kardinalnosti/zadržavanju koje niste planirali.

## Kompromisi i načini otkazivanja

- **Zadržavanje vs trošak:** dulje zadržavanje = linearni rast pohrane; agresivno slojevite.
- **Kafka backpressure:** ako consumeri zaostaju, disk se puni — dimenzionirajte zadržavanje i nadzirite lag.
- **Eksplozija kardinalnosti:** polja visoke kardinalnosti (user_id) napuhuju ES indekse; sampleirajte ih ili odbacite.
- **Trošak upita na cold podacima:** Athena skeniranja koštaju po TB — particionirajte Parquet po datumu/servisu da skeniranja ostanu ograničena.
- **At-least-once duplikati:** dedup po event id-u ako su točni brojevi važni.

Append pipeline

Hot store: indeks za pretragu

Cold store: object storage + tiering

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja