Azure Stream Analytics'te sorgu paralelleştirmeyi kullanma

Bu makalede, Azure Stream Analytics'te paralelleştirmeden nasıl yararlanabileceğiniz gösterilmektedir. Giriş bölümlerini yapılandırarak ve analiz sorgusu tanımını ayarlayarak Stream Analytics işlerini ölçeklendirmeyi öğreneceksiniz.

Önkoşul olarak, akış birimlerini anlama ve ayarlama başlığında açıklanan akış birimi hakkında bilgi sahibi olmak isteyebilirsiniz.

Stream Analytics işinin bölümleri nelerdir?

Stream Analytics iş tanımı en az bir akış girişi, bir sorgu ve çıkış içerir. Girişler, işin veri akışını okuduğu yerdir. Sorgu, veri giriş akışını dönüştürmek için kullanılır ve çıkış, işin iş sonuçlarını gönderdiği yerdir.

Giriş ve çıkışlardaki bölümlendirmeler

Bölümleme, verileri bir bölüm anahtarına göre alt kümelere bölmenizi sağlar. Girişiniz (örneğin Event Hubs) bir anahtarla bölümlenmişse, Stream Analytics işinize giriş eklerken bölüm anahtarını belirtmenizi öneririz. Stream Analytics işini ölçeklendirmek, giriş ve çıkıştaki bölümlerden yararlanır. Stream Analytics işi farklı bölümleri paralel işleyebilir ve yazabilir, bu da verimi artırır.

Girişler

Tüm Azure Stream Analytics akış girişleri bölümlemeden yararlanabilir: Event Hubs, IoT Hub, Blob depolama, Data Lake Storage 2. Nesil.

Not

Uyumluluk düzeyi 1.2 ve üzeri için, sorguda PARTITION BY anahtar sözcüğüne gerek olmadan bölüm anahtarını giriş özelliği olarak ayarlayın. Uyumluluk düzeyi 1.1 ve altı için bölüm anahtarını sorgudaki PARTITION BY anahtar sözcüğüyle tanımlayın.

Çıkışlar

Stream Analytics ile çalışırken aşağıdaki çıkışlarda bölümlemeden yararlanın:

  • Azure Data Lake Storage
  • Azure İşlevleri
  • Azure Tablosu
  • Blob depolama (bölüm anahtarını açıkça ayarlayın)
  • Azure Cosmos DB (bölüm anahtarını açıkça ayarlayın)
  • Event Hubs (bölüm anahtarını açıkça ayarlayın)
  • IoT Hub (bölüm anahtarını açıkça ayarlayın)
  • Service Bus
  • İsteğe bağlı bölümleme ile SQL ve Azure Synapse Analytics: Azure SQL Veritabanı sayfasında daha fazla bilgi bulabilirsiniz.

Power BI bölümlemesi desteklemez. Ancak, girişi bu bölümde açıklandığı gibi bölümleyebilirsiniz.

Bölümler hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

Sorgu

Bir işin paralel olması için bölüm anahtarlarının tüm girişler, tüm sorgu mantığı adımları ve tüm çıkışlar arasında hizalanması gerekir. Sorgu mantığı bölümleme, birleştirmeler ve toplamalar için kullanılan anahtarlar tarafından belirlenir (GROUP BY). Eğer sorgu mantığı anahtarlı değilse (projeksiyon, filtreler, ilişkisel birleştirmeler...) son gereksinim göz ardı edilebilir.

  • Bir giriş ve çıkış WarehouseId ile bölümlenmişse ve sorgu WarehouseId olmadan ProductId ile gruplandırılıyorsa, iş paralel değildir.
  • Birleştirilecek iki giriş farklı bölüm anahtarları (WarehouseId ve ProductId) tarafından bölümlenmişse, iş paralel değildir.
  • Tek bir iş, her biri kendi bölüm anahtarına sahip iki veya daha fazla bağımsız veri akışı içeriyorsa, iş paralel değildir.

İş yalnızca tüm girişler, çıkışlar ve sorgu adımları aynı anahtarı kullandığında paraleldir.

Utanç verici derecede paralel işler

Utanç verici derecede paralel bir iş, Azure Stream Analytics'teki en ölçeklenebilir senaryodur. Girişin bir bölümünü sorgunun bir örneğine çıkışın bir bölümüne bağlar. Bu paralellik aşağıdaki gereksinimlere sahiptir:

  • Sorgu mantığınız aynı sorgu örneği tarafından işlenen anahtara bağlıysa, olayların girişinizin aynı bölümüne gittiğinden emin olmanız gerekir. Event Hubs veya IoT Hub için, olay verilerinin PartitionKey değerinin ayarlanmış olması gerektiği anlamına gelir. Alternatif olarak, bölümlenmiş gönderenleri kullanabilirsiniz. Blob depolama için bu, olayların aynı bölüm klasörüne gönderildiği anlamına gelir. Örneğin, kullanıcıID bölüm anahtarı olarak kullanılarak bölümlenmiş ve giriş olay merkezi üzerinde kullanıcıID başına verileri toplayan bir sorgu örneği olabilir. Ancak, sorgu mantığınız aynı anahtarın aynı sorgu örneği tarafından işlenmesini gerektirmiyorsa, bu gereksinimi yoksayabilirsiniz. Bu mantığın bir örneği, basit bir select-project-filter sorgusu olabilir.

  • Ardından sorgunuzun bölümlenmiş olmasını sağlayın. Uyumluluk düzeyi 1.2 veya üzeri olan işler için (önerilir), giriş ayarlarında Bölüm Anahtarı olarak özel bir sütun belirtin ve iş otomatik olarak paralel olur. Uyumluluk düzeyi 1.0 veya 1.1 olan işler için sorgunuzun tüm adımlarında PARTITION BY PartitionId kullanın. Birden çok adımınız olabilir, ancak bunların tümünün aynı anahtarla bölümlenmiş olması gerekir.

  • Stream Analytics'te desteklenen çıkışların çoğu bölümlemeden yararlanabilir. Bölümlemesi desteklemeyen bir çıkış türü kullanırsanız işiniz utanç verici derecede paralel değildir. Event Hubs çıkışları için Bölüm anahtarı sütununun sorguda kullanılan bölüm anahtarına ayarlandığından emin olun. Daha fazla bilgi için çıkış bölümüne bakın.

  • Giriş bölümlerinin sayısı, çıkış bölümlerinin sayısına eşit olmalıdır. Blob depolama çıkışı bölümleri destekleyebilir ve yukarı akış sorgusunun bölümleme düzenini devralır. Blob depolama için bir bölüm anahtarı belirttiğinizde, veriler giriş bölümü başına bölümlendiğinden sonuç hala tamamen paralel olur. Tam paralel bir işe izin veren bölüm değerlerine örnekler aşağıda verilmiştir:

    • Sekiz olay hub'ı giriş bölümü ve sekiz olay hub'ı çıkış bölümü
    • Sekiz olay merkezi giriş bölümleme ve blob depolama çıkışı
    • Rastgele kardinaliteye sahip özel bir alan tarafından bölümlenmiş sekiz olay hub'ı giriş bölümü ve blob depolama çıkışı
    • Sekiz blob depolama giriş bölümü ve blob depolama çıkışı
    • Sekiz blob depolama giriş bölümü ve sekiz olay hub'ı çıkış bölümü

Aşağıdaki bölümlerde, utanç verici derecede paralel olan bazı örnek senaryolar açıklanmıştır.

Basit sorgu

  • Giriş: Sekiz bölümlü bir olay hub'ı
  • Çıkış: Sekiz bölümü olan bir olay hub'ı ("Bölüm anahtarı sütunu" PartitionId kullanılacak şekilde ayarlanmalıdır)

Sorgu:

    --Using compatibility level 1.2 or above
    SELECT TollBoothId
    FROM Input1
    WHERE TollBoothId > 100
    
    --Using compatibility level 1.0 or 1.1
    SELECT TollBoothId
    FROM Input1 PARTITION BY PartitionId
    WHERE TollBoothId > 100

Bu sorgu basit bir filtredir. Bu nedenle, olay hub'ına gönderilen girişi bölümleme konusunda endişelenmeniz gerekmez. Uyumluluk düzeyi 1.2'den önce olan işlerin PARTITION BY PartitionId yan tümcesini içermesi gerektiğine dikkat edin, böylece daha önce belirtilen 2. gereksinimi karşılamış olur. Çıktı için, işteki olay hub'ı çıkışını yapılandırarak bölüm anahtarını PartitionId olarak ayarlamanız gerekir. Son bir denetim, giriş bölümlerinin sayısının çıkış bölümleri sayısına eşit olduğundan emin olmaktır.

Gruplandırma anahtarıyla sorgulama

  • Giriş: Sekiz bölümlü olay hub'ı
  • Çıkış: Blob depolama

Sorgu:

    --Using compatibility level 1.2 or above
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    
    --Using compatibility level 1.0 or 1.1
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Bu sorguda bir gruplandırma anahtarı var. Bu nedenle, birlikte gruplandırılmış olaylar aynı Event Hubs bölümüne gönderilmelidir. Bu örnekte TollBoothID'ye göre gruplandırdığınızdan TollBoothID , olaylar Event Hubs'a gönderildiğinde bölüm anahtarı olarak kullanıldığından emin olmanız gerekir. Ardından Azure Stream Analytics'te PARTITION BY PartitionId kullanarak bu bölüm şemasından devralabilir ve tam paralelleştirmeyi etkinleştirebilirsiniz. Gereksinim 4’e uygun olarak, çıktının blob depolama olması nedeniyle bir bölüm anahtarı değeri yapılandırma konusunda endişelenmeniz gerekmez.

Utanç verici derecede paralel olmayan* senaryo örnekleri

Önceki bölümde, makalede bazı utanç verici paralel senaryolar ele alınmıştır. Bu bölümde, utanç verici derecede paralel olmak için tüm gereksinimleri karşılamayen senaryolar hakkında bilgi ediniyorsunuz.

Eşleşmeyen bölüm sayısı

  • Giriş: Sekiz bölümlü bir olay hub'ı
  • Çıkış: 32 bölümlü bir etkinlik merkezi

Giriş bölümü sayısı çıkış bölümü sayısıyla eşleşmiyorsa, topoloji sorgudan bağımsız olarak utanç verici derecede paralel değildir. Ancak, yine de bazı paralelleştirme düzeylerini alabilirsiniz.

Bölümlenmemiş çıkışı kullanarak sorgulama

  • Giriş: Sekiz bölümlü bir olay hub'ı
  • Çıkış: Power BI

Power BI çıkışı şu anda bölümlemesi desteklemez. Bu nedenle, bu senaryo utanç verici bir şekilde paralel değildir.

Farklı PARTITION BY değerlerine sahip çok adımlı sorgu

  • Giriş: Sekiz bölümlü olay hub'ı
  • Çıkış: Sekiz bölümlü olay hub'ı
  • Uyumluluk düzeyi: 1.0 veya 1.1

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 Partition By TollBoothId
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Gördüğünüz gibi ikinci adımda bölümleme anahtarı olarak TollBoothId kullanılır. Bu adım, ilk adımla aynı değildir ve bu nedenle bir karıştırma işlemi gerektirir.

Farklı PARTITION BY değerlerine sahip çok adımlı sorgu

  • Giriş: Sekiz bölümlü olay hub'ı ("Bölüm anahtarı sütunu" ayarlanmadı, varsayılan olarak "PartitionId" olarak belirlenmiştir)
  • Çıkış: Sekiz bölümlü olay hub'ı ("Bölüm anahtarı sütunu" "TollBoothId" kullanacak şekilde ayarlanmalıdır)
  • Uyumluluk düzeyi - 1,2 veya üzeri

Sorgu:

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

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Uyumluluk düzeyi 1.2 veya üzeri, varsayılan olarak paralel sorgu yürütmeyi etkinleştirir. Örneğin, "TollBoothId" sütunu giriş Bölüm Anahtarı olarak ayarlandığı sürece önceki bölümdeki sorgu bölümlenmiştir. PARTITION BY PartitionId yan tümcesi gerekli değildir.

Bir görevin maksimum akış birimlerini hesapla

Stream Analytics işinin kullanabileceği toplam akış birimi sayısı, iş için tanımlanan sorgudaki adımların sayısına ve her adım için bölüm sayısına bağlıdır.

Sorgudaki adımlar

Sorguda bir veya birden çok adım olabilir. Her adım, WITH anahtar sözcüğü tarafından tanımlanan bir alt sorgudur. WITH anahtar sözcüğü dışında olan sorgu (yalnızca bir sorgu) aşağıdaki sorgudaki SELECT deyimi gibi bir adım olarak da sayılır:

Sorgu:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

Bu sorgu iki adımdan oluşur.

Not

Bu sorgu makalenin devamında daha ayrıntılı olarak ele alınmalıdır.

Bir adımı bölümleme

Bir adımı bölümlendirmek için aşağıdaki koşullar gerekir:

  • Giriş kaynağının bölümlenmiş olması gerekir.
  • Sorgunun SELECT deyimi bölümlenmiş giriş kaynağından okunmalıdır.
  • Adım içindeki sorguda PARTITION BY anahtar sözcüğü olmalıdır.

Bir sorgu bölümlendiğinde, giriş olayları ayrı bölüm gruplarında işlenir ve toplanır ve grupların her biri için çıkış olayları oluşturulur. Birleşik bir toplama istiyorsanız, toplamak için bölümlenmemiş ikinci bir adım oluşturmanız gerekir.

bir iş için maksimum akış birimlerini hesaplama

Bölümlenmemiş tüm adımlar birlikte bir Stream Analytics görevi için bir akış birimine (SU V2s) kadar ölçeklendirilir. Ayrıca, bölümlenmiş bir adımda her bölüm için bir SU V2 ekleyebilirsiniz. Aşağıdaki tabloda bazı örnekler görebilirsiniz.

Sorgu Görev için en fazla SU sayısı
  • Sorgu bir adım içerir.
  • Adım bölümlenmez.
 1 SU V2
  • Giriş veri akışı 16 tarafından bölümlenmiştir.
  • Sorgu bir adım içerir.
  • Adım bölümlenmiştir.
 16 SU V2 (1 * 16 bölümlü)
  • Sorgu iki adım içerir.
  • Adımların hiçbiri bölümlenmez.
 1 SU V2
  • Giriş veri akışı 3 tarafından bölümlenmiştir.
  • Sorgu iki adım içerir. Giriş adımı bölümlenmiştir ve ikinci adım bölümlenmez.
  • SELECT deyimi bölümlenmiş girişten okur.
 4 SU V2s (bölümlenmiş adımlar için 3 + bölümlenmemiş adımlar için 1)

Ölçeklendirme örnekleri

Aşağıdaki sorgu, üç gişesi olan bir ücretli istasyondan geçen üç dakikalık bir pencere içindeki araba sayısını hesaplar. Bu sorguyu bir SU V2'ye kadar ölçeklendikleyebilirsiniz.

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Sorgu için daha fazla SU kullanmak için hem giriş veri akışını hem de sorguyu bölümle. Veri akışı bölümü 3 olarak ayarlandığından, aşağıdaki değiştirilen sorgu 3 SU V2'ye kadar ölçeklendirilebilir:

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

Bir sorguyu bölümlediğinizde, giriş olayları ayrı bölüm gruplarında işlenir ve toplanır. Sorgu, grupların her biri için çıkış olayları oluşturur. Bölümleme, GROUP BY alanı giriş veri akışındaki bölüm anahtarı olmadığında bazı beklenmeyen sonuçlara neden olabilir. Örneğin, önceki sorgudaki TollBoothId alanı Input1'in bölüm anahtarı değildir. Sonuç olarak, TollBooth #1 içindeki veriler birden çok bölüme yayılabilir.

Stream Analytics , Input1 bölümlerinin her birini ayrı ayrı işler. Sonuç olarak sorgu, aynı atlayan pencerede aynı gişe için araç sayısının birden çok kaydını oluşturur. Giriş bölüm anahtarını değiştiremiyorsanız, aşağıdaki örnekte olduğu gibi bölümler arasında değerleri toplamak için bölümleme dışı bir adım ekleyerek bu sorunu düzeltin:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

Bu sorguyu 4 SU V2'ye ölçeklendirin.

Not

İki akışı birleştiriyorsanız, akışların birleştirmeleri oluşturmak için kullandığınız sütunun bölüm anahtarı tarafından bölümlenmiş olduğundan emin olun. Ayrıca her iki akışta da aynı sayıda bölüme sahip olduğunuzdan emin olun.

Büyük ölçekte daha yüksek aktarım hızı elde etme

Utanç verici derecede paralel bir iş gereklidir ancak büyük ölçekte daha yüksek bir aktarım hızını sürdürmek için yeterli değildir. Her depolama sistemi ve buna karşılık gelen Stream Analytics çıkışı, mümkün olan en iyi yazma aktarım hızını elde etme konusunda çeşitlemelere sahiptir. Tüm ölçekli senaryolarda olduğu gibi, bazı zorluklar çözmek için doğru yapılandırmaları gerektirir. Bu bölümde, birkaç yaygın çıktının yapılandırmaları ele alınmakta ve saniyede 1 bin, 5 bin ve 10 bin olay alma hızlarının korunması için örnekler sunulmaktadır.

Aşağıdaki gözlemlerde durum bilgisi olmayan (geçiş) sorgusu olan bir Stream Analytics işi, Event Hubs, Azure SQL veya Azure Cosmos DB'ye yazan temel bir JavaScript kullanıcı tanımlı işlevi (UDF) kullanılır.

Event Hubs

Alım Hızı (saniye başına olaylar) Akış Birimleri Çıkış Kaynakları
1 K 1/3 2 TU
5 K 1 6 TU
10 K 2 10 TU

Event Hubs çözümü akış birimleri (SU) ve aktarım hızı açısından doğrusal olarak ölçeklendirilerek Stream Analytics'te verileri analiz etmenin ve akıştan çıkarmanın en verimli ve performanslı yoludur. İşlerin ölçeğini 66 SU V2'ye kadar artırabilirsiniz ve bu da kabaca günde 400 MB/sn'ye veya 38 trilyon olaya kadar işlemeye dönüşür.

Azure SQL

Alım Hızı (saniye başına olaylar) Akış Birimleri Çıkış Kaynakları
1 K 2/3 S3
5 K 3 P4
10 Kelvin 6 P6

Azure SQL, Inherit Partitioning adı verilen paralel yazmayı destekler, ancak varsayılan olarak etkinleştirilmez. Ancak, tamamen paralel bir sorguyla birlikte Bölüm Devralma özelliğinin etkinleştirilmesi, daha yüksek aktarım hızı elde etmek için yeterli olmayabilir. SQL yazma aktarım hızı, veritabanı yapılandırmanıza ve tablo şemanıza önemli ölçüde bağlıdır. SQL Çıktı Performansı makalesinde, yazma aktarım hızınızı en üst düzeye çıkarabilecek parametreler hakkında daha fazla ayrıntı bulunur. Azure Stream Analytics'in Azure SQL Veritabanı'na çıktısı ile ilgili makalede belirtildiği gibi, bu çözüm 8 bölümün ötesine tam paralel bir işlem hattı olarak doğrusal şekilde ölçeklenmez ve SQL çıkışından önce yeniden bölümleme gerekebilir (bkz. INTO). Premium SKU'lar, birkaç dakikada bir gerçekleşen günlük yedeklemelerinin ek yükünün yanı sıra yüksek GÇ hızlarını sürdürmek için gereklidir.

Azure Cosmos DB

Alım Hızı (saniye başına olaylar) Akış Birimleri Çıkış Kaynakları
1 K 2/3 20 K RU
5 K 4 60 K RU
10 K 8 120 K RU

Stream Analytics'ten Azure Cosmos DB çıkışı, uyumluluk düzeyi 1.2 altında yerel tümleştirme kullanacak şekilde güncelleştirilir. Uyumluluk düzeyi 1.2, önemli ölçüde daha yüksek aktarım hızı sağlar ve yeni işler için varsayılan uyumluluk düzeyi olan 1.1 ile karşılaştırıldığında RU tüketimini azaltır. Çözüm, /deviceId üzerinde bölümlenmiş Azure Cosmos DB kapsayıcılarını kullanır ve çözümün geri kalanı aynı şekilde yapılandırılır.

Azure için tüm Ölçekli Akış örnekleri, yük simülasyonu yapan test istemcilerinden beslenen girdi olarak Event Hubs'ı kullanır. Her giriş olayı, yapılandırılmış alım hızlarını aktarım hızına (1 MB/sn, 5 MB/sn ve 10 MB/sn) kolayca çeviren 1 KB JSON belgesidir. Olaylar, en fazla 1.000 cihaz için aşağıdaki JSON verilerini (kısaltılmış biçimde) gönderen bir IoT cihazının benzetimini yapar:

{
    "eventId": "b81d241f-5187-40b0-ab2a-940faf9757c0",
    "complexData": {
        "moreData0": 51.3068118685458,
        "moreData22": 45.34076957651598
    },
    "value": 49.02278128887753,
    "deviceId": "contoso://device-id-1554",
    "type": "CO2",
    "createdAt": "2019-05-16T17:16:40.000003Z"
}

Not

Çözümde kullanılan çeşitli bileşenler nedeniyle yapılandırmalar değişebilir. Daha doğru bir tahmin için örnekleri senaryonuza uyacak şekilde özelleştirin.

Performans sorunlarını tanımlama

İşlem hattınızdaki performans sorunlarını belirlemek için Azure Stream Analytics işinizin Ölçümler bölmesini kullanın. Giriş hızına uygun olup olmadığını görmek için aktarım hızını ve "Filigran Gecikmesi" veya Bekleyen Olaylar için Giriş/Çıkış Olayları'nı gözden geçirin. Event Hubs ölçümleri için Kısıtlanmış İstekler'i arayın ve Eşik Birimlerini buna göre ayarlayın. Azure Cosmos DB ölçümleri için, bölüm anahtarı aralıklarınızın eşit olarak tüketildiğinden emin olmak için Verim altında Bölüm anahtarı aralığı başına maksimum tüketilen RU/sn'yi gözden geçirin. Azure SQL DB için Günlük GÇ ve CPU'sunu izleyin.

Yardım alın

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

Sonraki adımlar

  • Last updated on