Felsöka Azure Stream Analytics frågor
Den här artikeln beskriver vanliga problem med att utveckla Stream Analytics frågor och hur du felsöker dem.
I den här artikeln beskrivs vanliga problem Azure Stream Analytics att utveckla frågor, felsöka frågeproblem och hur du korrigerar problemen. Många felsökningssteg kräver att resursloggar är aktiverade för Stream Analytics jobb. Om du inte har aktiverat resursloggar kan du se Felsöka Azure Stream Analytics med hjälp av resursloggar.
Frågan producerar inte förväntade utdata
Granska fel genom att testa lokalt:
- På Azure Portal väljer du Testa på fliken Fråga. Använd nedladdade exempeldata för att testa frågan. Granska eventuella fel och försök att åtgärda dem.
- Du kan också testa din fråga lokalt med Azure Stream Analytics verktyg för Visual Studio eller Visual Studio Code.
Felsöka frågor steg för steg lokalt med hjälp av jobbdiagram i Azure Stream Analytics verktyg för Visual Studio Code. Jobbdiagrammet visar hur data flödar från indatakällor (händelsehubb, IoT Hub osv.) via flera frågesteg och slutligen till utdata-mottagare. Varje frågesteg mappas till en tillfällig resultatuppsättning som definierats i skriptet med hjälp av WITH-instruktionen. Du kan visa data, samt mått, i varje mellanliggande resultatuppsättning för att hitta orsaken till problemet.
Om du använder Tidsstämpel efterkontrollerar du att händelserna har tidsstämplar som är större än jobbets starttid.
Eliminera vanliga fallgropar, till exempel:
- En WHERE-sats i frågan filtrerade bort alla händelser, vilket förhindrade att utdata genererades.
- En CAST-funktion misslyckas, vilket gör att jobbet misslyckas. Använd i stället för att undvika typkon typkon TRY_CAST.
- När du använder fönsterfunktioner väntar du hela fönstrets varaktighet för att se utdata från frågan.
- Tidsstämpeln för händelser föregår jobbets starttid och händelserna tas bort.
- JOIN-villkor matchar inte. Om det inte finns några matchningar blir utdata noll.
Se till att händelseordningsprinciperna är konfigurerade som förväntat. Gå till Inställningar och välj Händelseordning. Principen tillämpas inte när du använder knappen Testa för att testa frågan. Det här resultatet är en skillnad mellan att testa i webbläsaren och att köra jobbet i produktion.
Felsöka med hjälp av aktivitets- och resursloggar:
- Använd aktivitetsloggaroch filtrera för att identifiera och felsöka fel.
- Använd jobbresursloggar för att identifiera och felsöka fel.
Resursutnyttjandet är högt
Se till att du utnyttjar parallellisering i Azure Stream Analytics. Du kan lära dig att skala med frågeparallellisering av Stream Analytics jobb genom att konfigurera indatapartitioner och justera analysfrågedefinitionen.
Om resursutnyttjandet konsekvent är över 80 % ökar vattenstämpelfördröjningen och antalet bakåtloggade händelser ökar, överväg att öka antalet strömningsenheter. Hög användning anger att jobbet använder nära det högsta allokerade antalet resurser.
Felsöka frågor progressivt
Vid databearbetning i realtid kan det vara användbart att veta hur data ser ut mitt i frågan. Du kan se detta med hjälp av jobbdiagrammet i Visual Studio. Om du inte har någon Visual Studio kan du vidta ytterligare åtgärder för att mata ut mellanliggande data.
Eftersom indata eller steg i ett Azure Stream Analytics kan läsas flera gånger kan du skriva extra SELECT INTO-instruktioner. När du gör det matas mellanliggande data in i lagringen och du kan kontrollera att data är korrekta, precis som när du felsöker ett program med hjälp av watch-variabler.
Följande exempelfråga i ett Azure Stream Analytics jobb har en strömindata, två referensdataindata och utdata till Azure Table Storage. Frågan ansluter data från händelsehubben och två referensblobar för att hämta information om namn och kategori:
Observera att jobbet körs, men inga händelser skapas i utdata. På panelen Övervakning som visas här kan du se att indata producerar data, men du vet inte vilket steg i JOIN som gjorde att alla händelser ignorerades.
I så fall kan du lägga till några extra SELECT INTO-instruktioner i "logga" de mellanliggande JOIN-resultaten och de data som läses från indata.
I det här exemplet har vi lagt till två nya "tillfälliga utdata". De kan vara vilken mottagare du vill. Här använder vi Azure Storage som exempel:
Du kan sedan skriva om frågan så här:
Starta nu jobbet igen och låt det köras i några minuter. Fråga temp1 och temp2 med Visual Studio Cloud Explorer för att skapa följande tabeller:
temp1-tabell
temp2-tabell
Som du ser har både temp1 och temp2 data, och namnkolumnen fylls i korrekt i temp2. Men eftersom det fortfarande inte finns några data i utdata är något fel:
Genom att använda sampling av data kan du vara nästan säker på att problemet gäller den andra JOIN. Du kan ladda ned referensdata från bloben och ta en titt:
Som du ser skiljer sig formatet för GUID i dessa referensdata från formatet för kolumnen [from] i temp2. Det är därför data inte kom in i output1 som förväntat.
Du kan åtgärda dataformatet, ladda upp det till referensbloben och försöka igen:
Den här gången formateras och fylls data i utdata som förväntat.
Få hjälp
Om du vill ha mer hjälp kan du prova vår frågesida&Microsoft Q Azure Stream Analytics.