TIMESTAMP BY (Azure Stream Analytics)

  • Cikk

Minden adatfolyam-eseményhez tartozik időbélyeg. Alapértelmezés szerint az Event Hub és a IoT Hub eseményeinek időbélyege attól függ, hogy az esemény mikor érkezett az Eseményközponthoz vagy IoT Hub; a Blob Storage-ból származó eseményeket a blob utolsó módosítási időpontja időbélyegzi. 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. Egy Értékesítési pont alkalmazásban például előfordulhat, hogy a fizetési naplózott időpontnak megfelelő eseményidőbélyegre van szükség, nem pedig arra az időre, amikor egy fizetési esemény eléri az eseménybetöltési szolgáltatást. Emellett a georedundáns rendszerek és a hálózati késések hozzájárulhatnak a kiszámíthatatlan érkezési időkhez, így az alkalmazásidőt megbízhatóbbá teheti a streamelési alkalmazásokban. Ezekben az esetekben a TIMESTAMP BY záradék lehetővé teszi 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 az időbélyegek szempontjából két okból is előfordulhat, hogy az eseményeket sorrendben betölti:

  • Az egyes eseménykészítők eltérő (és ferde) rendszerórát tartalmazhatnak.
  • Az egyes eseménygyártók eseményeit késleltetheti az átvitel, 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 zavar nagy lehet, az egyetlen termelő eseményein belüli zavar á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 előállító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, hogy lehetővé tegye az események feldolgozását a független idősorokban. Az OVER záradéknak a feladat feldolgozására gyakorolt hatásáról az "OVER záradék és az eseményrendezés interakciója" című témakörben olvashat.

Syntax

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

Megjegyzések

Esemény időbélyegének 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 módosul:

  1. A maximális rendelésen kívüli tűrés egyetlen értéken belül van alkalmazva, amely meghaladja a <specifikációt>. Vagyis egy eseményt csak akkor tekintünk rendelésen kívülinek, ha az túl nagy sorrendben érkezik meg ugyanabból az eseménygyártótól származó egyéb események tekintetében.

    Például a "0" érték akkor használható, ha az ugyanazon eseménygyártótól származó eseményeket mindig megrendelik, és azonnali feldolgozást eredményeznek. A nagy értékek használata viszont feldolgozási késéseket fog okozni, miközben megvárja a nem megfelelő események összeállítását.

  2. A maximális késé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őpontjától.

    Vegye figyelembe, hogy a nagy értékek itt való használata nem okoz feldolgozási késéseket, és az események feldolgozása továbbra is azonnal történik (vagy a rendelésen kívüli maximális tűréshatárnak megfelelően). A több napos érték nem ésszerűtlen. A rendkívül 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 elavult időbélyegekkel rendelkezhetnek; azonban ezek sorrendben lesznek egy adott értéken <belül, több mint specifikációval>.

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 kell használni, vagy egyikhez sem.

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

  3. Ha a bemeneti adatfolyam több partícióval is rendelkezik, az 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 CROSS APPLY 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 műveletet, é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.

Példák

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 adat UNIX-idejének 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., csütörtök, 00:00:00 óta eltelt idő.

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

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 adatstreameket dolgoz fel, amelyek két típusú "A" és "B" eseményt tartalmaznak. Az "A" események időbélyeg-adatai az "timestampA" mezőben, a "B" események pedig időbélyegzővel rendelkeznek az "timestampB" mezőben.

Ez a példa bemutatja, hogyan írhat TIMESTAMP BY parancsot, hogy mindkét típusú eseményt/időbélyeget használni tudja.

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 (díjköteles állomásoktól) származó adatokat anélkül dolgozza fel, hogy időszabályzatokat alkalmaz a különböző útdíjfizetési állomások azonosítóira. 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

Lásd még:

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