Lưu trữ 100 triệu log event mỗi ngày thế nào?

Question

IT Interview Practice · Accepted Answer

Xây một **pipeline append-only: agent → Kafka → tiered storage (hot trong ClickHouse/ELK, cold trong object storage)** kèm chính sách retention index dữ liệu gần đây và lưu trữ phần còn lại giá rẻ. 100M event/ngày là ~1.200/giây trung bình (đỉnh cao hơn nhiều) và hàng chục-đến-hàng trăm GB mỗi ngày — bạn tối ưu cho write rẻ và chi phí query có giới hạn, không phải semantics 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
```

## Pipeline append

Log là write-once, không bao giờ update — nên đường ingest là một **append**. Các agent như **Fluent Bit / Vector** đẩy dòng lên **Kafka**, thứ đệm các burst và tách producer khỏi storage. Nếu ClickHouse down để bảo trì, event xếp hàng trong Kafka và replay — bạn không rớt log. Ghi theo batch (hàng nghìn dòng mỗi insert) vì insert từng dòng phá huỷ throughput trên columnar store.

## Hot store: index để search

Log gần đây cần search nhanh ("lỗi trong giờ qua của service X"). **ClickHouse** (columnar, nén 10x, scan hàng tỷ dòng/giây) hoặc **ELK stack** (inverted index của Elasticsearch) phục vụ việc này. Partition theo ngày/service để query prune về vài partition. Tầng này đắt trên mỗi GB, nên giữ nó nhỏ — chỉ 7–30 ngày gần nhất.

## Cold store: object storage + tiering

Log cũ hơn chuyển sang **S3 dạng Parquet** — rẻ, bền, query được theo yêu cầu qua Athena/Trino. Một **lifecycle policy** chuyển S3 → Glacier → xoá tại giới hạn retention của bạn (vd. 1 năm). *Tiering* này là đòn bẩy chi phí cốt lõi: hot storage có thể đắt gấp 50 lần archival.

## Góc nhìn phỏng vấn

Người phỏng vấn dò **đánh đổi index-vs-cost**: index mọi thứ cho search tuyệt vời nhưng vỡ ngân sách; không index gì thì rẻ nhưng không query được. Khá: "dùng ELK." Xuất sắc: bạn phân tầng — index lát hot gần đây, lưu trữ phần còn lại ở cold — và gọi tên Kafka là buffer làm ingestion chịu được sự cố downstream.

**Bẫy thường gặp:** để mọi log trong Elasticsearch mãi mãi. Đó là lựa chọn đắt nhất và cluster của nó sụp trước cardinality/retention bạn không lên kế hoạch.

## Đánh đổi & kịch bản hỏng

- **Retention vs cost:** retention dài hơn = storage tăng tuyến tính; phân tầng quyết liệt.
- **Kafka backpressure:** nếu consumer trễ, đĩa đầy — định cỡ retention và monitor lag.
- **Bùng nổ cardinality:** field cardinality cao (user_id) làm phình index ES; sample hoặc bỏ chúng.
- **Chi phí query trên cold data:** Athena scan tính tiền theo TB — partition Parquet theo ngày/service để scan có giới hạn.
- **Trùng do at-least-once:** dedup theo event id nếu cần đếm chính xác.

Pipeline append

Hot store: index để search

Cold store: object storage + tiering

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan