Kaip saugoti 100 mln. žurnalo (log) įvykių per dieną?

Question

IT Interview Practice · Accepted Answer

Sukurkite **append-only konvejerį: agentai → Kafka → pakopinė saugykla (karšta ClickHouse/ELK, šalta objektų saugykloje)** su saugojimo politika, kuri indeksuoja naujausius duomenis ir pigiai archyvuoja likusius. 100 mln. įvykių/dieną yra ~1 200/s vidutiniškai (smaigaliai gerokai aukštesni) ir dešimtys-iki-šimtų GB per dieną — optimizuojate pigiam įrašymui ir apribotai užklausų kainai, ne OLTP semantikai.

```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 konvejeris

Žurnalai rašomi vieną kartą, niekada neatnaujinami — tad priėmimo kelias yra **append**. Agentai kaip **Fluent Bit / Vector** siunčia eilutes į **Kafka**, kuris buferizuoja pliūpsnius ir atsieja gamintojus nuo saugyklos. Jei ClickHouse neveikia dėl priežiūros, įvykiai laukia eilėje Kafka ir pakartojami — neprarandate žurnalų. Rašykite partijomis (tūkstančiai eilučių viename insert), nes eilutės-po-eilutės insert sugriauna throughput stulpelinėse saugyklose.

## Karšta saugykla: indeksuokite paieškai

Naujausiems žurnalams reikia greitos paieškos („klaidos per paskutinę valandą servisui X"). **ClickHouse** (stulpelinė, suspaudžia 10x, skenuoja milijardus eilučių/s) arba **ELK stack** (Elasticsearch inverted index) tai aptarnauja. Skaidykite pagal dieną/servisą, kad užklausos apkarpytų iki kelių partition. Šis sluoksnis brangus už GB, tad laikykite jį mažą — tik paskutines 7–30 dienų.

## Šalta saugykla: objektų saugykla + tiering

Senesni žurnalai perkeliami į **S3 kaip Parquet** — pigu, patvaru, užklausiama pagal poreikį per Athena/Trino. **Lifecycle politika** perkelia S3 → Glacier → ištrynimas jūsų saugojimo ribose (pvz. 1 metai). Šis *tiering* yra pagrindinis kainos svertas: karšta saugykla gali būti 50x brangesnė nei archyvinė.

## Interviu perspektyva

Interviuotojai tiria **indeksavimo-vs-kainos kompromisą**: viską indeksuojant gaunama puiki paieška, bet susprogsta biudžetas; nieko neindeksuojant pigu, bet neužklausiama. Gerai: „naudokite ELK." Puikiai: taikote pakopas — indeksuojate naujausią karštą pjūvį, archyvuojate likusį šaltai — ir įvardijate Kafka kaip buferį, darantį priėmimą atsparų downstream gedimams.

**Dažni spąstai:** visų žurnalų laikymas Elasticsearch amžinai. Tai brangiausias variantas, o jo klasteris griūva nuo kardinalumo/saugojimo, kurio nesuplanavote.

## Kompromisai ir gedimų būdai

- **Saugojimas vs kaina:** ilgesnis saugojimas = tiesinis saugyklos augimas; taikykite pakopas agresyviai.
- **Kafka backpressure:** jei consumeriai atsilieka, diskas prisipildo — nustatykite saugojimo dydį ir stebėkite lag.
- **Kardinalumo sprogimas:** aukšto kardinalumo laukai (user_id) išpučia ES indeksus; imkite pavyzdžius arba atmeskite juos.
- **Užklausų kaina šaltiems duomenims:** Athena skenuoja už TB — skaidykite Parquet pagal datą/servisą, kad skenavimai liktų apriboti.
- **At-least-once dublikatai:** dedup pagal event id, jei tikslūs skaičiai svarbūs.

Append konvejeris

Karšta saugykla: indeksuokite paieškai

Šalta saugykla: objektų saugykla + tiering

Interviu perspektyva

Kompromisai ir gedimų būdai

Susiję klausimai