Kafka: nền tảng cốt lõi cho các hệ thống Big Data

Một hệ thống khởi đầu

Hãy tưởng tượng chúng ta có một hệ thống bán hàng giống Shopee. Giai đoạn đầu, công ty muốn tập trung vào sản phẩm chính - đó chính là nền tảng để đưa các mặt hàng lên, và người dùng có thể chọn. Flow của hệ thống: khách hàng đăng nhập, cho các mặt hàng vào giỏ, sau đó checkout và thanh toán. Ở mức cơ bản này, chúng ta có thể thiết kế một hệ thống chỉ với một backend để xử lý các logic, một frontend để hiển thị, và một database để lưu giữ thông tin về khách hàng, mặt hàng và các transaction...

Một thời gian sau, công ty phát triển hơn, các service cũng nhiều lên một cách nhanh chóng để theo kịp tốc độ phát triển. Nhu cầu kết nối giữa các service vì thế cũng tăng theo cấp số nhân, giữa core backend và permission service, payment gateway, storage... Hơn nữa, vì các thao tác của người dùng là khá quan trọng, chúng ta cần lưu nó vào audit trail system trước khi thực sự đưa vào database. Càng nhiều logic xử lý liên quan tới data, nhất là các thao tác liên quan tới lưu trữ, càng làm tốc độ phản hồi của application tới người dùng chậm đi. Điều này ngày càng trở nên nghiêm trọng và ảnh hưởng lớn hơn khi lượng người dùng truy cập ngày một nhiều.

Bên cạnh nhu cầu về business, công ty tiếp tục mở rộng hơn về mảng phân tích dữ liệu, chúng ta cần biết những mặt hàng nào trong ngày / tuần / tháng vừa qua bán được nhiều nhất, nhu cầu tìm kiếm, hay thậm chí là cả hành vi của người dùng (ví dụ như họ đang tìm kiếm và lướt qua rất nhiều những ốp lưng điện thoại IPhone 18, chúng ta có thể suy luận ra phần nào là họ vừa có điện thoại mới, để có thể gợi ý nhiều mặt hàng có ích hơn với khách hàng). Để giải quyết bài toán này, tất cả các event của người dùng sẽ được điều hướng tiếp qua một endpoint khác (bên cạnh audit trail và business database) - chúng ta có thể gọi nó là "analytical system" - trong đó bao gồm các ETL service và analytical database, tách biệt với transactional database chúng ta đã sử dụng ở trên. Như ta đã biết, điều này càng tạo thêm nhiều logic xử lý và nếu hệ thống vẫn sử dụng cơ chế xử lý dữ liệu đồng bộ (synchronous), các thao tác của khách hàng sẽ phải chờ cho đến khi mọi thứ hoàn toàn được xử lý xong.

Đến đây, nếu kiến trúc hệ thống vẫn giữ nguyên, khả năng mở rộng tiếp theo của hệ thống sẽ gần ngang con số 0.

Bài toán tiếp theo của hệ thống dữ liệu

Chúng ta có thể thấy 2 bài toán lớn cần giải quyết để có thể đi tiếp với hệ thống hiện tại:

• Cơ chế xử lý dữ liệu"bất đồng bộ" (asynchronous): các thao tác business chính của khách hàng không nên phải chờ cho tới khi analytics data được xử lý xong.

• Cơ chế giao tiếp hợp lý hơn giữa các service trên toàn hệ thống: phải có phương án để những event có thể đến đúng nơi cần đến một cách nhanh chóng hơn, và phải có cơ chế để xử lý lại những event đó khi có vấn đề có thể xảy ra ở tầng data processing.

Message Queue có phải là lời giải?

Chúng ta sẽ làm quen với traditional Message Queue (MQ), với đại diện là Redis Queue. Các giải pháp này sẽ giải quyết được một hoặc một vài bài toán cho hạ tầng dữ liệu, nhưng nó cũng đồng thời tạo ra một số vấn đề khác. Ví dụ chuyện gì sẽ xảy ra với Redis Queue khi chính nó bị unavailable, hay khi một event được lấy ra khỏi queue nhưng xử lý ở phía handler bị lỗi?

Tuy nhiên, vấn đề lớn nhất với các hệ thống dữ liệu hiện tại lại là khả năng mở rộng: làm thế nào để có thể xử lý được khối lượng lớn lên tới hàng tỷ event mỗi ngày? Đây chính là điểm yếu của các MQ truyền thống, khi mà chúng chưa được tối ưu cho thời đại Big Data.

Và Kafka ra đời tại LinkedIn, từ những nhu cầu về data platform như hệ thống của chúng ta đã gặp phải, tất nhiên, với một scale lớn hơn rất nhiều.

Vậy thì, Kafka là gì, và nó có thể giúp chúng ta giải quyết những bài toán trên như thế nào?

Kafka - "A distributed event streaming platform"

Kafka không chỉ là một Message Queue, nó được giới thiệu là "event-streaming platform", với nhiều cải tiến so với các MQ truyền thống. Để dễ hình dung, MQ với đại diện là Redis Queue, như là một cửa hàng thuê DVD xem phim thời xưa: bạn tới cửa hàng, thuê băng đem về, nếu DVD bị thuê mất, bạn phải chờ. Kafka - như Netflix streaming platform - bạn lên TV, chọn phim bạn muốn xem, và xem ngay lập tức, không ảnh hưởng bởi việc đã có ai thuê hay chưa. Tất nhiên, so sánh này chỉ mang tính hình tượng và không chính xác hoàn toàn, nhưng nó là một ví dụ dễ hiểu để có thể hình dung Kafka đã thay đổi cuộc chơi về data platform như chính Netflix đã thay đổi thế giới như thế nào.

Trở lại với các bài toán của chúng ta. Với Kafka xuất hiện trên hệ thống dữ liệu, giờ tất cả event sẽ được backend service đưa về một nơi tập trung, không phải broadcast cho tất cả các bên liên quan nữa. Ở đây, core backend service sẽ đóng vai trò là "producer". Ở phía bên kia, tất cả các analytics services, bao gồm cả audit trail system, sẽ đóng vai trò như những Netflix subscribers, và "consume" những event đã được gửi vào Kafka ở một thời điểm hợp lý. Điểm nổi bật, những producer và consumer hoạt động hoàn toàn độc lập và không bị block bởi nhau - có nghĩa là response time cho từng tác vụ sẽ được cải thiện một cách đáng kể.

Chúng ta vừa chuyển từ kiến trúc synchronous sang kiến trúc asynchronous event-driven. Với kiến trúc mới này, lớp user-facing sẽ được tách biệt với lớp data-processing, mang lại lợi thế lớn về response time và khả năng scale tốt với các component khác nhau. Ngoài ra, Kafka tự nó cũng có khả năng scale và đáp ứng high performance, high throughput rất tốt (distributed), điều mà các MQ truyền thống rất khó có thể đạt được.

Tất nhiên, chúng ta không thể bỏ qua những bất lợi khi chuyển sang kiến trúc mới này, ví dụ:

• Độ phức tạp của hệ thống tăng lên

• Kiến trúc này không thể áp dụng cho tất cả mọi thứ, vì thời gian event được xử lý xong có thể sẽ khá lâu sau khi được hệ thống tiếp nhận. Ví dụ các thao tác liên quan tới payment

• Ngoài ra, sẽ có khá nhiều bài toán mới xuất hiện khi thay đổi kiến trúc và sử dụng một platform mới, ví dụ như event loss, duplication, availability, scalability, maintenance...

Kết luận

Mặc dù vẫn tồn tại một số hạn chế đối với Kafka, và cả kiến trúc asynchronous event-driven, nhưng với nhu cầu về hệ thống dữ liệu ngày càng phát triển như hiện nay, Kafka vẫn trở thành một nền tảng cốt lõi cho các hệ thống dữ liệu lớn. Chúng ta gần như không thể thấy một công ty nào đang không sử dụng Kafka ở một mức độ nào đó trong thời điểm hiện nay, vì thế Kafka thực sự là một kĩ năng không thể bỏ qua đối với các bạn làm backend và architecture.

Ở các phần sau, chúng ta sẽ cùng tìm hiểu về kiến trúc, công nghệ nằm bên dưới được Kafka sử dụng, mang lại khả năng scale và hiệu suất đáng kinh ngạc bỏ xa các MQ và Database truyền thống.