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

  • Článek
  • 6 min ke čtení

Tento článek popisuje běžné problémy s Azure Stream Analyticsmi výstupními připojeními a postupy při řešení problémů s výstupem. Mnohé kroky pro řešení potíží vyžadují, aby se pro vaši úlohu Stream Analytics povolily prostředky a další diagnostické protokoly. Pokud nemáte Povolené protokoly prostředků, přečtěte si téma řešení potíží s Azure Stream Analytics pomocí protokolů prostředků.

Úloha nevytváří výstup.

  1. Ověřte připojení ke výstupům pomocí tlačítka Testovat připojení pro každý výstup.

  2. Podívejte se na sledování metrik na kartě monitorování . Vzhledem k tomu, že jsou hodnoty agregované, jsou metriky zpožděné o několik minut.

    • Pokud je hodnota vstupních událostí větší než nula, může úloha číst vstupní data. Pokud hodnota vstupních událostí 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 referenční datový vstup, použijte při prohlížení metriky vstupních událostí rozdělení podle logického názvu. Pokud neexistují žádné vstupní události ze samotného referenčního data, pak pravděpodobně znamená, že tento vstupní zdroj není správně nakonfigurovaný pro načtení pravé referenční datové sady.
    • Pokud je hodnota chyby převodu dat větší než nula a stoupání, přečtěte si část Azure Stream Analytics chyby dat , kde najdete podrobné informace o chybách při převodu dat.
    • Pokud je hodnota chyby běhového prostředí větší než nula, úloha přijme data, ale při zpracování dotazu generuje chyby. Chcete-li najít chyby, klikněte na protokoly auditua potom vyfiltrujte stav selhání .
    • Pokud je hodnota vstupních událostí větší než nula a výstupní události se rovná nule, jeden z následujících příkazů je pravdivý:
      • Zpracování dotazu vedlo k nulovým výstupním událostem.
      • Události nebo pole mohou být poškozeny, což po zpracování dotazu vytvoří nulový výstup.
      • Úloha nemohla odeslat data do výstupní jímky pro účely 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, jsou chyby shrnuty každých 10 minut.

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

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

Dlouhé hodnoty času v dočasných prvcích dotazů mohou přispět k zpoždění výstupu. Aby se vytvořil správný výstup v rámci velkých oken času, úloha streamování načte data z poslední možné doby k vyplnění časového okna. Data mohou být až po dobu až sedmi dnů. Žádný výstup negeneruje, dokud nebudou přečteny nezpracované vstupní události. Tento problém se může nacházet při upgradu systému na úlohy streamování. V případě, že dojde k upgradu, úloha se restartuje. K těmto inovacím obvykle dochází jednou za několik měsíců.

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

Jedním z rizik pro tento druh prvního zpoždění výstupu je použití technik paralelního dotazování, jako je vytváření oddílů dat. Nebo můžete přidat další jednotky streamování pro zlepšení propustnosti, dokud se úloha nedosáhne. Další informace najdete v tématu týkajícím se vytváření úloh Stream Analytics.

Tyto faktory ovlivňují časovou osu prvního výstupu:

  • Použití agregovaných oken, jako je například klauzule GROUP BY pro bubny, skákající a posuvná okna:

    • V případě agregací nebo skákající oken se výsledky generují na konci časového rámce okna.
    • Pro posuvné okno se výsledky generují, když událost vstoupí do posuvných oken nebo je ukončí.
    • Pokud plánujete použít velkou velikost okna, například více než jednu hodinu, je nejlepší vybrat skákající nebo posuvné okno. Tyto typy oken umožňují zobrazit výstup častěji.

  • Používání dočasná spojení, jako je například spojení s DATEDIFF:

    • Shoduje se s vygenerováním hned po doručení obou stran odpovídajících událostí.
    • Data, u kterých chybí shoda, jako je levé vnější spojení, se generují na konci okna DATEDIFF pro každou událost na levé straně.

  • Použití dočasných analytických funkcí, jako je například FIRST, LAST a LAG s TRVÁNÍm LIMITu:

    • Pro analytické funkce je výstup vygenerován pro každou událost. Nedochází k žádnému zpoždění.

Výstup spadá pod

V průběhu běžné operace úlohy může výstup trvat déle a delší dobu latence. Pokud výstup spadá do toho, jak to bude, můžete určit hlavní příčiny tím, že prozkoumáte následující faktory:

  • Bez ohledu na to, jestli je jímka pro příjem dat omezená
  • Bez ohledu na to, jestli je nadřazený zdroj omezený
  • Určuje, jestli je logika zpracování v dotazu náročná na výpočetní výkon.

Chcete-li zobrazit podrobnosti výstupu, vyberte úlohu streamování v Azure Portal a pak vyberte diagram úlohy. Pro každý vstup existuje metrika události nevyřízených položek na oddíl. Pokud se metrika stále zvyšuje, je indikátorem, že systémové prostředky jsou omezené. Zvýšení je potenciálně v důsledku omezení výstupní jímky nebo vysokého využití procesoru. Další informace najdete v tématu ladění řízené daty pomocí diagramu úloh.

upozornění na porušení klíče s výstupem Azure SQL Database

když nakonfigurujete databázi Azure SQL jako výstup do úlohy Stream Analytics, hromadně vloží záznamy do cílové tabulky. Obecně Azure Stream Analytics garantuje doručení do výstupní jímky aspoň jednou . v případě, že má SQL tabulka definované jedinečné omezení, můžete stále přecházet na výstup SQL, který je právě jednou .

když nastavíte omezení jedinečnosti klíčů pro SQL tabulku, Azure Stream Analytics odebere duplicitní záznamy. Rozdělí data do dávek a rekurzivně je vloží, dokud nebude nalezen jediný duplicitní záznam. Proces rozdělení a vložení ignoruje duplicitní hodnoty v jednom okamžiku. Pro úlohu streamování, která má mnoho duplicitních řádků, je proces neefektivní a časově náročný. pokud se v protokolu aktivit během předchozí hodiny zobrazí více výstražných zpráv o porušení klíčů, je pravděpodobný, že výstup SQL zpomaluje celou úlohu.

Chcete-li 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ých vložení. Azure SQL Database jednoduše vytvoří zprávu upozornění namísto chyby. V důsledku toho Azure Stream Analytics už nevytvářejí chyby narušení primárního klíče.

Při konfiguraci IGNORE_DUP_KEY pro několik typů indexů Pamatujte na následující poznámky:

  • Nemůžete nastavit IGNORE_DUP_KEY pro primární klíč nebo jedinečné omezení, které používá příkaz ALTER INDEX. Index je potřeba vyřadit a znovu vytvořit.
  • IGNORE_DUP_KEY můžete nastavit pomocí příkazu ALTER INDEX pro jedinečný index. Tato instance je odlišná od primárního KLÍČového a JEDINEČNÉho omezení a je vytvořena pomocí definice indexu nebo indexu.
  • Možnost IGNORE_DUP_KEY neplatí pro indexy úložiště sloupců, protože pro ně nemůžete vymáhat jedinečnost.

SQL logiky opakování výstupu

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

  1. Úloha se pokusí o připojení k SQL.
  2. Úloha načte schéma cílové tabulky.
  3. Úloha ověřuje názvy a typy sloupců oproti 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 zapisuje tabulku dat do SQL pomocí rozhraní APIBulkCopy.

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

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

    Selhání přihlášení a problémy s bránou firewall se zopakují nejméně 5 minut po předchozím pokusu a budou se opakovat, dokud nebudou úspěšné.

  • Chyby dat, jako je například přetypování chyb a porušení omezení schématu, jsou zpracovávány s výstupními zásadami chyb. Tyto chyby jsou zpracovávány opakováním binárních rozdělených dávek, dokud konkrétní záznam nezpůsobující chybu nebude zpracován pomocí akce přeskočit nebo opakovat. Primární porušení omezení jedinečnosti klíčů je vždy zpracováváno.

  • k nepřechodným chybám může dojít, když dojde k potížím se službou SQL nebo interním kódem. Například pokud chyby například (kód 1132) Elastický fond zasáhne limit úložiště, nevyřeší opakované pokusy chybu. V těchto scénářích se Stream Analytics úlohy degradují.

  • BulkCopy k vypršení časového limitu může dojít BulkCopy v kroku 5. BulkCopy může občas docházet k časovým limitům operací. Výchozí minimální nakonfigurovaný časový limit je pět minut a při následném volání se zdvojnásobí. Jakmile je časový limit vyšší než 15 minut, je maximální velikost pomocného parametru dávky BulkCopy snížena na polovinu, dokud nebudou 100 události na dávku ponechány.

Názvy sloupců jsou malými písmeny v Azure Stream Analytics (1,0)

Při použití původní úrovně kompatibility (1,0) Azure Stream Analytics změny názvů sloupců na malá písmena. Toto chování bylo opraveno v novějších úrovních kompatibility. Pokud chcete 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 chcete získat další pomoc, vyzkoušejte si naši stránku Microsoft Q&Azure Stream Analytics.

Další kroky