Nếu có thể xây dựng lại Kafka từ đầu thì sao?

• KIP-1150 (Kafka không đĩa) và dự án fork Kafka của AutoMQ đang thúc đẩy mạnh mẽ các cuộc thảo luận về Kafka tối ưu cho đám mây
• Nếu xây dựng lại Kafka, đề xuất loại bỏ cấu trúc partition hiện có và chuyển sang cách tiếp cận lấy khóa làm trung tâm
• Đây là lúc cần có các tính năng kiểm soát đồng thời và hỗ trợ schema phía broker
• Đồng thời cũng nhấn mạnh nhu cầu tích hợp các đặc tính hệ thống hiện đại như khả năng mở rộng, snapshot, multi-tenancy
• Từ nền tảng Kafka, bài viết hình dung về một hệ thống event log cloud-native thực thụ vượt qua các giới hạn của Kafka hiện tại

---

Nếu xây dựng lại Kafka?

• Gần đây, KIP-1150 (Kafka không đĩa) và bản fork Kafka của AutoMQ đã được công bố; mục tiêu là tích hợp Kafka với object storage như S3 để cải thiện tính co giãn và giảm chi phí trong môi trường đám mây
• Bài viết đề xuất nhiều hướng cải tiến khác nhau khi hình dung một hệ thống event log cloud-native vượt ra ngoài những giới hạn hiện tại của Kafka

Đề xuất kiến trúc không partition

• Vì object storage trên đám mây hoạt động gần như kho lưu trữ vô hạn, nhu cầu về topic partition giảm đi
• Trong nhiều trường hợp, chỉ thứ tự thông điệp toàn cục hoặc thứ tự giữa các thông điệp có cùng khóa mới thực sự quan trọng
• Có thể ẩn khái niệm partition khỏi người dùng và mang lại trải nghiệm sử dụng đơn giản hơn

Cách tiếp cận lấy khóa làm trung tâm

• Thay vì quét partition, đề xuất thiết kế cho phép truy cập và phát lại nhanh toàn bộ thông điệp của một khóa cụ thể
• Có thể hỗ trợ các luồng ở cấp độ hàng triệu thực thể, từ đó điều chỉnh linh hoạt số lượng consumer theo nhu cầu
• Lỗi được cô lập theo từng khóa nên hiệu quả xử lý của toàn hệ thống tăng lên
• Đây là cấu trúc lý tưởng cho event sourcing hoặc hệ thống actor model

Hỗ trợ phân cấp topic

• Tương tự các hệ thống như Solace, cần nâng một phần payload thông điệp thành định danh topic dạng đường dẫn có cấu trúc để cho phép đăng ký theo mẫu
• Broker có thể hỗ trợ lọc subscription hiệu quả mà không cần phân tích toàn bộ thông điệp

Tính năng kiểm soát đồng thời

• Kafka hiện tại không có cách để ngăn xung đột đồng thời khi ghi
• Nếu hỗ trợ optimistic locking theo từng khóa, có thể xác minh rằng thông điệp được ghi sau khi đã nhìn thấy trạng thái mới nhất
• Điều này giúp ngăn vấn đề mất cập nhật

Hỗ trợ schema phía broker

• Kafka hiện coi thông điệp chỉ là mảng byte đơn thuần nên phụ thuộc vào schema registry bên ngoài
• Bài viết đề xuất cần có hỗ trợ mặc định ở cấp broker cho thông tin schema như metadata AsyncAPI nhằm đảm bảo tính nhất quán của schema
• Nhờ đó cũng có thể tích hợp dễ dàng với các open table format như Apache Iceberg

Khả năng mở rộng và kiến trúc plugin

• Đề xuất một kiến trúc có khả năng mở rộng và khả năng cắm plugin tương tự Postgres hay Kubernetes
• Cần cho phép triển khai dễ dàng các bộ lọc hoặc phép biến đổi ở tầng broker mà không cần proxy hiểu giao thức như Kroxylicious
• Các tính năng như giới hạn tốc độ, mã hóa topic, hay backend dựa trên bảng Iceberg cần có thể được triển khai dưới dạng plugin

Callback commit đồng bộ

• Kafka hiện tại chỉ đảm bảo tính nhất quán cuối cùng
• Bài viết đề xuất cần một cấu trúc cho phép producer, ngay sau khi gửi thông điệp, có thể xác nhận ngay liệu dữ liệu phát sinh liên quan đã được cập nhật hay chưa
• Việc hỗ trợ read-your-own-writes sẽ cho phép sử dụng Kafka như một log cơ sở dữ liệu thực thụ

Tính năng snapshot

• Cơ chế compaction hiện tại của Kafka chỉ giữ lại thông điệp cuối cùng, điều này chỉ hiệu quả khi thông điệp đó chứa toàn bộ trạng thái
• Nếu chỉ ghi lại thay đổi, phải phát lại toàn bộ sự kiện theo từng khóa nên thời gian xử lý tăng lên
• Vì vậy cần có tính năng nén logic để tóm tắt các sự kiện theo từng khóa thành snapshot

Hỗ trợ multi-tenancy mặc định

• Mọi hệ thống dữ liệu hiện đại đều nên xem multi-tenancy là năng lực mặc định
• Cần cho phép tạo môi trường tenant mới với chi phí thấp và gần như tức thì, đồng thời tách biệt chặt chẽ tài nguyên, bảo mật và kiểm soát truy cập

Các ghi chú khác

• Một số tính năng đã xuất hiện trong các hệ thống như S2 (luồng high-cardinality), Waltz (optimistic locking), và Apache Pulsar (multi-tenancy)
• Tuy nhiên, hiện chưa có hệ thống mã nguồn mở nào hỗ trợ đồng thời toàn bộ các tính năng được đề xuất
• Bài viết phản ánh quan điểm cá nhân của tác giả thuộc Confluent, không phải lập trường chính thức
• Về mặt lý thuyết, tác giả cho rằng kiến trúc dựa trên cây LSM sẽ là lựa chọn đầy hứa hẹn

[kaydash]

Chúng ta đã gọi nó là Redis rồi mà

[GN⁺]

Ý kiến trên Hacker News

• Đồng ý. Với một số trường hợp sử dụng cụ thể, việc giải quyết vấn đề head-of-line là đáng làm

  • Tuy nhiên, mọi hệ thống streaming hiện nay (hoặc các cách lách) đều phát sinh chi phí O(n^2) cho việc xác nhận theo từng message key
  • Các hệ thống như Pulsar thường được dùng cho tính năng này
  • Sự phức tạp này có thể không xuất hiện hằng ngày, nhưng khi xảy ra thì phải chờ
  • Sau thời gian dài nghiên cứu vấn đề này cùng đồng nghiệp, chúng tôi đi đến kết luận rằng cần có thay đổi kiến trúc mang tính nền tảng để hỗ trợ xác nhận theo từng message key một cách có thể mở rộng
  • Kiến trúc đó cần một chỉ mục được sắp xếp, nghĩa là xử lý n message với độ phức tạp O(n log n)
  • Tôi muốn viết blog về chủ đề này nhưng chưa có thời gian
  • Nếu định phụ thuộc vào xác nhận theo từng message key, hãy dự liệu các đợt gián đoạn hoặc độ trễ không thường xuyên

• NATS.io dễ dùng hơn Kafka và đã giải quyết sẵn nhiều điểm như bỏ partition, hỗ trợ stream dựa trên key, và cấu trúc phân cấp topic linh hoạt

• Hành trình của tôi với Kafka phần lớn cũng tương tự

  • Ban đầu tôi nghĩ: "Ồ, một append-only log có thể mở rộng, thật tuyệt và đơn giản"
  • Nhưng khi dùng rồi mới nhận ra nó cực kỳ phức tạp

• Trong một số trường hợp sử dụng cụ thể, sẽ rất hữu ích nếu có thể đảm bảo rằng khi yêu cầu tạo được xác nhận thì view dữ liệu dẫn xuất cũng đã được cập nhật

  • Đừng dùng Kafka, hãy ghi trực tiếp vào kho dữ liệu phía dưới
  • Khi đó bạn sẽ biết dữ liệu đã được commit, và bạn sẽ có một cơ sở dữ liệu có thể truy vấn

• Tôi đã đặt câu hỏi này từ 6 năm trước

  • Nếu viết bằng Rust và tận dụng WASM thì sao
  • Tôi đã làm việc này suốt 6 năm qua
  • Trong 2 năm gần đây, tôi đã xây dựng Flink bằng Rust và WASM

• Kafka trên object storage ư? Điều đó sẽ làm tăng độ trễ và chi phí lên gấp 10 lần

  • Kafka là nạn nhân của chính thành công của nó
  • Thiết kế của nó đơn giản và thanh lịch, nên nó đang bị dùng cho đủ loại mục đích mà ban đầu không được thiết kế cho
  • Dĩ nhiên nó không hoàn hảo cho những trường hợp sử dụng đó

• Về chuyện "bỏ partition" và "stream cấp độ key"

  • Khi backend lưu trữ vẫn phụ thuộc vào phân vùng vật lý, thì điều đó về cơ bản chỉ là đổi tên partition thành key, và key thành event

• Nên chú ý đến Northguard

  • Đây là tên dự án viết lại Kafka của LinkedIn, đã được giới thiệu tại một buổi meetup về stream processing khoảng một tuần trước

• Tôi tự hỏi có bao nhiêu vấn đề của Apache Kafka có thể được giải quyết chỉ bằng cách chuyển sang Apache Pulsar

  • Tôi bỏ qua giai đoạn học Kafka và dùng luôn Pulsar
  • Nó rất hợp với trường hợp sử dụng của chúng tôi
  • Không có gì để phàn nàn
  • Nhưng tôi vẫn thắc mắc vì sao lại có quá ít người dùng nó

• Đây là một phép thử tư duy hữu ích

  • Các câu trả lời ngụ ý kết luận rằng Kafka nên được thay thế bằng thứ gì đó mới lại khá im ắng
  • Điểm mạnh lớn nhất của Kafka là hệ sinh thái rộng lớn và hữu ích được xây dựng trên nó
  • Nhưng đó cũng là điểm yếu
  • Nó buộc phải giữ lại một số quyết định thiết kế mà nếu bắt đầu lại từ đầu hôm nay thì có lẽ sẽ không làm như vậy
  • Hoặc phải từ bỏ khả năng tương thích ngược và tái tạo lại hệ sinh thái mà nó đã có