Udostępnij za pośrednictwem

Skalowanie zadania usługi Azure Stream Analytics w celu zwiększenia przepływności

  • Artykuł

W tym artykule pokazano, jak dostosować zapytanie usługi Stream Analytics w celu zwiększenia przepływności zadań usługi Streaming Analytics. Poniższy przewodnik umożliwia skalowanie zadania w celu obsługi większego obciążenia i korzystania z większej liczby zasobów systemowych (takich jak większa przepustowość, więcej zasobów procesora CPU, więcej pamięci).

Aby spełnić wymagania wstępne, przeczytaj następujące artykuły:

Przypadek 1 — Zapytanie jest z natury w pełni równoległe między partycjami wejściowymi

Jeśli zapytanie jest z natury w pełni równoległe między partycjami wejściowymi, możesz wykonać następujące kroki:

  • Utwórz zapytanie tak, aby było żenujące równolegle przy użyciu słowa kluczowego PARTITION BY . Aby uzyskać więcej informacji, zobacz Używanie równoległego przetwarzania zapytań w usłudze Azure Stream Analytics.
  • W zależności od typów danych wyjściowych używanych w zapytaniu niektóre dane wyjściowe mogą nie być równoległe lub wymagają dalszej konfiguracji, aby być kłopotliwie równoległe. Na przykład dane wyjściowe usługi Power BI nie mogą być równoległe. Dane wyjściowe są zawsze scalane przed wysłaniem do ujścia danych wyjściowych. Obiekty blob, tabele, usługa Azure Data Lake Storage, usługa Service Bus i funkcja platformy Azure są automatycznie równoległe. Dane wyjściowe sql i Azure Synapse Analytics mają opcję równoległego przetwarzania. Centrum zdarzeń musi mieć ustawioną konfigurację PartitionKey zgodną z polem PARTITION BY (zwykle PartitionId). W przypadku usługi Event Hubs należy również zwrócić szczególną uwagę na dopasowanie liczby partycji dla wszystkich danych wejściowych i wszystkich danych wyjściowych, aby uniknąć krzyżowania między partycjami.
  • Uruchom zapytanie przy użyciu 1 jednostki przesyłania strumieniowego (SU) v2 (która jest pełną pojemnością pojedynczego węzła obliczeniowego), aby zmierzyć maksymalną osiągalną przepływność, a jeśli używasz funkcji GROUP BY, zmierz liczbę grup (kardynalność), które może obsłużyć zadanie. Ogólne objawy zadania osiągające limity zasobów systemowych są następujące.
    • Metryka wykorzystania jednostek strumienia (SU) wynosi ponad 80%. Wskazuje, że użycie pamięci jest wysokie. Czynniki przyczyniające się do zwiększenia tej metryki zostały opisane w opisie i dostosowaniu jednostek przesyłania strumieniowego usługi Stream Analytics.
    • Sygnatura czasowa danych wyjściowych spada z tyłu w odniesieniu do czasu zegara ściany. W zależności od logiki zapytania sygnatura czasowa danych wyjściowych może mieć przesunięcie logiki z zegara ściany. Jednak powinny one postępować w mniej więcej tym samym tempie. Jeśli sygnatura czasowa danych wyjściowych spada dalej i dalej, oznacza to, że system przepracuje. Może to być wynikiem ograniczania przepustowości ujścia danych wyjściowych podrzędnych lub wysokiego wykorzystania procesora CPU. W tej chwili nie udostępniamy metryki wykorzystania procesora CPU, więc odróżnienie tych dwóch może być trudne.
      • Jeśli problem jest spowodowany ograniczaniem ujścia, należy zwiększyć liczbę partycji wyjściowych (a także partycji wejściowych, aby zachować zadanie w pełni równoległe) lub zwiększyć ilość zasobów ujścia (na przykład liczbę jednostek żądań dla usługi Cosmos DB).
    • Na diagramie zadań istnieje metryka zdarzeń listy prac dla poszczególnych partycji dla każdego danych wejściowych. Jeśli metryka zdarzeń listy prac stale rośnie, jest to również wskaźnik, że zasób systemowy jest ograniczony (albo ze względu na ograniczanie ujścia danych wyjściowych lub wysokie użycie procesora CPU).
  • Po określeniu limitów tego, co może osiągnąć jedno zadanie SU V2, można ekstrapolować liniowo pojemność przetwarzania zadania podczas dodawania większej liczby jednostek jednostki SU, przy założeniu, że nie masz żadnych niesymetryczności danych, co sprawia, że pewna partycja "gorąca".

Uwaga

Wybierz odpowiednią liczbę jednostek przesyłania strumieniowego: ponieważ usługa Stream Analytics tworzy węzeł przetwarzania dla każdego dodanego 1 jednostki SU V2, najlepiej jest sprawić, aby liczba węzłów była dzielnikiem liczby partycji wejściowych, aby partycje mogły być równomiernie rozłożone między węzłami. Na przykład zmierzono 1 zadanie SU V2 może osiągnąć szybkość przetwarzania 4 MB/s, a liczba partycji wejściowych wynosi 4. Możesz uruchomić zadanie za pomocą 2 jednostek SU V2, aby osiągnąć około 8 MB/s szybkości przetwarzania, lub 4 jednostki SU V2, aby osiągnąć 16 MB/s. Następnie możesz zdecydować, kiedy zwiększyć liczbę jednostek jednostki SU dla zadania, do jakiej wartości, jako funkcji współczynnika danych wejściowych.

Przypadek 2 — jeśli zapytanie nie jest żenujące równolegle.

Jeśli zapytanie nie jest żenujące równolegle, możesz wykonać następujące kroki.

  • Zacznij od zapytania bez partycji BY , aby uniknąć złożoności partycjonowania, i uruchom zapytanie z 1 SU V2, aby zmierzyć maksymalne obciążenie, jak w przypadku 1.
  • Jeśli możesz osiągnąć przewidywane obciążenie w okresie przepływności, wszystko będzie gotowe. Alternatywnie możesz mierzyć to samo zadanie uruchomione z węzłami ułamkowych na 2/3 SU V2 i 1/3 SU V2, aby dowiedzieć się, jak minimalna liczba jednostek przesyłania strumieniowego działa w danym scenariuszu.
  • Jeśli nie możesz osiągnąć żądanej przepływności, spróbuj podzielić zapytanie na wiele kroków, jeśli nie ma jeszcze wielu kroków, i przydziel do jednego SU V2 dla każdego kroku zapytania. Jeśli na przykład masz trzy kroki, przydziel trzy jednostki SU V2 w opcji "Skaluj".
  • Aby uruchomić takie zadanie, usługa Stream Analytics umieszcza każdy krok na własnym węźle z dedykowanym zasobem SU V2.
  • Jeśli cel ładowania nadal nie został osiągnięty, możesz podjąć próbę użycia funkcji PARTITION BY , zaczynając od kroków bliżej danych wejściowych. W przypadku operatora GROUP BY , który nie można naturalnie partycjonować, można użyć lokalnego/globalnego wzorca agregacji, aby wykonać partycjonowaną grupę WEDŁUG , a następnie niepartyjną grupę WEDŁUG. Jeśli na przykład chcesz policzyć liczbę samochodów przechodzących przez każde stoisko płatne co 3 minuty, a ilość danych wykracza poza to, co można obsłużyć przez jeden numer SU V2.

Zapytanie:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

W zapytaniu liczysz samochody na stoisko płatne na partycję, a następnie dodajesz liczbę ze wszystkich partycji.

Po podzieleniu na partycje dla każdej partycji kroku przydziel jedną partycję SU V2, aby każda partycja mogła zostać umieszczona we własnym węźle przetwarzania.

Uwaga

Jeśli nie można partycjonować zapytania, dodanie dodatkowej jednostki SU w zapytaniu wieloe krokowym może nie zawsze poprawić przepływność. Jednym ze sposobów uzyskania wydajności jest zmniejszenie woluminu w początkowych krokach przy użyciu lokalnego/globalnego wzorca agregacji, zgodnie z opisem w kroku 5.

Przypadek 3 — Uruchamiasz wiele niezależnych zapytań w zadaniu.

W przypadku niektórych przypadków użycia niezależnego dostawcy oprogramowania, w których przetwarzanie danych z wielu dzierżaw w jednym zadaniu jest bardziej ekonomiczne, przy użyciu oddzielnych danych wejściowych i wyjściowych dla każdej dzierżawy kończy się wykonywanie wielu niezależnych zapytań (na przykład 20) w jednym zadaniu. Założeniem jest to, że obciążenie każdego z takich podzapytań jest stosunkowo małe.

W takim przypadku możesz wykonać następujące kroki.

  • W tym przypadku nie używaj funkcji PARTITION BY w zapytaniu
  • Zmniejsz liczbę partycji wejściowych do najniższej możliwej wartości 2, jeśli używasz usługi Event Hubs.
  • Uruchom zapytanie z jedną maszyną SU V2. W przypadku oczekiwanego obciążenia dla każdej podzapytania dodaj jak najwięcej takich podzapytania, dopóki zadanie nie osiągnie limitów zasobów systemowych. Zapoznaj się z przypadkiem 1, jeśli wystąpią objawy.
  • Po osiągnięciu mierzonego limitu podzapytania rozpocznij dodawanie podzapytania do nowego zadania. Liczba zadań do uruchomienia jako funkcja liczby niezależnych zapytań powinna być dość liniowa, przy założeniu, że nie masz żadnych niesymetryczności obciążenia. Następnie można przewidzieć liczbę zadań SU V2, które należy uruchomić jako funkcję liczby dzierżaw, które chcesz obsłużyć.
  • W przypadku używania sprzężenia danych referencyjnych z takimi zapytaniami połącz dane wejściowe przed dołączeniem do tych samych danych referencyjnych. Następnie podziel zdarzenia w razie potrzeby. W przeciwnym razie każde sprzężenie danych referencyjnych przechowuje kopię danych referencyjnych w pamięci, prawdopodobnie niepotrzebnie wysadzając użycie pamięci.

Uwaga

Ile dzierżaw należy umieścić w każdym zadaniu? Ten wzorzec zapytania często ma dużą liczbę podzapytania i powoduje bardzo dużą i złożoną topologię. Kontroler zadania może nie być w stanie obsłużyć tak dużej topologii. W zasadzie trzymaj się poniżej 40 dzierżaw dla zadania 1/3 SU V2 i 60 dzierżaw dla zadań 2/3 i 1 SU V2. Po przekroczeniu pojemności kontrolera zadanie nie zostanie uruchomione pomyślnie.

Uzyskaj pomoc

Aby uzyskać dalszą pomoc, wypróbuj stronę pytań i odpowiedzi firmy Microsoft dotyczącą usługi Azure Stream Analytics.

Następne kroki