Problemen met Azure Stream Analytics-uitvoer oplossen

Artikel
12/18/2023

In dit artikel worden veelvoorkomende problemen met Uitvoerverbindingen van Azure Stream Analytics beschreven en hoe u uitvoerproblemen kunt oplossen. Voor veel stappen voor probleemoplossing moeten resource- en andere diagnostische logboeken worden ingeschakeld voor uw Stream Analytics-taak. Als u geen resourcelogboeken hebt ingeschakeld, raadpleegt u Problemen met Azure Stream Analytics oplossen met behulp van resourcelogboeken.

De taak produceert geen uitvoer

Controleer de verbinding met uitvoer met behulp van de knop Verbinding testen voor elke uitvoer.
Bekijk de Stream Analytics-taak bewaken met Azure Portal op het tabblad Monitor. Omdat de waarden worden geaggregeerd, worden de metrische gegevens een paar minuten vertraagd.
- Als de waarde voor invoerevenementen groter is dan nul, kan de taak de invoergegevens lezen. Als de waarde voor invoerevenementen niet groter is dan nul, is er een probleem met de invoer van de taak. Zie Problemen met invoerverbindingen oplossen voor meer informatie. Als uw taak verwijzingsgegevensinvoer heeft, past u splitsen op logische naam toe wanneer u de metrische gegevens voor invoergebeurtenissen bekijkt. Als er alleen geen invoergebeurtenissen van uw referentiegegevens zijn, betekent dit waarschijnlijk dat deze invoerbron niet juist is geconfigureerd om de juiste referentiegegevensset op te halen.
- Als de waarde gegevensconversiefouten groter is dan nul en klimt, raadpleegt u Azure Stream Analytics-gegevensfouten voor gedetailleerde informatie over fouten bij gegevensconversie.
- Als de waarde runtimefouten groter is dan nul, ontvangt uw taak gegevens, maar genereert deze fouten tijdens het verwerken van de query. Als u de fouten wilt vinden, gaat u naar de auditlogboeken en filtert u vervolgens op de status Mislukt .
- Als de waarde voor invoerevenementen groter is dan nul en de waarde voor uitvoer gebeurtenissen gelijk is aan nul, is een van de volgende instructies waar:
  - De queryverwerking heeft geresulteerd in nul uitvoer gebeurtenissen.
  - Gebeurtenissen of velden zijn mogelijk ongeldig, wat resulteert in een nuluitvoer na de verwerking van de query.
  - De taak kan om connectiviteits- of verificatieredenen geen gegevens naar de uitvoersink pushen.
In logboekberichten van bewerkingen worden aanvullende details uitgelegd, inclusief wat er gebeurt, behalve in gevallen waarin de querylogica alle gebeurtenissen filtert. Als bij het verwerken van meerdere gebeurtenissen fouten worden gegenereerd, worden de fouten elke tien minuten samengevoegd.

De eerste uitvoer is vertraagd

Wanneer een Stream Analytics-taak wordt gestart, worden de invoer gebeurtenissen gelezen. Er kan echter een vertraging optreden in de uitvoer, in bepaalde omstandigheden.

Grote tijdwaarden in tijdelijke query-elementen kunnen bijdragen aan de uitvoervertraging. Om de juiste uitvoer te produceren in grote tijdvensters, leest de streamingtaak gegevens van de meest recente tijd die mogelijk is om het tijdvenster te vullen. De gegevens kunnen maximaal zeven dagen voorbij zijn. Er wordt geen uitvoer geproduceerd totdat de openstaande invoer gebeurtenissen worden gelezen. Dit probleem kan optreden wanneer het systeem de streamingtaken bijwerkt. Wanneer er een upgrade plaatsvindt, wordt de taak opnieuw gestart. Dergelijke upgrades vinden over het algemeen elke paar maanden plaats.

Gebruik discretie bij het ontwerpen van uw Stream Analytics-query. Als u een groot tijdvenster gebruikt voor tijdelijke elementen in de querysyntaxis van de taak, kan dit leiden tot een vertraging in de eerste uitvoer wanneer de taak wordt gestart of opnieuw wordt gestart. Meer dan enkele uren, maximaal zeven dagen, wordt beschouwd als een groot tijdvenster.

Een oplossing voor dit soort eerste uitvoervertraging is het gebruik van queryparallellisatietechnieken, zoals het partitioneren van de gegevens. U kunt ook meer streaming-eenheden toevoegen om de doorvoer te verbeteren totdat de taak is opgeslagen. Zie Overwegingen bij het maken van Stream Analytics-taken voor meer informatie.

Deze factoren zijn van invloed op de tijdigheid van de eerste uitvoer:

Het gebruik van gevensterde aggregaties, zoals een GROUP BY-component van tumbling-, hopping- en schuifvensters:
- Voor tumbling- of hoppingvensteraggregaties worden de resultaten gegenereerd aan het einde van de periode van het venster.
- Voor een schuifvenster worden de resultaten gegenereerd wanneer een gebeurtenis het schuifvenster binnenkomt of verlaat.
- Als u van plan bent om een groot venster te gebruiken, zoals meer dan één uur, kunt u het beste een hopping- of schuifvenster kiezen. Met deze venstertypen kunt u de uitvoer vaker zien.
Het gebruik van tijdelijke joins, zoals JOIN met DATEDIFF:
- Overeenkomsten worden gegenereerd zodra beide zijden van de overeenkomende gebeurtenissen binnenkomen.
- Gegevens die geen overeenkomst hebben, zoals LEFT OUTER JOIN, worden aan het einde van het DATUMEDIFF-venster gegenereerd voor elke gebeurtenis aan de linkerkant.
Het gebruik van tijdelijke analytische functies, zoals ISFIRST, LAST en LAG met LIMIT DURATION:
- Voor analysefuncties wordt de uitvoer gegenereerd voor elke gebeurtenis. Er is geen vertraging.

De uitvoer valt achter

Tijdens de normale werking van een taak kan de uitvoer langere en langere latentieperioden hebben. Als de uitvoer er zo achter komt, kunt u de hoofdoorzaken aanwijzen door de volgende factoren te onderzoeken:

Of de downstream-sink wordt beperkt
Of de upstream-bron wordt beperkt
Of de verwerkingslogica in de query rekenintensief is

Als u de uitvoergegevens wilt bekijken, selecteert u de streamingtaak in Azure Portal en selecteert u vervolgens Taakdiagram. Voor elke invoer is er een metrische waarde voor backlog-gebeurtenissen per partitie. Als de metrische waarde blijft toenemen, is het een indicator dat de systeembronnen worden beperkt. De toename wordt mogelijk veroorzaakt door een beperking van de uitvoersink of een hoog CPU-gebruik. Zie Gegevensgestuurde foutopsporing met behulp van het taakdiagram voor meer informatie.

Waarschuwing over schending van de sleutel met Azure SQL Database-uitvoer

Wanneer u een Azure SQL-database configureert als uitvoer voor een Stream Analytics-taak, worden records bulksgewijs in de doeltabel ingevoegd. Over het algemeen garandeert Azure Stream Analytics ten minste eenmaal levering aan de uitvoersink. U kunt nog steeds exact één keer leveren aan een SQL-uitvoer wanneer een SQL-tabel een unieke beperking heeft gedefinieerd.

Wanneer u unieke sleutelbeperkingen voor de SQL-tabel instelt, verwijdert Azure Stream Analytics dubbele records. Hiermee worden de gegevens gesplitst in batches en worden de batches recursief ingevoegd totdat één dubbele record wordt gevonden. Het splits- en invoegproces negeert de duplicaten één voor één. Voor een streamingtaak met veel dubbele rijen is het proces inefficiënt en tijdrovend. Als u waarschuwingsberichten over meerdere belangrijke schendingen in uw activiteitenlogboek ziet voor het afgelopen uur, is het waarschijnlijk dat uw SQL-uitvoer de hele taak vertraagt.

U kunt dit probleem oplossen door de index te configureren die de sleutelschending veroorzaakt door de optie IGNORE_DUP_KEY in te schakelen. Met deze optie kan SQL dubbele waarden negeren tijdens bulksgewijs invoegen. Azure SQL Database produceert gewoon een waarschuwingsbericht in plaats van een fout. Als gevolg hiervan produceert Azure Stream Analytics geen fouten meer met schending van de primaire sleutel.

Let op de volgende opmerkingen bij het configureren van IGNORE_DUP_KEY voor verschillende typen indexen:

U kunt IGNORE_DUP_KEY niet instellen op een primaire sleutel of een unieke beperking die GEBRUIKMAAKT van ALTER INDEX. U moet de index verwijderen en opnieuw maken.
U kunt IGNORE_DUP_KEY instellen met ALTER INDEX voor een unieke index. Dit exemplaar verschilt van de beperking PRIMARY KEY/UNIQUE en wordt gemaakt met behulp van een CREATE INDEX- of INDEX-definitie.
De optie IGNORE_DUP_KEY is niet van toepassing op kolomopslagindexen omdat u er geen uniekheid op kunt afdwingen.

Logica voor opnieuw proberen van SQL-uitvoer

Wanneer een Stream Analytics-taak met SQL-uitvoer de eerste batch gebeurtenissen ontvangt, worden de volgende stappen uitgevoerd:

De taak probeert verbinding te maken met SQL.
De taak haalt het schema van de doeltabel op.
De taak valideert kolomnamen en -typen op basis van het doeltabelschema.
De taak bereidt een in-memory gegevenstabel voor op basis van de uitvoerrecords in de batch.
De taak schrijft de gegevenstabel naar SQL met behulp van bulkcopy-API.

Tijdens deze stappen kan de SQL-uitvoer de volgende typen fouten ondervinden:

Tijdelijke fouten die opnieuw worden geprobeerd met behulp van een strategie voor exponentieel uitstel. Het minimale interval voor opnieuw proberen is afhankelijk van de afzonderlijke foutcode, maar de intervallen zijn doorgaans minder dan 60 seconden. De bovengrens kan maximaal vijf minuten duren.

Aanmeldingsfouten en firewallproblemen worden ten minste vijf minuten na de vorige poging opnieuw geprobeerd en worden opnieuw geprobeerd totdat ze zijn geslaagd.
Gegevensfouten, zoals cast-fouten en schendingen van schemabeperkingen, worden verwerkt met uitvoerfoutbeleid. Deze fouten worden verwerkt door binaire splitsbatches opnieuw uit te voeren totdat de afzonderlijke record die de fout veroorzaakt, wordt verwerkt door overslaan of opnieuw te proberen. Schending van primaire unieke sleutelbeperkingen wordt altijd afgehandeld.
Niet-tijdelijke fouten kunnen optreden wanneer er problemen zijn met de SQL-service of interne codefouten. Wanneer bijvoorbeeld fouten zoals (Code 1132) Elastische pool die de opslaglimiet bereikt, wordt de fout niet opgelost door nieuwe pogingen. In deze scenario's ondervindt de Stream Analytics-taak degradatie.
BulkCopy time-outs kunnen optreden tijdens BulkCopy stap 5. BulkCopy kan af en toe time-outs van bewerkingen ervaren. De standaard minimaal geconfigureerde time-out is vijf minuten en wordt verdubbeld wanneer deze opeenvolgend wordt bereikt. Zodra de time-out hoger is dan 15 minuten, wordt de hint BulkCopy voor maximale batchgrootte beperkt tot de helft totdat er 100 gebeurtenissen per batch overblijven.

Belangrijk

Voor niet-netwerkinjectieve ASA-taken vertrouwt u niet op bron-IP-adres van verbindingen die afkomstig zijn van ASA. Ze kunnen openbare of privé-IP-adressen zijn, afhankelijk van bewerkingen van de service-infrastructuur die van tijd tot tijd plaatsvinden.

Kolomnamen zijn kleine letters in Azure Stream Analytics (1.0)

Wanneer u het oorspronkelijke compatibiliteitsniveau (1.0) gebruikt, worden kolomnamen in kleine letters gewijzigd in Azure Stream Analytics. Dit gedrag is opgelost in latere compatibiliteitsniveaus. Als u het geval wilt behouden, gaat u naar compatibiliteitsniveau 1.1 of hoger. Zie compatibiliteitsniveau voor Stream Analytics-taken voor meer informatie.

Hulp vragen

Probeer onze microsoft Q&A-vragenpagina voor Azure Stream Analytics voor meer hulp.

Delen via