Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
✅ Azure Stream Analytics ✅ Fabric Olay Akışı
Uyarı
Fabric Eventstream, Azure Stream Analytics ile aynı çalışma zamanı üzerinde oluşturulur. Bu nedenle, bu makalede açıklanan kavramlar hem Azure Stream Analytics hem de Doku Olay Akışı için geçerlidir.
Tüm veri akışı olaylarının kendisiyle ilişkilendirilmiş bir zaman damgası vardır. Varsayılan olarak Event Hubs ve IoT Hub'daki olaylar, event'in Event Hubs veya IoT Hub tarafından ne zaman alındığına göre zaman damgasına alınır; Blob depolamadan gelen olaylar, blob'un son değiştirme zamanı tarafından zaman damgasına eklenir. İşinizi yeniden başlattığınızda veya yeniden çalıştırırsanız bir olayın zaman damgası değişmez.
Birçok akış uygulaması, varış saati yerine bir olayın gerçekleştiği tam zaman damgasını kullanmayı gerektirir. Örneğin, bir Satış Noktası uygulamasında, bir ödeme olayının olay alma hizmetine ulaşması yerine ödemenin günlüğe kaydedilildiği zamana karşılık gelen olay zaman damgaları gerekebilir. Buna ek olarak, coğrafi olarak dağıtılmış sistemler ve ağ gecikme süreleri öngörülemeyen varış sürelerine katkıda bulunarak uygulama süresinin akış uygulamasında daha güvenilir bir şekilde kullanılmasını sağlayabilir. Bu durumlarda TIMESTAMP BY yan tümcesi özel zaman damgası değerlerinin belirtilmesine olanak tanır. Değer, olay yükünden veya DATETIME türündeki ifadeden herhangi bir alan olabilir. ISO 8601 biçimlerinden herhangi birine uyan dize değerleri de desteklenir.
Özel bir zaman damgası (TIMESTAMP BY yan tümcesi) kullanmak, Azure Stream Analytics'in olayları zaman damgalarına göre sıra dışı bir şekilde almasına neden olabilir:
- Tek tek olay üreticilerinin farklı (ve çarpık) sistem saatleri olabilir.
- Tek tek olay üreticilerinden gelen olaylar, örneğin üreticinin sitesinde ağ kullanılamadığı için aktarımda gecikebilir.
Olay üreticileri arasındaki bozukluk büyük olsa da, tek bir üreticiden gelen olaylardaki bozukluk genellikle küçük, hatta var olmayandır. Bir sorgu yalnızca her olay üreticisinden gelen verileri bağımsız olarak işlerse, her üreticinin olaylarını kendi zaman çizelgesinde işlemek, üreticiler arasındaki zaman dengesizliklerini yönetmekten daha verimlidir. Azure Stream Analytics, olayların bağımsız zaman çizelgelerinde işlenmesini sağlamak için OVER <over belirtim> alt öğesini belirterek alt akışları destekler. OVER yan tümcesinin kullanımının işin işlenmesi üzerindeki etkisi için bkz. 'OVER yan tümcesi olay sıralamasıyla etkileşim kurar'.
Syntax
TIMESTAMP BY scalar_expression [OVER <over spec> ]
<over spec> ::=
{ column_name | expression } [,...n ]
Remarks
Olay zaman damgası alınıyor
Olay zaman damgası, System.Timestamp() özelliği kullanılarak sorgunun herhangi bir bölümündeki SELECT deyiminde alınabilir.
OVER yan tümcesi olay sıralamasıyla etkileşim kurar
OVER yan tümcesi kullanıldığında, Azure Stream Analytics tarafından olay işlemenin çeşitli yönleri değiştirilir:
Maksimum sıra dışı tolerans, belirtim üzerinden< tek bir değer tanımlama grubu >içinde uygulanır. Başka bir deyişle, bir olay yalnızca aynı olay üreticisinden gelen diğer olaylarla ilgili olarak çok fazla sıra dışı gelirse sıra dışı olarak kabul edilir.
Örneğin, aynı olay üreticisinden gelen olaylar her zaman sıralıysa ve anında işlemeyle sonuçlanırsa '0' değeri kullanılabilir. Öte yandan, burada büyük değerlerin kullanılması, sıra dışı olayların birleştirilmesini beklerken işleme gecikmelerine neden olur.
En yüksek geç varış toleransı genel olarak uygulanır (OVER kullanılmamış gibi). Başka bir ifadeyle, seçilen zaman damgası (TIMESTAMP BY yan tümcesinde) varış zamanından çok uzaktaysa bir olayın geç geldiği kabul edilir.
Burada büyük değerlerin kullanılması işlem gecikmelerine neden olmaz ve olaylar hemen (veya en yüksek sıra dışı toleransa göre) işlenmeye devam eder. Birkaç günlük bir değer makul değildir. Ancak, olağanüstü uzun değerlerin kullanılması, işi işlemek için gereken bellek miktarını etkileyebilir.
Her olay üreticisi için çıkış olayları hesaplandıklarında oluşturulur ve bu da çıkış olaylarının sıra dışı zaman damgaları olabileceği anlamına gelir; ancak bunlar, fazla belirtimli> tek bir değer tanımlama grubu <içinde sıralı olacaktır.
Sınırlamalar ve Kısıtlamalar
TIMESTAMP BY OVER yan tümcesi aşağıdaki kullanım sınırlamalarına sahiptir:
TIMESTAMP BY OVER yan tümcesi, sorgunun tüm girişleri için kullanılmalıdır veya hiçbiri için kullanılmamalıdır.
TIMESTAMP BY OVER yan tümcesi yalnızca tam paralel işlerde veya tek bölüm işleriyle desteklenir.
Giriş akışında birden fazla bölüm varsa OVER yan tümcesi PARTITION BY yan tümcesiyle birlikte kullanılmalıdır. PartitionId sütunu TIMESTAMP BY OVER sütunlarının bir parçası olarak belirtilmelidir.
TIMESTAMP BY OVER yan tümcesi kullanılırsa, yan tümcesindeki sütun adları, akışlar arasında birleştirme sırasında GROUP BY deyimlerinde ve tüm JOIN koşullarında gruplandırma anahtarı olarak kullanılmalıdır.
SELECT deyiminde veya diğer sorgu yan tümcelerinde oluşturulan sütunlar TIMESTAMP BY yan tümcesinde kullanılamaz. Giriş yükünden bir alan kullanılmalıdır. Örneğin, CROSS APPLY sonucu TIMESTAMP BY hedef değeri olarak kullanılamaz. Ancak, CROSS APPLY işlemini gerçekleştiren bir Azure Stream Analytics işi kullanabilir ve TIMESTAMP BY işlemini gerçekleştirmek için ikinci bir iş kullanabilirsiniz.
System.Timestamp() değerini oluşturan TIMESTAMP BY olduğundan, System.Timestamp() TIMESTAMP BY içinde kullanılamaz.
Examples
Örnek 1 – Yükten bir zaman damgası alanına erişme
Yükün alanını olay zaman damgası olarak kullanma EntryTime
SELECT
EntryTime,
LicensePlate,
State
FROM input TIMESTAMP BY EntryTime
Örnek 2 – Yükten UNIX zamanını olay zaman damgası olarak kullanma
UNIX sistemleri genellikle 00:00:00 Eşgüdümlü Evrensel Saat (UTC), Perşembe, 1 Ocak 1970'ten bu yana geçen milisaniye sayısı olarak tanımlanan POSIX (veya Dönem) süresini kullanır.
Bu örnekte, olay zaman damgası olarak Dönem süresi içeren sayısal epochtime alanın nasıl kullanılacağı gösterilmektedir.
SELECT
System.Timestamp(),
LicensePlate,
State
FROM input TIMESTAMP BY DATEADD(millisecond, epochtime, '1970-01-01T00:00:00Z')
Örnek 3 – Heterojen zaman damgaları
A ve B olayları içeren iki tür olay içeren heterojen veri akışlarını işlediğini düşünün. A olayları alanında timestampA zaman damgası verilerine ve B olayları alanında zaman damgasına timestampBsahiptir.
Bu örnekte, her iki olay/zaman damgası türüyle de çalışabilmek için TIMESTAMP BY yazma işlemi gösterilmektedir.
SELECT
System.Timestamp(),
eventType,
eventValue,
FROM input TIMESTAMP BY
(CASE eventType
WHEN 'A' THEN timestampA
WHEN 'B' THEN timestampB
ELSE NULL END)
Örnek 4 – Bölümlenmiş sorguda birden çok zaman çizelgesini işleme
Farklı ücretli istasyon kimliklerine zaman ilkeleri uygulamadan farklı gönderenlerden (ücretli istasyonlar) verileri işleyin. Giriş verileri TollId temelinde bölümlenmiştir.
SELECT
TollId,
COUNT(*) AS Count
FROM input
TIMESTAMP BY EntryTime OVER TollId, PartitionId
PARTITION BY PartitionId
GROUP BY TUMBLINGWINDOW(minute,3), TollId, PartitionId
Ayrıca Bkz.
System.Timestamp()
Zaman Dengesizliği İlkeleri
Azure Stream Analytics'te zaman işlemeyi anlama
Unix Saati