Aracılığıyla paylaş

Azure Stream Analytics işlerinde denetim noktası ve yeniden yürütme kavramları

  • Makale

Bu makalede Azure Stream Analytics'teki iç denetim noktası ve yeniden yürütme kavramları ve bunların iş kurtarma üzerindeki etkisi açıklanmaktadır. Stream Analytics işi her çalıştırıldığında, durum bilgileri dahili olarak korunur. Bu durum bilgileri düzenli aralıklarla bir denetim noktasına kaydedilir. Bazı senaryolarda, bir iş hatası veya yükseltme gerçekleşirse iş kurtarma için denetim noktası bilgileri kullanılır. Diğer durumlarda, denetim noktası kurtarma için kullanılamaz ve yeniden yürütme gereklidir.

Zamana bağlı öğelerde durum bilgisi olan sorgu mantığı

Azure Stream Analytics işinin benzersiz özelliğinden biri, pencereli toplamalar, zamana bağlı birleşimler ve zamana bağlı analiz işlevleri gibi durum bilgisi olan işlemler gerçekleştirmektir. İş çalıştırıldığında bu işleçlerin her biri durum bilgilerini tutar. Bu sorgu öğelerinin pencere boyutu üst sınırı yedi gündür.

Geçici pencere kavramı birkaç Stream Analytics sorgu öğesinde görünür:

  1. Pencereli toplamalar (Atlayan, Atlamalı ve Kayan pencerelerin GROUP BY'ı)

  2. Zamana bağlı birleşimler (DATEDIFF ile JOIN)

  3. Zamana bağlı analiz işlevleri (LIMIT DURATION ile ISFIRST, LAST ve LAG)

İşletim sistemi yükseltmesi de dahil olmak üzere düğüm hatasından iş kurtarma

Stream Analytics işi her çalıştırıldığında, birden çok çalışan düğümünde çalışmak için dahili olarak ölçeği genişletilir. Her çalışan düğümlerinin durumu birkaç dakikada bir kontrol noktalarına alınır ve bu da sistemin bir hata oluşursa kurtarılmasında yardımcı olur.

Bazen, belirli bir çalışan düğümü başarısız olabilir veya bu çalışan düğümü için bir İşletim Sistemi yükseltmesi gerçekleşebilir. Stream Analytics otomatik olarak kurtarmak için yeni bir iyi durumdaki düğüm alır ve önceki çalışan düğümlerinin durumu en son kullanılabilir denetim noktasından geri yüklenir. Çalışmaya devam etmek için, denetim noktasının alındığı zamandan itibaren durumu geri yüklemek için az miktarda yeniden yürütme gerekir. Genellikle geri yükleme boşluğu yalnızca birkaç dakikadır. İş için yeterli Akış Birimi seçildiğinde yeniden yürütmenin hızla tamamlanması gerekir.

Tam paralel sorguda, bir çalışan düğümü hatasından sonra yakalamak için gereken süre aşağıdakiyle orantılıdır:

[giriş olay hızı] x [boşluk uzunluğu] / [işleme bölümü sayısı]

Düğüm hatası ve işletim sistemi yükseltmesi nedeniyle önemli işlem gecikmesi gözlemlerseniz, sorguyu tamamen paralel hale getirmeyi ve daha fazla Akış Birimi ayırmak için işi ölçeklendirmeyi göz önünde bulundurun. Daha fazla bilgi için bkz. Aktarım hızını artırmak için Azure Stream Analytics işini ölçeklendirme.

Bu tür bir kurtarma işlemi gerçekleştiğinde geçerli Stream Analytics bir rapor göstermiyor.

Hizmet yükseltmesinden iş kurtarma

Microsoft zaman zaman Azure hizmetinde Stream Analytics işlerini çalıştıran ikili dosyaları yükseltmektedir. Bu zamanlarda kullanıcıların çalışan işleri daha yeni bir sürüme yükseltilir ve iş otomatik olarak yeniden başlatılır.

Azure Stream Analytics, son denetim noktası durumundan verileri geri yüklemek için mümkün olduğunda denetim noktalarını kullanır. İç denetim noktalarının kullanılamadığı senaryolarda, akış sorgusunun durumu tamamen yeniden yürütme tekniği kullanılarak geri yüklenir. Stream Analytics işlerinin daha önce tam olarak aynı girişi yeniden yürütmesine izin vermek için, kaynak veriler için bekletme ilkesini en azından sorgunuzdaki pencere boyutlarına ayarlamak önemlidir. Kaynak veriler tam pencere boyutunu içerecek kadar geri saklanamadığından, bunun yapılmaması hizmet yükseltmesi sırasında yanlış veya kısmi sonuçlara neden olabilir.

Genel olarak, gereken yeniden yürütme miktarı pencerenin ortalama olay hızıyla çarpılmasıyla orantılıdır. Örneğin, giriş hızı saniyede 1000 olay olan bir iş için, bir saatten büyük bir pencere boyutunun büyük bir yeniden yürütme boyutuna sahip olduğu kabul edilir. Tam ve doğru sonuçlar üretebilmesi için durumu başlatmak için bir saate kadar verilerin yeniden işlenmesi gerekebilir ve bu da uzun bir süre boyunca gecikmeli çıkışa (çıkış olmadan) neden olabilir. Penceresiz veya veya LAGgibi JOIN diğer zamansal işleçleri olmayan sorgular sıfır yeniden yürütmeye sahip olabilir.

Yeniden yürütme yakalama süresini tahmin

Hizmet yükseltmesi nedeniyle gecikme süresini tahmin etmek için şu tekniği izleyebilirsiniz:

  1. Giriş Event Hubs'ını sorgunuzdaki en büyük pencere boyutunu (beklenen olay hızında) kapsayacak kadar veriyle yükleyin. Olayların zaman damgası, canlı giriş akışı gibi bu süre boyunca duvar saati zamanına yakın olmalıdır. Örneğin, sorgunuzda 3 günlük bir pencere varsa, olayları üç gün boyunca Event Hubs'a gönderin ve olayları göndermeye devam edin.

  2. Başlangıç saati olarak Şimdi'yi kullanarak işi başlatın.

  3. Başlangıç saati ile ilk çıkışın oluşturulduğu zaman arasındaki süreyi ölçün. Hizmet yükseltmesi sırasında işin ne kadar gecikmeye neden olacağı kabaca bir süredir.

  4. Gecikme çok uzunsa, işinizi bölümlemeye ve SU sayısını artırmaya çalışın, böylece yük daha fazla düğüme yayılır. Alternatif olarak, sorgunuzdaki pencere boyutlarını azaltmayı göz önünde bulundurun ve aşağı akış havuzundaki Stream Analytics işi tarafından üretilen çıktıda daha fazla toplama veya durum bilgisi olan başka işlemler gerçekleştirin (örneğin, Azure SQL Veritabanı'nı kullanma).

Görev açısından kritik işlerin yükseltilirken genel hizmet kararlılığıyla ilgili endişeler için, eşleştirilmiş Azure bölgelerinde yinelenen işleri çalıştırmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Hizmet güncelleştirmeleri sırasında Stream Analytics iş güvenilirliğini garanti edin.

Kullanıcı tarafından başlatılan durdurma ve başlatma işlemlerinden iş kurtarma

Akış işinde Sorgu söz dizimini düzenlemek veya girişleri ve çıkışları ayarlamak için, değişikliklerin yapılması ve iş tasarımının yükseltilmesi için işin durdurulması gerekir. Bu tür senaryolarda, bir kullanıcı akış işini durdurup yeniden başlattığında, kurtarma senaryosu hizmet yükseltmesine benzer.

Kullanıcı tarafından başlatılan bir işin yeniden başlatılması için denetim noktası verileri kullanılamaz. Böyle bir yeniden başlatma sırasında çıkışın gecikmesini tahmin etmek için, önceki bölümde açıklanan yordamı kullanın ve gecikme çok uzunsa benzer azaltma uygulayın.

Sonraki adımlar

Güvenilirlik ve ölçeklenebilirlik hakkında daha fazla bilgi için şu makalelere bakın: