Wie speicherst du 100 Mio. Log-Events pro Tag?

Question

IT Interview Practice · Accepted Answer

Baue eine **Append-only-Pipeline: Agents → Kafka → gestaffelter Storage (heiß in ClickHouse/ELK, kalt in Object Storage)** mit einer Retention Policy, die aktuelle Daten indexiert und den Rest günstig archiviert. 100 Mio. Events/Tag sind ~1.200/Sek. im Schnitt (Spitzen weit höher) und zehn bis hunderte GB täglich - du optimierst für günstige Writes und begrenzte Query-Kosten, nicht für OLTP-Semantik.

```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 werden einmal geschrieben, nie aktualisiert - der Ingest-Pfad ist also ein **Append**. Agents wie **Fluent Bit / Vector** schicken Zeilen an **Kafka**, das Bursts puffert und Producer von Storage entkoppelt. Ist ClickHouse zur Wartung offline, warten Events in Kafka und werden neu abgespielt - du droppst keine Logs. Batche Writes (Tausende Rows pro Insert), denn Per-Row-Inserts zerstören den Throughput auf Columnar Stores.

## Hot Store: für Suche indexieren

Aktuelle Logs brauchen schnelle Suche ("Fehler in der letzten Stunde für Service X"). **ClickHouse** (columnar, komprimiert 10x, scannt Milliarden Rows/Sek.) oder der **ELK-Stack** (Elasticsearch Inverted Index) bedienen das. Partitioniere nach Tag/Service, damit Queries auf wenige Partitionen beschnitten werden. Diese Schicht ist teuer pro GB, halte sie also klein - nur die letzten 7-30 Tage.

## Cold Store: Object Storage + Tiering

Ältere Logs wandern nach **S3 als Parquet** - günstig, langlebig, on demand über Athena/Trino abfragbar. Eine **Lifecycle Policy** überführt S3 → Glacier → Löschung an deinem Retention-Limit (z. B. 1 Jahr). Dieses *Tiering* ist der zentrale Kostenhebel: Hot Storage kann das 50-fache des Archival-Preises kosten.

## Interview-Perspektive

Interviewer sondieren den **Index-vs-Kosten-Trade-off**: alles zu indexieren gibt hervorragende Suche, sprengt aber das Budget; nichts zu indexieren ist günstig, aber nicht abfragbar. Gut: "ELK verwenden." Hervorragend: Du staffelst - indexierst die aktuelle heiße Scheibe, archivierst den Rest kalt - und benennst Kafka als den Puffer, der Ingestion gegen Downstream-Ausfälle resilient macht.

**Häufige Falle:** alle Logs für immer in Elasticsearch zu legen. Es ist die teuerste Option und sein Cluster kippt bei Kardinalität/Retention um, die du nicht eingeplant hast.

## Trade-offs & Fehlermodi

- **Retention vs. Kosten:** längere Retention = lineares Speicherwachstum; staffle aggressiv.
- **Kafka-Backpressure:** hinken Consumer hinterher, füllt sich die Platte - dimensioniere Retention und überwache Lag.
- **Kardinalitätsexplosion:** hochkardinale Felder (user_id) blähen ES-Indizes auf; sample oder droppe sie.
- **Query-Kosten auf Cold Data:** Athena-Scans kosten pro TB - partitioniere Parquet nach Datum/Service, damit Scans begrenzt bleiben.
- **At-least-once-Duplikate:** dedupliziere auf einer Event-ID, wenn exakte Zähler zählen.

Append-Pipeline

Hot Store: für Suche indexieren

Cold Store: Object Storage + Tiering

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen