Cum stochezi 100M de evenimente de log pe zi?

Question

IT Interview Practice · Accepted Answer

Construiește un **pipeline append-only: agenți → Kafka → stocare pe niveluri (hot în ClickHouse/ELK, cold în object storage)** cu o politică de retenție care indexează datele recente și arhivează ieftin restul. 100M de evenimente/zi înseamnă ~1.200/sec în medie (vârfuri mult mai mari) și zeci-până-la-sute de GB zilnic — optimizezi pentru scrieri ieftine și cost de interogare delimitat, nu pentru semantică 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

Log-urile sunt write-once, niciodată actualizate — deci calea de ingestie este un **append**. Agenți precum **Fluent Bit / Vector** trimit liniile către **Kafka**, care face buffering la rafale și decuplează producătorii de stocare. Dacă ClickHouse este căzut pentru mentenanță, evenimentele se pun în coadă în Kafka și fac replay — nu pierzi log-uri. Fă scrieri în batch (mii de rânduri per insert) pentru că insert-urile per rând distrug throughput-ul pe columnar stores.

## Store hot: indexează pentru căutare

Log-urile recente au nevoie de căutare rapidă ("erori în ultima oră pentru serviciul X"). **ClickHouse** (columnar, comprimă 10x, scanează miliarde de rânduri/sec) sau **stack-ul ELK** (index inversat Elasticsearch) servesc asta. Fă partition după zi/serviciu, astfel încât interogările să facă pruning la câteva partiții. Acest tier este scump per GB, deci ține-l mic — doar ultimele 7–30 de zile.

## Store cold: object storage + tiering

Log-urile mai vechi se mută în **S3 ca Parquet** — ieftin, durabil, interogabil la cerere prin Athena/Trino. O **politică de lifecycle** tranziționează S3 → Glacier → ștergere la limita ta de retenție (de ex. 1 an). Acest *tiering* este pârghia principală de cost: stocarea hot poate fi de 50x prețul celei de arhivă.

## Perspectiva de interviu

Intervievatorii sondează **compromisul index-vs-cost**: indexarea a tot oferă căutare excelentă, dar aruncă în aer bugetul; indexarea a nimic este ieftină, dar neinterogabilă. Bine: "folosește ELK." Excelent: faci tiering — indexezi felia hot recentă, arhivezi restul cold — și numești Kafka ca bufferul care face ingestia rezilientă la căderile din aval.

**Capcană obișnuită:** a pune toate log-urile în Elasticsearch pentru totdeauna. Este opțiunea cea mai scumpă, iar clusterul lui se prăbușește la cardinalitatea/retenția pe care nu ai planificat-o.

## Compromisuri și moduri de eșec

- **Retenție vs cost:** retenție mai lungă = creștere liniară a stocării; fă tiering agresiv.
- **Backpressure Kafka:** dacă consumerii rămân în urmă, discul se umple — dimensionează retenția și monitorizează lag-ul.
- **Explozie de cardinalitate:** câmpurile cu cardinalitate mare (user_id) umflă indecșii ES; fă sampling sau elimină-le.
- **Cost de interogare pe date cold:** scanurile Athena costă per TB — fă partition la Parquet după dată/serviciu, astfel încât scanurile să rămână delimitate.
- **Dubluri at-least-once:** fă dedup pe un id de eveniment dacă numerele exacte contează.

Pipeline append

Store hot: indexează pentru căutare

Store cold: object storage + tiering

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe