Aktarım hızını artırmak için Azure Stream Analytics işini ölçeklendirme

  • Makale

Bu makalede, Stream Analytics işlerinin aktarım hızını artırmak için Stream Analytics sorgusunu nasıl ayarladığınız gösterilmektedir. Daha yüksek yükü işleyecek şekilde işinizi ölçeklendirmek ve daha fazla sistem kaynağından (daha fazla bant genişliği, daha fazla CPU kaynağı, daha fazla bellek gibi) yararlanmak için aşağıdaki kılavuzu kullanabilirsiniz.

Önkoşul olarak aşağıdaki makaleleri okuyun:

Olay 1 – Sorgunuz giriş bölümleri arasında doğal olarak tamamen paralelleştirilebilir

Sorgunuz giriş bölümleri arasında doğal olarak tamamen paralelleştirilebilirse aşağıdaki adımları izleyebilirsiniz:

  • PARTITION BY anahtar sözcüğünü kullanarak sorgunuzu utanç verici bir şekilde paralel olacak şekilde yazın. Daha fazla bilgi için bkz . Azure Stream Analytics'te sorgu paralelleştirmeyi kullanma.
  • Sorgunuzda kullanılan çıkış türlerine bağlı olarak, bazı çıkışlar paralelleştirilebilir olmayabilir veya utanç verici şekilde paralel olması için daha fazla yapılandırma gerekebilir. Örneğin, Power BI çıkışı paralelleştirilebilir değildir. Çıkışlar her zaman çıkış havuzuna gönderilmeden önce birleştirilir. Bloblar, Tablolar, Azure Data Lake Depolama, Service Bus ve Azure İşlevi otomatik olarak paralelleştirilir. SQL ve Azure Synapse Analytics çıkışlarında paralelleştirme seçeneği vardır. Bir olay hub'ına PARTITION BY alanıyla eşleşecek şekilde PartitionKey yapılandırmasının ayarlanmış olması gerekir (genellikle PartitionId). Event Hubs için, bölümler arasında çapraz geçişten kaçınmak için tüm girişlerin ve tüm çıkışların bölüm sayısını eşleştirmeye de dikkat edin.
  • Maksimum ulaşılabilir aktarım hızını ölçmek için sorgunuzu 1 akış birimi (SU) V2 (tek bir bilgi işlem düğümünün tam kapasitesi) ile çalıştırın ve GROUP BY kullanıyorsanız işin kaç grup (kardinalite) işleyebileceğini ölçün. Sistem kaynak sınırlarına isabet eden işin genel belirtileri şunlardır.
    • Akış birimi (SU) kullanım ölçümü %80'in üzerindedir. Bellek kullanımının yüksek olduğunu gösterir. Bu ölçümün artmasına katkıda bulunan faktörler, Stream Analytics akış birimlerini anlama ve ayarlama konusunda açıklanmıştır.
    • Çıkış zaman damgası, duvar saati zamanına göre geride kalıyor. Sorgu mantığınıza bağlı olarak çıkış zaman damgasının duvar saati saatinden bir mantık uzaklığı olabilir. Ancak, kabaca aynı hızda ilerlemelidir. Çıkış zaman damgası daha fazla ve daha fazla geride kalıyorsa bu, sistemin fazla çalışmakta olduğunu gösteren bir göstergedir. Aşağı akış çıkış havuzu azaltmasının veya yüksek CPU kullanımının bir sonucu olabilir. Şu anda CPU kullanım ölçümü sağlamadığımız için ikisini ayırt etmek zor olabilir.
      • Sorun havuz azaltmadan kaynaklanıyorsa, çıkış bölümlerinin sayısını artırmanız (ve işi tamamen paralelleştirilebilir tutmak için giriş bölümleri) veya havuzun kaynak miktarını artırmanız (örneğin, Cosmos DB için İstek Birimi sayısı) gerekir.
    • İş diyagramında her giriş için bölüm başına kapsam olay ölçümü bulunur. Kapsam olayı ölçümü artmaya devam ederse, sistem kaynağının kısıtlandığının göstergesidir (çıkış havuzu azaltma veya yüksek CPU nedeniyle).
  • Bir SU V2 işinin ulaşabileceği sınırları belirledikten sonra, belirli bir bölümü "sık erişimli" yapan herhangi bir veri dengesizliği olmadığı varsayılarak, daha fazla SU eklediğinizde işin işleme kapasitesini doğrusal olarak tahmin edebilirsiniz.

Not

Doğru akış birimi sayısını seçin: Stream Analytics eklenen her 1 SU V2 için bir işleme düğümü oluşturduğundan, bölümlerin düğümler arasında eşit bir şekilde dağıtılabilmesi için düğüm sayısını giriş bölümü sayısının böleni yapmak en iyisidir. Örneğin, 1 SU V2 işinizin 4 MB/sn işleme hızına ulaşabileceğini ve giriş bölüm sayınızın 4 olduğunu ölçtünüz. yaklaşık 8 MB/sn işleme hızına ulaşmak için işinizi 2 SU V2 ile veya 16 MB/sn'ye ulaşmak için 4 SU V2 ile çalıştırmayı seçebilirsiniz. Ardından, giriş oranınızın bir işlevi olarak işin SU sayısını ne zaman hangi değere artıracağınız hakkında karar vekleyebilirsiniz.

Olay 2 - Sorgunuz utanç verici derecede paralel değilse.

Sorgunuz utanç verici derecede paralel değilse bu adımları izleyebilirsiniz.

  • Bölümleme karmaşıklığını önlemek için önce PARTITION BY içermeyen bir sorguyla başlayın ve Olay 1'de olduğu gibi maksimum yükü ölçmek için sorgunuzu 1 SU V2 ile çalıştırın.
  • Aktarım hızı süresinde beklenen yüke ulaşabiliyorsanız işiniz tamamlanmıştır. Alternatif olarak, senaryonuza uygun en az akış birimi sayısını bulmak için 3/2/3 SU V2 ve 1/3 SU V2'de kesirli düğümlerle çalışan aynı işi ölçmeyi seçebilirsiniz.
  • İstenen aktarım hızına ulaşamıyorsanız, zaten birden çok adımı yoksa sorgunuzu birden çok adıma ayırmayı ve sorgudaki her adım için en fazla bir SU V2 ayırmayı deneyin. Örneğin üç adımınız varsa "Ölçek" seçeneğinde üç SU V2 ayırın.
  • Stream Analytics, böyle bir işi çalıştırmak için her adımı ayrılmış bir SU V2 kaynağıyla kendi düğümüne yerleştirir.
  • Hala yük hedefinize ulaşamadıysanız, girişe daha yakın adımlardan başlayarak BÖLÜM'ünüzü kullanmaya çalışabilirsiniz. Doğal olarak bölümlenebilir olmayan GROUP BY işleci için, bölümlenmiş GROUP BY ve ardından bölümlenmemiş GROUP BY gerçekleştirmek için yerel/genel toplama desenini kullanabilirsiniz. Örneğin, her geçiş ücreti standında her 3 dakikada bir kaç araba geçtiğini saymak istiyorsanız ve verilerin hacmi bir SU V2 tarafından işlenemeyecek kadar fazladır.

Sorgu:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

Sorguda, bölüm başına ücretli kabin başına araba sayıyor ve ardından tüm bölümlerdeki sayıyı bir araya ekliıyorsunuz.

Bölümlendikten sonra, adımın her bölümü için bir SU V2 ayırın, böylece her bölüm kendi işleme düğümüne yerleştirilebilir.

Not

Sorgunuz bölümlenemiyorsa, çok adımlı bir sorguya ek SU eklemek her zaman aktarım hızını geliştirmeyebilir. Performans kazanmanın bir yolu, 5. adımda açıklandığı gibi yerel/genel toplama desenini kullanarak ilk adımlardaki hacmi azaltmaktır.

3. Olay: Bir işte çok sayıda bağımsız sorgu çalıştırıyorsunuz.

Her kiracı için ayrı girişler ve çıkışlar kullanarak tek bir işte birden çok kiracıdan verileri işlemenin daha uygun maliyetli olduğu bazı ISV kullanım örnekleri için, tek bir işte oldukça az (örneğin 20) bağımsız sorgu çalıştırırsınız. Varsayım, bu tür alt sorguların yükünün nispeten küçük olduğudur.

Bu durumda, bu adımları izleyebilirsiniz.

  • Bu durumda sorguda PARTITION BY kullanmayın
  • Event Hubs kullanıyorsanız giriş bölümü sayısını mümkün olan en düşük 2 değerine düşürün.
  • Sorguyu bir SU V2 ile çalıştırın. Her alt sorgu için beklenen yükle, iş sistem kaynak sınırlarına gelene kadar mümkün olduğunca çok alt sorgu ekleyin. Ortaya çıkan belirtiler için Olay 1'e bakın.
  • Ölçülen alt sorgu sınırına ulaştıktan sonra alt sorguyu yeni bir işe eklemeye başlayın. Herhangi bir yük dengesizliği olmadığı varsayılarak, bağımsız sorgu sayısının işlevi olarak çalıştırılacak iş sayısı oldukça doğrusal olmalıdır. Daha sonra hizmet vermek istediğiniz kiracı sayısının işlevi olarak kaç SU V2 işi çalıştırmanız gerektiğini tahmin edebilirsiniz.
  • Bu tür sorgularla başvuru verilerini birleştirmeyi kullanırken, aynı başvuru verileriyle birleştirmeden önce girişleri birleştirin. Ardından, gerekirse olayları ayırın. Aksi takdirde, her başvuru veri birleştirmesi bellekte başvuru verilerinin bir kopyasını tutar ve bellek kullanımını gereksiz yere patlatmış olabilir.

Not

Her işe kaç kiracı yerleştireceksiniz? Bu sorgu düzeni genellikle çok sayıda alt sorguya sahiptir ve sonuç olarak çok büyük ve karmaşık topoloji elde eder. İşin denetleyicisi böyle büyük bir topolojiyi işleyemeyebilir. Kural olarak, 3/1 SU V2 işi için 40 kiracının altında, 2/3 ve 1 SU V2 işleri için 60 kiracıda kalın. Denetleyicinin kapasitesini aştığınızda, iş başarıyla başlatılmaz.

Yardım alın

Daha fazla yardım için Azure Stream Analytics için Microsoft Soru-Cevap soru sayfamızı deneyin.

Sonraki adımlar