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ì

## Điều cần hiểu trước khi nhìn vào công cụ

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. Một pipeline chỉ có ý nghĩa khi dữ liệu cuối đủ mới, đủ đúng và giải thích được nguồn gốc.

Một dashboard rất đẹp vẫn có thể kể sai câu chuyện nếu dữ liệu đến trễ, bị nhân đôi sau phép join hoặc thay đổi định nghĩa mà không ai ghi lại. Vì vậy, phần khó của nghề dữ liệu không chỉ là xử lý thật nhiều dòng, mà là làm cho con số có nguồn gốc và có thể kiểm tra.

Kafka thường xuất hiện trong những sơ đồ kiến trúc rất hoành tráng. Nhưng giá trị thật của nó khá giản dị: giúp nhiều hệ thống trao đổi sự kiện mà không phải chờ nhau từng bước.

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

## Hãy bắt đầu từ dòng chảy sự kiện, không phải số lượng broker

Producer ghi sự kiện vào topic; consumer đọc và xử lý theo nhu cầu riêng. Kafka giữ lại log sự kiện để nhiều nhóm tiêu thụ độc lập, thay vì buộc mọi dịch vụ gọi trực tiếp lẫn nhau.

## Chuyện gì xảy ra khi đem vào dự án thật?

Khi đơn hàng được tạo, thanh toán, kho, thông báo và phân tích đều có thể quan tâm. Nếu mọi phần nối trực tiếp với nhau, một thay đổi nhỏ dễ làm cả mạng lưới trở nên mong manh.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Bạn nên mô tả rõ sự kiện có ý nghĩa gì, ai sở hữu schema và cách xử lý trùng lặp. Kafka không xóa bỏ độ phức tạp; nó chuyển độ phức tạp sang thiết kế sự kiện và vận hành.

- 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?

## 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.

## Góc nhìn dành cho developer Việt Nam

Trong các đội data tại Việt Nam, người hiểu cả kỹ thuật lẫn ý nghĩa nghiệp vụ thường tạo ra khác biệt lớn. Đừng chỉ hỏi pipeline có chạy không; hãy hỏi dữ liệu có đủ, có mới, có đúng đơn vị và có phục vụ được quyết định đang cần hay không.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Building Event-Driven Microservices, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/building-event-driven-microservices-adam-bellemare-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.