Si i ruani 100M log events në ditë?

Question

IT Interview Practice · Accepted Answer

Ndërtoni një **pipeline append-only: agents → Kafka → tiered storage (i nxehtë në ClickHouse/ELK, i ftohtë në object storage)** me një retention policy që indekson të dhënat e fundit dhe arkivon pjesën tjetër lirë. 100M events/ditë janë ~1,200/sek mesatarisht (spikes shumë më të larta) dhe dhjetëra-deri-qindra GB në ditë — optimizoni për shkrime të lira dhe kosto query të kufizuar, jo semantikë 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
```

## Append pipeline

Logs shkruhen një herë, kurrë nuk përditësohen — kështu që rruga e ingest është një **append**. Agents si **Fluent Bit / Vector** dërgojnë rreshtat te **Kafka**, i cili buffer-on burst-et dhe bën decouple të prodhuesve nga magazinimi. Nëse ClickHouse është poshtë për mirëmbajtje, event-et rreshtohen në Kafka dhe bëjnë replay — nuk hidhni logs. Batch-oni shkrimet (mijëra rreshta për insert) sepse insert-et për çdo rresht shkatërrojnë throughput-in në columnar stores.

## Hot store: indekso për kërkim

Logs e fundit kanë nevojë për kërkim të shpejtë ("gabime në orën e fundit për service X"). **ClickHouse** (columnar, kompreson 10x, skanon miliarda rreshta/sek) ose **ELK stack** (Elasticsearch inverted index) e shërbejnë këtë. Partition sipas ditës/service-it që query-t të pastrohen në pak partitions. Ky tier është i shtrenjtë për GB, kështu që mbajeni të vogël — vetëm 7–30 ditët e fundit.

## Cold store: object storage + tiering

Logs më të vjetër lëvizin te **S3 si Parquet** — të lirë, të qëndrueshëm, të interrogueshëm sipas kërkesës përmes Athena/Trino. Një **lifecycle policy** i kalon S3 → Glacier → fshirje në limitin tuaj të retention (p.sh. 1 vit). Ky *tiering* është leva kryesore e kostos: hot storage mund të jetë 50x çmimi i arkivit.

## Këndvështrimi i intervistës

Intervistuesit heton **kompromisin index-vs-kosto**: indeksimi i gjithçkaje jep kërkim të shkëlqyer por thyen buxhetin; indeksimi i asgjëje është i lirë por i pa-interrogueshëm. Mirë: "përdor ELK." E shkëlqyer: bëni tier — indeksoni pjesën e fundit të nxehtë, arkivoni pjesën tjetër të ftohtë — dhe emërtoni Kafka si buffer-in që e bën ingestion-in rezistent ndaj ndërprerjeve downstream.

**Kurthi i zakonshëm:** vendosja e të gjitha logs në Elasticsearch përgjithmonë. Është opsioni më i shtrenjtë dhe klaster-i i tij rrëzohet nga kardinaliteti/retention që nuk planifikuat.

## Kompromiset & mënyrat e dështimit

- **Retention vs kosto:** retention më i gjatë = rritje lineare e magazinimit; bëni tier agresivisht.
- **Kafka backpressure:** nëse consumers vonojnë, disku mbushet — dimensiononi retention dhe monitoroni lag.
- **Cardinality explosion:** fusha me kardinalitet të lartë (user_id) fryjnë ES indexes; bëni sample ose hidhini.
- **Kosto query mbi të dhëna të ftohta:** Athena skanon me kosto për TB — partition Parquet sipas datës/service-it që skanimet të mbeten të kufizuara.
- **At-least-once dupes:** dedup mbi një event id nëse numrat e saktë kanë rëndësi.

Append pipeline

Hot store: indekso për kërkim

Cold store: object storage + tiering

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme