Mô hình hóa dữ liệu với Kafka? Chủ đề và phân vùng

Một trong những điều đầu tiên tôi nghĩ đến khi sử dụng dịch vụ mới (chẳng hạn như kho dữ liệu không phải RDBMS hoặc hàng đợi tin nhắn) là: "Tôi nên cấu trúc dữ liệu của mình như thế nào?".

Tôi đã đọc và xem một số tài liệu giới thiệu. Cụ thể, lấy ví dụ, Kafka: Hệ thống nhắn tin phân tán để xử lý nhật ký , viết:

• "Chủ đề là nơi chứa các thông điệp được liên kết"
• "đơn vị song song nhỏ nhất là phân vùng của một chủ đề. Điều này ngụ ý rằng tất cả các thông điệp ... thuộc về một phân vùng cụ thể của một chủ đề sẽ được người tiêu dùng trong một nhóm người tiêu dùng sử dụng."

Biết điều này, điều gì sẽ là một ví dụ tốt minh họa cách sử dụng các chủ đề và phân vùng? Khi nào nên một cái gì đó là một chủ đề? Khi nào nên một cái gì đó là một phân vùng?

Ví dụ: giả sử dữ liệu (Clojure) của tôi trông như sau:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

Chủ đề nên được dựa trên user-id? viewed? at? Còn phân vùng thì sao?

Làm thế nào để tôi quyết định?

Khi cấu trúc dữ liệu của bạn cho Kafka, nó thực sự phụ thuộc vào cách thức mà nó có nghĩa là được tiêu thụ.

Trong tâm trí tôi, một chủ đề là một nhóm các tin nhắn thuộc loại tương tự sẽ được sử dụng bởi cùng một loại người tiêu dùng, vì vậy trong ví dụ trên, tôi sẽ chỉ có một chủ đề và nếu bạn quyết định đẩy một số loại khác dữ liệu thông qua Kafka, bạn có thể thêm một chủ đề mới cho điều đó sau.

Các chủ đề được đăng ký trong ZooKeeper, điều đó có nghĩa là bạn có thể gặp sự cố nếu cố gắng thêm quá nhiều trong số chúng, ví dụ như trường hợp bạn có một triệu người dùng và đã quyết định tạo chủ đề cho mỗi người dùng.

Mặt khác, phân vùng là một cách để song song việc tiêu thụ các thông điệp và tổng số phân vùng trong cụm môi giới ít nhất phải bằng số lượng người tiêu dùng trong nhóm người tiêu dùng để hiểu được tính năng phân vùng. Người tiêu dùng trong một nhóm người tiêu dùng sẽ phân chia gánh nặng xử lý chủ đề giữa họ theo phân vùng để một người tiêu dùng sẽ chỉ quan tâm đến các thông điệp trong chính phân vùng đó được "gán cho".

Phân vùng có thể được đặt rõ ràng bằng cách sử dụng khóa phân vùng ở phía nhà sản xuất hoặc nếu không được cung cấp, một phân vùng ngẫu nhiên sẽ được chọn cho mỗi thông báo.

Khi bạn biết cách phân vùng luồng sự kiện của mình, tên chủ đề sẽ dễ dàng, vì vậy hãy trả lời câu hỏi đó trước.

@Ludd là chính xác - cấu trúc phân vùng bạn chọn sẽ phụ thuộc phần lớn vào cách bạn muốn xử lý luồng sự kiện. Lý tưởng nhất là bạn muốn có một khóa phân vùng có nghĩa là xử lý sự kiện của bạn là phân vùng cục bộ .

Ví dụ:

1. Nếu bạn quan tâm đến thời gian trung bình tại chỗ của người dùng, thì bạn nên phân vùng theo :user-id. Bằng cách đó, tất cả các sự kiện liên quan đến một hoạt động trang web của một người dùng sẽ có sẵn trong cùng một phân vùng. Điều này có nghĩa là một công cụ xử lý luồng như Apache Samza có thể tính thời gian trung bình tại chỗ cho một người dùng nhất định chỉ bằng cách xem xét các sự kiện trong một phân vùng. Điều này tránh phải thực hiện bất kỳ loại phân vùng toàn cầu tốn kém xử lý
2. Nếu bạn quan tâm đến các trang phổ biến nhất trên trang web của mình, bạn nên phân vùng theo :viewedtrang. Một lần nữa, Samza sẽ có thể giữ số lượt xem của một trang nhất định chỉ bằng cách xem các sự kiện trong một phân vùng duy nhất

Nói chung, chúng tôi đang cố gắng tránh phải dựa vào trạng thái toàn cầu (chẳng hạn như giữ số lượng trong cơ sở dữ liệu từ xa như DynamoDB hoặc Cassandra), và thay vào đó có thể làm việc bằng cách sử dụng trạng thái phân vùng cục bộ. Điều này là do trạng thái cục bộ là nguyên thủy cơ bản trong xử lý luồng .

Nếu bạn cần cả hai trường hợp sử dụng ở trên, thì một mẫu chung với Kafka là phân vùng đầu tiên bằng cách nói :user-idvà sau đó phân vùng lại bằng cách:viewed sẵn sàng cho giai đoạn xử lý tiếp theo.

Về tên chủ đề - một điều hiển nhiên ở đây sẽ là eventshoặc user-events. Để cụ thể hơn, bạn có thể đi với events-by-user-idvà / hoặc events-by-viewed.

Điều này không liên quan chính xác đến câu hỏi, nhưng trong trường hợp bạn đã quyết định phân tách logic các bản ghi dựa trên các chủ đề và muốn tối ưu hóa số lượng chủ đề / phân vùng trong Kafka, thì điều này blog có thể có ích.

Những điểm chính trong một bản tóm tắt:

• Nói chung, càng có nhiều phân vùng trong cụm Kafka, thông lượng có thể đạt được càng cao. Đặt mức tối đa có thể đạt được trên một phân vùng duy nhất cho sản xuất là p và mức tiêu thụ là c . Giả sử thông lượng mục tiêu của bạn là t . Sau đó, bạn cần phải có ít nhất các phân vùng tối đa ( t / p , t / c ).

• Hiện tại, trong Kafka, mỗi nhà môi giới mở một tệp xử lý cả chỉ mục và tệp dữ liệu của mỗi phân đoạn nhật ký. Vì vậy, càng nhiều phân vùng, càng cao, người ta cần phải cấu hình giới hạn xử lý tệp mở trong hệ điều hành cơ bản. Ví dụ, trong hệ thống sản xuất của chúng tôi, chúng tôi đã từng thấy một lỗi nói too many files are open, trong khi chúng tôi có khoảng 3600 phân vùng chủ đề.

• Khi một nhà môi giới bị tắt ô uế (ví dụ: giết -9), sự không có sẵn được quan sát có thể tỷ lệ thuận với số lượng phân vùng.

• Độ trễ từ đầu đến cuối trong Kafka được xác định theo thời gian từ khi thông báo được nhà sản xuất xuất bản đến khi tin nhắn được đọc bởi người tiêu dùng. Theo nguyên tắc thông thường, nếu bạn quan tâm đến độ trễ, có lẽ nên giới hạn số lượng phân vùng trên mỗi nhà môi giới ở mức 100 x b x r , trong đó b là số lượng nhà môi giới trong cụm Kafka và r là hệ số sao chép.

Tôi nghĩ tên chủ đề là kết luận của một loại tin nhắn và nhà sản xuất xuất bản tin nhắn cho chủ đề và tin nhắn đăng ký của người tiêu dùng thông qua chủ đề đăng ký.

Một chủ đề có thể có nhiều phân vùng. phân vùng là tốt cho song song. phân vùng cũng là đơn vị nhân rộng, vì vậy trong Kafka, người lãnh đạo và người theo dõi cũng được nói ở cấp độ phân vùng. Trên thực tế, một phân vùng là một hàng đợi có thứ tự mà thứ tự là thông báo đã đến. Và chủ đề được sáng tác bởi một hoặc nhiều hàng đợi trong một từ đơn giản. Điều này rất hữu ích cho chúng tôi để mô hình hóa cấu trúc của chúng tôi.

Kafka được LinkedIn phát triển để tổng hợp và phân phối nhật ký. cảnh này là một ví dụ rất tốt

Các sự kiện của người dùng trên web hoặc ứng dụng của bạn có thể được đăng nhập bởi máy chủ Web của bạn và sau đó được gửi đến nhà môi giới Kafka thông qua nhà sản xuất. Trong nhà sản xuất, bạn có thể chỉ định phương pháp phân vùng, ví dụ: loại sự kiện (sự kiện khác nhau được lưu trong phân vùng khác nhau) hoặc thời gian sự kiện (phân vùng một ngày vào khoảng thời gian khác nhau theo logic ứng dụng của bạn) hoặc loại không có logic và cân bằng tất cả nhật ký thành nhiều phân vùng.

Về trường hợp của bạn trong câu hỏi, bạn có thể tạo một chủ đề gọi là "sự kiện xem trang" và tạo N phân vùng thông qua các khóa băm để phân phối nhật ký vào tất cả các phân vùng. Hoặc bạn có thể chọn logic phân vùng để tạo nhật ký phân phối theo tinh thần của bạn.