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ümler

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 olarak kullanabilir ve yazabilir ve bu da aktarım hızını 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.

Çıkışlar

Stream Analytics ile çalışırken çıkışlarda bölümlemeden yararlanabilirsiniz:

• Azure Data Lake Storage
• Azure İşlevleri
• Azure Tablosu
• Blob depolama (bölüm anahtarını açıkça ayarlayabilir)
• Azure Cosmos DB (bölüm anahtarını açıkça ayarlamanız gerekir)
• Event Hubs (bölüm anahtarını açıkça ayarlamanız gerekir)
• IoT Hub (bölüm anahtarını açıkça ayarlamanız gerekir)
• Service Bus
• İsteğe bağlı bölümleme ile SQL ve Azure Synapse Analytics: çıkış 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:

• Event Hubs özelliklerine genel bakış
• Veri bölümleme

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). Sorgu mantığı anahtarlanmamışsa (projeksiyon, filtreler, bilgi birleştirmeleri...) bu son gereksinim yoksayılabilir.

• Giriş ve çıkış tarafından bölümlenmişse WarehouseIdve sorgu tarafından olmadan WarehouseIdgruplandırılıyorsaProductId, 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.
• Her biri kendi bölüm anahtarına sahip olan iki veya daha fazla bağımsız veri akışı tek bir işte yer alırsa, iş paralel değildir.

Yalnızca tüm girişler, çıkışlar ve sorgu adımları aynı anahtarı kullandığında iş paralel olur.

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. Örnek olarak, kullanıcı kimliği başına verileri toplayan ve giriş olay hub'ına bölüm anahtarı olarak userID kullanılarak bölümlenen bir sorgu örneği örnektir. 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.

• Sonraki adım sorgunuzun bölümlenmiş olmasını sağlamaktır. Uyumluluk düzeyi 1.2 veya üzeri olan işler için (önerilir), özel sütun giriş ayarlarında Bölüm Anahtarı olarak belirtilebilir ve iş otomatik olarak paralel olur. Uyumluluk düzeyi 1.0 veya 1.1 olan işler, sorgunuzun tüm adımlarında PARTITION BY PartitionId kullanmanızı gerektirir. Birden çok adıma izin verilir, ancak bunların tümü aynı anahtarla bölümlenmelidir.

• 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 bir şekilde paralel olmaz. Event Hubs çıkışı 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ı belirtildiğinde, 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 hub'ı giriş bölümü 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" kullanılacak PartitionIdş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şelenmemiz gerekmez. Uyumluluk düzeyi 1.2'den önce olan işlerin PARTITION BY PartitionId yan tümcesi içermesi gerektiğine dikkat edin, bu nedenle 2. gereksinimi daha önce karşılar. Çıktı için, bölüm anahtarının PartitionId olarak ayarlanması için işte olay hub'ı çıkışını yapılandırmamı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ığımız için, olaylar Event Hubs'a gönderildiğinde bölüm anahtarı olarak kullanıldığından emin TollBoothID olmamı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. Çıktı blob depolama olduğundan, gereksinim #4'e göre bölüm anahtarı değerini yapılandırma konusunda endişelenmemiz 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 olay hub'ı

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 elde edebiliriz.

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 karıştırma yapmamızı 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ümlenir. PARTITION BY PartitionId yan tümcesi gerekli değildir.

İşin en yüksek akış birimlerini hesaplama

Stream Analytics işi tarafından kullanılabilecek 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.

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 işi için bir akış birimine (SU V2) kadar ölçeklendirilebilir. 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.

Ö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 sorgu bir SU V2'ye kadar ölçeklendirilebilir.

    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ın hem de sorgunun bölümlenmiş olması gerekir. 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

Sorgu bölümlendiğinde, giriş olayları ayrı bölüm gruplarında işlenir ve toplanır. Çıkış olayları da grupların her biri için oluşturulur. 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 dosyasındaki veriler birden çok bölüme yayılabilir.

Input1 bölümlerinin her biri Stream Analytics tarafından ayrı ayrı işlenir. Sonuç olarak, aynı Atlayan penceredeki aynı gişe için araç sayısının birden fazla kaydı oluşturulur. Giriş bölüm anahtarı değiştirilemiyorsa, bu sorun aşağıdaki örnekte olduğu gibi bölümler arasında değerleri toplamak için bölümleme dışı bir adım eklenerek düzeltilebilir:

    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 4 SU V2'ye ölçeklendirilebilir.

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, doğru yapılandırmalar kullanılarak çözülebilecek bazı zorluklar vardır. Bu bölümde, birkaç yaygın çıktının yapılandırmaları ele alınmaktadır ve saniyede 1 K, 5 K ve 10 K'lik alım oranlarının sürdürülmesi için örnekler sağlanmaktadır.

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

Event Hubs

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ği 66 SU V2'ye kadar artırılabilir ve bu da kabaca günde 400 MB/sn'ye veya 38 trilyon olaya kadar işlemeye çevrilebilir.

Azure SQL

Azure SQL , Bölümlemesi Devral adı verilen paralel yazmayı destekler, ancak varsayılan olarak etkinleştirilmez. Ancak, Tam paralel sorguyla birlikte Bölümlemesi Devral ö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ı makaleye çıkışında belirtildiği gibi, bu çözüm 8 bölümün ötesinde tam paralel bir işlem hattı olarak doğrusal olarak ölçeklendirilmediğinden 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

Stream Analytics'ten alınan Azure Cosmos DB çıkışı, uyumluluk düzeyi 1.2 altında yerel tümleştirme kullanacak şekilde güncelleştirildi. 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.

Ölçekli Azure'daki tüm Akış örnekleri , test istemcilerinin yük simülasyonuyla beslenen giriş 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"
}

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. İşin giriş hızına uygun olup olmadığını görmek için aktarım hızı ve "Filigran Gecikmesi" veya GeriLogged 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 düzgün bir şekilde tüketildiğinden emin olmak için Aktarım Hızı altındaki Bölüm anahtarı aralığı başına en fazla tüketilen RU/sn bölümünü 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 sayfamızı deneyin.

Sonraki adımlar

• Azure Stream Analytics'e giriş
• Azure Akış Analizi'ni kullanmaya başlama
• Azure Akış Analizi Sorgu Dili Başvurusu
• Azure Akış Analizi Yönetimi REST API'si Başvurusu