Omówienie i dostosowywanie jednostek przesyłania strumieniowego usługi Stream Analytics

Artykuł
12/05/2022
Czas czytania: 9 min

Omówienie jednostki przesyłania strumieniowego i węzła przesyłania strumieniowego

Jednostki przesyłania strumieniowego (SU) reprezentują zasoby obliczeniowe przydzielone do wykonania zadania usługi Stream Analytics. Im większa liczba jednostek przesyłania strumieniowego, tym większa ilość zasobów procesora i pamięci jest przydzielana do zadania. Ta pojemność pozwala skupić się na logice zapytań i abstrakcjach konieczność zarządzania sprzętem w celu uruchomienia zadania usługi Stream Analytics w odpowiednim czasie.

Co 6 jednostek SU odpowiadających jednemu węzłowi przesyłania strumieniowego dla zadania. Zadania z 1 i 3 jednostkami SU mają również tylko jeden węzeł przesyłania strumieniowego, ale z ułamkiem zasobów obliczeniowych w porównaniu z 6 jednostkami SU. Zadania 1 i 3 jednostek SU zapewniają ekonomiczną opcję dla obciążeń wymagających mniejszej skali. Zadanie może być skalowane poza 6 jednostek SU do 12, 18, 24 i innych, dodając więcej węzłów przesyłania strumieniowego, które zapewniają więcej rozproszonych zasobów obliczeniowych, co umożliwia zadanie przetwarzania większej liczby woluminów danych.

W celu uzyskania małych opóźnień przetwarzania strumieni całe przetwarzanie dla zadań usługi Azure Stream Analytics jest wykonywane w pamięci. Gdy zabraknie pamięci, zadanie przesyłania strumieniowego kończy się niepowodzeniem. W związku z tym w przypadku zadania produkcyjnego ważne jest monitorowanie użycia zasobów zadania przesyłania strumieniowego i upewnienie się, że przydzielono wystarczający zasób, aby utrzymać zadania uruchomione 24/7.

Metryka procentowego wykorzystania jednostek SU, która waha się od 0% do 100%, opisuje zużycie pamięci obciążenia. W przypadku zadania przesyłania strumieniowego z minimalnym zużyciem ta metryka zwykle wynosi od 10% do 20%. Jeśli wykorzystanie jednostek SU% jest wysokie (powyżej 80%), lub jeśli zdarzenia wejściowe zostaną wycofane (nawet w przypadku niskiego użycia jednostek SU%, ponieważ nie pokazuje użycia procesora CPU), obciążenie prawdopodobnie wymaga większej liczby zasobów obliczeniowych, co wymaga zwiększenia liczby jednostek SU. Najlepiej zachować metryki SU poniżej 80% do uwzględnienia okazjonalnych skoków. Aby reagować na zwiększone obciążenia i zwiększyć liczbę jednostek przesyłania strumieniowego, rozważ ustawienie alertu o wartości 80% na metryce Wykorzystanie jednostek SU. Ponadto możesz użyć metryk opóźnienia znaku wodnego i zdarzeń z powrotem, aby sprawdzić, czy istnieje wpływ.

Konfigurowanie jednostek przesyłania strumieniowego usługi Stream Analytics (SU)

Zaloguj się w witrynie Azure Portal
Na liście zasobów znajdź zadanie usługi Stream Analytics, które chcesz skalować, a następnie otwórz je.
Na stronie zadania w obszarze Konfiguruj nagłówek wybierz pozycję Skaluj. Domyślna liczba jednostek SU to 3 podczas tworzenia zadania.
Wybierz opcję SU na liście rozwijanej, aby ustawić jednostki SU dla zadania. Zwróć uwagę, że masz ograniczenie do określonych ustawień jednostki SU.
Liczbę jednostek SU przypisanych do zadania można zmienić nawet wtedy, gdy jest uruchomiona. Nie jest to możliwe, jeśli zadanie używa niezdzielonych danych wyjściowych lub ma zapytanie wieloetapowe z różnymi wartościami PARTITION BY. Być może możesz ograniczyć wybór spośród zestawu wartości SU, gdy zadanie jest uruchomione.

Monitorowanie wydajności zadań

Za pomocą Azure Portal można śledzić metryki związane z wydajnością zadania. Aby dowiedzieć się więcej o definicji metryk, zobacz Metryki zadań usługi Azure Stream Analytics. Aby dowiedzieć się więcej na temat monitorowania metryk w portalu, zobacz Monitorowanie zadania usługi Stream Analytics za pomocą Azure Portal.

Oblicz oczekiwaną przepływność obciążenia. Jeśli przepływność jest mniejsza niż oczekiwano, dostosuj partycję wejściową, dostosuj zapytanie i dodaj jednostki SU do zadania.

How many SUs are required for a job? (Ile jednostek przesyłania strumieniowego jest wymaganych dla zadania?)

Wybranie liczby wymaganych jednostek SU dla określonego zadania zależy od konfiguracji partycji dla danych wejściowych i zapytania zdefiniowanego w ramach zadania. Strona Skalowanie umożliwia ustawienie odpowiedniej liczby jednostek SU. Najlepszym rozwiązaniem jest przydzielanie większej liczby jednostek SU niż jest to konieczne. Aparat przetwarzania usługi Stream Analytics optymalizuje opóźnienia i przepływność kosztem przydzielania dodatkowej pamięci.

Ogólnie rzecz biorąc, najlepszym rozwiązaniem jest rozpoczęcie od 6 jednostek SU dla zapytań, które nie używają partycji BY. Następnie określ słodką plamę przy użyciu metody próbnej i błędu, w której należy zmodyfikować liczbę jednostek SU po przekazaniu reprezentatywnych ilości danych i zbadać metrykę Wykorzystanie SU%. Maksymalna liczba jednostek przesyłania strumieniowego, które mogą być używane przez zadanie usługi Stream Analytics, zależy od liczby kroków w zapytaniu zdefiniowanym dla zadania i liczby partycji w każdym kroku. Więcej informacji na temat limitów można znaleźć tutaj.

Aby uzyskać więcej informacji na temat wybierania odpowiedniej liczby jednostek SU, zobacz tę stronę: Skalowanie zadań usługi Azure Stream Analytics w celu zwiększenia przepływności

Uwaga

Wybór liczby jednostek SU wymaganych dla określonego zadania zależy od konfiguracji partycji dla danych wejściowych i zapytania zdefiniowanego dla zadania. Możesz wybrać maksymalnie limit przydziału w jednostkach SU dla zadania. Domyślnie każda subskrypcja platformy Azure ma limit przydziału do 500 jednostek SU dla wszystkich zadań analitycznych w określonym regionie. Aby zwiększyć liczbę jednostek SU dla subskrypcji przekraczających ten limit przydziału, skontaktuj się z pomoc techniczna firmy Microsoft. Prawidłowe wartości jednostek SU na zadanie to 1, 3, 6 i w górę o 6.

Czynniki zwiększające procentowe wykorzystanie jednostek przesyłania strumieniowego

Elementy zapytania czasowego (zorientowanego na czas) to podstawowy zestaw operatorów stanowych udostępnianych przez usługę Stream Analytics. Usługa Stream Analytics zarządza stanem tych operacji wewnętrznie w imieniu użytkownika, zarządzając zużyciem pamięci, punktami kontrolnymi w celu zapewnienia odporności i odzyskiwania stanu podczas uaktualniania usługi. Mimo że usługa Stream Analytics w pełni zarządza stanami, istnieje wiele zaleceń dotyczących najlepszych rozwiązań, które użytkownicy powinni rozważyć.

Należy pamiętać, że zadanie ze złożoną logiką zapytań może mieć wysokie wykorzystanie jednostek SU% nawet wtedy, gdy nie otrzymuje on stale zdarzeń wejściowych. Może się to zdarzyć po nagłym skoku liczby zdarzeń wejściowych i wyjściowych. Zadanie może nadal utrzymywać stan w pamięci, jeśli zapytanie jest złożone.

Wykorzystanie jednostek SU% może nagle spaść do 0 na krótki okres przed powrotem do oczekiwanych poziomów. Dzieje się tak z powodu przejściowych błędów lub uaktualnień zainicjowanych przez system. Zwiększenie liczby jednostek przesyłania strumieniowego dla zadania może nie zmniejszyć wykorzystania jednostek SU%, jeśli zapytanie nie jest w pełni równoległe.

Porównując wykorzystanie w danym okresie, należy użyć metryk szybkości zdarzeń. Metryki InputEvents i OutputEvents pokazują, ile zdarzeń zostało odczytanych i przetworzonych. Istnieją również metryki wskazujące liczbę zdarzeń błędów, takich jak błędy deserializacji. Gdy liczba zdarzeń na jednostkę czasową wzrośnie, liczba jednostek SU% zwiększa się w większości przypadków.

Logika zapytań stanowych w elementach czasowych

Jedną z unikatowych możliwości zadania usługi Azure Stream Analytics jest wykonywanie przetwarzania stanowego, takiego jak agregacje okienne, sprzężenia czasowe i funkcje analityczne czasowe. Każdy z tych operatorów przechowuje informacje o stanie. Maksymalny rozmiar okna dla tych elementów zapytania wynosi siedem dni.

Koncepcja okna czasowego jest wyświetlana w kilku elementach zapytania usługi Stream Analytics:

Agregacje okienne: GROUP BY of Tumbling, Hopping i Przesuwane okna
Sprzężenia czasowe: JOIN with DATEDIFF, funkcja
Funkcje analityczne czasowe: ISFIRST, LAST i LAG z CZASEM TRWANIA LIMITU

Następujące czynniki wpływają na pamięć używaną (część metryki jednostek przesyłania strumieniowego) przez zadania usługi Stream Analytics:

Agregacje okienne

Ilość używanej pamięci (rozmiar stanu) dla agregacji okien nie zawsze jest bezpośrednio proporcjonalna do rozmiaru okna. Zamiast tego zużywana pamięć jest proporcjonalna do kardynalności danych lub liczby grup w każdym przedziale czasu.

Na przykład w poniższym zapytaniu liczba skojarzona z clusterid jest kardynalnością zapytania.

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Aby rozwiązać wszelkie problemy spowodowane wysoką kardynalnością w poprzednim zapytaniu, można wysyłać zdarzenia do usługi Event Hubs podzielone na partycje według clusterid, i skalować zapytanie w poziomie, umożliwiając systemowi przetwarzanie każdej partycji wejściowej oddzielnie przy użyciu funkcji PARTITION BY , jak pokazano w poniższym przykładzie:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Po podzieleniu zapytania na partycje są rozłożone na wiele węzłów. W rezultacie liczba clusterid wartości przychodzących do każdego węzła jest zmniejszana, co zmniejsza kardynalność grupy według operatora.

Partycje usługi Event Hubs powinny być partycjonowane przez klucz grupowania, aby uniknąć potrzeby kroku redukcji. Aby uzyskać więcej informacji, zobacz Omówienie usługi Event Hubs.

Sprzężenia czasowe

Zużywana pamięć (rozmiar stanu) sprzężenia czasowego jest proporcjonalna do liczby zdarzeń w czasowym pomieszczeniu przełącznika sprzężenia, co jest współczynnikiem wprowadzania zdarzeń mnożonym przez rozmiar pomieszczenia przełącznika. Innymi słowy, pamięć zużywana przez sprzężenia jest proporcjonalna do zakresu czasu DateDiff pomnożonego przez średni współczynnik zdarzeń.

Liczba niedopasowanych zdarzeń w sprzężeniu wpływa na wykorzystanie pamięci dla zapytania. Następujące zapytanie służy do znajdowania wyświetleń reklam, które generują kliknięcia:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

W tym przykładzie jest możliwe, że wiele reklam jest wyświetlanych, a kilka osób klika je i jest wymagane, aby zachować wszystkie zdarzenia w przedziale czasu. Używana pamięć jest proporcjonalna do wielkości okna i szybkości zdarzeń.

Aby to skorygować, wyślij zdarzenia do usługi Event Hubs podzielone na partycje przy użyciu kluczy sprzężenia (identyfikator w tym przypadku) i przeprowadź skalowanie zapytania w poziomie, umożliwiając systemowi przetwarzanie każdej partycji wejściowej oddzielnie przy użyciu funkcji PARTITION BY , jak pokazano poniżej:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10

Po podzieleniu zapytania na partycje są rozłożone na wiele węzłów. W związku z tym liczba zdarzeń przychodzących do każdego węzła jest zmniejszana, co zmniejsza rozmiar stanu przechowywanego w oknie sprzężenia.

Funkcje analityczne czasowe

Zużywana pamięć (rozmiar stanu) funkcji analitycznej czasowej jest proporcjonalna do współczynnika zdarzeń pomnożonego przez czas trwania. Pamięć zużywana przez funkcje analityczne nie jest proporcjonalna do rozmiaru okna, ale raczej liczby partycji w każdym przedziale czasu.

Korygowanie jest podobne do sprzężenia czasowego. Zapytanie można skalować w poziomie przy użyciu funkcji PARTITION BY.

Bufor poza kolejnością

Użytkownik może skonfigurować rozmiar buforu poza kolejnością w okienku Konfiguracji zamawiania zdarzeń. Bufor służy do przechowywania danych wejściowych przez czas trwania okna i zmienia ich kolejność. Rozmiar buforu jest proporcjonalny do współczynnika wprowadzania zdarzeń pomnożoną przez rozmiar okna poza kolejnością. Domyślny rozmiar okna to 0.

Aby skorygować przepełnienie buforu poza kolejnością, przeprowadź skalowanie zapytania w poziomie przy użyciu funkcji PARTITION BY. Po podzieleniu zapytania na partycje są rozłożone na wiele węzłów. W związku z tym liczba zdarzeń przychodzących do każdego węzła jest zmniejszana, co zmniejsza liczbę zdarzeń w każdym buforze zmiany kolejności.

Liczba partycji wejściowych

Każda partycja wejściowa zadania wejściowego ma bufor. Większa liczba partycji wejściowych, tym więcej zasobów zużywa zadanie. Dla każdej jednostki przesyłania strumieniowego usługa Azure Stream Analytics może przetwarzać około 1 MB/s danych wejściowych. W związku z tym można zoptymalizować, pasując do liczby jednostek przesyłania strumieniowego usługi Stream Analytics z liczbą partycji w centrum zdarzeń.

Zazwyczaj zadanie skonfigurowane z jedną jednostką przesyłania strumieniowego jest wystarczające dla centrum zdarzeń z dwiema partycjami (co jest minimum dla centrum zdarzeń). Jeśli centrum zdarzeń ma więcej partycji, zadanie usługi Stream Analytics zużywa więcej zasobów, ale niekoniecznie używa dodatkowej przepływności zapewnianej przez usługę Event Hubs.

W przypadku zadania z 6 jednostkami przesyłania strumieniowego może być konieczne 4 lub 8 partycji z centrum zdarzeń. Należy jednak unikać zbyt wielu niepotrzebnych partycji, ponieważ powoduje to nadmierne użycie zasobów. Na przykład centrum zdarzeń z 16 partycjami lub większymi w zadaniu usługi Stream Analytics, które ma 1 jednostkę przesyłania strumieniowego.

Dane referencyjne

Dane referencyjne w usłudze ASA są ładowane do pamięci w celu szybkiego wyszukiwania. W przypadku bieżącej implementacji każda operacja sprzężenia z danymi referencyjnymi przechowuje kopię danych referencyjnych w pamięci, nawet jeśli wielokrotnie łączysz się z tymi samymi danymi referencyjnymi. W przypadku zapytań z partycją PARTITION BY każda partycja ma kopię danych referencyjnych, więc partycje są w pełni oddzielone. Dzięki efektowi mnożnika użycie pamięci może szybko uzyskać bardzo duże, jeśli łączysz się z danymi referencyjnymi wiele razy z wieloma partycjami.

Korzystanie z funkcji UDF

Po dodaniu funkcji UDF usługa Azure Stream Analytics ładuje środowisko uruchomieniowe Języka JavaScript do pamięci. Będzie to miało wpływ na jednostki SU%.