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 süresi kavramları

Tartışmayı daha iyi çerçeveye getirmek 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 stand 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 işleminin net ilerleme durumunu belirtmesine olanak 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 yapılabilir. Ö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 zamanını 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. Tarafından zaman damgası 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 zaman nasıl ilerler?

Uygulama zamanını kullandığınızda, zaman ilerlemesi gelen olayları temel alır. Akış işleme sisteminin olay olup olmadığını veya olayların gecikmeli olup olmadığını 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ış zamanından geçen süredir.

Varış zamanı yalnızca gerçek varış zamanı Event Hubs gibi giriş olay aracısı üzerinde 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ında, 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çısından dengeyi 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 olduğu durumlar gibi gelen hiçbir olayın gelmediği bir dönem olabilir. Bu sorun, giriş olay aracısı içinde birden çok bölümün 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ışlardan etkilenebilir.
Sistem davranışının yinelenebilir olması gerekir. Yinelenebilirlik, akış veri işleme sisteminin önemli bir özelliğidir.

Filigran, varış saatinden ve uygulama saatinden 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 ekler.

Olay saati olarak varış saatini kullanmayı seçtiğinizde, orada sıra 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 olaylar

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

Filigranlar oluşturulduktan sonra hizmet, olay 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 göre 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 varyasyonu 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, sistemin olay gönderenler üzerindeki saat üzerinde çok az denetimi vardır. Olayı gönderenler, alanda, belki de farklı donanım ve yazılım sürümlerinde 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şinizdeki alt akışları kullanabilirsiniz. Alt akışın atanması için OVER anahtar sözcüğünden sonra bir anahtar sütun adı (örneğin, ) deviceidsağlayın; böylece sistem bu sütuna göre 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ı olabileceğ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 büyük olasılıkla çok küçüktür. 5 dakika ile başlamanızı ve cihaz saat dengesizliği desenine göre ayarlamalar yapmanızı öneririz.

Erken gelen olaylar

Geç varış tolerans penceresinin tersi gibi görünen erken varış penceresi olarak adlandırılan 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ş zamanını 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ıç zamanını 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 basittir: olay 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 tekrarlanabilir olmasını sağlamak için kullanılır. Böyle bir mekanizma olmadan, diğer birçok akış sisteminin iddia ettikleri gibi tekrarlanabilirliği garanti etmek mümkün olmaz.

Olay sıralama süresi toleranslarının yan etkileri

Stream Analytics işlerinin çeşitli Olay sıralama seçenekleri vardır. Azure portalında ikisi 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, çıkışa erken olaylar gönderilebilir. Erken gelen tüm olaylar bırakılır, bu nedenle çıkıştan hiçbirini görmezsiniz.
Azure Stream Analytics tarafından işlenmek üzere Event Hubs'a eski olayları 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ç gelen 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 hesaplanmış 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 süresi, 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. Gecikmeler, geç gelen olaylar penceresini büyük bir değere ayarladığınızda 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ştirirse, normalde aynı olur.

Gözlemlenen ölçümler

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

Metrik Sistem	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ındaki 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 olay 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ındaki 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 olayların 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 zamanı olarak hesaplanır ve şimdiye kadar gördüğü en büyük filigran çıkarılır. Daha fazla bilgi için filigran gecikmesi blog gönderisine bakın.

Bu ölçüm değerinin normal işlem altı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.
Filigran, tolerans penceresinin boyutuna göre 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 genişletmek 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 çeşidine göre büyük ölçüde farklılık gösterir.

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

Azure Stream Analytics, çıktı olayları üretmek 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. Pencerelenmiş 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ştikçe, 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şlenmesiyle elde edilir ve daha doğru bir çıkış elde edilir.

Filigranların resimli örneği

Aşağıdaki görüntülerde filigranların farklı koşullarda nasıl ilerleyişi gösterilmektedir.

Bu tabloda, aşağıda grafikte yer alan örnek veriler gösterilmektedir. Olay saatinin ve varış saatinin, bazen eşleşen ve bazen eşleşmeyen farklılık gösterdiğine dikkat 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

Bu olaylar boyunca ilerleyen filigran resmi:

Ö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 bırakılır.
  
  Filigran, erken bir olay söz konusu olduğunda ilerlemez.
3. Dördüncü olay (cihaz3) ve beşinci olay (cihaz1) 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 zamanı (12:12) filigran düzeyinin altındadır. Olay süresi, su işareti seviyesine (12:17) ayarlanır.
5. Onikinci olay (cihaz3) işlendiğinde, varış zamanı (12:27) olay saatinden 6 dakika öncedir (12:21). Geç varış ilkesi uygulanır. Olay zamanı, filigranın üzerinde (12:21) ayarlanmıştır (12:21) bu nedenle başka ayarlama uygulanmaz.
Erken varış ilkesi olmadan ilerleyen 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 (saat 12:11'de deviceId1) bu senaryoda bırakılmadığını ve filigranın 12:15'e yükselttiğine 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 olan birden çok filigran izlenir. Sonuç olarak zamanlarının ayarlandığı daha az olay vardır.