Azure Event Hub

Kilka słów o Event Hubie.
Event Hub to service streamingowy przeznaczona do przyjmowania i konsumowania dużej ilości danych strumieniowych z bardzo dużą wydajnością.
Partycjonowani skalowalni konsumenci to model odczytu Event Hubów, zapewniający dużą wydajność obslugi wiadomości. Event Hub jest zaprojektowany jako elastyczny komponent, który można wkomponować w całą strukturę przekazywania wiadomości w projekcie.
Tutaj znajdziecie dokumentację.

Event Hub Namespace

Gdy tworzymy nową usługę w Azure pod tytułem event hub tak naprawdę tworzy się dla nas Event Hub Namespace. To taki agregator, miejsce, w którym dalej możemy tworzyć faktyczne instancje Event Hubów.

Event Hub

Event hub przyjmuje dane od (event producers) każdego bytu rozsyłającego zdarzenia za pomocą protokołu HTTP, AMQP 1.0 lub Apache Kafka. Każdy nadawca zostaje powiązany z specyficzną dla siebie partycją, na której dane są zapisywane w kolejności odbierania ich przez Event Hub. Wiadomości są odczytywane z Event Hubu przez odbiorców zdarzeń (event receivers) protokołem AMQP, czyli dwustronną sesją co zapewnia natychmiastową dostępność eventów pojawiających się w Event Hubie.

Throughput unit

Rozliczanie płatności oraz przepustowości odbywa się na poziomie całego namespacu. Czyli wszystkie event huby w danym namespacie mają w sumie do dyspozycji przepustowość określona jest na poziomie namespacu.
1 unit throughput oznacza, że możemy transmitować 1MB/s do naszego namespacu oraz 2MB/s z naszego namespacu (output)

Partycjonowanie Event Huba

Standardowo event hub ma od 2 do nawet 32 partycji na których zapisywane są dane.
Czyli każda wiadomość jest partycjonowana (minimum 2 partycje). Dane są dzielone na poszczególne partycje i zapisywane w kolejności przyjścia.
Partycjonowanie pozwala zwiększyć wydajność Event Huba. Ilość partycji powinniśmy określać na podstawie przewidywanej liczby niezależnych równoległych odczytów (Event receivers).
Jednak nie możemy również przesadzić w drugą stronę. Każda partycja zawiera eventy w kolejności ich przychodzenia od danego nadawcy powiązanego z daną partycją (Partition Key). Jeśli mamy 32 partycje i jedno źródło eventów nie będziemy mieli kolejności pojawiania się eventów.
Partycjonowanie jest również istotne przy rozliczaniu - jedna partycja ma maksymalną przepustowość jednego throughput unit.

Consumer Groups

Każdy Event Hub ma przynajmniej jedną grupę konsumentów $default. Zalecane jest stworzenie swoich własnych tak, aby nie wpaść w tarapaty. Gdy wykonujemy odczyt musimy odczytać wszystkie partycje. Każdą partycje może odczytywać osobny Event Receiver, którzy ponownie grupowani są w Consumer Group. Grupa konsumentów to swojego rodzaju widok na dane w partycjach, status oraz offset od którego dane powinny być czytane. Skoro jest to widok a możemy mieć wiele rozdzielnych grup konsumenckich to model odczytu kursora po stronie konsumenta (Client side cursor model).

Event Hub Capture

Wszystkie wiadomości, które przychodzą do Event Huba mogą być zapisywane. Mamy tutaj do wyboru albo Azure Storega albo Azure Data Lake.
Jest to raczej wykorzystywane do tworzenia Cold Path dla danych przychodzących., czyli jest to bardziej archiwizacja wszystkich danych.
Taka automatyczna archiwizacja danych w tym przypadku jest stosunkowo droga, bo stanowi około 3 krotność kosztu event huba. Warto więc przemyśleć czy to dobre miejsce na taką operację.

Stwórzmy Event Hub z dodatkową grupą konsumencką w istniejącym
Event Hub Namespace