Azure Stream Analytics işlerinde denetim noktası ve yeniden yürütme kavramları
Bu makalede, Azure Stream Analytics ' deki iç denetim noktası ve yeniden yürütme kavramları ve bunların iş kurtarmasında etkileri açıklanmaktadır. Stream Analytics iş her çalıştığında durum bilgileri dahili olarak tutulur. Bu durum bilgileri düzenli aralıklarla bir denetim noktasına kaydedilir. Bazı senaryolarda, iş hatası veya yükseltme gerçekleşirse, iş kurtarma için denetim noktası bilgileri kullanılır. Başka bir durumda, 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şin benzersiz özelliğinden biri, pencereli toplamalar, zamana bağlı birleşimler ve zamana bağlı analitik işlevler gibi durum bilgisi olmayan bir işlem gerçekleştirmesinin bir özelliğidir. Bu işleçlerin her biri, iş çalıştırıldığında durum bilgilerini tutar. Bu sorgu öğeleri için en büyük pencere boyutu yedi gündür.
Zamana bağlı pencere kavramı çeşitli Stream Analytics sorgu öğelerinde görünür:
Pencereli toplamalar (Tdönerek gruplama, atlamalı ve kayan pencereler)
Zamana bağlı birleşimler (DATEDIFF ile BIRLEŞTIRME)
Zamana bağlı analitik işlevler (ıSFIRST, LAST ve LIMIT SÜRESI ile GECIKME)
İşletim sistemi yükseltmesi dahil olmak üzere düğüm hatasından iş kurtarma
Bir Stream Analytics işi her çalıştığında, dahili olarak birden çok çalışan düğümünde çalışacak şekilde ölçeklendirilir. Her çalışan düğümün durumu her birkaç dakikada bir denetim noktası olarak belirlenir ve bu da bir hata oluşursa sistemin kurtarılmasına yardımcı olur.
Her zaman, belirli bir çalışan düğümü başarısız olabilir veya çalışan düğümü için bir Işletim sistemi yükseltmesi meydana gelebilir. Otomatik olarak kurtarmak için, Stream Analytics yeni bir sağlıklı düğüm elde edin ve önceki çalışan düğümün durumu kullanılabilir en son denetim noktasından geri yüklenir. Çalışmayı sürdürdüğünüzde, durumu kontrol noktasının alındığı zamandan 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 sayıda akış birimi seçildiğinde, yeniden yürütme işlemi hızlı tamamlanmalıdır.
Tam paralel bir sorguda, bir çalışan düğümü hatasından sonra yakalamak için gereken süre şu şekilde orantılıdır:
[giriş olayı oranı] x [boşluk uzunluğu]/[işleme bölümlerinin sayısı]
Düğüm arızası ve işletim sistemi yükseltmesi nedeniyle önemli işlem gecikmesi gözlemlerseniz, sorguyu tamamen paralel hale getirmeyi düşünün ve işi daha fazla akış birimi ayırmaya göre ölçeklendirin. Daha fazla bilgi için bkz. işlem hızını artırmak için Azure Stream Analytics bir Işi ölçeklendirme.
Geçerli Stream Analytics, bu tür bir kurtarma işlemi gerçekleşirken rapor göstermez.
Hizmet yükseltmesinden iş kurtarma
Microsoft, Azure hizmetindeki Stream Analytics işleri çalıştıran ikilileri zaman zaman yükseltir. Bu saatlerde, 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.
Şu anda, kurtarma denetim noktası biçimi yükseltmeler arasında korunmaz. Sonuç olarak, akış sorgusunun durumu tamamen yeniden yürütme tekniği kullanılarak geri yüklenmelidir. Stream Analytics işlerin daha önce aynı girişi yeniden çalıştırmasına izin vermek için, kaynak veriler için bekletme ilkesinin en azından Sorgunuzdaki pencere boyutlarına ayarlanması önemlidir. Bunun başarısız olması, hizmet yükseltmesi sırasında yanlış veya kısmi sonuçlara neden olabilir. bu nedenle, kaynak veriler tam pencere boyutunu içerecek kadar geri saklanmayabilir.
Genel olarak, gereken yeniden yürütme miktarı, ortalama olay oranı ile çarpılan pencere boyutuyla orantılıdır. Örnek olarak, saniye başına 1000 etkinlikten oluşan bir iş için, bir saatten büyük bir pencere boyutu büyük bir yeniden yürütme boyutuna sahip olacak şekilde değerlendirilir. Bir saatlik verilerin tam ve doğru sonuçlar üretebilmesi için, bu durum, bazı genişletilmiş bir süre için geciken çıkış (çıkış yok) oluşmasına neden olabilecek şekilde yeniden işlenmesi gerekebilir. Windows ya da gibi diğer zamana bağlı işleçlere sahip JOIN sorguların LAG sıfır yeniden oynamış olması gerekir.
Tahmin yeniden yürütme yakalama süresi
Bir hizmet yükseltmesi nedeniyle gecikme süresini tahmin etmek için bu tekniği izleyebilirsiniz:
Sorgunuzun beklenen olay hızında en büyük pencere boyutunu kapsamak için, giriş olayı hub 'ını yeterli verilerle yükleyin. Etkinlik zaman damgası, canlı bir giriş akışımız gibi, bu süre boyunca o zaman içindeki duvar saati zamanına yakın olmalıdır. Örneğin, sorgunuzda 3 günlük bir pencere varsa olayları üç gün boyunca olay hub 'ına gönderin ve olayları gönderilmeye devam edin.
İşi Şimdi başlangıç saati olarak kullanmaya başlayın.
Başlangıç saati ile ilk çıktının oluşturulduğu zaman arasındaki süreyi ölçün. Bu süre, bir hizmet yükseltmesi sırasında işin ne kadar ertelendirileceğini kabaca doğurur.
Gecikme çok uzunsa, işinizi bölümleyip SUs sayısını artırarak yük daha fazla düğüme yayılmaya çalışın. Alternatif olarak, Sorgunuzdaki pencere boyutlarını azaltmayı göz önünde bulundurun ve aşağı akış havuzunda (örneğin, Azure SQL veritabanı kullanılarak) Stream Analytics işi tarafından oluşturulan çıktıda daha fazla toplama veya diğer durum bilgisi içeren işlem gerçekleştirin.
Görev açısından kritik işlerin yükseltilmesi sırasında genel hizmet kararlılığı sorunu için, eşlenmiş 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 iş güvenilirliğini garanti Stream Analytics.
Kullanıcı tarafından başlatılan durdurma ve başlatmadan iş kurtarma
Bir akış işinde sorgu söz dizimini düzenlemek veya girişleri ve çıkışları ayarlamak için, değişiklikleri yapmak ve iş tasarımını yükseltmek için işin durdurulması gerekir. Bu tür senaryolarda, bir Kullanıcı akış işini durdurduğu ve yeniden başlattığı zaman, Kurtarma senaryosu hizmet yükseltmesine benzerdir.
Denetim noktası verileri Kullanıcı tarafından başlatılan bir iş yeniden başlatması için kullanılamaz. Bu tür bir yeniden başlatma sırasında çıktının gecikmesini tahmin etmek için, önceki bölümde açıklanan yordamın aynısını kullanın ve gecikme çok uzunsa, benzer risk azaltma uygulayın.
Sonraki adımlar
Güvenilirlik ve ölçeklenebilirlik hakkında daha fazla bilgi için şu makalelere bakın: