Řešení potíží s výstupy Azure Stream Analytics

  • Článek

Tento článek popisuje běžné problémy s výstupními připojeními Azure Stream Analytics a řešení potíží s výstupem. Řada kroků pro řešení potíží vyžaduje povolení prostředků a dalších diagnostických protokolů pro vaši úlohu Stream Analytics. Pokud nemáte povolené protokoly prostředků, přečtěte si téma Řešení potíží se službou Azure Stream Analytics pomocí protokolů prostředků.

Úloha nevygeneruje výstup.

  1. Pomocí tlačítka Test Připojení ion pro každý výstup ověřte připojení k výstupům.

  2. Podívejte se na úlohu Monitorování Stream Analytics pomocí webu Azure Portal na kartě Monitorování . Vzhledem k tomu, že se hodnoty agregují, metriky se zpozdí o několik minut.

    • Pokud je hodnota Vstupní události větší než nula, může úloha číst vstupní data. Pokud hodnota Vstupní události není větší než nula, dojde k problému se vstupem úlohy. Další informace najdete v tématu Řešení potíží se vstupními připojeními . Pokud má vaše úloha vstup referenčních dat, při pohledu na metriku Vstupní události použijte rozdělení podle logického názvu. Pokud neexistují žádné vstupní události ze samotných referenčních dat, znamená to pravděpodobně, že tento vstupní zdroj není správně nakonfigurovaný tak, aby načítá správnou referenční datovou sadu.
    • Pokud je hodnota Chyby převodu dat větší než nula a lezení, přečtěte si podrobnosti o chybách převodu dat v Azure Stream Analytics.
    • Pokud je hodnota Chyby za běhu větší než nula, vaše úloha obdrží data, ale při zpracování dotazu vygeneruje chyby. Pokud chcete najít chyby, přejděte do protokolů auditu a pak vyfiltrujte stav Selhání .
    • Pokud je hodnota Vstupní události větší než nula a hodnota Výstupní události se rovná nule, platí jeden z následujících příkazů:
      • Zpracování dotazů vedlo k nulovým výstupním událostem.
      • Události nebo pole můžou být špatně formátované, což vede k nulovému výstupu po zpracování dotazu.
      • Úloha nemohla odesílat data do výstupní jímky z důvodů připojení nebo ověřování.

    Zprávy protokolu operací vysvětlují další podrobnosti, včetně toho, co se děje, s výjimkou případů, kdy logika dotazu filtruje všechny události. Pokud zpracování více událostí generuje chyby, chyby se agregují každých 10 minut.

První výstup je zpožděný.

Při spuštění úlohy Stream Analytics se načtou vstupní události. V některých případech ale může dojít ke zpoždění výstupu.

Velké časové hodnoty v elementech dočasného dotazu můžou přispět ke zpoždění výstupu. Aby se ve velkých časových oknech vytvořil správný výstup, úloha streamování čte data z posledního možného časového intervalu. Data můžou být za posledních 7 dnů. Dokud se nepřečtou nevyřízené vstupní události, nevygeneruje se žádný výstup. Tento problém se může zobrazit, když systém upgraduje úlohy streamování. Po provedení upgradu se úloha restartuje. K takovým upgradům obvykle dochází jednou za několik měsíců.

Při návrhu dotazu Stream Analytics použijte vlastní uvážení. Pokud použijete velké časové okno pro dočasné prvky v syntaxi dotazu úlohy, může to vést ke zpoždění prvního výstupu při spuštění nebo restartování úlohy. Více než několik hodin, až sedm dní, je považováno za velké časové období.

Jedním z omezení tohoto druhu prvního zpoždění výstupu je použití technik paralelizace dotazů, jako je dělení dat. Nebo můžete přidat další jednotky streamování, abyste zlepšili propustnost, dokud úloha nezachytí. Další informace najdete v tématu Důležité informace o vytváření úloh Stream Analytics.

Tyto faktory ovlivňují aktuálnost prvního výstupu:

  • Použití agregací s okny, jako je klauzule GROUP BY pro přeskakující, přeskakování a posuvná okna:

    • Pokud chcete agregovat přeskakující nebo přeskakující okno, vygenerují se výsledky na konci časového rámce okna.
    • V případě posuvného okna se výsledky vygenerují, když událost vstoupí nebo ukončí posuvné okno.
    • Pokud plánujete použít velkou velikost okna, například více než hodinu, je nejlepší zvolit skákání nebo posuvné okno. Tyto typy oken umožňují zobrazit výstup častěji.

  • Použití dočasných spojení, například JOIN s DATEDIFF:

    • Odpovídá vygenerování, jakmile přijdou obě strany odpovídajících událostí.
    • Data, která nemají shodu, například LEFT OUTER JOIN, se generují na konci okna DATEDIFF pro každou událost na levé straně.

  • Použití dočasných analytických funkcí, jako jsou ISFIRST, LAST a LAG s LIMIT DURATION:

    • Pro analytické funkce se výstup vygeneruje pro každou událost. Neexistuje žádné zpoždění.

Výstup se zapadá

Během normálního provozu úlohy může výstup mít delší a delší období latence. Pokud se výstup za tímto způsobem zapadne, můžete určit původní příčiny prozkoumáním následujících faktorů:

  • Zda je podřízená jímka omezena
  • Určuje, jestli je nadřazený zdroj omezený.
  • Určuje, jestli je logika zpracování v dotazu náročná na výpočetní výkon.

