दररोज 10 कोटी log events तुम्ही कसे साठवाल?

Question

IT Interview Practice · Accepted Answer

एक **append-only pipeline बनवा: agents → Kafka → tiered storage (hot ClickHouse/ELK मध्ये, cold object storage मध्ये)** एका retention policy सह जी अलीकडील data index करते आणि उर्वरित स्वस्तात archive करते. दररोज 10 कोटी events म्हणजे सरासरी ~1,200/sec (spikes खूप जास्त) आणि दररोज दहा-ते-शंभर GB — तुम्ही स्वस्त writes आणि बांधलेल्या query cost साठी optimize करता, OLTP semantics साठी नाही.

```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 write-once असतात, कधीही update होत नाहीत — म्हणून ingest path एक **append** आहे. **Fluent Bit / Vector** सारखे agents lines **Kafka** कडे पाठवतात, जे bursts buffer करते आणि producers ला storage पासून decouple करते. ClickHouse maintenance साठी down असल्यास, events Kafka मध्ये queue होतात आणि replay होतात — तुम्ही logs टाकत नाही. Batch writes (प्रति insert हजारो rows) कारण per-row inserts columnar stores वर throughput नष्ट करतात.

## Hot store: search साठी index

अलीकडील logs ना जलद search लागते ("service X साठी शेवटच्या तासातील errors"). **ClickHouse** (columnar, 10x compress करते, अब्जावधी rows/sec scan करते) किंवा **ELK stack** (Elasticsearch inverted index) हे serve करतात. day/service नुसार partition करा जेणेकरून queries काही partitions पर्यंत prune होतात. हा tier प्रति GB महाग आहे, म्हणून तो लहान ठेवा — फक्त शेवटचे 7–30 दिवस.

## Cold store: object storage + tiering

जुने logs **S3 ला Parquet म्हणून** हलतात — स्वस्त, durable, Athena/Trino द्वारे मागणीनुसार queryable. एक **lifecycle policy** तुमच्या retention मर्यादेला (उदा. 1 वर्ष) S3 → Glacier → deletion transition करते. हे *tiering* मुख्य cost lever आहे: hot storage archival पेक्षा 50x किंमतीचे असू शकते.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारे **index-vs-cost तडजोड** तपासतात: सर्व काही index करणे उत्तम search देते पण budget उडवते; काहीही index न करणे स्वस्त पण unqueryable. चांगले: "ELK वापरा." उत्तम: तुम्ही tier करता — अलीकडील hot slice index करा, उर्वरित cold archive करा — आणि Kafka ला ingestion downstream outages ला resilient बनवणारा buffer म्हणून नाव देता.

**सामान्य सापळा:** सर्व logs कायमचे Elasticsearch मध्ये ठेवणे. तो सर्वात महाग पर्याय आहे आणि तुम्ही नियोजित न केलेल्या cardinality/retention वर त्याचे cluster कोसळते.

## तडजोडी आणि अपयश

- **Retention vs cost:** दीर्घ retention = linear storage वाढ; आक्रमकपणे tier करा.
- **Kafka backpressure:** consumers मागे पडल्यास, disk भरते — retention size करा आणि lag monitor करा.
- **Cardinality explosion:** high-cardinality fields (user_id) ES indexes फुगवतात; sample करा किंवा टाका.
- **Cold data वरील Query cost:** Athena scans प्रति TB खर्च करतात — Parquet ला date/service नुसार partition करा जेणेकरून scans बांधलेले राहतात.
- **At-least-once dupes:** exact counts महत्त्वाचे असल्यास event id वर dedup करा.

Append pipeline

Hot store: search साठी index

Cold store: object storage + tiering

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

संबंधित प्रश्न