TIMESTAMP BY

✅ Azure Stream Analytics

Minden adatfolyam-eseményhez tartozik időbélyeg. Alapértelmezés szerint az Event Hub és az IoT Hub eseményei időbélyegzővel vannak ellátva attól függően, hogy az esemény mikor érkezett az Eseményközponthoz vagy az IoT Hubhoz; A Blob Storage-ból származó események időbélyegzője a blob utolsó módosítási időpontja. Az esemény időbélyege nem változik, ha újrakezdi vagy újra futtatja a feladatot.

Számos streamelési alkalmazásnak az érkezési idő helyett pontosan azt az időbélyeget kell használnia, amely szerint egy esemény történt. Például egy Értékesítési pont alkalmazásban szükség lehet a fizetés naplózásának időpontjának megfelelő esemény-időbélyegekre, nem pedig arra az időre, amikor egy fizetési esemény eléri az eseménybetöltési szolgáltatást. Emellett a földrajzilag elosztott rendszerek és a hálózati késések hozzájárulhatnak a kiszámíthatatlan érkezési időkhez, így az alkalmazásidő megbízhatóbbá válhat a streamelési alkalmazásokban. Ezekben az esetekben a TIMESTAMP BY záradék lehetővé teszi az egyéni időbélyeg-értékek megadását. Az érték bármilyen mező lehet az esemény hasznos adataiból vagy a DATETIME típusú kifejezésből. Az ISO 8601 formátumoknak megfelelő sztringértékek is támogatottak.

Vegye figyelembe, hogy egy egyéni időbélyeg (TIMESTAMP BY záradék) használatával az Azure Stream Analytics két okból is rendezetlenül betöltheti az eseményeket az időbélyegek tekintetében:

• Az egyes eseménykészítők eltérő (és ferde) rendszerórákat is tartalmazhatnak.
• Az egyes eseménygyártók eseményei késleltethetik az átvitelt, például a gyártó telephelyén a hálózat elérhetetlensége miatt.

Bár az eseménykészítők közötti rendellenesség nagy lehet, az egyetlen termelő eseményei között a rendellenesség általában kicsi vagy akár nem is létezik. Ha egy lekérdezés csak az egyes eseménykészítők adatait dolgozza fel egymástól függetlenül, az egyes gyártók eseményeinek kezelése a saját idővonalán hatékonyabb, mint a termelők közötti időeltérések kezelése. Az Azure Stream Analytics úgy támogatja az alstreameket, hogy a over <over spec> alfeltételt adja meg az események független idővonalon történő feldolgozásának engedélyezéséhez. Az OVER záradéknak a feladat feldolgozására gyakorolt hatásáról lásd: "OVER záradék interakcióba lép az eseményrendezéssel".

Syntax

TIMESTAMP BY scalar_expression [OVER <over spec> ]  
      
<over spec> ::= 
      { column_name | expression } [,...n ]  

Remarks

Eseményidőbélyeg beolvasása

Az eseményidőbélyeg a LEKÉRDEZÉS bármely részén lekérhető a SELECT utasításban a System.Timestamp() tulajdonság használatával.

AZ OVER záradék interakcióba lép az eseményrendezéssel

Az OVER záradék használata esetén az Azure Stream Analytics eseményfeldolgozásának több aspektusa is módosul:

1. A maximális rendelésen kívüli tűrés egyetlen értéken <belül, több mint specifikáción> belül van alkalmazva. Ez azt jelzi, hogy egy eseményt csak akkor tekintünk rendelésen kívülre, ha az túl sok megrendelésből érkezik ugyanabból az eseménygyártótól származó egyéb eseményekhez képest.

   Például a "0" érték akkor használható, ha az ugyanabból az eseménygyártóból származó eseményeket mindig rendezik, és azonnali feldolgozást eredményeznek. A nagy értékek itt való használata viszont feldolgozási késéseket fog okozni, miközben a rendelésen kívüli eseményekre vár.

2. A maximális késői érkezési tűrést globálisan alkalmazza a rendszer (mintha nem használták volna az OVER-t). Vagyis egy esemény késői érkezésnek minősül, ha a választott időbélyege (a TIMESTAMP BY záradékban) túl messze van az érkezési időtől.

   Vegye figyelembe, hogy a nagy értékek itt nem okoznak feldolgozási késést, és az események feldolgozása továbbra is azonnal történik (vagy a rendelésen kívüli maximális tűrésnek megfelelően). A több napos érték nem ésszerűtlen. A kivételesen hosszú értékek használata azonban hatással lehet a feladat feldolgozásához szükséges memória mennyiségére.

3. Az egyes eseménykészítők kimeneti eseményei a számításuk során jönnek létre, ami azt jelenti, hogy a kimeneti események rendelésen kívüli időbélyegekkel rendelkezhetnek; azonban egy adott értéken <>belül rendezve lesznek.

Korlátozások és korlátozások

A TIMESTAMP BY OVER záradék a következő használati korlátozásokkal rendelkezik:

1. A TIMESTAMP BY OVER záradékot a lekérdezés összes bemenetéhez használni kell, vagy egyikhez sem.

2. A TIMESTAMP BY OVER záradék csak teljesen párhuzamos feladatokkal vagy egyetlen partíciós feladatokkal támogatott.

3. Ha a bemeneti adatfolyam több partícióval is rendelkezik, a OVER záradékot a PARTITION BY záradékkal együtt kell használni. A PartitionId oszlopot a TIMESTAMP BY OVER oszlopok részeként kell megadni.

4. A TIMESTAMP BY OVER záradék használata esetén a záradék oszlopneveit csoportosítási kulcsként kell használni a GROUP BY utasításokban és az összes JOIN-predikátumban a streamek közötti csatlakozáskor.

5. A SELECT utasításban vagy bármely más lekérdezési záradékban létrehozott oszlopok nem használhatók a TIMESTAMP BY záradékban, a bemeneti hasznos adat mezőit kell használni. A KERESZT ALKALMAZ függvény eredménye például nem használható a TIMESTAMP BY célértékeként. Használhat azonban egy Azure Stream Analytics-feladatot, amely végrehajtja a CROSS APPLY-et, és egy második feladatot is használhat a TIMESTAMP BY végrehajtásához.

6. A System.Timestamp() nem használható a TIMESTAMP BY függvényben, mivel a TIMESTAMP BY a System.Timestamp() értékét határozza meg.

Examples

1. példa – Időbélyegmező elérése a hasznos adatokból

Mező használata EntryTime a hasznos adatokból eseményidőbélyegként

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime  

2. példa – A hasznos adatokBÓL származó UNIX-idő használata eseményidőbélyegként

A UNIX rendszerek gyakran a POSIX (vagy Epoch) időt használják, amely az 1970. január 1-jei csütörtök, 00:00:00 óra óta eltelt ezredmásodpercek száma.

Ez a példa bemutatja, hogyan használható az epochtime értéket tartalmazó numerikus "epochtime" mező eseményidőbélyegként.

SELECT  
      System.Timestamp(),  
      LicensePlate,  
      State  
FROM input TIMESTAMP BY DATEADD(millisecond, epochtime, '1970-01-01T00:00:00Z')  

3. példa – Heterogén időbélyegek

Képzelje el, hogy heterogén adatfolyamokat dolgoz fel, amelyek két típusú "A" és "B" eseményt tartalmaznak. Az "A" események időbélyeg-adatokkal rendelkeznek az "időbélyegA" mezőben, a "B" események pedig időbélyeget a "timestampB" mezőben.

Ez a példa bemutatja, hogyan írhat TIMESTAMP BY-t mindkét típusú esemény/időbélyeg használatához.

SELECT  
      System.Timestamp(),  
      eventType,  
      eventValue,  
FROM input TIMESTAMP BY  
      (CASE eventType   
            WHEN 'A' THEN timestampA  
            WHEN 'B' THEN timestampB  
      ELSE NULL END) 

4. példa – Több idősor kezelése particionált lekérdezésben

A különböző feladóktól (útdíjadóktól) származó adatok feldolgozása anélkül, hogy időszabályzatokat alkalmaz a különböző útdíj-állomásazonosítókra. A bemeneti adatok particionálása a TollId alapján történik.

SELECT
      TollId,
      COUNT(*) AS Count
FROM input
      TIMESTAMP BY EntryTime OVER TollId, PartitionId
      PARTITION BY PartitionId
GROUP BY TUMBLINGWINDOW(minute,3), TollId, PartitionId

See Also

System.Timestamp()
Időeltérés szabályzatai
Az Azure Stream Analytics időkezelésének ismertetése
Unix Time