Modelowanie danych z Kafką? Tematy i partycje

Jedną z pierwszych rzeczy, o których myślę podczas korzystania z nowej usługi (takiej jak magazyn danych inny niż RDBMS lub kolejka komunikatów), jest: „Jak powinienem uporządkować dane?”.

Przeczytałem i obejrzałem kilka materiałów wprowadzających. W szczególności weźmy na przykład Kafka: Distributed Messaging System for Log Processing , który pisze:

• „Temat to kontener, z którym powiązane są wiadomości”
• „Najmniejszą jednostką paralelizmu jest podział tematu. Oznacza to, że wszystkie wiadomości, które… należą do określonej partycji tematu, będą konsumowane przez konsumenta w grupie konsumentów”.

Wiedząc o tym, jaki byłby dobry przykład ilustrujący, jak używać tematów i partycji? Kiedy coś powinno być tematem? Kiedy coś powinno być partycją?

Na przykład załóżmy, że moje dane (Clojure) wyglądają następująco:

{: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"}

Czy temat powinien być oparty na user-id? viewed? at? A co z partycją?

Jak mam zdecydować?

Podczas tworzenia struktury danych dla platformy Kafka tak naprawdę zależy to od tego, jak mają być one wykorzystywane.

Moim zdaniem temat to grupa wiadomości podobnego typu, które będą konsumowane przez tego samego rodzaju konsumentów, więc w powyższym przykładzie miałbym tylko jeden temat i jeśli zdecydujesz się wcisnąć inny rodzaj dane za pośrednictwem platformy Kafka, możesz później dodać nowy temat.

Tematy są rejestrowane w ZooKeeper, co oznacza, że ​​możesz napotkać problemy, jeśli próbujesz dodać ich zbyt wiele, np. Przypadek, w którym masz milion użytkowników i zdecydowałeś się utworzyć temat dla każdego użytkownika.

Z drugiej strony partycje to sposób na zrównoleglenie zużycia komunikatów, a całkowita liczba partycji w klastrze brokera musi być co najmniej taka sama, jak liczba konsumentów w grupie konsumentów, aby nadać sens funkcji partycjonowania. Konsumenci w grupie konsumenckiej podzielą ciężar przetwarzania tematu między siebie zgodnie z partycjonowaniem, tak aby jeden konsument zajmował się tylko wiadomościami w samej partycji, do której jest „przypisany”.

Partycjonowanie można ustawić jawnie przy użyciu klucza partycji po stronie producenta lub, jeśli nie zostanie podany, dla każdego komunikatu zostanie wybrana losowa partycja.

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

@Ludd ma rację - wybrana struktura partycji będzie w dużej mierze zależała od tego, jak chcesz przetwarzać strumień zdarzeń. W idealnym przypadku potrzebujesz klucza partycji, co oznacza, że ​​przetwarzanie zdarzeń odbywa się lokalnie na partycji .

Na przykład:

1. Jeśli zależy Ci na średnim czasie spędzanym przez użytkowników w witrynie, podziel według :user-id. W ten sposób wszystkie zdarzenia związane z aktywnością w witrynie 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 spędzony w witrynie dla danego użytkownika, po prostu patrząc na zdarzenia w pojedynczej partycji. Pozwala to uniknąć wszelkiego rodzaju kosztownego globalnego przetwarzania partycji
2. Jeśli zależy Ci na najpopularniejszych stronach w Twojej witrynie, podziel według :viewedstrony. Ponownie Samza będzie w stanie zliczać wyświetlenia danej strony po prostu patrząc na zdarzenia w jednej partycji

Ogólnie rzecz biorąc, staramy się uniknąć konieczności polegania na stanie globalnym (takim jak przechowywanie liczników w zdalnej bazie danych, takiej jak DynamoDB lub Cassandra), i zamiast tego możemy pracować przy użyciu stanu lokalnego partycji. Dzieje się tak, ponieważ stan lokalny jest podstawowym prymitywem w przetwarzaniu strumieniowym .

Jeśli potrzebujesz obu powyższych przypadków użycia, typowym wzorcem w Kafce jest :user-id, powiedzmy , najpierw podzielenie na partycje , a następnie ponowne podzielenie według :viewedgotowości do następnej fazy przetwarzania.

W przypadku nazw tematów - oczywistym tutaj byłoby eventslub user-events. Aby być bardziej szczegółowym, możesz iść z events-by-user-idi / lub events-by-viewed.

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ć.

Kluczowe wnioski w pigułce:

• Ogólnie rzecz biorąc, im więcej partycji znajduje się w klastrze Kafka, tym większą przepustowość można osiągnąć. Niech maksymalne osiągalne maksimum na pojedynczej partycji dla produkcji będzie p, a zużycie będzie równe c . Powiedzmy, że docelowa przepustowość wynosi t . Następnie musisz mieć co najmniej max ( t / p , t / c ) partycji.

• Obecnie w Kafce każdy broker otwiera uchwyt pliku zarówno indeksu, jak i plik danych każdego segmentu dziennika. Tak więc, im więcej partycji, tym wyższa jest wymagana konfiguracja limitu otwierania plików w podstawowym systemie operacyjnym. Np. W naszym systemie produkcyjnym widzieliśmy kiedyś błąd informujący too many files are open, że mieliśmy około 3600 partycji tematycznych.

• Gdy broker jest zamykany w nieczysty sposób (np. Zabija -9), obserwowana niedostępność może być proporcjonalna do liczby partycji.

• Opóźnienie od końca do końca w Kafce jest definiowane przez czas od opublikowania wiadomości przez producenta do momentu odczytania wiadomości przez konsumenta. Z reguły, 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.

Myślę, że nazwa tematu jest podsumowaniem pewnego rodzaju wiadomości, a producent publikuje wiadomość w temacie, a wiadomość subskrybuje konsumenta poprzez temat subskrybowania.

Temat może mieć wiele partycji. partycja jest dobra dla równoległości. partycja jest również jednostką replikacji, więc w Kafce lider i zwolennik jest również określany na poziomie podziału. W rzeczywistości partycja jest uporządkowaną kolejką, której kolejnością jest kolejność nadejścia wiadomości. Temat składa się z jednej lub więcej kolejki jednym prostym słowem. Jest to przydatne dla nas do modelowania naszej struktury.

Usługa Kafka została opracowana przez LinkedIn w celu agregacji i dostarczania dzienników. ta scena jest bardzo dobra jako przykład.

Zdarzenia użytkownika w Twojej sieci lub aplikacji mogą być rejestrowane przez serwer sieciowy, a następnie wysyłane do brokera Kafka za pośrednictwem producenta. W producencie możesz określić metodę partycji, na przykład: typ zdarzenia (inne zdarzenie jest zapisywane na innej partycji) lub czas zdarzenia (podział dnia na inny okres zgodnie z logiką aplikacji) lub typ użytkownika lub po prostu brak logiki i zbilansuj wszystkie dzienniki 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 hash, aby równomiernie rozdzielić dzienniki na wszystkie partycje. Lub możesz wybrać logikę partycji, aby dystrybuować dzienniki według twojego ducha.