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'te zaman işleme, akış olaylarının ne zaman oluştuğuna ve ne zaman geldiklerine göre zaman damgasını nasıl alındığını, sıralandığını ve işlendiğini belirleyen mekanizmalar kümesidir. Bu makalede, Azure Stream Analytics işlerindeki pratik zaman işleme sorunlarını çözmek için tasarım seçimleri yapma adımları açıklanmaktadır. 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, bir gişe sensörü arabayı gördüğünde ve bilgisayar sistemi verileri işleyip sonuçları birkaç saniye içinde verdiğinde.
Filigran: Akış işlemcisinin olayları hangi noktaya kadar alıp işlediğini gösteren bir 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, Azure Stream Analytics'in sistemin ne zaman geri çekilmesi gerekmeyen tam, 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
Azure Stream Analytics, olay zamanını seçmek için size 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. 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 zaman SYSTEM.TIMESTAMP'te mevcuttur.
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 heuristik filigranlar oluşturur.
Gelen bir olay olduğunda filigran, Azure Stream Analytics'in şu ana kadar gördüğü en büyük olay zamanıdır, ancak bu hesaplamaya sıra dışı olay tolerans penceresi boyutu dahil edilmez.
Gelen bir olay olmadığında, filigran mevcut tahmini varış zamanından geç varış toleransı süresi çıkarıldığında elde edilen sonuçtur. 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.
Gerçek varış zamanı, olayları işleyen Azure Stream Analytics VM'sinde değil giriş olay aracısı üzerinde (Event Hubs veya IoT Hub gibi) oluşturulduğundan, varış zamanı yalnızca tahmin edilebilir.
Tasarım, filigran oluşturma dışında iki ek amaca hizmet eder:
Sistem, gelen olaylar olsa da olmasa da 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 olması gibi gelen olayları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ı olarak saklanır ve bu nedenle tekrar edilebilir. Olay olmadığında bir varış zamanı tahmin edildiğinde, Azure Stream Analytics hata kurtarma için tekrar oynatma sırasında tekrarlanabilirlik sağlamak amacıyla tahmini varış zamanını kaydeder.
Olay zamanı olarak varış saatini kullanmayı seçtiğinizde, sıra dışı toleransı ve geç varış toleransını yapılandırmanız gerekmez. Giriş olay aracısında varış süresinin artacağı garanti edildiğinden, 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ış saatiylekarşı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 varyasyonunu alt akışlarla ele alma
Azure Stream Analytics'in en büyük gözlenen zaman damgası ile tolerans penceresi arasındaki farkı kullanarak olay zamanı ilerlemesini izlediği sezgisel filigran oluşturma mekanizması, zamanın çoğunlukla çeşitli olay göndericileri arasında senkronize olduğu pek çok 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. Etkinlik göndericiler, sahada bulunan, belki farklı donanım ve firmware sürümlerine sahip her türlü IoT cihaz olabilir.
Azure 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ışı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 bir 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ı kullandığınızda, Azure 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 fazla geç varış toleransı Zaman Damgası 2 eksi Zaman Damgası 1'dir. Varsayılan geç varış toleransı ayarı 5 saniyedir ve bu ayar farklı zaman damgalarına sahip IoT cihazları için büyük olasılıkla çok küçüktür. 5 dakika ile başlayın ve cihazınızın saat dengesizliği düzenine göre ayarlamalar yapın.
Erken gelen olaylar
** Erken varış penceresi, bir olayın gerçekleşme süresinden ne kadar erken gelebileceğini, Azure Stream Analytics'in onu bırakmadan önce belirleyen sabit bir 5 dakikalık toleranstır. Bu pencere geç varış tolerans penceresinden farklı bir amaca hizmet eder.
Azure Stream Analytics kesin sonuçlar garanti ettiğinden, iş başlangıç zamanını yalnızca işin ilk çıkış zamanı olarak belirleyebilirsiniz, giriş zamanı olarak değil. sistemin yalnızca pencerenin ortasından değil, tam pencereyi işlemesi için iş başlangıç zamanı gereklidir.
Azure 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ı ile, çeviri basittir: olay başlangıç zamanı eksi erken gelen 5 dakikalık 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ğlar. 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
Azure 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. Azure Stream Analytics, güçlü garantiler sağlamak için bu zaman ilkelerini kullanır. Ancak, bu ayarların bazen beklenmedik etkileri vardır:
Çok erken olan olayları yanlışlıkla gönderme.
Erken olayların normalde çıktısı alınmamalıdır. Gönderenin saati çok hızlı çalışıyorsa çıkışa erken olaylar gönderilebilir. Tüm erken gelen etkinlikler bırakılır, bu yüzden bunlardan hiçbirini çıkışta 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 Azure Stream Analytics, geçmiş olay işleme senaryolarına göre neredeyse gerçek zamanlı olay işleme senaryoları için daha uygundur. Bu davranışı bazı durumlarda aşmak için Geç gelen Olaylar zamanını en büyük mümkün değer olan 20 güne ayarlayabilirsiniz.
Çıkışlar gecikiyor gibi görünüyor.
İlk filigran hesaplanmış zamanda oluşturulur: sistemin şu ana kadar gözlemlediği maksimum etkinlik süresi, sistemin üzerine kurulu sıra dışı tolerans penceresi boyutu çıkarıldığında. Varsayılan olarak, sırasız işlem toleransı sıfır (00 dakika ve 00 saniye) olarak yapılandırılır. Bunu daha yüksek, sıfırdan farklı bir zamana ayarladığınızda, akış işinin ilk çıktısı, hesaplanan ilk filigran zamanı nedeniyle bu süre kadar (veya daha uzun) gecikir.
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 seyrek aralıklarla ise, çıkış bu miktarda gecikebilir. Varsayılan Geç gelen 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ı ayarlanmamıştır. Zaman damgalarının hangi olaylar için ayarlandığını belirlemek için bunu kullanabilirsiniz. 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 | Açıklama |
|---|---|
| Sıra Dışı Olaylar | Sırasız olarak alınan ve ya bırakılan ya da zaman damgası düzeltilmiş 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 metrik, ihmal edilen veya zaman damgası ayarlanmış olayları içerir. Azure portalındaki işin Olay sıralama sayfasında, geç gelen olaylar ayarının yapılandırması bu ölçümü doğrudan etkiler. |
| Erken Giriş Olayları | Kaynaktan erken gelen, bırakılmış veya zaman damgası ayarlanan ve 5 dakikadan daha erken gelen olayların sayısını gösterir. |
| Filigran Gecikmesi | Akış veri işleme işinin gecikmesini gösterir. Daha fazla bilgi için aşağıdaki bölüme bakın. |
Filigran gecikme ayrıntıları
Azure Stream Analytics, Filigran gecikmesi ölçümünü işleme düğümünün duvar saati süresi olarak hesaplar ve şimdiye kadar gördüğü en büyük filigranı çıkararak belirler. Daha fazla bilgi için bkz. filigran gecikmesi.
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 yapısal bir özelliği olan işleme gecikmesi. Normalde bu gecikme nominaldir.
Düzen dışı tolerans penceresi, filigranın tolerans penceresinin boyutuna göre küçülmesi nedeniyle 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 birkaç kaynak kısıtlaması daha vardır. Eşik gecikmesi ölçümü aşağıdaki nedenlerle artabilir:
Azure Stream Analytics'te giriş olaylarının hacmini işlemek için yeterli işlem kaynağı yok. Kaynakları ölçeklendirmek için Akış Birimlerini anlama ve ayarlama konusuna bakın.
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 birimlerinin ölçeğini otomatik olarak artırma.
Çıkış havuzları (Azure SQL Veritabanı, Blob Depolama veya Power BI gibi) yeterli kapasiteyle sağlanmadığından kısıtlanır. Olası çözümler, kullanılan çıkış hizmetine 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, pencerelerden oluşturulan kısmi toplamaları görmek isteyebilirsiniz. Kısmi toplamalar şu anda Azure Stream Analytics'te desteklenmemektedir.
Diğer akış çözümlerinde, çıkış olayları harici koşullara bağlı olarak çeşitli tetikleyici noktalarında somutlaştırılabilir. Bazı çözümlerde belirli bir zaman penceresi için çıkış olaylarının birden çok kez oluşturulabilmesi 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 çevrimiçi olarak ağa bağlanır. Ardından gerçek olay verileri giriş akışına dahil edilebilir. İşlenen bu zaman penceresi, daha doğru bir çıktı üretir.
Filigranların görselli ö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ış penceresi 5 dakikadır
- Geç gelen pencere 5 dakikadır
- Yeniden sıralama penceresi 2 dakikadır
Bu olaylar boyunca filigranın geçişini/gösterimini tasvir eden illüstrasyon:
Önceki grafikte gösterilen önemli işlemler:
İlk olay (cihaz1) ve ikinci olay (device2) zamanları hizalanmış ve ayarlama yapılmadan işlenir. Filigran her bir olayda ilerleme kaydeder.
Üçüncü olay (cihaz1) işlendiğinde, varış saati (12:11) olay saatinden önce (12:17) olur. Etkinlik 6 dakika erken ulaştığı için, 5 dakikalık erken varış toleransını aştığından etkinlik programdan çıkarılır.
Filigran, erken bir olay söz konusu olduğunda ilerlemez.
Dördüncü olay (cihaz3) ve beşinci olay (cihaz1) zamanları hizalanmış ve ayar yapılmadan işlenir. Filigran her etkinlikte ilerler.
Altıncı olay (cihaz3) işlendiğinde, varış zamanı (12:17) ve olay saati (12:12) filigran düzeyinin altındadır. Etkinlik zamanı, filigran seviyesine (12:17) ayarlanır.
Onikinci olay (cihaz3) işlendiğinde, varış zamanı (12:27) olay saatinden 6 dakika öncedir (12:21). Geç varış ilkesi uygulanır. Olay zamanı (12:22), filigranın üzerinde (12:21) ayarlanmıştır, bu nedenle başka ayarlama uygulanmaz.
Erken varış ilkesi olmadan ilerleyen filigranın ikinci gösterimi:
Bu örnekte erken varış ilkesi uygulanmaz. Erken gelen aykırı değer olayları eşik değerini önemli ölçüde yükseltir. Üçüncü olayın (deviceId1 saat 12:11) bu senaryoda düşürülmediğine ve filigranın 12:15'e yükseltildiğ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). Her akış için bir tane olmak üzere birden çok filigran izlenir. Sonuç olarak zaman ayarlaması yapılan daha az olay vardır.
