如何每天存储 1 亿条日志事件？

Question

如何每天存储 1 亿条日志事件？

IT Interview Practice · Accepted Answer

构建一个**只追加（append-only）的管道：agents → Kafka → 分层存储（热数据在 ClickHouse/ELK，冷数据在对象存储）**，配一个保留策略，为近期数据建 index，并廉价地归档其余部分。每天 1 亿事件平均约为每秒 1,200 条（峰值远高于此），每天数十到数百 GB——你为廉价写入和有界的查询成本做优化，而非 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）**。像 **Fluent Bit / Vector** 这样的 agent 把日志行发往 **Kafka**，由它缓冲突发并把生产者与存储解耦。如果 ClickHouse 因维护而宕机，事件在 Kafka 中排队并重放——你不会丢日志。批量写入（每次 insert 数千行），因为逐行 insert 会摧毁列式存储的 throughput。

## 热存储：为搜索建 index

近期日志需要快速搜索（"服务 X 过去一小时的错误"）。**ClickHouse**（列式，压缩 10 倍，每秒扫描数十亿行）或 **ELK 栈**（Elasticsearch 倒排索引）来承担这个。按天/服务 partition，使查询裁剪到少数几个 partition。这一层按 GB 计算很贵，所以保持小规模——只放最近 7–30 天。

## 冷存储：对象存储 + 分层

较旧的日志以 **Parquet 形式移到 S3**——便宜、持久，可通过 Athena/Trino 按需查询。一个**生命周期策略（lifecycle policy）**在你的保留期限（例如 1 年）执行 S3 → Glacier → 删除的转换。这个*分层（tiering）*是核心的成本杠杆：热存储的价格可能是归档的 50 倍。

## 面试视角

面试官考察 **index 与成本的权衡**：为所有内容建 index 能带来出色的搜索但会撑爆预算；什么都不建 index 便宜但无法查询。好："用 ELK。"出色：你分层——为近期的热切片建 index，把其余的冷归档——并指出 Kafka 是让摄取对下游中断具有韧性的缓冲区。

**常见陷阱：**把所有日志永久放在 Elasticsearch 里。这是最昂贵的选项，而且它的集群会在你未曾规划的 cardinality/保留期上崩溃。

## 权衡与故障模式

- **保留期与成本：**更长的保留期 = 线性的存储增长；积极分层。
- **Kafka 反压：**如果消费者落后，磁盘会被填满——合理设置保留并监控 lag。
- **Cardinality 爆炸：**高基数字段（user_id）会使 ES index 膨胀；对它们采样或丢弃。
- **冷数据的查询成本：**Athena 按 TB 扫描计费——按日期/服务 partition Parquet，使扫描保持有界。
- **At-least-once 重复：**如果精确计数重要，就按 event id 去重。

追加管道

热存储：为搜索建 index

冷存储：对象存储 + 分层

面试视角

权衡与故障模式

相关问题