Jak przechowywać 100 mln zdarzeń logów dziennie?

Question

IT Interview Practice · Accepted Answer

Zbuduj **append-only pipeline: agenci → Kafka → magazyn warstwowy (gorący w ClickHouse/ELK, zimny w object storage)** z polityką retencji indeksującą świeże dane i tanio archiwizującą resztę. 100 mln zdarzeń/dzień to średnio ~1200/s (skoki znacznie wyższe) i dziesiątki-setki GB dziennie — optymalizujesz pod tanie zapisy i ograniczony koszt zapytań, nie pod semantykę 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
```

## Pipeline append

Logi są zapisywane raz, nigdy aktualizowane — więc ścieżka przyjmowania to **append**. Agenci jak **Fluent Bit / Vector** wysyłają linie do **Kafki**, która buforuje skoki i odseparowuje producentów od magazynu. Jeśli ClickHouse jest wyłączony na konserwację, zdarzenia czekają w Kafce i są odtwarzane — nie gubisz logów. Zapisuj wsadowo (tysiące wierszy na insert), bo inserty per-wiersz niszczą throughput w store'ach kolumnowych.

## Gorący magazyn: indeksuj pod wyszukiwanie

Świeże logi potrzebują szybkiego wyszukiwania („błędy z ostatniej godziny dla serwisu X"). **ClickHouse** (kolumnowy, kompresuje 10x, skanuje miliardy wierszy/s) lub **stos ELK** (odwrócony indeks Elasticsearch) to obsługują. Partycjonuj po dniu/serwisie, aby zapytania przycinały się do kilku partycji. Ta warstwa jest droga per GB, więc trzymaj ją małą — tylko ostatnie 7–30 dni.

## Zimny magazyn: object storage + warstwowanie

Starsze logi przenoszą się do **S3 jako Parquet** — tanie, trwałe, odpytywalne na żądanie przez Athena/Trino. **Polityka lifecycle** przenosi S3 → Glacier → usunięcie przy limicie retencji (np. 1 rok). To *warstwowanie (tiering)* jest głównym mechanizmem kosztowym: gorący magazyn może być 50x droższy od archiwalnego.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówcy sondują **kompromis indeks-vs-koszt**: indeksowanie wszystkiego daje świetne wyszukiwanie, ale rozsadza budżet; indeksowanie niczego jest tanie, ale nieodpytywalne. Dobrze: „użyj ELK". Świetnie: warstwujesz — indeksujesz świeży gorący wycinek, archiwizujesz resztę na zimno — i nazywasz Kafkę jako bufor czyniący przyjmowanie odpornym na awarie downstream.

**Częsta pułapka:** trzymanie wszystkich logów w Elasticsearch na zawsze. To najdroższa opcja, a jej klaster przewraca się na kardynalności/retencji, których nie zaplanowałeś.

## Kompromisy i tryby awarii

- **Retencja vs koszt:** dłuższa retencja = liniowy wzrost magazynu; warstwuj agresywnie.
- **Backpressure Kafki:** jeśli konsumenci są w tyle, dysk się zapełnia — dobierz retencję i monitoruj lag.
- **Eksplozja kardynalności:** pola o wysokiej kardynalności (user_id) rozdmuchują indeksy ES; próbkuj lub odrzucaj je.
- **Koszt zapytań na zimnych danych:** Athena nalicza za skanowany TB — partycjonuj Parquet po dacie/serwisie, aby skany pozostały ograniczone.
- **Duble at-least-once:** dedupikuj po id zdarzenia, jeśli dokładne liczniki mają znaczenie.

Pipeline append

Gorący magazyn: indeksuj pod wyszukiwanie

Zimny magazyn: object storage + warstwowanie

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania