Time handling in Azure Stream Analytics begrijpenUnderstand time handling in Azure Stream Analytics

In dit artikel leert u hoe u ontwerp opties kunt maken om praktische problemen met de tijds verwerking op te lossen in Azure Stream Analytics taken.In this article, you learn how to make design choices to solve practical time handling problems in Azure Stream Analytics jobs. De beslissingen met betrekking tot het afhandelen van tijden zijn nauw verwant met de factoren voor gebeurtenis volgorde.Time handling design decisions are closely related to event ordering factors.

Achtergrond tijd conceptenBackground time concepts

Voor een betere bespreking van de discussie kunt u een aantal achtergrond concepten definiëren:To better frame the discussion, let's define some background concepts:

  • Tijd van de gebeurtenis: de tijd waarop de oorspronkelijke gebeurtenis heeft plaatsgevonden.Event time: The time when the original event happened. Bijvoorbeeld wanneer een zwevende auto op de weg een bestaans hokje benadert.For example, when a moving car on the highway approaches a toll booth.

  • Verwerkings tijd: de tijd waarop de gebeurtenis het verwerkings systeem bereikt en wordt waargenomen.Processing time: The time when the event reaches the processing system and is observed. Bijvoorbeeld wanneer een sensor die de telefoon gebruikt, de auto ziet en het computer systeem even duurt om de gegevens te verwerken.For example, when a toll booth sensor sees the car and the computer system takes a few moments to process the data.

  • Water merk: een markering voor een gebeurtenis die aangeeft tot welke punt gebeurtenissen zijn uitgevallen op de streaming-processor.Watermark: An event time marker that indicates up to what point events have been ingressed to the streaming processor. Met water merken kan het systeem aangeven dat de voortgang van de gebeurtenissen duidelijk wordt geconsumeerd.Watermarks let the system indicate clear progress on ingesting the events. Door de aard van streams, worden de binnenkomende gebeurtenis gegevens nooit gestopt, waardoor water merken de voortgang van een bepaald punt in de stroom aangeven.By the nature of streams, the incoming event data never stops, so watermarks indicate the progress to a certain point in the stream.

    Het watermerk concept is belang rijk.The watermark concept is important. Met water merken kunnen Stream Analytics bepalen wanneer het systeem volledige, juiste en herhaal bare resultaten kan produceren die niet hoeven te worden ingetrokken.Watermarks allow Stream Analytics to determine when the system can produce complete, correct, and repeatable results that don’t need to be retracted. De verwerking kan worden uitgevoerd op een voorspel bare en herhaal bare manier.The processing can be done in a predictable and repeatable way. Als er bijvoorbeeld een hertelling moet worden uitgevoerd voor een bepaalde voor waarde voor fout afhandeling, zijn water merken veilig begin-en eind punten.For example, if a recount needs to be done for some error handling condition, watermarks are safe starting and ending points.

Zie blog 101 berichten van Tyler Akidau en streaming 102voor meer informatie over dit onderwerp.For additional resources on this subject, see Tyler Akidau's blog posts Streaming 101 and Streaming 102.

De beste begin tijd kiezenChoose the best starting time

Stream Analytics biedt gebruikers twee opties voor het verzamelen van de gebeurtenis tijd: aankomst tijd en toepassings tijd.Stream Analytics gives users two choices for picking event time: arrival time and application time.

Aankomst tijdArrival time

Aankomst tijd wordt toegewezen aan de invoer bron wanneer de gebeurtenis de bron bereikt.Arrival time is assigned at the input source when the event reaches the source. U kunt de aankomst tijd openen met behulp van de eigenschap EventEnqueuedUtcTime voor Event hubs invoer, de eigenschap IoTHub. EnqueuedTime voor IOT hub invoer en de eigenschap BlobProperties. LastModified voor BLOB-invoer.You can access arrival time by using the EventEnqueuedUtcTime property for Event Hubs input, the IoTHub.EnqueuedTime property for IoT Hub input, and the BlobProperties.LastModified property for blob input.

Aankomst tijd wordt standaard gebruikt en wordt het beste gebruikt voor scenario's voor gegevens archivering waarbij tijdelijke logica niet nodig is.Arrival time is used by default and is best used for data archiving scenarios where temporal logic isn't necessary.

Toepassings tijd (ook wel gebeurtenis tijd genoemd)Application time (also named Event Time)

De tijd van de toepassing wordt toegewezen wanneer de gebeurtenis wordt gegenereerd en maakt deel uit van de nettolading van de gebeurtenis.Application time is assigned when the event is generated, and it's part of the event payload. Als u gebeurtenissen wilt verwerken op toepassings tijd, gebruikt u de component time stamp by in de query selecteren.To process events by application time, use the Timestamp by clause in the SELECT query. Als time stamp by ontbreekt, worden gebeurtenissen verwerkt op aankomst tijd.If Timestamp by is absent, events are processed by arrival time.

Het is belang rijk dat u een tijds tempel in de payload gebruikt wanneer tijdelijke logica betrokken is bij het account voor vertragingen in het bron systeem of in het netwerk.It's important to use a timestamp in the payload when temporal logic is involved to account for delays in the source system or in the network. De tijd die aan een gebeurtenis is toegewezen, is beschikbaar in het systeem. TIJDS tempel.The time assigned to an event is available in SYSTEM.TIMESTAMP.

Hoe tijd loopt in Azure Stream AnalyticsHow time progresses in Azure Stream Analytics

Wanneer u toepassings tijd gebruikt, wordt de voortgang van de tijd gebaseerd op de binnenkomende gebeurtenissen.When you use application time, the time progression is based on the incoming events. Het is moeilijk om te weten dat het systeem van de stroom verwerking weet of er geen gebeurtenissen zijn of dat gebeurtenissen worden vertraagd.It's difficult for the stream processing system to know if there are no events, or if events are delayed. Daarom genereert Azure Stream Analytics heuristische water merken op de volgende manieren voor elke invoer partitie:For this reason, Azure Stream Analytics generates heuristic watermarks in the following ways for each input partition:

  • Wanneer er een binnenkomende gebeurtenis is, is het water merk de grootste gebeurtenis tijd die Stream Analytics tot ver de grootte van het verouderde tolerantie venster heeft gezien.When there's any incoming event, the watermark is the largest event time Stream Analytics has seen so far minus the out-of-order tolerance window size.

  • Wanneer er geen inkomende gebeurtenis is, is het water merk het huidige geschatte aankomst tijd min het venster late aankomst tolerantie.When there's no incoming event, the watermark is the current estimated arrival time minus the late arrival tolerance window. De geschatte aankomst tijd is de tijd die is verstreken vanaf de laatste keer dat een invoer gebeurtenis is waargenomen plus de aankomst tijd van de invoer gebeurtenis.The estimated arrival time is the time that has elapsed from the last time an input event was seen plus that input event's arrival time.

    De aankomst tijd kan alleen worden geschat omdat de werkelijke aankomst tijd wordt gegenereerd op de invoer gebeurtenis Broker, zoals Event Hubs, noch op de Azure Stream Analytics VM de gebeurtenissen verwerkt.The arrival time can only be estimated because the real arrival time is generated on the input event broker, such as Event Hubs, nor on the Azure Stream Analytics VM processing the events.

Het ontwerp heeft twee extra andere doel einden dan het genereren van water merken:The design serves two additional purposes other than generating watermarks:

  1. Het systeem genereert de resultaten tijdig met of zonder binnenkomende gebeurtenissen.The system generates results in a timely fashion with or without incoming events.

    U hebt de controle over hoe tijdig u de uitvoer resultaten wilt weer geven.You have control over how timely you want to see the output results. In de Azure Portal op de pagina gebeurtenis volgorde van uw stream Analytics taak, kunt u de instelling voor niet-beschik bare gebeurtenissen configureren.In the Azure portal, on the Event ordering page of your Stream Analytics job, you can configure the Out of order events setting. Wanneer u deze instelling configureert, moet u rekening houden met de afweging van de tijd lijn met de tolerantie van out-of-order gebeurtenissen in de gebeurtenis stroom.When you configure that setting, consider the trade-off of timeliness with tolerance of out-of-order events in the event stream.

    Het venster late aankomst tolerantie is nodig om water merken te kunnen blijven genereren, zelfs als er geen binnenkomende gebeurtenissen zijn.The late arrival tolerance window is necessary to keep generating watermarks, even in the absence of incoming events. Het kan zijn dat er een periode is waarin er geen binnenkomende gebeurtenissen zijn, zoals wanneer een gebeurtenis invoer stroom verspreid is.At times, there may be a period where no incoming events come in, like when an event input stream is sparse. Dit probleem wordt exacerbated door het gebruik van meerdere partities in de invoer gebeurtenis Broker.That problem is exacerbated by the use of multiple partitions in the input event broker.

    Streaming-gegevens verwerkings systemen zonder een tolerantie venster voor late aankomst kunnen aflopen van vertraagde uitvoer wanneer de invoer sparse is en er meerdere partities worden gebruikt.Streaming data processing systems without a late arrival tolerance window may suffer from delayed outputs when inputs are sparse and multiple partitions are used.

  2. Het systeem gedrag moet herhaalbaar zijn.The system behavior needs to be repeatable. Herhaal baarheid is een belang rijke eigenschap van een systeem voor het verwerken van gegevens stromen.Repeatability is an important property of a streaming data processing system.

    Het water merk is afgeleid van de aankomst tijd en toepassings tijd.The watermark is derived from the arrival time and application time. Beide worden bewaard in de Event Broker en kunnen dus worden herhaald.Both are persisted in the event broker, and thus repeatable. Wanneer een aankomst tijd wordt geschat in afwezigheid van gebeurtenissen, Azure Stream Analytics journalen de geschatte aankomst tijd voor Herhaal baarheid tijdens het opnieuw afspelen voor fout herstel.When an arrival time is estimated in the absence of events, Azure Stream Analytics journals the estimated arrival time for repeatability during replay for failure recovery.

Wanneer u ervoor kiest om aankomst tijd te gebruiken als de tijd van de gebeurtenis, hoeft u de tolerantie voor buiten-of nabestelling en de duur van late aankomst niet te configureren.When you choose to use arrival time as the event time, there you don't need to configure the out-of-order tolerance and late arrival tolerance. Omdat aankomst tijd gegarandeerd toeneemt in de invoer gebeurtenis broker, Azure stream Analytics de configuraties gewoon ongedaan maken.Since arrival time is guaranteed to be increasing in the input event broker, Azure Stream Analytics simply disregards the configurations.

Achterstallige gebeurtenissenLate arriving events

Op basis van de definitie van het venster late aankomst tolerantie voor elk binnenkomend evenement Azure Stream Analytics de tijd van de gebeurtenis vergeleken met de aankomst tijd.By definition of late arrival tolerance window, for each incoming event, Azure Stream Analytics compares the event time with the arrival time. Als de tijd van de gebeurtenis zich buiten het tolerantie venster bevindt, kunt u het systeem configureren om de gebeurtenis te verwijderen of de tijd van de gebeurtenis aan te passen binnen de tolerantie.If the event time is outside of the tolerance window, you can configure the system to drop the event or adjust the event's time to be within the tolerance.

Als er water merken worden gegenereerd, kan de service mogelijk gebeurtenissen ontvangen met een gebeurtenis tijd die lager is dan het water merk.Once watermarks are generated, the service can potentially receive events with an event time lower than the watermark. U kunt de service zo configureren dat deze gebeurtenissen worden neerzetten of de tijd van de gebeurtenis aanpassen aan de watermerk waarde.You can configure the service to either drop those events, or adjust the event's time to the watermark value.

Als onderdeel van de aanpassing wordt het systeem. time stamp van de gebeurtenis ingesteld op de nieuwe waarde, maar het veld voor de gebeurtenis tijd zelf wordt niet gewijzigd.As a part of the adjustment, the event's System.Timestamp is set to the new value, but the event time field itself is not changed. Deze aanpassing is de enige situatie waarin een gebeurtenis systeem. time stamp kan afwijken van de waarde in het veld gebeurtenis tijd en kan leiden tot onverwachte resultaten.This adjustment is the only situation where an event's System.Timestamp can be different from the value in the event time field and may cause unexpected results to be generated.

Tijd variatie met substreams afhandelenHandle time variation with substreams

De beschreven methode voor het genereren van de heuristische water merk werkt goed in de meeste gevallen waarin tijd voornamelijk wordt gesynchroniseerd tussen de verschillende afzenders van de gebeurtenis.The heuristic watermark generation mechanism described works well in most of cases where time is mostly synchronized between the various event senders. In werkelijkheid, met name in veel IoT-scenario's, heeft het systeem echter weinig controle over de klok van de afzenders van de gebeurtenis.However, in real life, especially in many IoT scenarios, the system has little control over the clock on the event senders. De afzenders van de gebeurtenis kunnen allerlei apparaten in het veld zijn, mogelijk op verschillende versies van hardware en software.The event senders could be all sorts of devices in the field, perhaps on different versions of hardware and software.

In plaats van een water merk te gebruiken dat globaal is voor alle gebeurtenissen in een invoer partitie, heeft Stream Analytics een ander mechanisme met de naam substreams.Instead of using a watermark that is global to all events in an input partition, Stream Analytics has another mechanism called substreams. U kunt substreams gebruiken in uw taak door een taak query te schrijven die gebruikmaakt van de component time stamp by en het sleutel woord over.You can utilize substreams in your job by writing a job query that uses the TIMESTAMP BY clause and the keyword OVER. Als u de substream wilt aanwijzen, geeft u de naam van een sleutel kolom op achter het sleutel woord over , zoals een deviceid , zodat het systeem tijd beleid op die kolom toepast.To designate the substream, provide a key column name after the OVER keyword, such as a deviceid, so that system applies time policies by that column. Elke substream krijgt een eigen onafhankelijk water merk.Each substream gets its own independent watermark. Dit mechanisme is handig voor het genereren van tijdige uitvoer, bij het verwerken van grote klok scheefheden of netwerk vertragingen tussen gebeurtenis afzenders.This mechanism is useful to allow timely output generation, when dealing with large clock skews or network delays among event senders.

Substreams zijn een unieke oplossing die wordt geleverd door Azure Stream Analytics en die niet worden aangeboden door andere systemen voor gegevensverwerking van gegevens stromen.Substreams are a unique solution provided by Azure Stream Analytics, and are not offered by other streaming data processing systems.

Wanneer u substreams gebruikt, past Stream Analytics het venster late aankomst tolerantie toe op binnenkomende gebeurtenissen.When you use substreams, Stream Analytics applies the late arrival tolerance window to incoming events. De late aankomst tolerantie bepaalt het maximum bedrag waarmee verschillende substreams van elkaar kunnen zijn.The late arrival tolerance decides the maximum amount by which different substreams can be apart from each other. Als apparaat 1 bijvoorbeeld de Time Stamp 1 heeft en apparaat 2 de tijds tempel 2 is, is de te late aankomst tolerantie tijds tempel 2 minus tijds Tempel 1.For example, if Device 1 is at Timestamp 1, and Device 2 is at Timestamp 2, the at most late arrival tolerance is Timestamp 2 minus Timestamp 1. De standaard instelling is vijf seconden en is waarschijnlijk te klein voor apparaten met uiteenlopende-tijds tempels.The default setting is 5 seconds and is likely too small for devices with divergent timestamps. We raden u aan om te beginnen met 5 minuten en aanpassingen aan te brengen op basis van het patroon voor de klok van het apparaat.We recommend that you start with 5 minutes and make adjustments according to their device clock skew pattern.

Vroege arrivende gebeurtenissenEarly arriving events

Mogelijk hebt u een ander concept met de naam vroege aankomst gezien dat lijkt op het tegenovergestelde van het venster late aankomst tolerantie.You may have noticed another concept called early arrival window that looks like the opposite of late arrival tolerance window. Dit venster is vijf minuten opgelost en is een ander doel dan het tolerantie venster late aankomst.This window is fixed at 5 minutes and serves a different purpose from the late arrival tolerance window.

Omdat Azure Stream Analytics gegarandeerde resultaten oplevert, kunt u de begin tijd van de taak alleen opgeven als de eerste uitvoer tijd van de taak, niet de invoer tijd.Because Azure Stream Analytics guarantees complete results, you can only specify job start time as the first output time of the job, not the input time. De begin tijd van de taak is vereist zodat het volledige venster wordt verwerkt, niet alleen vanaf het midden van het venster.The job start time is required so that the complete window is processed, not just from the middle of the window.

Stream Analytics wordt de begin tijd van de query specificatie afgeleid.Stream Analytics derives the start time from the query specification. Omdat de invoer gebeurtenis Broker echter alleen wordt geïndexeerd op aankomst tijd, moet het systeem de begin tijd van de gebeurtenis vertalen naar aankomst tijd.However, because the input event broker is only indexed by arrival time, the system has to translate the starting event time to arrival time. Het systeem kan beginnen met het verwerken van gebeurtenissen vanaf dat punt in de invoer gebeurtenis Broker.The system can start processing events from that point in the input event broker. De eerste keer dat de limiet wordt bereikt, is de vertaling eenvoudig: de begin tijd van de gebeurtenis min het eerste binnengekomen venster van 5 minuten.With the early arriving window limit, the translation is straightforward: starting event time minus the 5-minute early arriving window. Deze berekening betekent ook dat het systeem alle gebeurtenissen weglaat die worden gezien als een gebeurtenis tijd van vijf minuten vóór de aankomst tijd.This calculation also means that the system drops all events that are seen as having an event time 5 minutes earlier than the arrival time. De gegevens over de vroege invoer gebeurtenissen worden verhoogd wanneer de gebeurtenissen worden verwijderd.The early input events metric is incremented when the events are dropped.

Dit concept wordt gebruikt om ervoor te zorgen dat de verwerking kan worden herhaald, ongeacht waar u begint met het uitvoeren van.This concept is used to ensure the processing is repeatable no matter where you start to output from. Zonder een dergelijk mechanisme is het niet mogelijk om Herhaal baarheid te garanderen, net als bij veel andere claim van streaming Systems.Without such a mechanism, it would not be possible to guarantee repeatability, as many other streaming systems claim they do.

Neven effecten van tijd toleranties voor gebeurtenis ordeningSide effects of event ordering time tolerances

Stream Analytics taken hebben verschillende opties voor het ordenen van gebeurtenissen .Stream Analytics jobs have several Event ordering options. Twee kunnen worden geconfigureerd in de Azure Portal: de instelling voor de niet-ingestelde volg orde (buiten de juiste volg orde) en de gebeurtenissen die een te late instelling aankomen (tolerantie voor late aankomst).Two can be configured in the Azure portal: the Out of order events setting (out-of-order tolerance), and the Events that arrive late setting (late arrival tolerance). De vroege aankomst tolerantie is vast en kan niet worden aangepast.The early arrival tolerance is fixed and cannot be adjusted. Deze tijd beleids regels worden door Stream Analytics gebruikt om sterke garanties te bieden.These time policies are used by Stream Analytics to provide strong guarantees. Deze instellingen hebben echter enkele soms onverwachte gevolgen:However, these settings do have some sometimes unexpected implications:

  1. Per ongeluk gebeurtenissen verzenden die te vroeg zijn.Accidentally sending events that are too early.

    Vroege gebeurtenissen mogen niet normaal worden gegenereerd.Early events should not be outputted normally. Het is mogelijk dat vroege gebeurtenissen worden verzonden naar de uitvoer als de klok van de afzender te snel wordt uitgevoerd.It's possible that early events are sent to the output if sender’s clock is running too fast though. Alle vroege Aankomende gebeurtenissen worden verwijderd, zodat u deze niet in de uitvoer kunt zien.All early arriving events are dropped, so you will not see any of them from the output.

  2. Oude gebeurtenissen verzenden naar Event Hubs die moeten worden verwerkt door Azure Stream Analytics.Sending old events to Event Hubs to be processed by Azure Stream Analytics.

    Hoewel oude gebeurtenissen op de eerste onschadelijk kunnen oplopen, vanwege de toepassing van de vertraagde aankomst tolerantie, kunnen de oude gebeurtenissen worden verwijderd.While old events may seem harmless at first, because of the application of the late arrival tolerance, the old events may be dropped. Als de gebeurtenissen te oud zijn, wordt de waarde van System. time stamp gewijzigd tijdens gebeurtenis opname.If the events are too old, the System.Timestamp value is altered during event ingestion. Als gevolg van dit gedrag is momenteel Azure Stream Analytics beter geschikt voor de bijna-real-time verwerkings scenario's voor gebeurtenissen, in plaats van historische gebeurtenis verwerkings scenario's.Due to this behavior, currently Azure Stream Analytics is more suited for near-real-time event processing scenarios, instead of historical event processing scenarios. In sommige gevallen kunt u de gebeurtenissen die laat tijd aankomen aan de grootste mogelijke waarde (20 dagen) instellen om dit gedrag te omzeilen.You can set the Events that arrive late time to the largest possible value (20 days) to work around this behavior in some cases.

  3. De uitvoer lijkt te zijn vertraagd.Outputs seem to be delayed.

    Het eerste water merk wordt gegenereerd op de berekende tijd: de maximale gebeurtenis tijd die het systeem heeft waargenomen tot nu toe, min de grootte van het verouderde tolerantie venster.The first watermark is generated at the calculated time: the maximum event time the system has observed so far, minus the out-of-order tolerance window size. De out-of-order-tolerantie wordt standaard ingesteld op nul (00 minuten en 00 seconden).By default, the out-of-order tolerance is configured to zero (00 minutes and 00 seconds). Wanneer u deze instelt op een hogere, niet-nul-waarde, wordt de eerste uitvoer van de streaming-taak vertraagd met die waarde (of hoger) vanwege de tijd van de eerste water merk die wordt berekend.When you set it to a higher, non-zero time value, the streaming job's first output is delayed by that value of time (or greater) due to the first watermark time that is calculated.

  4. De invoer is verspreid.Inputs are sparse.

    Wanneer er geen invoer is in een bepaalde partitie, wordt de watermerk tijd berekend als de aankomst tijd minus het venster late aankomst tolerantie.When there is no input in a given partition, the watermark time is calculated as the arrival time minus the late arrival tolerance window. Als invoer gebeurtenissen echter niet veelvuldig en verspreid zijn, kan de uitvoer worden vertraagd met die hoeveelheid tijd.As a result, if input events are infrequent and sparse, the output can be delayed by that amount of time. De standaard gebeurtenissen waarbij de late waarde wordt bereikt, is 5 seconden.The default Events that arrive late value is 5 seconds. Er wordt een vertraging weer geven bij het verzenden van invoer gebeurtenissen per keer.You should expect to see some delay when sending input events one at a time, for example. De vertraging kan erger raken wanneer u gebeurtenissen instelt waarmee het venster over een grote waarde wordt bereikt.The delays can get worse, when you set Events that arrive late window to a large value.

  5. De waarde van het systeem. time stamp wijkt af van de tijd in het veld voor de gebeurtenis tijd .System.Timestamp value is different from the time in the event time field.

    Zoals eerder beschreven, past het systeem de gebeurtenis tijd aan door de tolerantie voor de buiten-of nabestelling of het Windows-venster met de achterstand voor aankomst.As described previously, the system adjusts event time by the out-of-order tolerance or late arrival tolerance windows. De waarde System. time stamp van de gebeurtenis wordt aangepast, maar niet het veld gebeurtenis tijd .The System.Timestamp value of the event is adjusted, but not the event time field. Dit kan worden gebruikt om te bepalen voor welke gebeurtenissen de tijds tempels zijn aangepast.This can be used to identify for which events the timestamps adjusted. Als het systeem de tijds tempel heeft gewijzigd vanwege een van de toleranties, zijn deze normaal gesp roken hetzelfde.If the system changed the timestamp due to one of the tolerances, normally they are the same.

Metrische gegevens om te observerenMetrics to observe

U kunt een aantal de tijds tolerantie-effecten van de gebeurtenis volgorde bekijken via de metrische gegevens van stream Analytics-opdracht.You can observe a number of the Event ordering time tolerance effects through Stream Analytics job metrics. De volgende metrische gegevens zijn relevant:The following metrics are relevant:

MetrischMetric BeschrijvingDescription
Out-of-order gebeurtenissenOut-of-Order Events Hiermee wordt het aantal gebeurtenissen aangegeven dat niet in de juiste volg orde is ontvangen, die zijn verwijderd of een aangepast tijds tempel hebben gekregen.Indicates the number of events received out of order, that were either dropped or given an adjusted timestamp. Deze metrische gegevens worden rechtstreeks beïnvloed door de configuratie van de instelling voor niet-bestel gebeurtenissen op de pagina gebeurtenis volgorde van de taak in de Azure Portal.This metric is directly impacted by the configuration of the Out of order events setting on the Event ordering page on the job in the Azure portal.
Late invoer gebeurtenissenLate Input Events Hiermee wordt het aantal gebeurtenissen aangegeven dat te laat arriveren vanaf de bron.Indicates the number of events arriving late from the source. Deze metriek bevat gebeurtenissen die zijn verwijderd of waarvoor de tijds tempel ervan is aangepast.This metric includes events that have been dropped or have had their timestamp was adjusted. Deze metrische gegevens worden rechtstreeks beïnvloed door de configuratie van de gebeurtenissen die een te late instelling aankomen op de pagina gebeurtenis volgorde van de taak in de Azure Portal.This metric is directly impacted by the configuration of the Events that arrive late setting in the Event ordering page on the job in the Azure portal.
Vroege invoer gebeurtenissenEarly Input Events Hiermee wordt het aantal gebeurtenissen aangegeven dat zich vroeg van de bron bevindt die zijn verwijderd, of hun tijds tempel is aangepast als deze na vijf minuten te vroeg zijn.Indicates the number of events arriving early from the source that have either been dropped, or their timestamp has been adjusted if they are beyond 5 minutes early.
Watermerk vertragingWatermark Delay Hiermee wordt de vertraging van de verwerkings taak voor streaming-gegevens aangegeven.Indicates the delay of the streaming data processing job. Zie de volgende sectie voor meer informatie.See more information in the following section.

Details van watermerk vertragingWatermark delay details

De metrische gegevens van het watermerk vertraging worden berekend als de klok tijd van de wand van het verwerkings knooppunt min het grootste water merk dat tot nu toe is gezien.The Watermark delay metric is computed as the wall clock time of the processing node minus the largest watermark it has seen so far. Zie de blog post water merk vertragingvoor meer informatie.For more information, see the watermark delay blog post.

Er kunnen verschillende redenen zijn waarom deze metrische waarde groter is dan 0 onder normale werking:There can be several reasons this metric value is larger than 0 under normal operation:

  1. De inherente verwerkings vertraging van de streaming-pijp lijn.Inherent processing delay of the streaming pipeline. Normaal gesp roken is deze vertraging nominaal.Normally this delay is nominal.

  2. Het venster voor de buiten-volg orde van de tolerantie heeft een vertraging geïntroduceerd, omdat het water merk wordt verminderd met de grootte van het tolerantie venster.The out-of-order tolerance window introduced delay, because watermark is reduced by the size of the tolerance window.

  3. Het venster late aankomst heeft vertraging geïntroduceerd, omdat het water merk wordt verminderd met het formaat van het tolerantie venster.The late arrival window introduced delay, because watermark is reduced by the size the tolerance window.

  4. Klok scheefheid van het verwerkings knooppunt dat de metriek genereert.Clock skew of the processing node generating the metric.

Er zijn een aantal andere resource beperkingen waardoor de streaming pijp lijn kan vertragen.There are a number of other resource constraints that can cause the streaming pipeline to slow down. De metriek voor het watermerk vertraging kan de volgende oorzaken hebben:The watermark delay metric can rise due to:

  1. Er zijn onvoldoende verwerkings resources in Stream Analytics om het volume van invoer gebeurtenissen te verwerken.Not enough processing resources in Stream Analytics to handle the volume of input events. Zie informatie over streaming-eenheden begrijpen en aanpassenvoor meer informatie over het schalen van resources.To scale up resources, see Understand and adjust Streaming Units.

  2. Onvoldoende door Voer in de invoer gebeurtenis-Brokers, zodat ze worden beperkt.Not enough throughput within the input event brokers, so they are throttled. Zie Azure-Event hubs doorvoer eenheden automatisch opschalenvoor mogelijke oplossingen.For possible solutions, see Automatically scale up Azure Event Hubs throughput units.

  3. Uitvoer-sinks worden niet ingericht met voldoende capaciteit, zodat ze worden beperkt.Output sinks are not provisioned with enough capacity, so they are throttled. De mogelijke oplossingen variëren op basis van de gebruikte uitvoer service.The possible solutions vary widely based on the flavor of output service being used.

Frequentie van uitvoer gebeurtenisOutput event frequency

Azure Stream Analytics gebruikt de voortgang van het water merk als enige trigger voor het produceren van uitvoer gebeurtenissen.Azure Stream Analytics uses watermark progress as the only trigger to produce output events. Omdat het water merk is afgeleid van invoer gegevens, kan het worden herhaald tijdens het herstellen van de fout en wordt het proces ook gestart met het opnieuw verwerken van de gebruiker.Because the watermark is derived from input data, it is repeatable during failure recovery and also in user initiated reprocessing. Wanneer u gebruikmaakt van statistische functies in Vensters, produceert de service alleen uitvoer aan het einde van de Windows.When using windowed aggregates, the service only produces outputs at the end of the windows. In sommige gevallen willen gebruikers mogelijk gedeeltelijke aggregaties zien die zijn gegenereerd door de Windows.In some cases, users may want to see partial aggregates generated from the windows. Gedeeltelijke aggregaties worden momenteel niet ondersteund in Azure Stream Analytics.Partial aggregates are not supported currently in Azure Stream Analytics.

In andere streaming-oplossingen kunnen uitvoer gebeurtenissen op verschillende trigger punten worden gerealiseerd, afhankelijk van externe omstandigheden.In other streaming solutions, output events could be materialized at various trigger points, depending on external circumstances. Het is mogelijk dat in sommige oplossingen de uitvoer gebeurtenissen voor een bepaald tijd venster meerdere keren kunnen worden gegenereerd.It's possible in some solutions that the output events for a given time window could be generated multiple times. Naarmate de invoer waarden worden geraffineerd, worden de statistische resultaten nauw keuriger.As the input values are refined, the aggregate results become more accurate. Gebeurtenissen kunnen op het eerst worden speculatief en na verloop van tijd worden gewijzigd.Events could be speculated at first, and revised over time. Wanneer bijvoorbeeld een bepaald apparaat offline is van het netwerk, kan een geschatte waarde door een systeem worden gebruikt.For example, when a certain device is offline from the network, an estimated value could be used by a system. Later is hetzelfde apparaat online voor het netwerk.Later on, the same device comes online to the network. Vervolgens kunnen de werkelijke gebeurtenis gegevens worden opgenomen in de invoer stroom.Then the actual event data could be included in the input stream. De uitvoer resultaten van de verwerking van dat tijd venster genereren nauw keurige uitvoer.The output results from processing that time window produces more accurate output.

Geïllustreerd voor beeld van water merkenIllustrated example of watermarks

De volgende afbeeldingen laten zien hoe water merken in verschillende omstandigheden worden uitgevoerd.The following images illustrate how watermarks progress in different circumstances.

In deze tabel worden de voorbeeld gegevens weer gegeven die hieronder zijn gediagrameerd.This table shows the example data that is charted below. U ziet dat de tijd van de gebeurtenis en de aankomst tijd variëren, soms overeenkomend en soms niet.Notice that the event time and the arrival time vary, sometimes matching and sometimes not.

Tijdstip van gebeurtenisEvent time Aankomst tijdArrival time DeviceIdDeviceId
12:0712:07 12:0712:07 device1device1
12:0812:08 12:0812:08 device2device2
12:1712:17 12:1112:11 device1device1
12:0812:08 12:1312:13 device3device3
12:1912:19 12:1612:16 device1device1
12:1212:12 12:1712:17 device3device3
12:1712:17 12:1812:18 device2device2
12:2012:20 12:1912:19 device2device2
12:1612:16 12:2112:21 device3device3
12:2312:23 12:2212:22 device2device2
12:2212:22 12:2412:24 device2device2
12:2112:21 12:2712:27 device3device3

In deze afbeelding worden de volgende toleranties gebruikt:In this illustration, the following tolerances are used:

  • Vroege aankomst Windows is vijf minutenEarly arrival windows is 5 minutes
  • Het venster late aankomst is vijf minutenLate arriving window is 5 minutes
  • Het venster opnieuw rangschikken is 2 minutenReorder window is 2 minutes
  1. Afbeelding van het water merk dat door deze gebeurtenissen wordt uitgevoerd:Illustration of watermark progressing through these events:

    Afbeelding van Azure Stream Analytics watermerk

    Belang rijke processen die in de voor gaande afbeelding worden geïllustreerd:Notable processes illustrated in the preceding graphic:

    1. De eerste gebeurtenis (device1) en tweede gebeurtenis (device2) hebben uitgelijnde tijden en worden zonder aanpassingen verwerkt.The first event (device1), and second event (device2) have aligned times and are processed without adjustments. Het water merk loopt op elke gebeurtenis.The watermark progresses on each event.

    2. Wanneer de derde gebeurtenis (device1) wordt verwerkt, wordt de aankomst tijd (12:11) voorafgaat aan de gebeurtenis tijd (12:17).When the third event (device1) is processed, the arrival time (12:11) precedes the event time (12:17). De gebeurtenis is zes minuten te vroeg gearriveerd, waardoor de gebeurtenis wordt verwijderd als gevolg van de verval datum van 5 minuten voor de vroege aankomst.The event arrived 6 minutes early, so the event is dropped due to the 5-minute early arrival tolerance.

      Het water merk wordt niet in dit geval voor een vroege gebeurtenis uitgevoerd.The watermark doesn't progress in this case of an early event.

    3. De vierde gebeurtenis (device3) en vijfde gebeurtenis (device1) hebben uitgelijnde tijden en worden zonder aanpassing verwerkt.The fourth event (device3), and fifth event (device1) have aligned times and are processed without adjustment. Het water merk loopt op elke gebeurtenis.The watermark progresses on each event.

    4. Wanneer de zesde gebeurtenis (device3) wordt verwerkt, wordt de aankomst tijd (12:17) en de tijd van de gebeurtenis (12:12) lager dan het watermerk niveau.When the sixth event (device3) is processed, the arrival time (12:17) and the event time (12:12) is below the watermark level. De tijd van de gebeurtenis wordt aangepast aan het water merk niveau (12:17).The event time is adjusted to the water mark level (12:17).

    5. Wanneer de twaalfde gebeurtenis (device3) wordt verwerkt, is de aankomst tijd (12:27) 6 minuten vóór de tijd van de gebeurtenis (12:21).When the twelfth event (device3) is processed, the arrival time (12:27) is 6 minutes ahead of the event time (12:21). Het beleid voor late aankomst wordt toegepast.The late arrival policy is applied. De tijd van de gebeurtenis wordt aangepast (12:22), boven het water merk (12:21), zodat er geen verdere aanpassing wordt toegepast.The event time is adjusted (12:22), which is above the watermark (12:21) so no further adjustment is applied.

  2. Tweede afbeelding van het water merk dat wordt uitgevoerd zonder een early-ontvangst beleid:Second illustration of watermark progressing without an early arrival policy:

    Azure Stream Analytics geen voor beeld van eerste beleids watermerk

    In dit voor beeld wordt geen beleid voor vroegtijdige ontvangst toegepast.In this example, no early arrival policy is applied. Uitschieter gebeurtenissen waarmee het water merk vroegtijdig wordt verhoogd.Outlier events that arrive early raise the watermark significantly. De derde gebeurtenis (deviceId1 op tijd 12:11) wordt in dit scenario niet verwijderd en het water merk wordt verhoogd naar 12:15.Notice the third event (deviceId1 at time 12:11) is not dropped in this scenario, and the watermark is raised to 12:15. De vierde gebeurtenis tijd wordt ingesteld op 7 minuten (12:08 tot 12:15).The fourth event time is adjusted forward 7 minutes (12:08 to 12:15) as a result.

  3. In de laatste afbeelding worden substreams gebruikt (via de DeviceId).In the final illustration, substreams are used (OVER the DeviceId). Meerdere water merken worden bijgehouden, één per stroom.Multiple watermarks are tracked, one per stream. Er zijn minder gebeurtenissen waarbij de tijden worden aangepast als resultaat.There are fewer events with their times adjusted as a result.

    Afbeelding van water merken Azure Stream Analytics substreamen

Volgende stappenNext steps