Azure Stream Analytics'te zaman işlemeyi anlama

Makale
01/23/2024

Bu makalede, Azure Stream Analytics işlerindeki pratik zaman işleme sorunlarını çözmek için tasarım seçimleri yapmayı öğreneceksiniz. Zaman işleme tasarım kararları olay sıralama faktörleriyle yakından ilgilidir.

Arka plan zamanı kavramları

Tartışmanın çerçevesini daha iyi belirlemek için bazı arka plan kavramlarını tanımlayalım:

Olay zamanı: Özgün olayın gerçekleştiği saat. Örneğin, otoyolda hareket eden bir araba ücretli bir standa yaklaştığında.
İşleme süresi: Olayın işleme sistemine ulaştığı ve gözlemlendiği zaman. Örneğin, ücretli bir kabin sensörü arabayı gördüğünde ve bilgisayar sisteminin verileri işlemesi birkaç dakika sürer.
Filigran: Akış işlemcisine hangi nokta olaylarının giriş yaptığını gösteren olay zamanı işaretçisi. Filigranlar, sistemin olayları alma konusunda net bir ilerleme göstermesini sağlar. Akışların doğası gereği, gelen olay verileri hiçbir zaman durmaz, bu nedenle filigranlar akışın belirli bir noktasına ilerleme durumunu gösterir.

Filigran kavramı önemlidir. Filigranlar, Stream Analytics'in sistemin ne zaman geri çekilmesi gerekmeyen eksiksiz, doğru ve yinelenebilir sonuçlar üretebileceğini belirlemesine olanak sağlar. İşleme tahmin edilebilir ve tekrarlanabilir bir şekilde gerçekleştirilebilir. Örneğin, bazı hata işleme koşulları için yeniden sayma yapılması gerekiyorsa, filigranlar güvenli başlangıç ve bitiş noktalarıdır.

Bu konuyla ilgili ek kaynaklar için Tyler Akidau'nun Streaming 101 ve Streaming 102 blog gönderilerine bakın.

En iyi başlangıç saatini seçin

Stream Analytics, kullanıcılara olay saatini seçmek için iki seçenek sunar: varış saati ve uygulama saati.

Varış saati

Olay kaynağa ulaştığında giriş kaynağına varış zamanı atanır. Event Hubs girişi için EventEnqueuedUtcTime özelliğini, IoT Hub girişi için IoTHub.EnqueuedTime özelliğini ve blob girişi için BlobProperties.LastModified özelliğini kullanarak varış zamanına erişebilirsiniz.

Varış zamanı varsayılan olarak kullanılır ve en iyi zamansal mantığın gerekli olmadığı veri arşivleme senaryolarında kullanılır.

Uygulama süresi (Olay Zamanı olarak da adlandırılır)

Uygulama zamanı, olay oluşturulduğunda atanır ve olay yükünün bir parçasıdır. Olayları uygulama zamanına göre işlemek için SELECT sorgusundaki Timestamp by yan tümcesini kullanın. Timestamp by yoksa, olaylar varış zamanına göre işlenir.

Kaynak sistemdeki veya ağdaki gecikmeleri hesaba katmak için zamansal mantık söz konusu olduğunda yükte bir zaman damgası kullanmak önemlidir. Bir olaya atanan süre SİSTEM'de kullanılabilir. ZAMAN DAMGASı.

Azure Stream Analytics'te süre nasıl ilerler?

Uygulama zamanını kullandığınızda, ilerleme süresi gelen olayları temel alır. Akış işleme sisteminin olay olup olmadığını veya olayların geciktirilip geciktirilmediğini bilmesi zordur. Bu nedenle Azure Stream Analytics, her giriş bölümü için aşağıdaki yollarla buluşsal filigranlar oluşturur:

Gelen bir olay olduğunda filigran, Stream Analytics'in şu ana kadar gördüğü en büyük olay zamanıdır ve sıra dışı tolerans penceresi boyutu çıkarılır.
Gelen olay olmadığında, filigran geçerli tahmini varış zamanı eksi geç varış toleransı penceresidir. Tahmini varış zamanı, bir giriş olayının son görüldüğü zamandan ve bu giriş olayının varış saatinden geçen süredir.

Varış süresi yalnızca gerçek varış zamanı Event Hubs gibi giriş olay aracısı veya olayları işleyen Azure Stream Analytics VM'sinde oluşturulduğundan tahmin edilebilir.

Tasarım, filigran oluşturma dışında iki ek amaca hizmet eder:

Sistem, gelen olaylarla veya olaylar olmadan zamanında sonuç oluşturur.

Çıkış sonuçlarını ne kadar zamanında görmek istediğinizi denetleyebilirsiniz. Azure portal, Stream Analytics işinizin Olay sıralama sayfasında Sıra dışı olaylar ayarını yapılandırabilirsiniz. Bu ayarı yapılandırırken, olay akışındaki sıra dışı olayların toleransıyla zaman aşımını göz önünde bulundurun.

Gelen olaylar olmasa bile filigran oluşturmaya devam etmek için geç varış tolerans penceresi gereklidir. Bazen, olay giriş akışının seyrek olması gibi gelen olayların gelmediği bir dönem olabilir. Bu sorun, giriş olay aracısı içinde birden çok bölüm kullanılmasıyla daha da şiddetlenir.

Girişler seyrek olduğunda ve birden çok bölüm kullanıldığında geç varış toleransı penceresi olmayan akış veri işleme sistemleri gecikmeli çıkışlara maruz kalabilir.
Sistem davranışının yinelenebilir olması gerekir. Yinelenebilirlik, akış veri işleme sisteminin önemli bir özelliğidir.

Filigran, varış saatinden ve uygulama zamanından türetilir. Her ikisi de olay aracısında kalıcı hale gelir ve bu nedenle yinelenebilir. Olayların olmadığı bir varış zamanı tahmin edildiğinde Azure Stream Analytics, hata kurtarma için yeniden yürütme sırasında tekrarlanabilirlik için tahmini varış zamanını günlüğe kaydeder.

Varış saatini etkinlik saati olarak kullanmayı seçtiğinizde, orada sipariş dışı toleransı ve geç varış toleransını yapılandırmanız gerekmez. Giriş olayı aracısında varış süresinin artacağı garanti olduğundan, Azure Stream Analytics yapılandırmaları göz ardı eder.

Geç gelen etkinlikler

Azure Stream Analytics, her gelen olay için geç varış toleransı penceresinin tanımına göre olay saatinivarış saatiyle karşılaştırır. Olay zamanı tolerans penceresinin dışındaysa, olayı bırakmak veya olayın saatini tolerans içinde olacak şekilde ayarlamak için sistemi yapılandırabilirsiniz.

Filigranlar oluşturulduktan sonra hizmet, etkinlik süresi filigrandan daha düşük olan olayları alabilir. Hizmeti bu olayları bırakacak şekilde yapılandırabilir veya olayın zamanını filigran değerine ayarlayabilirsiniz .

Ayarlamanın bir parçası olarak, olayın System.Timestamp değeri yeni değere ayarlanır, ancak olay zamanı alanının kendisi değiştirilmez. Bu ayarlama, bir olayın System.Timestamp değerinin olay zamanı alanındaki değerden farklı olabileceği ve beklenmeyen sonuçların oluşturulmasına neden olabileceği tek durumdur.

Zaman varyasyonlarını alt akışlarla işleme

Açıklanan buluşsal filigran oluşturma mekanizması, zamanın çoğunlukla çeşitli olay gönderenleri arasında eşitlendiği çoğu durumda iyi çalışır. Ancak, gerçek hayatta, özellikle de birçok IoT senaryosunda, sistem olay gönderenleri üzerinde saat üzerinde çok az denetime sahiptir. Olayı gönderenler, alanda, belki de farklı donanım ve yazılım sürümlerinde bulunan her türlü cihaz olabilir.

Stream Analytics, giriş bölümündeki tüm olaylar için genel bir filigran kullanmak yerine alt akışlar adlı başka bir mekanizmaya sahiptir. TIMESTAMP BY yan tümcesini ve OVER anahtar sözcüğünü kullanan bir iş sorgusu yazarak işinizde alt akışları kullanabilirsiniz. Alt akışı tasarlamak için OVER anahtar sözcüğünden sonra bir anahtar sütun adı (örneğin, ) deviceidsağlayın; böylece sistem bu sütuna zaman ilkeleri uygular. Her alt akış kendi bağımsız filigranını alır. Bu mekanizma, olay gönderenler arasında büyük saat dengesizlikleriyle veya ağ gecikmeleriyle ilgilenirken zamanında çıkış oluşturulmasına izin vermek için kullanışlıdır.

Alt akışlar, Azure Stream Analytics tarafından sağlanan benzersiz bir çözüm olup diğer akış veri işleme sistemleri tarafından sunulmaz.

Alt akışları kullandığınızda Stream Analytics, gelen olaylara geç varış toleransı penceresini uygular. Geç varış toleransı, farklı alt akışların birbirinden ayrılabileceği maksimum miktara karar verir. Örneğin, Cihaz 1 Zaman Damgası 1'de ve Cihaz 2 Zaman Damgası 2'deyse, en geç varış toleransı Zaman Damgası 2 eksi Zaman Damgası 1'dir. Varsayılan ayar 5 saniyedir ve farklı zaman damgalarına sahip cihazlar için çok küçük olabilir. 5 dakika ile başlamanızı ve cihaz saat dengesizliği desenine göre ayarlamalar yapmanızı öneririz.

Erken gelen etkinlikler

Erken varış penceresi olarak adlandırılan ve geç varış tolerans penceresinin tersi gibi görünen başka bir kavram fark etmiş olabilirsiniz. Bu pencere 5 dakikada düzeltilir ve geç varış tolerans penceresinden farklı bir amaca hizmet eder.

Azure Stream Analytics tam sonuçları garanti ettiğinden, giriş saatini değil yalnızca işin ilk çıkış zamanı olarak iş başlangıç zamanını belirtebilirsiniz. yalnızca pencerenin ortasından değil, tam pencerenin işlenmesi için iş başlangıç zamanı gereklidir.

Stream Analytics, başlangıç saatini sorgu belirtiminden türetir. Ancak, giriş olay aracısı yalnızca varış zamanına göre dizinlendiğinden, sistemin başlangıç olayı saatini varış zamanına çevirmesi gerekir. Sistem, giriş olay aracısında bu noktadan olayları işlemeye başlayabilir. Erken gelen pencere sınırıyla, çeviri oldukça basittir: başlangıç etkinliği zamanı eksi 5 dakikalık erken gelen pencere. Bu hesaplama, sistemin olay zamanına sahip olduğu görülen tüm olayları varış saatinden 5 dakika önce bırakması anlamına da gelir. Olaylar bırakıldığında erken giriş olayları ölçümü artırılır.

Bu kavram, nereden çıkış yapmaya başladığınızdan bağımsız olarak işlemenin yinelenebilir olmasını sağlamak için kullanılır. Böyle bir mekanizma olmadan, diğer birçok akış sisteminin iddia ettikleri gibi yinelenebilirliği garanti etmek mümkün olmazdı.

Olay sıralama zaman toleranslarının yan etkileri

Stream Analytics işlerinin çeşitli Olay sıralama seçenekleri vardır. Azure portal iki tane yapılandırılabilir: Sıra dışı olaylar ayarı (sıra dışı tolerans) ve Geç gelen olaylar ayarı (geç varış toleransı). Erken varış toleransı sabittir ve ayarlanamaz. Bu zaman ilkeleri Stream Analytics tarafından güçlü garantiler sağlamak için kullanılır. Ancak, bu ayarların bazen beklenmedik etkileri vardır:

Çok erken olan olayları yanlışlıkla gönderme.

Erken olaylar normal şekilde çıkarılmamalıdır. Gönderenin saati çok hızlı çalışıyorsa erken olayların çıkışa gönderilmesi mümkündür. Erken gelen tüm olaylar bırakılır, bu nedenle çıkıştan hiçbirini görmezsiniz.
Eski olayları Azure Stream Analytics tarafından işlenmek üzere Event Hubs'a gönderme.

Eski olaylar ilk başta zararsız görünse de, geç varış toleransının uygulanması nedeniyle eski olaylar bırakılabilir. Olaylar çok eskiyse, olay alımı sırasında System.Timestamp değeri değiştirilir. Bu davranış nedeniyle, şu anda Azure Stream Analytics geçmiş olay işleme senaryoları yerine neredeyse gerçek zamanlı olay işleme senaryoları için daha uygundur. Bazı durumlarda bu davranışa geçici bir çözüm bulmak için geç saate ulaşan Olayları mümkün olan en büyük değere (20 gün) ayarlayabilirsiniz.
Çıkışlar gecikmiş gibi görünüyor.

İlk filigran hesaplanan zamanda oluşturulur: sistemin şu ana kadar gözlemlediği maksimum olay süresi , sıra dışı tolerans penceresi boyutu çıkarılır. Varsayılan olarak, sıra dışı tolerans sıfır (00 dakika ve 00 saniye) olarak yapılandırılır. Bunu daha yüksek, sıfır olmayan bir zaman değerine ayarladığınızda, akış işinin ilk çıkışı, hesaplanan ilk filigran süresi nedeniyle bu zaman değeri (veya daha büyük) tarafından geciktirilir.
Girişler seyrektir.

Belirli bir bölümde giriş olmadığında, filigran zamanı varış saati eksi geç varış toleransı penceresi olarak hesaplanır. Sonuç olarak, giriş olayları seyrek ve seyrekse, çıkış bu kadar gecikmeli olabilir. Geç gelen varsayılan Olaylar değeri 5 saniyedir. Örneğin, giriş olaylarını birer birer gönderirken biraz gecikme görmeyi beklemeniz gerekir. Geç gelen olaylar penceresini büyük bir değere ayarladığınızda gecikmeler daha da kötü olabilir.
System.Timestamp değeri olay zamanı alanındaki zamandan farklıdır.

Daha önce açıklandığı gibi sistem, olay süresini sıra dışı tolerans veya geç varış toleransı pencerelerine göre ayarlar. Olayın System.Timestamp değeri ayarlanır, ancak olay zamanı alanı ayarlanmaz. Bu, zaman damgalarının hangi olaylar için ayarlanacağını belirlemek için kullanılabilir. Sistem toleranslardan biri nedeniyle zaman damgasını değiştirdiyse, normalde aynı olur.

Gözlemlenmek için ölçümler

Azure Stream Analytics iş ölçümleri aracılığıyla Olay sıralama zaman toleransı etkilerinin bir dizisini gözlemleyebilirsiniz. Aşağıdaki ölçümler geçerlidir:

Ölçüm	Açıklama
Sıra Dışı Olaylar	Bırakılan veya ayarlanmış bir zaman damgası verilen sıra dışı olarak alınan olayların sayısını gösterir. Bu ölçüm, Azure portal işin Olay sıralama sayfasındaki Sıra dışı olayları ayarının yapılandırmasından doğrudan etkilenir.
Geç Giriş Olayları	Kaynaktan geç gelen olayların sayısını gösterir. Bu ölçüm, bırakılan veya zaman damgasının ayarlandığı olayları içerir. Bu ölçüm, Azure portal işin Olay sıralama sayfasında geç gelen olaylar ayarının yapılandırmasından doğrudan etkilenir.
Erken Giriş Olayları	Kaynaktan erken gelen ve bırakılan olay sayısını gösterir veya zaman damgası 5 dakikadan erkense ayarlanmıştır.
Filigran Gecikmesi	Akış veri işleme işinin gecikmesini gösterir. Aşağıdaki bölümde daha fazla bilgi bulabilirsiniz.

Filigran gecikme ayrıntıları

Filigran gecikmesi ölçümü, işleme düğümünün duvar saati saati ile şimdiye kadar gördüğü en büyük filigranı çıkararak hesaplanır. Daha fazla bilgi için filigran gecikmesi blog gönderisine bakın.

Bu ölçüm değerinin normal işlem kapsamında 0'dan büyük olmasının birkaç nedeni olabilir:

Akış işlem hattının doğal işleme gecikmesi. Normalde bu gecikme nominaldir.
Eşik tolerans penceresinin boyutu küçüldüğünden, sıra dışı tolerans penceresi gecikmeye neden oldu.
Filigran tolerans penceresinin boyutuna göre küçüldüğünden geç varış penceresi gecikmeye neden oldu.
Ölçümü oluşturan işleme düğümünün saat dengesizliği.

Akış işlem hattının yavaşlamasına neden olabilecek başka kaynak kısıtlamaları da vardır. Eşik gecikmesi ölçümü aşağıdaki nedenlerle artabilir:

Stream Analytics'te giriş olaylarının hacmini işlemek için yeterli işlem kaynağı yok. Kaynakların ölçeğini artırmak için bkz. Akış Birimlerini anlama ve ayarlama.
Giriş olayı aracıları içinde yeterli aktarım hızı olmadığından kısıtlanırlar. Olası çözümler için bkz. Azure Event Hubs aktarım hızı birimlerinin ölçeğini otomatik olarak artırma.
Çıkış havuzları yeterli kapasiteyle sağlanmadığından kısıtlanır. Olası çözümler, kullanılan çıkış hizmetinin türüne göre büyük ölçüde farklılık gösterir.

Çıkış olayı sıklığı

Azure Stream Analytics, çıkış olayları oluşturmak için tek tetikleyici olarak filigran ilerleme durumunu kullanır. Filigran giriş verilerinden türetildiğinden, hata kurtarma sırasında ve kullanıcı tarafından başlatılan yeniden işlemede yinelenebilir. Pencereli toplamaları kullanırken, hizmet yalnızca pencerelerin sonunda çıkışlar üretir. Bazı durumlarda, kullanıcılar pencerelerden oluşturulan kısmi toplamaları görmek isteyebilir. Kısmi toplamalar şu anda Azure Stream Analytics'te desteklenmemektedir.

Diğer akış çözümlerinde çıkış olayları dış koşullara bağlı olarak çeşitli tetikleyici noktalarında gerçekleştirilebilir. Bazı çözümlerde belirli bir zaman penceresi için çıkış olaylarının birden çok kez oluşturulabileceği mümkündür. Giriş değerleri iyileştirilirken toplama sonuçları daha doğru hale gelir. Olaylar ilk başta kurgulanabilir ve zaman içinde düzeltilebilir. Örneğin, belirli bir cihaz ağdan çevrimdışı olduğunda, sistem tarafından tahmini bir değer kullanılabilir. Daha sonra aynı cihaz ağa çevrimiçi olarak gelir. Ardından gerçek olay verileri giriş akışına dahil edilebilir. Çıkış, bu zaman penceresinin işlenmesi sonucunda daha doğru bir çıkış üretir.

Resimli filigran örneği

Aşağıdaki resimler filigranların farklı koşullarda nasıl ilerleyişini göstermektedir.

Bu tabloda aşağıda grafikte yer alan örnek veriler gösterilmektedir. Olay saatinin ve varış saatinin bazen eşleşip bazen eşleşmediğini fark edin.

Etkinlik saati	Varış saati	DeviceId
12:07	12:07	cihaz1
12:08	12:08	cihaz2
12:17	12:11	cihaz1
12:08	12:13	cihaz3
12:19	12:16	cihaz1
12:12	12:17	cihaz3
12:17	12:18	cihaz2
12:20	12:19	cihaz2
12:16	12:21	cihaz3
12:23	12.22	cihaz2
12.22	12:24	cihaz2
12:21	12:27	cihaz3

Bu çizimde aşağıdaki toleranslar kullanılmıştır:

Erken varış pencereleri 5 dakikadır
Geç gelen pencere 5 dakikadır
Yeniden sıralama penceresi 2 dakikadır

Filigranın şu olaylar boyunca ilerletilmesine ilişkin çizim:

Önceki grafikte gösterilen önemli işlemler:
1. İlk olay (cihaz1) ve ikinci olay (device2) zamanları hizalanmış ve ayarlama yapılmadan işlenir. Filigran her olayda ilerler.
2. Üçüncü olay (cihaz1) işlendiğinde, varış saati (12:11) olay saatinden önce (12:17) olur. Etkinlik 6 dakika erken ulaştığından, 5 dakikalık erken varış toleransı nedeniyle etkinlik düşer.
  
  Bu erken olay durumunda filigran ilerlemiyor.
3. Dördüncü olay (cihaz3) ve beşinci olay (device1) zamanları hizalanmış ve ayar yapılmadan işlenir. Filigran her olayda ilerler.
4. Altıncı olay (cihaz3) işlendiğinde, varış zamanı (12:17) ve olay saati (12:12) filigran düzeyinin altındadır. Olay zamanı su işareti düzeyine (12:17) ayarlanır.
5. Onikinci olay (cihaz3) işlendiğinde, varış zamanı (12:27) etkinlik saatinden 6 dakika öncedir (12:21). Geç varış politikası uygulanır. Olay zamanı, filigranın (12:21) üzerinde olan ayarlanır (12:22), bu nedenle başka bir ayar uygulanmaz.
Erken varış ilkesi olmadan devam eden filigranın ikinci çizimi:

Bu örnekte erken varış ilkesi uygulanmaz. Erken gelen aykırı değer olayları filigranı önemli ölçüde yükseltir. Üçüncü olayın (12:11 saatinde deviceId1) bu senaryoda bırakılmadığını ve filigranın 12:15'e yükseltildiğinden dikkat edin. Dördüncü olay zamanı, sonuç olarak 7 dakika ileriye (12:08- 12:15) ayarlanır.
Son çizimde, alt akışlar kullanılır (DeviceId üzerinden). Akış başına bir tane olacak şekilde birden çok filigran izlenir. Sonuç olarak zamanlarının ayarlandığı daha az olay vardır.