Rozwiązywanie problemów z danymi wyjściowymi usługi Azure Stream Analytics

  • Artykuł

W tym artykule opisano typowe problemy z połączeniami wyjściowymi usługi Azure Stream Analytics i sposoby rozwiązywania problemów z danymi wyjściowymi. Wiele kroków rozwiązywania problemów wymaga włączenia zasobów i innych dzienników diagnostycznych dla zadania usługi Stream Analytics. Jeśli nie masz włączonych dzienników zasobów, zobacz Rozwiązywanie problemów z usługą Azure Stream Analytics przy użyciu dzienników zasobów.

Zadanie nie generuje danych wyjściowych

  1. Sprawdź łączność z danymi wyjściowymi przy użyciu przycisku Testuj Połączenie ion dla poszczególnych danych wyjściowych.

  2. Zapoznaj się z tematem Monitorowanie zadania usługi Stream Analytics za pomocą witryny Azure Portal na karcie Monitorowanie . Ponieważ wartości są agregowane, metryki są opóźnione o kilka minut.

    • Jeśli wartość Zdarzenia wejściowe jest większa niż zero, zadanie może odczytać dane wejściowe. Jeśli wartość Zdarzenia wejściowe nie jest większa niż zero, występuje problem z danymi wejściowymi zadania. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z połączeniami wejściowymi . Jeśli zadanie ma dane wejściowe danych referencyjnych, zastosuj dzielenie według nazwy logicznej podczas przeglądania metryki Zdarzenia wejściowe. Jeśli nie ma żadnych zdarzeń wejściowych z danych referencyjnych, prawdopodobnie oznacza to, że to źródło wejściowe nie zostało prawidłowo skonfigurowane do pobrania odpowiedniego zestawu danych referencyjnych.
    • Jeśli wartość Błędy konwersji danych jest większa niż zero i wspinaczka, zobacz Błędy danych usługi Azure Stream Analytics, aby uzyskać szczegółowe informacje o błędach konwersji danych.
    • Jeśli wartość Błędy środowiska uruchomieniowego jest większa niż zero, zadanie odbiera dane, ale generuje błędy podczas przetwarzania zapytania. Aby znaleźć błędy, przejdź do dzienników inspekcji, a następnie przefiltruj stan Niepowodzenie .
    • Jeśli wartość Zdarzenia wejściowe jest większa niż zero, a wartość Zdarzenia wyjściowe równa zero, jedna z następujących instrukcji ma wartość true:
      • Przetwarzanie zapytania spowodowało zero zdarzeń wyjściowych.
      • Zdarzenia lub pola mogą być źle sformułowane, co powoduje zero danych wyjściowych po przetworzeniu zapytania.
      • Zadanie nie mogło wypchnąć danych do ujścia danych wyjściowych ze względów łączności lub uwierzytelniania.

    Komunikaty dziennika operacji wyjaśniają dodatkowe szczegóły, w tym informacje o tym, co się dzieje, z wyjątkiem przypadków, w których logika zapytania filtruje wszystkie zdarzenia. Jeśli przetwarzanie wielu zdarzeń generuje błędy, błędy agregują się co 10 minut.

Pierwsze dane wyjściowe są opóźnione

Po uruchomieniu zadania usługi Stream Analytics zdarzenia wejściowe są odczytywane. Jednak w pewnych okolicznościach może wystąpić opóźnienie w danych wyjściowych.

Duże wartości czasu w elementach zapytania czasowego mogą przyczynić się do opóźnienia danych wyjściowych. Aby wygenerować poprawne dane wyjściowe w dużych przedziałach czasu, zadanie przesyłania strumieniowego odczytuje dane z najnowszego możliwego czasu wypełnienia przedziału czasu. Dane mogą trwać do siedmiu dni. Żadne dane wyjściowe nie są generowane do momentu odczytania zaległych zdarzeń wejściowych. Ten problem może wystąpić, gdy system uaktualnia zadania przesyłania strumieniowego. Po uaktualnieniu zadanie zostanie uruchomione ponownie. Takie uaktualnienia są zwykle wykonywane raz na kilka miesięcy.

Użyj uznania podczas projektowania zapytania usługi Stream Analytics. Jeśli używasz dużego przedziału czasu dla elementów czasowych w składni zapytania zadania, może to prowadzić do opóźnienia w pierwszych danych wyjściowych po uruchomieniu lub ponownym uruchomieniu zadania. Ponad kilka godzin, do siedmiu dni, jest uważane za duże przedziały czasu.

Jednym z środków zaradczych dla tego rodzaju pierwszego opóźnienia danych wyjściowych jest użycie technik przetwarzania równoległego zapytań, takich jak partycjonowanie danych. Możesz też dodać więcej jednostek przesyłania strumieniowego, aby zwiększyć przepływność, dopóki zadanie nie dogoni. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące tworzenia zadań usługi Stream Analytics.

Te czynniki wpływają na osie czasu pierwszych danych wyjściowych:

  • Zastosowanie agregacji okiennych, takich jak klauzula GROUP BY wirowania, przeskoków i okien przesuwnych:

    • W przypadku agregacji okien stałoczasowych lub przeskoków wyniki są generowane na końcu przedziału czasu okna.
    • W przypadku okna przesuwanego wyniki są generowane po wejściu zdarzenia lub zamknięciu okna przesuwnego.
    • Jeśli planujesz użyć dużego rozmiaru okna, takiego jak więcej niż jedna godzina, najlepiej wybrać okno przeskoku lub przesuwane. Te typy okien umożliwiają częstsze wyświetlanie danych wyjściowych.

  • Użycie sprzężeń czasowych, takich jak JOIN z DATEDIFF:

    • Dopasowania są generowane zaraz po obu stronach dopasowanych zdarzeń.
    • Dane, które nie mają dopasowania, na przykład LEFT OUTER JOIN, są generowane na końcu okna DATEDIFF dla każdego zdarzenia po lewej stronie.

  • Zastosowanie funkcji analitycznych czasowych, takich jak ISFIRST, LAST i LAG z limitem czasu trwania:

    • W przypadku funkcji analitycznych dane wyjściowe są generowane dla każdego zdarzenia. Nie ma opóźnienia.

Dane wyjściowe spadają w tyle

Podczas normalnego działania zadania dane wyjściowe mogą mieć dłuższe i dłuższe okresy opóźnienia. Jeśli dane wyjściowe spadną w tyle, możesz wskazać główne przyczyny, sprawdzając następujące czynniki:

  • Czy ujście podrzędne jest ograniczane
  • Czy źródło nadrzędne jest ograniczane
  • Czy logika przetwarzania w zapytaniu jest intensywnie obciążana obliczeniami

Aby wyświetlić szczegóły danych wyjściowych, wybierz zadanie przesyłania strumieniowego w witrynie Azure Portal, a następnie wybierz pozycję Diagram zadań. Dla każdego danych wejściowych istnieje metryka zdarzeń listy prac na partycję. Jeśli metryka stale rośnie, oznacza to, że zasoby systemowe są ograniczone. Wzrost jest potencjalnie spowodowany ograniczaniem przepustowości ujścia danych wyjściowych lub wysokim użyciem procesora CPU. Aby uzyskać więcej informacji, zobacz Debugowanie oparte na danych przy użyciu diagramu zadań.

Ostrzeżenie o naruszeniu klucza przy użyciu danych wyjściowych usługi Azure SQL Database

Podczas konfigurowania bazy danych Azure SQL Database jako danych wyjściowych zadania usługi Stream Analytics jest ona zbiorczo wstawiana do tabeli docelowej. Ogólnie rzecz biorąc, usługa Azure Stream Analytics gwarantuje co najmniej jednokrotne dostarczanie do ujścia danych wyjściowych. Nadal można osiągnąć dokładnie jednokrotne dostarczanie do danych wyjściowych SQL, gdy tabela SQL ma zdefiniowane unikatowe ograniczenie.

Podczas konfigurowania unikatowych ograniczeń klucza w tabeli SQL usługa Azure Stream Analytics usuwa zduplikowane rekordy. Dzieli ona dane na partie i rekursywnie wstawia partie do momentu znalezienia pojedynczego zduplikowanego rekordu. Proces dzielenia i wstawiania ignoruje duplikaty pojedynczo. W przypadku zadania przesyłania strumieniowego zawierającego wiele zduplikowanych wierszy proces jest nieefektywny i czasochłonny. Jeśli w dzienniku aktywności jest wyświetlanych wiele komunikatów ostrzegawczych o naruszeniach klucza w ciągu poprzedniej godziny, prawdopodobnie dane wyjściowe SQL spowalniają całe zadanie.

Aby rozwiązać ten problem, skonfiguruj indeks powodujący naruszenie klucza, włączając opcję IGNORE_DUP_KEY. Ta opcja umożliwia programowi SQL ignorowanie zduplikowanych wartości podczas wstawiania zbiorczego. Usługa Azure SQL Database po prostu generuje komunikat ostrzegawczy zamiast błędu. W związku z tym usługa Azure Stream Analytics nie generuje już błędów naruszenia klucza podstawowego.

Podczas konfigurowania IGNORE_DUP_KEY dla kilku typów indeksów należy zwrócić uwagę na następujące obserwacje:

  • Nie można ustawić IGNORE_DUP_KEY na klucz podstawowy lub unikatowe ograniczenie używające alter INDEX. Musisz usunąć indeks i utworzyć go ponownie.
  • Można ustawić IGNORE_DUP_KEY przy użyciu polecenia ALTER INDEX dla unikatowego indeksu. To wystąpienie różni się od ograniczenia KLUCZ PODSTAWOWY/UNIKATOWY i jest tworzone przy użyciu definicji CREATE INDEX lub INDEX.
  • Opcja IGNORE_DUP_KEY nie ma zastosowania do indeksów magazynu kolumn, ponieważ nie można wymusić na nich unikatowości.

Logika ponawiania prób danych wyjściowych SQL

Gdy zadanie usługi Stream Analytics z danymi wyjściowymi SQL odbiera pierwszą partię zdarzeń, są wykonywane następujące kroki:

  1. Zadanie próbuje nawiązać połączenie z bazą danych SQL.
  2. Zadanie pobiera schemat tabeli docelowej.
  3. Zadanie weryfikuje nazwy i typy kolumn względem schematu tabeli docelowej.
  4. Zadanie przygotowuje tabelę danych w pamięci z rekordów wyjściowych w partii.
  5. Zadanie zapisuje tabelę danych w języku SQL przy użyciu interfejsu API bulkCopy.

W tych krokach dane wyjściowe SQL mogą wystąpić następujące typy błędów:

  • Błędy przejściowe, które są ponawiane przy użyciu strategii ponawiania prób wykładniczego wycofywania. Minimalny interwał ponawiania prób zależy od indywidualnego kodu błędu, ale interwały są zwykle mniejsze niż 60 sekund. Górny limit może wynosić co najwyżej pięć minut.

    Błędy logowania i problemy z zaporą są ponawiane co najmniej 5 minut po poprzedniej próbie i są ponawiane, dopóki nie powiedzie się.

  • Błędy danych, takie jak błędy rzutowania i naruszenia ograniczeń schematu, są obsługiwane przy użyciu zasad błędów wyjściowych. Te błędy są obsługiwane przez ponowienie próby dzielenia partii binarnych do momentu, gdy pojedynczy rekord powodujący błąd jest obsługiwany przez pomijanie lub ponawianie próby. Naruszenie ograniczeń klucza unikatowego podstawowego jest zawsze obsługiwane.

  • Błędy nie przejściowe mogą wystąpić, gdy występują problemy z usługą SQL lub wewnętrzne błędy kodu. Jeśli na przykład błędy takie jak (kod 1132) Elastycznej puli osiąga limit magazynu, ponowne próby nie powodują usunięcia błędu. W tych scenariuszach pogorszenie środowiska zadań usługi Stream Analytics.

  • BulkCopy Przekroczenia limitu czasu mogą wystąpić w BulkCopy kroku 5. BulkCopy czasami mogą wystąpić przekroczenia limitu czasu operacji. Domyślny minimalny skonfigurowany limit czasu wynosi pięć minut i jest dwukrotnie dwukrotny po kolejnych trafieniach. Po przekroczeniu limitu czasu powyżej 15 minut maksymalna wskazówka BulkCopy rozmiaru partii zostanie zmniejszona do połowy do 100 zdarzeń na partię.

    Ważne

    W przypadku zadań asa z iniekcją nienależącą do sieci nie należy w żaden sposób polegać na źródłowym adresie IP połączeń pochodzących z usługi ASA. Mogą to być publiczne lub prywatne adresy IP w zależności od operacji infrastruktury usług, które są wykonywane od czasu do czasu.

Nazwy kolumn są małymi literami w usłudze Azure Stream Analytics (1.0)

W przypadku korzystania z oryginalnego poziomu zgodności (1.0) usługa Azure Stream Analytics zmienia nazwy kolumn na małe litery. To zachowanie zostało naprawione w późniejszych poziomach zgodności. Aby zachować przypadek, przejdź do poziomu zgodności 1.1 lub nowszego. Aby uzyskać więcej informacji, zobacz Poziom zgodności zadań usługi Stream Analytics.

Uzyskaj pomoc

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

Następne kroki