Modelowanie danych z Kafką? Tematy i partycje

Gdy już wiesz, jak podzielić strumień zdarzeń, nazwa tematu będzie łatwa, więc najpierw odpowiedzmy na to pytanie.

@ Ludd ma rację - wybrana struktura partycji zależy w dużej mierze od tego, jak chcesz przetworzyć strumień zdarzeń. Najlepiej, jeśli potrzebujesz klucza partycji, co oznacza, że Twoje przetwarzanie zdarzeń to partition-local.

Na przykład:

1. jeśli zależy ci na średnim czasie użytkowników na stronie, powinieneś podzielić według :user-id. W ten sposób, wszystkie zdarzenia związane z aktywnością witryny jednego użytkownika będą dostępne na tej samej partycji. Oznacza to, że silnik przetwarzania strumieniowego, taki jak Apache Samza , może obliczyć średni czas na miejscu dla danego użytkownika po prostu patrząc na zdarzenia w jednej partycji. Pozwala to uniknąć konieczności wykonywania wszelkiego rodzaju kosztownego przetwarzania partycji-global
2. jeśli zależy ci na najpopularniejszych stronach w Twojej witrynie, powinieneś podzielić na strony :viewed. Znowu Samza będzie w ten sposób możliwe jest wyświetlenie wszystkich stron na jednej partycji.]}

Ogólnie rzecz biorąc, staramy się unikać polegania na stanie globalnym (takim jak przechowywanie danych w zdalnej bazie danych, takiej jak DynamoDB lub Cassandra), a zamiast tego BYĆ w stanie pracować przy użyciu stanu lokalnego partycji. Dzieje się tak, ponieważ lokalny stan jest podstawowym prymitywem w przetwarzaniu strumienia.

Jeśli potrzebujesz obu powyższych przypadków użycia, to wspólny wzór z Kafką jest pierwszy partycja przez say :user-id, a następnie do ponowna partycja przez :viewed gotowa do następnej fazy przetwarzania.

W temacie nazwy-oczywistym tutaj byłoby events lub user-events. Aby być bardziej szczegółowym, możesz użyć events-by-user-id i / lub events-by-viewed.

Myślę, że nazwa tematu jest konkluzją pewnego rodzaju wiadomości, a producent publikuje wiadomość do tematu, a konsument subskrybuje wiadomość poprzez Subskrybuj temat.

Temat może mieć wiele partycji. partycja jest dobra dla równoległości. partycja jest również jednostką replikacji, więc w Kafka, lider i follower jest również powiedziane na poziomie partycji. W rzeczywistości partycja jest kolejką uporządkowaną, której kolejność jest kolejką wiadomości. A temat składa się z jednej lub kilku kolejek w proste słowo. Jest to dla nas przydatne do modelowania naszej struktury.

Kafka jest rozwijana przez LinkedIn do agregacji i dostarczania logów. ta scena jest bardzo dobra jako przykład.

Zdarzenia użytkownika w sieci lub aplikacji mogą być rejestrowane przez web sever, a następnie wysyłane do brokera Kafka za pośrednictwem producenta. W producer można określić metodę partycji, na przykład: typ zdarzenia (różne zdarzenia są zapisywane na innej partycji) lub czas zdarzenia (partycja dzień w innym okresie według twoja logika aplikacji) lub typ użytkownika lub po prostu brak logiki i zrównoważenie wszystkich logów na wiele partycji.

Jeśli chodzi o Twój przypadek, możesz utworzyć jeden temat o nazwie "page-view-event" i utworzyć N partycji za pomocą kluczy hashowych, aby równomiernie rozłożyć dzienniki na wszystkie partycje. Albo możesz wybrać logikę partycji, aby dziennik był rozprowadzany przez twojego ducha.

Nie jest to dokładnie związane z pytaniem, ale jeśli już zdecydowałeś się na logiczną segregację rekordów na podstawie tematów i chcesz zoptymalizować liczbę tematów / partycji w Kafce, Ten blog może się przydać.

Najważniejsze informacje w skrócie:

• Ogólnie rzecz biorąc, im więcej partycji jest w klastrze Kafka, tym wyższa przepustowość można osiągnąć. Niech max osiągalny na jednej partycji do produkcji będzie p i konsumpcja być c. Powiedzmy, że docelowa przepustowość wynosi t. Wtedy musisz mieć co najmniej max(t/p, t/c) partycje.

• Obecnie w Kafce każdy broker otwiera plik zarówno indeksu, jak i Pliku danych każdego segmentu dziennika. Im więcej partycji, tym wyżej trzeba skonfigurować otwarty plik obsługa limitu w podstawowym systemie operacyjnym. Np. w naszym systemie produkcyjnym, kiedyś zauważyliśmy błąd mówiący too many files are open, podczas gdy mieliśmy około 3600 partycji tematycznych.

• Gdy broker jest wyłączony (np. kill -9), obserwowana niedostępność może być proporcjonalna do liczby partycji.

• Termin "end-to-end latency" w Kafce jest definiowany przez czas, od kiedy wiadomość jest publikowana przez producenta do kiedy wiadomość jest czytana przez konsumenta. Z reguły thumb, jeśli zależy ci na opóźnieniu, prawdopodobnie dobrym pomysłem jest ograniczenie liczby partycji na brokera do 100 x b x r, gdzie b to liczba brokerów w klastrze Kafka, a r to współczynnik replikacji.