Jak uložíte 100 milionů log událostí denně?

Question

IT Interview Practice · Accepted Answer

Postavte **append-only pipeline: agenti → Kafka → vrstvené úložiště (hot v ClickHouse/ELK, cold v object storage)** s retenční politikou, která indexuje nedávná data a zbytek levně archivuje. 100 milionů událostí/den je průměrně ~1 200/s (špičky mnohem vyšší) a desítky až stovky GB denně — optimalizujete pro levné zápisy a ohraničenou cenu dotazu, ne pro OLTP sémantiku.

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

Logy se zapisují jednou, nikdy neaktualizují — takže cesta příjmu je **append**. Agenti jako **Fluent Bit / Vector** posílají řádky do **Kafky**, která bufferuje výkyvy a odděluje producenty od úložiště. Pokud je ClickHouse mimo kvůli údržbě, události čekají ve frontě v Kafce a přehrají se — logy neztratíte. Zapisujte dávkově (tisíce řádků na insert), protože per-row inserty ničí throughput na columnar storech.

## Hot store: indexuj pro vyhledávání

Nedávné logy potřebují rychlé vyhledávání („chyby za poslední hodinu pro službu X“). **ClickHouse** (columnar, komprimuje 10×, skenuje miliardy řádků/s) nebo **ELK stack** (Elasticsearch invertovaný index) toto obsluhují. Partitionujte podle dne/služby, aby dotazy prořízly na pár partitionů. Tato vrstva je drahá na GB, takže ji držte malou — jen posledních 7–30 dní.

## Cold store: object storage + tiering

Starší logy se přesunou do **S3 jako Parquet** — levné, trvanlivé, dotazovatelné na vyžádání přes Athena/Trino. **Lifecycle politika** přechází S3 → Glacier → smazání na vašem retenčním limitu (např. 1 rok). Tento *tiering* je klíčovou pákou nákladů: hot úložiště může být 50× dražší než archivní.

## Pohled z pohovoru

Tazatelé zkoumají **kompromis index-vs-cena**: indexovat vše dá skvělé vyhledávání, ale rozbije rozpočet; neindexovat nic je levné, ale nedotazovatelné. Dobré: „použij ELK.“ Skvělé: vrstvíte — indexujete nedávný hot výřez, zbytek archivujete cold — a pojmenujete Kafku jako buffer, který činí ingestion odolným vůči výpadkům downstreamu.

**Častá past:** dát všechny logy do Elasticsearch navždy. Je to nejdražší varianta a jeho cluster se zhroutí na kardinalitě/retenci, kterou jste neplánovali.

## Kompromisy a režimy selhání

- **Retence vs náklady:** delší retence = lineární růst úložiště; vrstvěte agresivně.
- **Kafka backpressure:** pokud consumeři zaostávají, disk se plní — dimenzujte retenci a monitorujte lag.
- **Exploze kardinality:** vysoce kardinalitní pole (user_id) nafouknou ES indexy; samplujte je nebo je zahoďte.
- **Cena dotazu na cold datech:** Athena skeny stojí za TB — partitionujte Parquet podle data/služby, aby skeny zůstaly ohraničené.
- **At-least-once duplicity:** deduplikujte podle event id, pokud jsou přesné počty důležité.

Append pipeline

Hot store: indexuj pro vyhledávání

Cold store: object storage + tiering

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky