Pojęcia dotyczące punktów kontrolnych i odtwarzania w zadaniach usługi Azure Stream Analytics
W tym artykule opisano wewnętrzne pojęcia dotyczące punktu kontrolnego i powtórek w usłudze Azure Stream Analytics oraz wpływ, który mają na odzyskiwanie zadania. Za każdym razem, gdy zadanie usługi Stream Analytics jest uruchamiane, informacje o stanie są przechowywane wewnętrznie. Informacje o stanie są okresowo zapisywane w punkcie kontrolnym. W niektórych scenariuszach informacje o punkcie kontrolnym są używane do odzyskiwania zadania w przypadku niepowodzenia lub uaktualnienia zadania. W innych okolicznościach nie można użyć punktu kontrolnego do odzyskania, a powtórka jest konieczna.
Logika zapytań stanowych w elementach czasowych
Jedną z unikatowych funkcji 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 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:
Agregacje okienne (GROUP BY of Tumbling, Hopping i Sliding windows)
Sprzężenia czasowe (JOIN with DATEDIFF)
Funkcje analityczne czasowe (ISFIRST, LAST i LAG z LIMIT DURATION)
Odzyskiwanie zadania po awarii węzła, w tym uaktualnianie systemu operacyjnego
Za każdym razem, gdy zadanie usługi Stream Analytics jest uruchamiane, jest skalowane wewnętrznie w poziomie, aby wykonać pracę w wielu węzłach roboczych. Stan każdego węzła roboczego jest punktów kontrolnych co kilka minut, co pomaga systemowi odzyskać sprawność w przypadku wystąpienia awarii.
Czasami dany węzeł roboczy może zakończyć się niepowodzeniem lub może wystąpić uaktualnienie systemu operacyjnego dla tego węzła roboczego. Aby odzyskać sprawne automatycznie, usługa Stream Analytics uzyskuje nowy węzeł w dobrej kondycji, a stan poprzedniego węzła procesu roboczego jest przywracany z najnowszego dostępnego punktu kontrolnego. Aby wznowić pracę, konieczna jest niewielka ilość powtórzeń w celu przywrócenia stanu od momentu wykonania punktu kontrolnego. Zwykle przerwa w przywracaniu wynosi tylko kilka minut. Po wybraniu wystarczającej liczby jednostek przesyłania strumieniowego dla zadania należy szybko ukończyć powtórkę.
W zapytaniu w pełni równoległym czas nadrobienia zaległości po awarii węzła procesu roboczego jest proporcjonalny do następujących elementów:
[szybkość zdarzeń wejściowych] x [długość luki] / [liczba partycji przetwarzania]
Jeśli kiedykolwiek zaobserwujesz znaczne opóźnienie przetwarzania z powodu awarii węzła i uaktualnienia systemu operacyjnego, rozważ wykonanie zapytania w pełni równoległego i przeskalowanie zadania w celu przydzielenia większej liczby jednostek przesyłania strumieniowego. Aby uzyskać więcej informacji, zobacz Skalowanie zadania usługi Azure Stream Analytics w celu zwiększenia przepływności.
Bieżąca usługa Stream Analytics nie wyświetla raportu, gdy odbywa się ten rodzaj procesu 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 tym czasie zadania uruchomione przez użytkowników są uaktualniane do nowszej wersji, a zadanie jest automatycznie uruchamiane ponownie.
Usługa Azure Stream Analytics używa punktów kontrolnych tam, gdzie to możliwe, aby przywrócić dane z ostatniego stanu punktu kontrolnego. W scenariuszach, w których nie można używać wewnętrznych punktów kontrolnych, stan zapytania przesyłania strumieniowego jest przywracany całkowicie przy użyciu techniki odtwarzania. Aby umożliwić zadania usługi Stream Analytics ponowne odtwarzanie dokładnie tych samych danych wejściowych z poprzednich, należy ustawić zasady przechowywania danych źródłowych na co najmniej rozmiar okna w zapytaniu. Nie można tego zrobić, może spowodować nieprawidłowe lub częściowe wyniki podczas uaktualniania usługi, ponieważ dane źródłowe mogą nie być przechowywane wystarczająco daleko, aby 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 z szybkością wprowadzania wynoszącą 1000 zdarzeń na sekundę rozmiar okna większy niż jedna godzina jest uznawany za duży rozmiar odtwarzania. Do jednej godziny może być konieczne ponowne przetworzenie danych w celu zainicjowania stanu, aby mogły one wygenerować pełne i poprawne wyniki, co może spowodować opóźnienie danych wyjściowych (brak danych wyjściowych) przez dłuższy czas. Kwerendy bez okien lub innych operatorów czasowych, takich jak JOIN lub LAG, miałyby zero powtórki.
Szacowanie czasu nadrobienia zaległości
Aby oszacować długość opóźnienia z powodu uaktualnienia usługi, możesz wykonać następującą technikę:
Załaduj dane wejściowe usługi Event Hubs z wystarczającą ilością danych, aby pokryć największy rozmiar okna w zapytaniu z oczekiwaną szybkością zdarzeń. Znacznik czasu zdarzeń powinien być zbliżony do czasu zegara ściany w tym okresie, jakby był to kanał wejściowy na żywo. Jeśli na przykład masz 3-dniowe okno zapytania, wyślij zdarzenia do usługi Event Hubs przez trzy dni i kontynuuj wysyłanie zdarzeń.
Uruchom zadanie przy użyciu polecenia Teraz jako godziny rozpoczęcia.
Zmierz czas między godziną rozpoczęcia a momentem wygenerowania pierwszych danych wyjściowych. Czas jest przybliżony, ile opóźnienia zadania zostanie naliczone podczas uaktualniania usługi.
Jeśli opóźnienie jest zbyt długie, spróbuj podzielić zadanie na partycje i zwiększyć liczbę jednostek SU, więc obciążenie jest rozłożone na więcej węzłów. Alternatywnie rozważ zmniejszenie rozmiarów okien w zapytaniu i przeprowadzenie dalszej agregacji lub innego przetwarzania stanowego na danych wyjściowych generowanych przez zadanie usługi Stream Analytics w ujściu podrzędnym (na przykład przy użyciu usługi Azure SQL Database).
W przypadku ogólnych problemów ze stabilnością usług 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 zadania od użytkownika zainicjowało zatrzymywanie i uruchamianie
Aby edytować składnię zapytania w zadaniu przesyłania strumieniowego lub dostosować dane wejściowe i wyjściowe, zadanie musi zostać zatrzymane, aby wprowadzić zmiany i uaktualnić projekt zadania. W takich scenariuszach, gdy użytkownik zatrzymuje zadanie przesyłania strumieniowego i uruchamia je ponownie, scenariusz odzyskiwania jest podobny do uaktualnienia usługi.
Nie można używać danych punktu kontrolnego na potrzeby ponownego uruchamiania zadania zainicjowanego przez użytkownika. Aby oszacować opóźnienie danych wyjściowych podczas takiego ponownego uruchomienia, użyj tej samej procedury, co opisano w poprzedniej sekcji, i zastosuj podobne środki zaradcze, jeśli opóźnienie jest zbyt długie.
Następne kroki
Aby uzyskać więcej informacji na temat niezawodności i skalowalności, zobacz następujące artykuły: