Wavi Books · Data Engineering & Phân tích dữ liệu

Apache Kafka là gì? Kiến trúc streaming cho Data Engineer

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Apache Kafka là gì, topic, partition, producer, consumer, consumer group và cách ứng dụng event streaming trong hệ thống dữ liệu hiện đại.

## Apache Kafka là gì

Apache Kafka là nền tảng event streaming phân tán, cho phép producer ghi sự kiện vào topic và consumer đọc theo tốc độ riêng. Dữ liệu được chia thành partition để mở rộng thông lượng và giữ thứ tự trong từng partition.

Kafka phù hợp khi nhiều hệ thống cần trao đổi dòng sự kiện bền vững, có khả năng phát lại. Nó không phải lựa chọn mặc định cho mọi queue hoặc mọi ứng dụng nhỏ.

## Những khái niệm cốt lõi cần nắm

- Topic phân loại dòng sự kiện.

- Partition tạo khả năng song song.

- Offset đánh dấu vị trí đọc.

- Consumer group phân phối công việc giữa các consumer.

## Lộ trình thực hành từng bước

- Bước 1: Xác định event schema và khóa partition.

- Bước 2: Thiết kế retry, dead-letter và idempotency.

- Bước 3: Theo dõi lag, throughput, dung lượng và lỗi deserialize.

## Những sai lầm thường gặp

- Dùng quá nhiều partition ngay từ đầu.

- Thay đổi schema phá vỡ consumer.

- Kỳ vọng exactly-once mà không xét toàn bộ pipeline.

## Góc nhìn dành cho người học và developer Việt Nam

Đội dữ liệu tại Việt Nam nên thử với một use case có giá trị rõ như đồng bộ đơn hàng hoặc clickstream, đồng thời tính chi phí vận hành cluster và năng lực trực ca.

## Nên học tiếp như thế nào?

Sau khi nắm phần cốt lõi, bạn nên tự xây một dự án nhỏ, ghi lại giả định, tiêu chí đánh giá và giới hạn của giải pháp. Các sách liên quan được Wavi Books gợi ý trong bài giúp bạn đào sâu kiến thức theo lộ trình có hệ thống thay vì chỉ ghép các hướng dẫn rời rạc.

## Mô hình log phân tán của Kafka

Kafka lưu event theo log append-only. Topic được chia partition; mỗi partition có thứ tự riêng và event được xác định bằng offset. Broker giữ partition, replication bảo vệ dữ liệu, controller quản lý metadata và leader. Cách nhìn này quan trọng hơn việc coi Kafka là một message queue nhanh.

Producer chọn partition, thường dựa trên key. Các event cùng key vào cùng partition và giữ thứ tự. Nếu dùng key ngẫu nhiên hoặc null, tải phân phối đều hơn nhưng mất đảm bảo thứ tự theo thực thể. Key là quyết định mô hình dữ liệu, không chỉ cấu hình hiệu năng.

## Delivery semantics

At-most-once có thể mất nhưng không lặp; at-least-once không mất nếu retry đúng nhưng có thể lặp; exactly-once của Kafka dựa trên idempotent producer và transaction trong phạm vi hỗ trợ. Khi event đi tới database hoặc API ngoài, toàn bộ end-to-end vẫn cần idempotency.

Consumer nên xử lý event rồi mới commit offset. Nếu commit trước và process lỗi, event bị mất; commit sau có thể xử lý lặp khi crash. Giải pháp thực dụng là thiết kế consumer idempotent bằng event ID, unique constraint hoặc bảng inbox.

```text Order Service -> orders.v1 (key=order_id) -> Payment Consumer |--> Inventory Consumer |--> Analytics Consumer ```

Các consumer group độc lập đọc cùng topic cho mục đích khác nhau. Trong một group, mỗi partition chỉ thuộc một consumer tại một thời điểm; vì vậy số consumer hữu ích không vượt số partition.

## Rebalance và consumer lag

Khi consumer tham gia/rời group hoặc partition thay đổi, Kafka rebalance assignment. Rebalance dài tạm dừng xử lý và có thể tăng lag. Static membership, cooperative rebalancing và tối ưu thời gian xử lý batch giúp giảm ảnh hưởng.

Lag là khoảng cách giữa offset mới nhất và offset consumer đã xử lý. Lag tăng có thể do tải cao, consumer chậm, downstream lỗi hoặc partition skew. Không chỉ cảnh báo tổng lag; cần xem theo partition và tốc độ tăng.

## Schema evolution

Event là hợp đồng lâu dài. Thêm trường optional thường tương thích; đổi kiểu, xóa trường hoặc thay semantics có thể phá consumer. Schema registry cùng Avro/Protobuf/JSON Schema giúp kiểm tra compatibility, nhưng governance và ownership vẫn cần con người.

Event nên mô tả sự kiện nghiệp vụ đã xảy ra, ví dụ OrderPaid, kèm event_id, occurred_at, producer, schema_version và correlation_id. Tránh đưa toàn bộ database row không có semantics lên topic.

## Partition và capacity planning

Nhiều partition tăng song song nhưng tốn file handle, memory, replication và thời gian recovery. Ước lượng throughput, kích thước event, retention, replication factor và headroom. Partition count khó giảm nên không chọn tùy tiện mức rất lớn.

## Vận hành production

Theo dõi under-replicated partitions, offline partitions, ISR changes, request latency, disk, network, producer error, consumer lag và rebalance. Test broker failure, rolling upgrade và network partition. Retention phải phù hợp khả năng replay và dung lượng.

## Bài tập thực hành

Xây luồng order-created với hai consumer: inventory và analytics. Cố tình làm consumer crash sau khi ghi database nhưng trước commit offset; quan sát duplicate và thêm idempotency. Sau đó tạo một key nóng để thấy partition skew. Bài tập này giúp hiểu semantics sâu hơn demo gửi/nhận message.