Как хранить 100 млн событий логов в день?

Question

IT Interview Practice · Accepted Answer

Постройте **append-only пайплайн: агенты → Kafka → tiered-хранилище (горячее в ClickHouse/ELK, холодное в объектном хранилище)** с политикой retention, которая индексирует свежие данные и дёшево архивирует остальное. 100 млн событий/день — это в среднем ~1200/с (пики намного выше) и десятки-сотни ГБ в сутки — вы оптимизируете под дешёвые записи и ограниченную стоимость запроса, а не под 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-пайплайн

Логи пишутся один раз и никогда не обновляются — поэтому путь приёма — это **append**. Агенты вроде **Fluent Bit / Vector** отправляют строки в **Kafka**, которая буферизует всплески и отделяет производителей от хранилища. Если ClickHouse лежит на обслуживании, события копятся в Kafka и переигрываются — вы не теряете логи. Пишите батчами (тысячи строк на вставку), потому что построчные вставки убивают throughput колоночных хранилищ.

## Горячее хранилище: индекс для поиска

Свежим логам нужен быстрый поиск («ошибки за последний час по сервису X»). **ClickHouse** (колоночный, сжимает 10x, сканирует миллиарды строк/с) или стек **ELK** (инвертированный индекс Elasticsearch) обслуживают это. Партиционируйте по дню/сервису, чтобы запросы отсекались до нескольких партиций. Этот слой дорог за ГБ, поэтому держите его маленьким — только последние 7–30 дней.

## Холодное хранилище: объектное хранилище + tiering

Старые логи переезжают в **S3 как Parquet** — дёшево, durable, запрашиваемо по требованию через Athena/Trino. **Lifecycle-политика** переводит S3 → Glacier → удаление на пределе retention (например, 1 год). Этот *tiering* — главный рычаг стоимости: горячее хранилище может быть в 50 раз дороже архивного.

## Взгляд с точки зрения интервью

Интервьюеры прощупывают компромисс **индекс-против-стоимости**: индексировать всё даёт отличный поиск, но взрывает бюджет; не индексировать ничего дёшево, но нельзя запрашивать. Хорошо: «использовать ELK». Отлично: вы делаете tiering — индексируете свежий горячий срез, архивируете остальное холодным — и называете Kafka буфером, делающим приём устойчивым к отказам downstream.

**Частая ловушка:** держать все логи в Elasticsearch навсегда. Это самый дорогой вариант, и его кластер валится на кардинальности/retention, которые вы не спланировали.

## Компромиссы и режимы отказа

- **Retention против стоимости:** более долгий retention = линейный рост хранилища; агрессивно делайте tiering.
- **Backpressure Kafka:** если consumer-ы отстают, диск заполняется — задавайте retention и мониторьте lag.
- **Взрыв кардинальности:** поля высокой кардинальности (user_id) раздувают индексы ES; сэмплируйте или отбрасывайте их.
- **Стоимость запроса по холодным данным:** Athena тарифицирует скан за ТБ — партиционируйте Parquet по дате/сервису, чтобы сканы оставались ограниченными.
- **Дубли at-least-once:** дедуплицируйте по event id, если важны точные счётчики.

Append-пайплайн

Горячее хранилище: индекс для поиска

Холодное хранилище: объектное хранилище + tiering

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы