Πώς αποθηκεύετε 100 εκατομμύρια log events την ημέρα;

Question

IT Interview Practice · Accepted Answer

Χτίστε ένα **append-only pipeline: agents → Kafka → tiered storage (hot σε ClickHouse/ELK, cold σε object storage)** με μια retention policy που κάνει index τα πρόσφατα δεδομένα και αρχειοθετεί φθηνά τα υπόλοιπα. 100 εκατ. events/μέρα είναι ~1.200/sec κατά μέσο όρο (spikes πολύ υψηλότερα) και δεκάδες-έως-εκατοντάδες GB ημερησίως — βελτιστοποιείτε για φθηνά writes και φραγμένο κόστος query, όχι για 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 γράφονται μία φορά, ποτέ δεν ενημερώνονται — οπότε το μονοπάτι ingest είναι ένα **append**. Agents όπως το **Fluent Bit / Vector** στέλνουν γραμμές στο **Kafka**, το οποίο κάνει buffer τα bursts και αποσυζευγνύει τους producers από το storage. Αν το ClickHouse είναι down για maintenance, τα events μπαίνουν στην ουρά του Kafka και κάνουν replay — δεν πετάτε logs. Κάντε batch τα writes (χιλιάδες rows ανά insert) γιατί τα per-row inserts καταστρέφουν το throughput σε columnar stores.

## Hot store: index για search

Τα πρόσφατα logs χρειάζονται γρήγορο search ("errors την τελευταία ώρα για την υπηρεσία X"). Το **ClickHouse** (columnar, συμπιέζει 10x, κάνει scan δισεκατομμύρια rows/sec) ή το **ELK stack** (Elasticsearch inverted index) το σερβίρουν αυτό. Κάντε partition ανά day/service ώστε τα queries να κλαδεύουν σε λίγα partitions. Αυτό το tier είναι ακριβό ανά GB, οπότε κρατήστε το μικρό — μόνο τις τελευταίες 7–30 μέρες.

## Cold store: object storage + tiering

Τα παλαιότερα logs μετακινούνται σε **S3 ως Parquet** — φθηνά, durable, queryable on demand μέσω Athena/Trino. Μια **lifecycle policy** μεταβαίνει S3 → Glacier → διαγραφή στο όριο retention (π.χ. 1 έτος). Αυτό το *tiering* είναι ο βασικός μοχλός κόστους: το hot storage μπορεί να είναι 50x η τιμή του archival.

## Οπτική συνέντευξης

Οι συνεντευκτές διερευνούν το **index-vs-cost trade-off**: το index-άρισμα των πάντων δίνει εξαιρετικό search αλλά τινάζει τον προϋπολογισμό· το index-άρισμα τίποτα είναι φθηνό αλλά μη-queryable. Καλό: "χρησιμοποίησε ELK." Εξαιρετικό: κάνετε tier — index το πρόσφατο hot κομμάτι, αρχειοθέτησε τα υπόλοιπα cold — και κατονομάζετε το Kafka ως το buffer που κάνει το ingestion ανθεκτικό σε downstream διακοπές.

**Συνηθισμένη παγίδα:** να βάζετε όλα τα logs στο Elasticsearch για πάντα. Είναι η πιο ακριβή επιλογή και το cluster του καταρρέει σε cardinality/retention που δεν σχεδιάσατε.

## Trade-offs & τρόποι αποτυχίας

- **Retention vs κόστος:** μεγαλύτερο retention = γραμμική αύξηση storage· κάντε tier επιθετικά.
- **Kafka backpressure:** αν οι consumers υστερούν, ο δίσκος γεμίζει — διαστασιολογήστε το retention και monitor το lag.
- **Cardinality explosion:** high-cardinality πεδία (user_id) φουσκώνουν τα ES indexes· κάντε sample ή drop τα.
- **Κόστος query σε cold data:** τα Athena scans κοστίζουν ανά TB — κάντε partition το Parquet ανά date/service ώστε τα scans να μένουν φραγμένα.
- **At-least-once dupes:** dedup σε ένα event id αν τα ακριβή counts έχουν σημασία.

Append pipeline

Hot store: index για search

Cold store: object storage + tiering

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις