Pojęcia dotyczące punktów kontrolnych i odtwarzania w zadaniach usługi Azure Stream Analytics

Azure Stream Analytics utrzymuje wewnętrzne informacje o stanie za każdym razem, gdy wykonuje się zadanie, i okresowo zapisuje ten stan w punkcie kontrolnym. Jeśli zadanie się nie powiedzie lub zostanie zaktualizowane, Stream Analytics może użyć najnowszego punktu kontrolnego do odzyskania danych. Gdy zadanie nie może użyć punktu kontrolnego, wykonuje powtórkę, przetwarzając ostatnie zdarzenia wejściowe, aby odbudować swój stan.

Ten artykuł wyjaśnia, jak działają punkty kontrolne i ponowne odtwarzanie w usłudze Azure Stream Analytics oraz jak wpływają one na czas potrzebny do przywrócenia zadania.

Logika zapytań stanowych w elementach czasowych

Jedną z unikalnych funkcji zadania Azure Stream Analytics jest wykonywanie przetwarzania stanowego, takiego jak agregaty okienkowe, łączenia czasowe oraz funkcje analityczne temporalne. Każdy z tych operatorów przechowuje informacje o stanie po uruchomieniu zadania. Maksymalny rozmiar okna dla tych elementów zapytania wynosi siedem dni.

Koncepcja okna czasowego pojawia się w kilku elementach zapytania usługi Stream Analytics:

  • Agregacja z oknami (GROUP BY w kontekście Tumbling, Hopping i Przesuwanych okien)
  • Łączenia czasowe (łączenie z funkcją RÓŻNICA_DAT)
  • Funkcje analizy czasowej (ISFIRST, LAST i LAG z ograniczeniem czasowym)

Odzyskiwanie zadania po awarii węzła, w tym uaktualnianie systemu operacyjnego

Za każdym razem, gdy uruchamiane jest zadanie usługi Stream Analytics, usługa wewnętrznie je skaluje, aby realizować zadania na wielu węzłach roboczych. Serwis kontroluje stan każdego węzła roboczego co kilka minut, co pomaga mu odzyskać stan w przypadku awarii.

Czasami dany węzeł roboczy może ulec awarii lub może nastąpić aktualizacja systemu operacyjnego dla tego węzła. Aby automatycznie przywrócić działanie, usługa Stream Analytics pozyskuje nowy, sprawny węzeł i przywraca stan poprzedniego węzła roboczego z najnowszego dostępnego punktu kontrolnego. Aby wznowić pracę, zadanie odtwarza niewielką ilość danych, aby przywrócić stan z ostatniego punktu kontrolnego. Zwykle przerwa w przywracaniu wynosi tylko kilka minut. Gdy wybierzesz wystarczającą liczbę jednostek streamingowych do zadania, powtórka kończy się szybko.

W pełni równoległym zapytaniu czas potrzebny do nadrobienia zaległości po awarii węzła procesora roboczego jest proporcjonalny do:

[szybkość zdarzeń wejściowych] x [długość luki] / [liczba partycji przetwarzania]

Jeśli kiedykolwiek zauważysz znaczne opóźnienia w przetwarzaniu spowodowane awarią węzła i aktualizacją systemu operacyjnego, rozważ pełną równoległość zapytania i skaluj zadanie, aby przydzielić więcej jednostek streamingowych. Aby uzyskać więcej informacji, zobacz Skalowanie zadania usługi Azure Stream Analytics w celu zwiększenia przepływności.

Stream Analytics obecnie nie pokazuje raportu o takim procesie odzyskiwania.

Odzyskiwanie zadania po uaktualnieniu usługi

Firma Microsoft od czasu do czasu uaktualnia pliki binarne uruchamiające zadania usługi Stream Analytics w usłudze platformy Azure. W takich momentach Microsoft aktualizuje uruchamiane zadania do nowszej wersji, a zadanie uruchamia się automatycznie.

Usługa Azure Stream Analytics używa punktów kontrolnych, gdy jest to możliwe, aby przywrócić dane z ostatniego stanu punktu kontrolnego. Gdy Stream Analytics nie może korzystać z wewnętrznych punktów kontrolnych, technika powtórek przywraca cały stan zapytania streamingowego. Aby umożliwić zadaniom Stream Analytics ponowne przetwarzanie dokładnie tych samych danych wejściowych, ustaw okres przechowywania danych źródłowych na co najmniej taki sam jak rozmiary okien w zapytaniu. Brak tego może skutkować błędnymi lub częściowymi wynikami podczas aktualizacji usługi, ponieważ Stream Analytics może nie przechowywać danych źródłowych wystarczająco daleko wstecz, by uwzględnić pełny rozmiar okna.

Ogólnie rzecz biorąc, wymagana ilość powtórzeń jest proporcjonalna do rozmiaru okna pomnożonego przez średni współczynnik zdarzeń. Na przykład w przypadku zadania o szybkości napływu 1 000 zdarzeń na sekundę okno dłuższe niż jedna godzina ma duży zakres odtwarzania. Usługa może wymagać ponownego przetworzenia danych z okresu do jednej godziny, aby zainicjować stan, tak aby mogła generować pełne i poprawne wyniki, co może spowodować opóźnione dane wyjściowe (lub ich brak) przez pewien dłuższy okres. Zapytania bez okien lub innych operatorów czasowych, takich jak JOIN lub LAG, mają zerowe odtwarzanie.

Szacowanie czasu nadrabiania zaległości

Aby oszacować długość opóźnienia spowodowanego modernizacją usługi, stosuj tę technikę:

  • Załaduj wejściowy hub zdarzeń wystarczającą ilością danych, aby pokryć największy rozmiar okna w zapytaniu, przy oczekiwanej częstotliwości zdarzeń. Znaczniki czasu zdarzeń powinny być przez cały ten czas zbliżone do rzeczywistego czasu zegarowego, tak jakby był to strumień wejściowy na żywo. Na przykład, jeśli w zapytaniu masz trzydniowe okno, wysyłaj zdarzenia do centrum zdarzeń przez trzy dni, a następnie kontynuuj ich wysyłanie.
  • Rozpocznij zadanie, używając teraz jako godziny rozpoczęcia.
  • Zmierz czas między rozpoczęciem a momentem, gdy zadanie generuje pierwszy wynik. Ten czas w przybliżeniu oznacza opóźnienie, jakiego doświadcza zadanie podczas aktualizacji usługi.
  • Jeśli opóźnienie jest zbyt długie, spróbuj podzielić pracę na części i zwiększyć liczbę jednostek streamingowych, aby obciążenie rozłożyło się na więcej węzłów. Alternatywnie rozważ zmniejszenie rozmiaru okien w zapytaniu oraz przeprowadzenie dalszej agregacji lub innego przetwarzania stanowego na danych wyjściowych generowanych przez zadanie Stream Analytics w docelowym ujściu danych (na przykład przy użyciu usługi Azure SQL Database).

W przypadku ogólnych problemów ze stabilnością usługi podczas uaktualniania zadań o znaczeniu krytycznym rozważ uruchomienie zduplikowanych zadań w sparowanych regionach świadczenia usługi Azure. Aby uzyskać więcej informacji, zobacz Gwarancja niezawodności zadania usługi Stream Analytics podczas aktualizacji usługi.

Odzyskiwanie zadań po zatrzymaniu i uruchamianiu inicjowanym przez użytkownika

Aby edytować składnię zapytań w zadaniu streamingowym lub dostosować wejścia i wyjścia, musisz zatrzymać zadanie, aby dokonać zmian i zaktualizować projekt zadania. W takich sytuacjach, gdy zatrzymujesz zadanie streamingowe i uruchamiasz je od nowa, scenariusz odzyskiwania jest podobny do aktualizacji usługi.

Restart zadania inicjowanego przez użytkownika nie może korzystać z danych punktów kontrolnych. Aby oszacować opóźnienie wyjścia podczas takiego restartu, należy stosować tę samą procedurę opisaną w poprzedniej sekcji i stosować podobne środki łagodzące, jeśli opóźnienie jest zbyt długie.

Treści powiązane

Aby uzyskać więcej informacji na temat niezawodności i skalowalności, zobacz następujące artykuły:

  • Last updated on