Stream Analytics akış birimlerini anlama ve ayarlama

Akış birimini ve akış düğümünü anlama

Akış birimleri (SU), Stream Analytics işini yürüten bilgi işlem kaynaklarını temsil eder. SU sayısı ne kadar yüksekse, işiniz için o kadar fazla CPU ve bellek kaynağı ayırırsınız. Bu kapasite sorgu mantığına odaklanmanızı sağlar ve Stream Analytics işinizi zamanında çalıştırmak için donanımı yönetme gereksinimini soyutlar.

Azure Stream Analytics iki akış birimi yapısını destekler: SU V1 (kullanım dışı bırakılacak) ve SU V2 (önerilen).

SU V1 modeli, Azure Stream Analytics'in her 6 SU'nun bir iş için tek bir akış düğümüne karşılık geldiği özgün teklifidir. İşler, 1 ve 3 SU ile de çalışabilir ve bunlar kesirli akış düğümlerine karşılık gelir. Ölçeklendirme, dağıtılmış bilgi işlem kaynakları sağlayan daha fazla akış düğümü ekleyerek 6'nın üzerinde 6 SU işi ile 12, 18, 24 ve üzeri artışlarla gerçekleşir.

SU V2 modeli (önerilen), aynı işlem kaynakları için uygun fiyatlandırmaya sahip basitleştirilmiş bir yapıdır. SU V2 modelinde 1 SU V2, işiniz için bir akış düğümüne karşılık gelir. 2 SU V2, 2 akış düğümüne, 3 ile 3 arasında vb. karşılık gelir. 1/3 ve 2/3 SU V2'lerine sahip işler, bir akış düğümü ve yalnızca bilgi işlem kaynaklarının bir kısmıyla da kullanılabilir. 3/1 ve 2/3 SU V2 işleri, daha küçük ölçekli iş yükleri için uygun maliyetli bir seçenek sağlar.

Aşağıdaki tabloda V1 ve V2 akış birimleri için temel alınan işlem gücü gösterilmektedir:

SU fiyatlandırması hakkında bilgi için Azure Stream Analytics Fiyatlandırma Sayfası'nı ziyaret edin.

Akış birimi dönüştürmelerini ve bunların nereye uygulanacağını anlama

Sistem, akış birimlerini REST API katmanından kullanıcı arabirimine (Azure portalı ve Visual Studio Code) otomatik olarak dönüştürür. Bu dönüştürmeyi Etkinlik günlüğünde de görürsünüz; burada akış birimi değerleri kullanıcı arabirimindeki değerlerden farklı görünür. Bu davranış tasarım gereğidir. REST API alanları tamsayı değerleriyle sınırlıdır, ancak Stream Analytics işleri kesirli düğümleri (1/3 ve 2/3 akış birimleri) destekler. Azure Stream Analytics kullanıcı arabirimi düğüm değerlerini 1/3, 2/3, 1, 2, 3 vb. olarak görüntülerken arka uç (etkinlik günlükleri, REST API katmanı) sırasıyla 10 ile çarpılan değerleri 3, 7, 10, 20 ve 30 olarak görüntüler.

Standart	Standart V2 (UI)	Standart V2 (Arka uç bileşenleri, günlükler, REST API, vb.)
1	1/3	3
3	2/3	7
6	1	10
12	2	20
18	3	30
...	...	...

Bu dönüştürme aynı ayrıntı düzeyini taşır ve V2 Stok Tutma Birimleri (SKU) için API katmanındaki ondalık noktayı ortadan kaldırır. Bu dönüştürme otomatiktir ve işinizin performansını etkilemez.

Tüketimi ve bellek kullanımını anlama

Düşük gecikme süreli akış işlemeyi başarabilmek için, Azure Stream Analytics işleri tüm işlemi bellekte gerçekleştirir. Bellek tükendiğinde akış görevi başarısız olur. Sonuç olarak, bir üretim işi için akış işinin kaynak kullanımını izlemek ve işlerin 7/24 çalışmasını sağlamak için yeterli kaynağın ayrıldığından emin olmak önemlidir.

%0 ile %100 arasında değişen SU % kullanım ölçümü, iş yükünüzün bellek tüketimini açıklar. Minimum ayak izi olan bir akış işi için bu ölçüm genellikle %10 ile %20 arasındadır. Eğer SU kullanımı yüksekse (%80'in üzerindeyse) veya giriş olayları birikiyorsa (düşük SU kullanımıyla bile olsa, çünkü bu CPU kullanımını göstermez), iş yükünüz büyük olasılıkla daha fazla işlem kaynağına ihtiyaç duyar, bu nedenle akış birimi sayısını artırmanız gereklidir. Ara sıra ani artışları hesaba katmak için SU ölçümünü %80'in altında tutmak en iyisidir. Artan iş yüklerine tepki vermek ve akış birimlerini artırmak için SU Kullanımı ölçümünde %80 uyarısını ayarlamayı göz önünde bulundurun. Ayrıca, bir etki olup olmadığını görmek için filigran gecikmesi ve birikmiş olay ölçümlerini de kullanabilirsiniz.

Stream Analytics akış birimlerini (SU) yapılandırma

1. Azure portalında oturum açın.

2. Kaynak listesinde, ölçeklendirmek istediğiniz Stream Analytics işini bulun ve açın.

3. İş sayfasındaki Yapılandır başlığının altında Ölçek'i seçin. İş oluştururken varsayılan SU sayısı 1'dir.

1. İşin SU'larını ayarlamak için açılan listede SU seçeneğini belirleyin. Belirli bir SU aralığıyla sınırlısınız.

2. İşinize atanan SU sayısını, çalışırken değiştirebilirsiniz. İşiniz bölümlenmemiş bir çıkış kullanıyorsa veya farklı PARTITION BY değerlerine sahip çok adımlı bir sorgusu varsa, iş çalışırken bir SU değerleri kümesi arasından seçim yapmakla kısıtlanmış olabilirsiniz.

İş performansını izleme

Azure portalını kullanarak işin performansla ilgili ölçümlerini izleyebilirsiniz. Ölçüm tanımı hakkında daha fazla bilgi için bkz. Azure Stream Analytics iş ölçümleri. Portalda ölçüm izleme hakkında daha fazla bilgi için bkz Azure portalı ile Stream Analytics işini izleme.

İş yükünün beklenen aktarım hızını hesaplama. Aktarım hızı beklenenden azsa giriş bölümünü ayarlayın, sorguyu ayarlayın ve işinize SU (Akış Birimi) ekleyin.

Bir iş için kaç SU gerekir?

Gerekli SU sayısı, girişlerin bölüm yapılandırmasına ve iş içinde tanımladığınız sorguya bağlıdır. Ölçek sayfası doğru sayıda SU ayarlamanıza olanak tanır. İhtiyacınız olduğunu düşündüğünüzden daha fazla SU ayırın. Stream Analytics işleme altyapısı, fazladan bellek ayırma maliyetiyle gecikme süresi ve aktarım hızı için iyileştirmeler sağlar.

Genel olarak, PARTITION BY kullanmayan sorgular için 1 SU V2 ile başlayın. Ardından deneme ve hataya göre en iyi sayıyı bulun. Temsili miktarda veri aktarıldıktan sonra SU sayısını değiştirin ve SU% Kullanım metriğini inceleyin. Stream Analytics işinin kullanabileceği akış birimi sayısı üst sınırı, iş için tanımlanan sorgudaki adım sayısına ve her adımda bölüm sayısına bağlıdır. Sınırlar hakkında buradan daha fazla bilgi edinebilirsiniz.

Doğru sayıda SU seçme hakkında daha fazla bilgi için bkz. Aktarım hızını artırmak için Azure Stream Analytics işlerini ölçeklendirme.

Not

Bir işin ihtiyaç duyduğu SU sayısı, girişlerin bölüm yapılandırmasına ve iş için tanımladığınız sorguya bağlıdır. Bir iş için kota dahilinde SU seçebilirsiniz. Azure Stream Analytics abonelik kotası hakkında bilgi için Stream Analytics sınırları'na bakın. Aboneliklerinizin SU'larını bu kotanın üzerine çıkarmak için Microsoft Desteği'ne başvurun. İş başına geçerli SU değerleri 1/3, 2/3, 1, 2, 3 vb. değerlerdir.

SU kullanım yüzdesini artıran faktörler

Zamana bağlı (zamana dayalı) sorgu öğeleri, Stream Analytics tarafından sağlanan durum bilgisi olan işleçlerin temel kümesidir. Stream Analytics bu işlemlerin durumunu sizin yerinize dahili olarak yönetir. Hizmet yükseltmeleri sırasında bellek tüketimini, dayanıklılık denetim noktalarını ve durum kurtarmayı yönetir. Stream Analytics durumları tam olarak yönetse de, birçok en iyi uygulama önerisini göz önünde bulundurun.

Karmaşık sorgu mantığına sahip bir iş, sürekli giriş olayları almasa bile yüksek SU% kullanımına sahip olabilir. Bu, giriş ve çıkış olaylarında ani bir ani artış sonrasında gerçekleşebilir. Sorgu karmaşıksa iş hafızada durumu korumaya devam edebilir.

Geçici hatalar veya sistem tarafından başlatılan yükseltmeler, SU% kullanımının beklenen düzeylere dönmeden önce kısa bir süre için aniden 0'a düşmesine neden olabilir. Bir iş için akış birimlerinin sayısını artırmak, sorgunuz tamamen paralel değilse SU% Kullanımını azaltmayabilir.

Belirli bir süre içindeki kullanımı karşılaştırdığınızda olay hızı ölçümlerini kullanın. InputEvents ve OutputEvents ölçümleri kaç olayın okunup işlendiğini gösterir. Seri durumdan çıkarma hataları gibi ölçümler hata olaylarının sayısını gösterir. Zaman birimi başına olay sayısı arttığında çoğu durumda SU% artar.

Zamana bağlı öğelerde durumlu sorgu mantığı

Azure Stream Analytics işlerinin benzersiz özelliklerinden biri, zaman penceresi toplamaları, zamansal birleşimler ve zamansal analiz işlevleri gibi durum bilgili işlemedir. Bu operatörlerin her biri durum bilgilerini tutar. Bu sorgu öğeleri için en büyük pencere boyutu yedi gündür.

Geçici pencere kavramı çeşitli Stream Analytics sorgu öğelerinde görünür:

1. Pencerelenmiş toplamalar: GROUP BY yuvarlanan, atlayan ve kayan pencereler

2. Zamana dayalı birleşimler: JOIN, DATEDIFF işleviyle

3. Zamana bağlı analiz işlevleri: ISFIRST, LASTve LAG ile LIMIT DURATION

Aşağıdaki faktörler Stream Analytics işleri tarafından kullanılan belleği (akış birimleri ölçümünün bir parçası) etkiler:

Pencerelenmiş toplamalar

Pencerelenmiş toplama için tüketilen bellek (durum boyutu) her zaman pencere boyutuyla doğru orantılı değildir. Bunun yerine, tüketilen bellek verilerin kardinalitesi veya her zaman penceresindeki grup sayısıyla orantılıdır.

Örneğin, aşağıdaki sorguda ile clusterid ilişkilendirilmiş sayı sorgunun kardinalitesidir. 

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Önceki sorguda yüksek kardinalitenin neden olduğu sorunları azaltmak için clusterid tarafından bölümlenmiş olayları Event Hubs'a gönderin. Aşağıdaki örnekte gösterildiği gibi, sistemin PARTITION BY kullanarak her giriş bölümünü ayrı ayrı işlemesine izin vererek sorgunun ölçeğini genişletin:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Sorgu bölümlendikten sonra birden çok düğüme yayılır. Sonuç olarak, her düğüme gelen değerlerin clusterid sayısı azaltılır ve bu da işlecin kardinalitesini GROUP BY azaltır. 

Azaltma adımı gereksinimini önlemek için Event Hubs'ı gruplandırma anahtarına göre bölümleyin. Daha fazla bilgi için bkz . Event Hubs'a genel bakış. 

Zamansal birleşimler

Zamana dayalı birleşim tarafından tüketilen bellek (durum boyutu), birleştirmenin zamansal esneklik aralığındaki olay sayısıyla orantılıdır. Bu sayı, olay giriş hızının esneklik alanı boyutuyla çarpılmasıyla eşittir. Başka bir deyişle, birleştirmeler tarafından tüketilen bellek, ortalama olay hızıyla çarpılan DateDiff zaman aralığıyla orantılıdır.

Birleştirmedeki eşleşmeyen olayların sayısı sorgunun bellek kullanımını etkiler. Aşağıdaki sorgu, tıklama oluşturan reklam gösterimlerini arar:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

Bu örnekte, çok sayıda reklam gösteriliyor ve bunlara çok az kişi tıklanıyor olabilir. Tüm olayları zaman penceresinde tutmanız gerekir. Tüketilen bellek miktarı pencere boyutu ve olay hızıyla doğru orantılıdır. 

Bu davranışı düzeltmek için olayları birleştirme anahtarlarıyla bölümlenmiş Event Hubs'a gönderin (bu örnekte kimlik) ve sistemin her giriş bölümünü aşağıda gösterildiği gibi PARTITION BY kullanarak ayrı ayrı işlemesine izin vererek sorgunun ölçeğini genişletin:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

Sorguyu bölümledikten sonra, onu birden çok düğüme dağıtırsınız. Sonuç olarak, her düğüme gelen olay sayısını azaltır ve birleştirme penceresinde tutulan durumun boyutunu azaltırsınız. 

Zamana bağlı analiz işlevleri

Zamansal analiz işlevi tarafından tüketilen bellek (durum boyutu), süreyle çarpılan olay hızıyla orantılıdır. Analiz işlevleri tarafından tüketilen bellek, pencere boyutuyla değil, her zaman penceresindeki bölüm sayısıyla orantılıdır.

Düzeltme, zamana bağlı birleşime benzer. PARTITION BY kullanarak sorgunun ölçeğini genişletebilirsiniz. 

Düzensiz arabellek

Sırasız arabellek boyutunu Olay Sıralama yapılandırma bölmesinde yapılandırabilirsiniz. Arabellek, pencerenin süresi boyunca girişleri tutar ve bunları yeniden sıralar. Arabelleğin boyutu, olay giriş oranının sırasız pencere boyutuyla çarpılmasıyla orantılıdır. Varsayılan pencere boyutu 0'dır. 

Sırasız arabellekteki taşmayı düzeltmek için PARTITION BY kullanarak sorgunun ölçeğini genişletin. Sorgu bölümlendikten sonra birden çok düğüme yayılır. Sonuç olarak, her düğüme gelen olay sayısı azalır ve böylece her yeniden sıralama arabelleğindeki olay sayısı azalır. 

Giriş bölümü sayısı

Her iş giriş bölümünün bir arabelleği vardır. Giriş bölümü sayısı ne kadar fazlaysa, iş o kadar fazla kaynak tüketir. Her akış birimi için Azure Stream Analytics yaklaşık 7 MB/sn girişi işleyebilir. Bu nedenle, Stream Analytics akış birimlerinin sayısını olay hub'ınızdaki bölüm sayısıyla eşleştirerek iyileştirebilirsiniz.

Genellikle, üçte bir akış birimiyle yapılandırılmış bir iş, iki bölüme sahip bir olay hub'ı için yeterlidir (ki bu olay hub'ları için minimum değerdir). Olay hub'ınız daha fazla bölüme sahipse Stream Analytics işiniz daha fazla kaynak tüketir, ancak Event Hubs tarafından sağlanan ek aktarım hızını kullanması gerekmez.

V2 akış birimi içeren bir iş için olay hub'ından 4 veya 8 bölüm gerekebilir. Ancak, gereksiz bölümleri aşırı kullanmaktan kaçının, çünkü bu, kaynakların aşırı kullanılmasına neden olur. Örneğin, 1 akış birimi olan bir Stream Analytics işinde 16 bölümlü veya daha büyük bir olay hub'ı.

Referans verileri

Azure Stream Analytics, hızlı arama için başvuru verilerini belleğe yükler. Geçerli uygulamayla, başvuru verilerine sahip her birleştirme işlemi, aynı başvuru verileriyle birden çok kez katılsanız bile başvuru verilerinin bir kopyasını bellekte tutar. PARTITION BY olan sorgular için, her bölümde başvuru verilerinin birer kopyası bulunur, bu nedenle bölümler tamamen bağımsızdır. Çarpan etkisiyle, referans verileriyle birden çok bölüme birden çok kez birleştirirseniz bellek kullanımı hızla oldukça yükselebilir.  

UDF işlevlerinin kullanımı

UDF işlevi eklediğinizde, Azure Stream Analytics JavaScript çalışma zamanını belleğe yükler ve bu da SU% değerini etkiler.

Sonraki adımlar

• Azure Stream Analytics'te paralelleştirilebilir sorgular oluşturma
• Aktarım hızını artırmak için Azure Stream Analytics işlerini ölçeklendirme
• Azure Stream Analytics iş ölçümleri
• Azure Stream Analytics iş ölçümleri boyutları
• Azure portalı ile Stream Analytics işini izleme
• Ölçüm boyutlarıyla Stream Analytics iş performansını analiz etme
• Akış Birimlerini anlama ve ayarlama