Xây dựng pipeline dữ liệu thời gian thực với Apache Kafka

Pipeline thời gian thực dễ trình bày lợi ích nhưng khó vận hành. Thách thức kỹ thuật không phải là đưa message vào Kafka. Thách thức là xây một hệ thống vẫn dễ quan sát, có thể replay và hợp lý về chi phí khi lưu lượng tăng lên.

Bắt đầu từ quyết định hạ nguồn

Trước khi tạo topic hoặc viết consumer, hãy xác định quyết định nào cần dữ liệu mới.

Ví dụ:

• chấm điểm rủi ro cần tín hiệu gian lận theo từng phút
• giám sát tồn kho cần cảnh báo bất thường nhanh
• quy trình hỗ trợ cần ngữ cảnh agent từ hệ thống đang hoạt động

Nếu không có quyết định nào tốt hơn đáng kể nhờ dữ liệu nhanh hơn, pipeline batch thường là câu trả lời tốt hơn. Đây là câu hỏi quyết định phần còn lại của bài viết có áp dụng cho bạn hay không, và rất đáng để trả lời thành thật. Một dashboard mà con người chỉ xem hai lần mỗi ngày không trở nên hữu ích hơn vì các con số phía sau mới bốn giây thay vì bốn giờ.

Thiết kế hợp đồng trước khi viết code

Một trong các lỗi streaming lớn nhất là phát hành sự kiện trước rồi mới quản trị sau. Trên thực tế, hợp đồng sự kiện cần được thiết kế trước khi quy mô tăng.

Điều đó có nghĩa là thống nhất về:

• cách đặt tên sự kiện
• quyền sở hữu payload
• quy tắc versioning
• cách xử lý dead-letter
• kỳ vọng về replay

Mục tiêu không phải là quan liêu. Mục tiêu là bảo đảm các đội hạ nguồn có thể tin ý nghĩa của luồng dữ liệu.

Biến schema thành việc của build

Schema registry biến câu "chúng ta đã thống nhất payload" thành thứ mà build có thể kiểm soát. Phần đáng hiểu là chế độ tương thích, vì nó quyết định bên nào phải triển khai trước:

• BACKWARD (mặc định phổ biến): schema mới đọc được dữ liệu ghi bằng schema cũ. Consumer nâng cấp trước. An toàn khi thêm trường tùy chọn hoặc bỏ trường.
• FORWARD: schema cũ đọc được dữ liệu ghi bằng schema mới. Producer nâng cấp trước.
• FULL: đúng cả hai chiều. Chặt nhất, và là lựa chọn phù hợp cho topic có nhiều consumer độc lập mà bạn không kiểm soát.

Chọn chế độ không phải thủ tục hình thức. Đó là khác biệt giữa một lần đổi tên trường diễn ra êm đẹp và một lần làm sập consumer lúc 2 giờ sáng vì không ai biết bên nào phải triển khai trước.

Thiết kế partition là quyết định khó sửa nhất

Partition là nơi tích tụ nhiều tiếc nuối nhất khi dùng Kafka, vì hai đặc tính mà nó kiểm soát kéo về hai hướng ngược nhau.

Số partition đặt trần cho khả năng xử lý song song. Trong một consumer group, mỗi partition chỉ được đúng một consumer đọc. Mười partition nghĩa là nhiều nhất mười consumer hữu ích; consumer thứ mười một sẽ ngồi không. Hãy tính từ throughput đo được thay vì chọn một con số tròn: lấy số sự kiện mỗi giây ở đỉnh mà bạn cần hấp thụ, chia cho mức một consumer xử lý được với workload thật, rồi cộng dự phòng cho tăng trưởng và cho giai đoạn phục hồi sau sự cố, khi bạn cần đuổi kịp nhanh hơn thời gian thực.

Chia quá nhiều partition cũng không miễn phí. Nhiều partition hơn đồng nghĩa nhiều file handle hơn, nhiều metadata hơn và rebalance lâu hơn, đúng thứ bạn không muốn gặp giữa lúc sự cố.

Khóa partition đặt ra bảo đảm về thứ tự. Kafka bảo đảm thứ tự trong một partition, không phải trên toàn topic. Khóa theo account_id nghĩa là mọi sự kiện của một tài khoản đến đúng thứ tự, và đó thường mới là bảo đảm thực sự quan trọng. Khóa theo thứ gì đó có độ phân tán cao nhưng vô nghĩa, hoặc để khóa rỗng cho round-robin, sẽ cho bạn throughput mà không có thứ tự.

Hãy cảnh giác với khóa nóng. Nếu một khách hàng tạo ba mươi phần trăm lưu lượng và bạn khóa theo khách hàng, một partition gánh ba mươi phần trăm tải và một consumer trở thành nút thắt. Khóa ghép như tenant_id:entity_id phân tán tải mà vẫn giữ thứ tự quan trọng, miễn là thứ tự theo từng thực thể thực sự là đủ.

Chọn ngữ nghĩa phân phối một cách có chủ đích

"Exactly-once" là cụm từ bị hiểu sai nhiều nhất trong streaming. Nên tách thành hai câu hỏi.

Bên trong Kafka, exactly-once là có thật. Producer idempotent khử trùng lặp khi retry, và transaction làm cho chu trình đọc - xử lý - ghi trở nên nguyên tử:

# producer
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=5
retries=2147483647
delivery.timeout.ms=120000
compression.type=zstd
linger.ms=20
batch.size=131072

# consumer
enable.auto.commit=false
isolation.level=read_committed
auto.offset.reset=earliest
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

Hai dòng trong đó quan trọng hơn vẻ ngoài của chúng. enable.auto.commit=false nghĩa là bạn commit offset sau khi công việc thành công, không phải theo bộ đếm thời gian có thể xác nhận những message bạn chưa từng xử lý. CooperativeStickyAssignor khiến rebalance diễn ra tăng dần thay vì dừng toàn bộ, nên thêm một consumer không còn làm cả group tạm dừng.

Bên ngoài Kafka, ngay khi dữ liệu vào kho dữ liệu, search index hay một lời gọi API, transaction không còn bảo vệ bạn. Mô hình khả thi là phân phối at-least-once vào một sink idempotent: mang theo event_id ổn định và ghi bằng merge thay vì insert. Khi đó replay tạo ra đúng các dòng cũ thay vì nhân bản, và bạn không bao giờ phải suy luận xem một lô đã được áp dụng một hay hai lần.

Lập kế hoạch replay từ ngày đầu

Backfill và khởi động lại consumer không phải trường hợp biên hiếm gặp. Chúng là sự kiện vận hành bình thường, và thời điểm để thiết kế cho chúng là trước lần đầu tiên.

Thời gian lưu trữ là đòn bẩy thứ nhất. Một topic bạn có thể cần replay không thể chỉ lưu bảy ngày nếu cửa sổ phục hồi xấu nhất của bạn là hai tuần:

cleanup.policy=delete
retention.ms=1209600000   # 14 ngày

Với topic biểu diễn trạng thái hiện tại thay vì lịch sử sự kiện, compaction thường phù hợp hơn. Nó giữ giá trị mới nhất theo từng khóa và loại bỏ các giá trị đã bị thay thế, nên một consumer mới có thể dựng lại trạng thái từ topic mà bạn không phải lưu mọi thay đổi trung gian:

cleanup.policy=compact
min.compaction.lag.ms=3600000

Đòn bẩy thứ hai là sink. Replay chỉ an toàn khi xử lý lại cùng các sự kiện hội tụ về cùng kết quả, và điều đó quay lại chuyện ghi idempotent. Một câu merge khóa theo định danh sự kiện khiến replay trở nên nhàm chán theo nghĩa tốt:

MERGE INTO analytics.orders AS target
USING staging.order_events AS source
  ON target.event_id = source.event_id
WHEN NOT MATCHED THEN INSERT *
WHEN MATCHED AND source.ingested_at > target.ingested_at THEN UPDATE SET *;

Xem khả năng quan sát là tính năng sản phẩm

Nếu consumer chậm lại hoặc âm thầm bỏ các sự kiện sai định dạng, tác động kinh doanh có thể lớn hơn cả một lần ngừng hoạt động hoàn toàn, vì không ai bị gọi dậy vì dữ liệu sai một cách lặng lẽ.

Hãy đo tối thiểu những chỉ số sau:

• Consumer lag, khoảng cách giữa log end offset và offset đã commit, theo từng partition thay vì lấy trung bình. Giá trị trung bình che mất đúng cái partition đang kẹt.
• Tuổi của message, chênh lệch giữa thời điểm sự kiện xảy ra và thời điểm xử lý. Đây mới là chỉ số nên đặt cảnh báo, vì nó là con số mà người phụ trách nghiệp vụ hiểu được. "Tín hiệu gian lận đang trễ chín phút" có ý nghĩa; "lag là 40.000" thì không.
• Tỷ lệ dead-letter, tính theo tỷ lệ trên throughput thay vì số tuyệt đối.
• Tần suất rebalance. Rebalance liên tục thường nghĩa là max.poll.interval.ms quá chặt so với thời gian xử lý thực tế.

Cho message hỏng một nơi để đi

Một message không parse được không nên làm kẹt cả partition. Hãy chuyển các lỗi sang một topic dead-letter kèm đủ ngữ cảnh để chẩn đoán về sau, và giữ offset gốc trong header để bạn tìm lại được sự kiện nguồn:

orders.v1        -> topic chính
orders.v1.dlq    -> lỗi, kèm header:
                    x-error-class, x-error-message,
                    x-source-partition, x-source-offset, x-failed-at

DLQ chỉ hữu ích nếu có người nhìn vào nó. Một cảnh báo theo tỷ lệ của nó là thứ biến DLQ từ nghĩa địa thành vòng phản hồi.

Giữ enrichment gần với giá trị kinh doanh

Không phải mọi chuyển đổi đều thuộc về Kafka. Đặt việc chuẩn hóa sự kiện nhẹ gần luồng dữ liệu, nơi nó giữ cho hợp đồng sạch sẽ: đổi tên trường, ép kiểu, loại bỏ bản ghi sai định dạng rõ ràng. Chuyển mô hình hóa nặng sang hệ thống dễ kiểm thử, dễ đánh version và dễ backfill hơn, thường là kho dữ liệu.

Phép thử thực tế là logic đó có cần lịch sử hay không. Bất cứ thứ gì phải join với dữ liệu nhiều tháng, hoặc mà analyst sẽ muốn sửa lại sau này, đều là công việc mô hình hóa và thuộc về nơi việc dựng lại rẻ.

Bảo vệ chi phí kho dữ liệu

Streaming vào kho dữ liệu trở nên đắt rất nhanh nếu mỗi message kích hoạt một lần ghi. Ba mô hình sau mang lại phần lớn khoản tiết kiệm:

1. Micro-batch thay vì ghi theo từng message. Gom đệm theo ngưỡng kích thước hoặc thời gian, cái nào đến trước, rồi ghi một lần. Đây thường là khác biệt giữa hóa đơn kho dữ liệu tăng theo số sự kiện và hóa đơn tăng theo khối lượng.
2. Tôn trọng bố cục bảng. Hãy partition và cluster bảng sink theo đúng các cột mà truy vấn thực sự lọc, thường là ngày sự kiện cộng với khóa khách hàng hoặc thực thể.
3. Gộp file nhỏ. Ghi streaming tần suất cao tạo ra rất nhiều file nhỏ, và các engine truy vấn sẽ trả giá cho điều đó ở mọi lần quét về sau.

Thiết kế đường xử lý lỗi mà con người dễ hiểu

Khi có sự cố, người vận hành cần câu trả lời nhanh cho hai câu hỏi:

1. điều gì đã lỗi
2. hành động nào khôi phục hệ thống an toàn

Câu trả lời này phải có trước sự cố, không phải sau đó. Trên thực tế, điều đó nghĩa là mỗi topic cần một runbook ngắn nêu rõ DLQ nằm ở đâu, quy trình replay an toàn ra sao, và những bảng hạ nguồn nào cần dựng lại nếu bạn thực sự replay. Đội viết sẵn tài liệu này trước sự cố đầu tiên sẽ phục hồi trong vài phút thay vì vài giờ.

AI agent phù hợp ở đâu

Pipeline Kafka có giá trị hơn khi kết hợp với tóm tắt có hỗ trợ AI hoặc quy trình phát hiện bất thường. Một mô hình hữu ích là:

• đưa sự kiện vào lưu trữ vận hành
• tổng hợp thành bảng giám sát
• chỉ kích hoạt agent hoặc trợ lý khi ngưỡng thực sự đáng chú ý

Cách này giữ hoạt động của agent tập trung vào sự kiện tín hiệu cao thay vì lưu lượng thô đầy nhiễu, và giữ chi phí ở mức dự đoán được. Chĩa một mô hình vào luồng thô vừa tốn kém vừa cho kết quả tệ hơn: tín hiệu mà người duyệt cần gần như luôn nằm ở mức tổng hợp, không phải ở từng sự kiện riêng lẻ.

Danh sách kiểm tra trước khi chạy thật

Trước khi một pipeline streaming gánh bất cứ thứ gì mà doanh nghiệp phụ thuộc vào:

• quyết định hạ nguồn đã được viết ra, và nó tốt lên nhờ dữ liệu mới hơn
• schema đã đăng ký với chế độ tương thích mà cả đội đã thống nhất
• khóa và số partition đến từ throughput đo được và một bảo đảm thứ tự đã nêu rõ
• sink là idempotent, để replay hội tụ thay vì nhân bản
• thời gian lưu trữ phủ được cửa sổ phục hồi xấu nhất, không phải trường hợp thông thường
• cảnh báo lag đặt theo tuổi message, theo từng partition
• đã có topic dead-letter và có người chịu trách nhiệm về tỷ lệ của nó
• runbook replay đã tồn tại và đã được thử một lần, có chủ đích, trước khi cần đến

Kết luận

Kafka là nền tảng tốt cho hệ thống thời gian thực, nhưng chỉ khi pipeline được thiết kế xoay quanh niềm tin, khả năng khôi phục và quyết định kinh doanh hạ nguồn.

Một luồng dữ liệu "chạy được" là chưa đủ. Nền tảng streaming hữu ích là nền tảng mà người vận hành có thể hiểu và xử lý khi chịu áp lực, nơi replay là quy trình thường ngày thay vì một hành động liều lĩnh, và nơi chi phí của độ tươi dữ liệu là thứ cả đội đã chủ động chọn.