Felsöka Azure Stream Analytics utdata

  • Artikel
  • 6 minuter för att läsa

Den här artikeln beskriver vanliga problem med att Azure Stream Analytics utdataanslutningar och hur du felsöker utdataproblem. Många felsökningssteg kräver att resursloggar och andra diagnostikloggar är aktiverade för Stream Analytics jobb. Om du inte har aktiverat resursloggar kan du gå till Felsöka Azure Stream Analytics med hjälp av resursloggar.

Jobbet producerar inte utdata

  1. Kontrollera anslutningen till utdata med knappen Testa anslutning för varje utdata.

  2. Titta på Övervakningsmått på fliken Övervaka. Eftersom värdena aggregeras fördröjs måtten med några minuter.

    • Om värdet för Indatahändelser är större än noll kan jobbet läsa indata. Om värdet för Indatahändelser inte är större än noll finns det ett problem med jobbets indata. Mer information finns i Felsöka indataanslutningar. Om jobbet har referensdataindata kan du använda delning efter logiskt namn när du tittar på måttet Indatahändelser. Om det inte finns några indatahändelser enbart från dina referensdata innebär det sannolikt att den här indatakällan inte har konfigurerats korrekt för att hämta rätt referensdatauppsättning.
    • Om värdet för Datakonverteringsfel är större än noll och gå upp i Azure Stream Analytics datafel för detaljerad information om datakonverteringsfel.
    • Om värdet För körningsfel är större än noll tar jobbet emot data men genererar fel när frågan bearbetas. Om du vill hitta felen går du till granskningsloggarnaoch filtrerar sedan på statusen Misslyckades.
    • Om värdet för Indatahändelser är större än noll och värdet För utdatahändelser är lika med noll är något av följande uttryck sant:
      • Frågebearbetningen resulterade i noll utdatahändelser.
      • Händelser eller fält kan vara felaktiga, vilket resulterar i noll utdata efter frågebearbetningen.
      • Jobbet kunde inte skicka data till utdata-mottagaren av anslutnings- eller autentiseringsskäl.

    Meddelanden i driftloggen förklarar ytterligare information, inklusive vad som händer, förutom i fall där frågelogiken filtrerar bort alla händelser. Om bearbetningen av flera händelser genererar fel aggregeras felen var 10:e minut.

De första utdata fördröjs

När ett Stream Analytics startar läses indatahändelserna. Men det kan finnas en fördröjning i utdata i vissa fall.

Stora tidsvärden i temporala frågeelement kan bidra till utdatafördröjningen. För att skapa rätt utdata över stora tidsfönster läser det strömmande jobbet data från den senaste möjliga tiden för att fylla tidsfönstret. Data kan vara upp till sju dagar tidigare. Inga utdata genererar förrän utestående indatahändelser läses. Det här problemet kan framtändas när systemet uppgraderar strömningsjobben. När en uppgradering sker startas jobbet om. Sådana uppgraderingar sker vanligtvis en gång varannan månad.

Använd diskretion när du utformar Stream Analytics fråga. Om du använder ett stort tidsfönster för temporala element i jobbets frågesyntax kan det leda till en fördröjning i de första utdata när jobbet startar eller startas om. Mer än flera timmar, upp till sju dagar, anses vara ett stort tidsfönster.

En åtgärd för den här typen av första utdatafördröjning är att använda tekniker för frågeparallellisering, till exempel partitionering av data. Eller så kan du lägga till fler enheter för strömning för att förbättra dataflödet tills jobbet ikapp. Mer information finns i Överväganden när du skapar Stream Analytics jobb.

Dessa faktorer påverkar tidslinjerna för de första utdata:

  • Användning av fönsterade aggregeringar, till exempel en GROUP BY-sats för rullande fönster, hoppande fönster och skjutfönster:

    • För aggregeringar av rullande eller hoppande fönster genereras resultatet i slutet av tidsperioden för fönstret.
    • För ett skjutfönster genererar resultatet när en händelse kommer in i eller lämnar skjutfönstret.
    • Om du planerar att använda en stor fönsterstorlek, till exempel mer än en timme, är det bäst att välja ett hoppande eller skjutfönster. Med dessa fönstertyper kan du se utdata oftare.

  • Användning av temporala kopplingar, till exempel JOIN med DATEDIFF:

    • Matchningar genereras så fort båda sidor av de matchade händelserna anländer.
    • Data som saknar en matchning, t.ex. VÄNSTER YTTRE KOPPLING, genereras i slutet av DATEDIFF-fönstret för varje händelse till vänster.

  • Användning av tidsbestämda analysfunktioner, till exempel ISFIRST, LAST och LAG med LIMIT DURATION(VARAKTIGHET):

    • För analysfunktioner genereras utdata för varje händelse. Det finns ingen fördröjning.

Utdata ligger efter

Under normal drift av ett jobb kan utdata ha längre och längre svarstider. Om utdata hamnar efter så här kan du hitta rotorsakerna genom att undersöka följande faktorer:

  • Om den underordnade mottagaren är begränsad
  • Om den överordnade källan är begränsad
  • Om bearbetningslogiken i frågan är beräkningsintensiv

Om du vill se utdatainformationen väljer du strömningsjobbet i Azure Portal och väljer sedan Jobbdiagram. För varje indata finns det ett händelsemått för kommande uppgifter per partition. Om måttet fortsätter att öka är det en indikator på att systemresurserna är begränsade. Ökningen kan bero på utdatabegränsningar eller hög CPU-användning. Mer information finns i Datadriven felsökning med hjälp av jobbdiagrammet.

Varning om nyckelöverträdelse med Azure SQL Database utdata

När du konfigurerar en Azure SQL-databas som utdata till ett Stream Analytics jobb massinfogar den poster i måltabellen. I allmänhet Azure Stream Analytics leverans minst en gång till utdata-mottagaren. Du kan fortfarande uppnå leverans exakt en gång till en SQL utdata när en SQL tabell har en unik begränsning definierad.

När du ställer in unika nyckelbegränsningar för SQL tabell tar Azure Stream Analytics bort dubblettposter. Den delar upp data i batchar och infogar batcharna rekursivt tills en enda dubblettpost hittas. Processen för att dela och infoga ignorerar dubbletterna en i taget. För ett strömningsjobb som har många dubblettrader är processen ineffektiv och tidskrävande. Om du ser flera varningsmeddelanden om nyckelöverträdelser i aktivitetsloggen för den föregående timmen är det troligt att dina SQL-utdata gör hela jobbet långsammare.

Lös problemet genom att konfigurera det index som orsakar nyckelöverträdelsen genom att aktivera IGNORE_DUP_KEY alternativet. Med det här SQL du ignorera dubblettvärden vid massinfogningar. Azure SQL Database genererar bara ett varningsmeddelande i stället för ett fel. Därför genererar Azure Stream Analytics inte längre överträdelser av primärnyckeln.

Observera följande observationer när du konfigurerar IGNORE_DUP_KEY för flera typer av index:

  • Du kan inte ange IGNORE_DUP_KEY på en primärnyckel eller en unik begränsning som använder ALTER INDEX. Du måste ta bort indexet och återskapa det.
  • Du kan ange IGNORE_DUP_KEY genom att använda ALTER INDEX för ett unikt index. Den här instansen skiljer sig från en PRIMARY KEY/UNIQUE-begränsning och skapas med hjälp av en CREATE INDEX- eller INDEX-definition.
  • Alternativet IGNORE_DUP_KEY gäller inte för kolumnlagerindex eftersom du inte kan tillämpa unikhet på dem.

SQL omprövningslogik för utdata

När ett Stream Analytics jobb med SQL-utdata tar emot den första batchen med händelser sker följande steg:

  1. Jobbet försöker ansluta till SQL.
  2. Jobbet hämtar schemat för måltabellen.
  3. Jobbet validerar kolumnnamn och -typer mot måltabellschemat.
  4. Jobbet förbereder en minnes in-memory-datatabell från utdataposterna i batchen.
  5. Jobbet skriver datatabellen för att SQL bulkcopy-API: et.

Under de här stegen SQL följande typer av fel:

  • Tillfälliga fel som försöks igen med hjälp av en återförsöksstrategi för exponentiell backoff. Det minsta återförsöksintervallet beror på den enskilda felkoden, men intervallen är vanligtvis mindre än 60 sekunder. Den övre gränsen kan vara högst fem minuter.

    Inloggningsfel och brandväggsproblem försöks igen minst 5 minuter efter föregående försök och försöks igen tills de lyckas.

  • Datafel, till exempel av rollfel och överträdelser av schemabegränsningar, hanteras med en princip för utdatafel. De här felen hanteras genom att försöka om batchar med binär delning tills den enskilda post som orsakar felet hanteras av hoppa över eller försök igen. Begränsningsfel för primär unik nyckel hanteras alltid.

  • Icke-tillfälliga fel kan inträffa när det finns SQL problem med tjänsten eller interna kodfel. Om till exempel fel som (kod 1132) Elastisk pool nå sin lagringsgräns löser inte återförsök felet. I dessa scenarier försämras Stream Analytics jobb.

  • BulkCopy tidsgränser kan inträffa under BulkCopy i steg 5. BulkCopy kan uppleva timeouter för åtgärden ibland. Standardvärdet för den minsta konfigurerade tidsgränsen är fem minuter och dubblerat när den används i följd. När tidsgränsen är över 15 minuter minskas den maximala batchstorlekstipset till hälften BulkCopy tills 100 händelser per batch lämnas.

Kolumnnamn är gemener i Azure Stream Analytics (1.0)

När du använder den ursprungliga kompatibilitetsnivån (1.0) Azure Stream Analytics kolumnnamnen till gemener. Det här beteendet har åtgärdats i senare kompatibilitetsnivåer. Om du vill bevara ärendet går du till kompatibilitetsnivå 1.1 eller senare. Mer information finns i Kompatibilitetsnivå för Stream Analytics jobb.

Få hjälp

Om du vill ha mer hjälp kan du prova vår Microsoft Q&A-frågesida för att Azure Stream Analytics.

Nästa steg