Pokud chcete zobrazit podrobnosti výstupu, vyberte úlohu streamování na webu Azure Portal a pak vyberte Diagram úlohy. Pro každý vstup existuje metrika událostí backlogu pro každý oddíl. Pokud se metrika stále zvyšuje, je to indikátor, že systémové prostředky jsou omezené. Zvýšení je potenciálně způsobené omezováním výstupní jímky nebo vysokým využitím procesoru. Další informace naleznete v tématu Ladění řízené daty pomocí diagramu úloh.

Upozornění na porušení klíče s výstupem služby Azure SQL Database

Když nakonfigurujete databázi Azure SQL jako výstup pro úlohu Stream Analytics, hromadně vloží záznamy do cílové tabulky. Obecně platí, že Azure Stream Analytics zaručuje alespoň jedno doručení do výstupní jímky. Pokud má tabulka SQL definované jedinečné omezení, můžete do výstupu SQL dosáhnout přesně jednou .

Když nastavíte omezení jedinečných klíčů v tabulce SQL, Azure Stream Analytics odebere duplicitní záznamy. Rozdělí data do dávek a rekurzivně vloží dávky, dokud se nenajde jeden duplicitní záznam. Proces rozdělení a vložení ignoruje duplicity po jednom. U úlohy streamování, která má mnoho duplicitních řádků, je proces neefektivní a časově náročný. Pokud se v protokolu aktivit zobrazuje několik zpráv upozornění na porušení klíče za předchozí hodinu, je pravděpodobné, že výstup SQL zpomaluje celou úlohu.

Pokud chcete tento problém vyřešit, nakonfigurujte index, který způsobuje porušení klíče, povolením možnosti IGNORE_DUP_KEY. Tato možnost umožňuje SQL ignorovat duplicitní hodnoty během hromadného vkládání. Azure SQL Database místo chyby jednoduše vygeneruje zprávu s upozorněním. V důsledku toho už Azure Stream Analytics nevygeneruje chyby porušení primárního klíče.

Při konfiguraci IGNORE_DUP_KEY pro několik typů indexů si všimněte následujících pozorování:

  • U primárního klíče nebo jedinečného omezení, které používá alter INDEX, nemůžete nastavit IGNORE_DUP_KEY. Index musíte vypustit a vytvořit ho znovu.
  • IGNORE_DUP_KEY můžete nastavit pomocí funkce ALTER INDEX pro jedinečný index. Tato instance se liší od omezení PRIMARY KEY/UNIQUE a vytváří se pomocí definice CREATE INDEX nebo INDEX.
  • Možnost IGNORE_DUP_KEY se nevztahuje na indexy úložiště sloupců, protože u nich nemůžete vynutit jedinečnost.

Logika opakování výstupu SQL

Když úloha Stream Analytics s výstupem SQL obdrží první dávku událostí, dojde k následujícím krokům:

  1. Úloha se pokusí připojit k SQL.
  2. Úloha načte schéma cílové tabulky.
  3. Úloha ověří názvy a typy sloupců ve schématu cílové tabulky.
  4. Úloha připraví tabulku dat v paměti z výstupních záznamů v dávce.
  5. Úloha zapíše tabulku dat do SQL pomocí rozhraní BulkCopy API.

Během těchto kroků může výstup SQL zaznamenat následující typy chyb:

  • Přechodné chyby , které se opakují pomocí exponenciální strategie opakování opakování. Minimální interval opakování závisí na individuálním kódu chyby, ale intervaly jsou obvykle kratší než 60 sekund. Horní limit může být maximálně pět minut.

    Chyby přihlášení a problémy s bránou firewall se opakují aspoň 5 minut po předchozím pokusu a opakují se, dokud nebudou úspěšné.

  • Chyby dat, jako jsou chyby přetypování a porušení omezení schématu, se zpracovávají pomocí zásad chyb výstupu. Tyto chyby se zpracovávají opakovaným pokusem o binární rozdělení dávek, dokud jednotlivý záznam způsobující chybu nezpracuje přeskočením nebo opakováním. Porušení omezení primárního jedinečného klíče se vždy zpracovává.

  • K ne přechodným chybám může dojít v případech, kdy dochází k problémům se službou SQL nebo interním chybám kódu. Pokud například chyby typu (kód 1132) elastického fondu dosáhne limitu úložiště, nevyřešují chyby opakování. V těchto scénářích dochází ke snížení výkonu úloh Stream Analytics.

  • BulkCopy K vypršení časových limitů může dojít během BulkCopy kroku 5. BulkCopy může občas dojít k vypršení časového limitu operace. Výchozí minimální nakonfigurovaný časový limit je pět minut a při po sobě jdoucím dosažení se zdvojnásobí. Po vypršení časového limitu nad 15 minut se maximální velikost BulkCopy dávky sníží na polovinu, dokud nezůstane 100 událostí na dávku.

    Důležité

    V případě nesítěných úloh ASA se nespoléhejte na zdrojovou IP adresu připojení přicházejících z ASA žádným způsobem. Můžou to být veřejné nebo privátní IP adresy v závislosti na operacích infrastruktury služeb, ke kterým dochází od času.

Názvy sloupců jsou v Azure Stream Analytics malými písmeny (1.0).

Při použití původní úrovně kompatibility (1.0) azure Stream Analytics změní názvy sloupců na malá písmena. Toto chování bylo opraveno v pozdějších úrovních kompatibility. Chcete-li zachovat případ, přejděte na úroveň kompatibility 1.1 nebo novější. Další informace najdete v tématu Úroveň kompatibility pro úlohy Stream Analytics.

Získání pomoci

Pokud potřebujete další pomoc, vyzkoušejte naši stránku pro otázky Microsoftu pro Azure Stream Analytics.

Další kroky