Škálování úlohy Azure Stream Analytics za účelem zvýšení propustnosti

Tento článek vysvětluje, jak ladit dotaz Azure Stream Analytics za účelem zvýšení propustnosti. Pomocí těchto vzorů škálování můžete zvládnout vyšší zatížení pomocí větší šířky pásma, procesoru a paměťových prostředků.

Azure Stream Analytics měří výpočetní kapacitu ve streamovacích jednotkách (SUs). Každá SU V2 představuje plnou kapacitu jednoho výpočetního uzlu. Trapně paralelní dotaz je ten, kde je možné každý vstupní oddíl zpracovávat nezávisle, bez dat sdílených napříč oddíly.

Předpoklady

Než začnete, projděte si tyto články:

Škálování plně paralelizovatelného dotazu

Pokud je váš dotaz trapně paralelní napříč vstupními oddíly, postupujte takto:

  1. Vytvořte svůj dotaz tak, aby používal klíčové slovo PARTITION BY . Další informace najdete v tématu Použití paralelizace dotazů v Azure Stream Analytics.

  2. V závislosti na typech výstupů použitých ve vašem dotazu mohou být některé výstupy buď neparalelizovatelné, nebo potřebují další konfiguraci, aby se jednoduše paralelizovaly. Můžete například nakonfigurovat výstupy pro paralelizaci. Ne všechny typy výstupu podporují paralelní zápisy:

    Typ výstupu Podpora paralelizace
    Azure Blob Storage, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions Automatické
    Azure SQL Database, Azure Synapse Analytics Optional. Vyžaduje konfiguraci.
    Azure Event Hubs Vyžaduje PartitionKey , aby odpovídalo poli PARTITION BY (obvykle PartitionId). Slaďte počty vstupních a výstupních particí, aby nedocházelo ke křížení.
    Power BI Nejde paralelizovat. Výstupy se před odesláním do jímky vždy sloučí.

  3. Spusťte dotaz s 1 SU V2 (což je plná kapacita jednoho výpočetního uzlu) a změřte maximální dosažitelnou propustnost. Pokud používáte GROUP BY, změřte, kolik skupin (kardinalita) může úloha zpracovat.

  4. Zkontrolujte limity systémových prostředků. Následující příznaky naznačují, že vaše úloha Azure Stream Analytics naráží na limity prostředků:

    Symptom Pravděpodobná příčina Action
    Metrika využití SU % překračuje 80% Vysoké využití paměti. Viz Vysvětlení a úprava jednotek streamování. Přidejte další SU V2.
    Časové razítko výstupu zaostává za skutečným časem V závislosti na logice dotazu může mít časové razítko výstupu logický posun vůči skutečnému času. Ale měly by postupovat přibližně stejným tempem. Pokud časové razítko výstupu stále více zaostává, je to indikátor, že systém je přetížený. Může to být výsledek omezení kapacity výstupního kanálu nebo vysokého využití procesoru. Stream Analytics v tuto chvíli neposkytuje metriku využití procesoru, takže může být obtížné tyto dvě metriky odlišit. Pokud je problém způsoben omezením propustnosti cíle, zvyšte počet výstupních oddílů (a také vstupních oddílů, aby byl zachován paralelismus) nebo navyšte prostředky cíle (například Request Units pro Azure Cosmos DB).
    Metrika událostí backlogu pro jednotlivé oddíly se stále zvyšuje (viditelné v diagramu úloh) Omezování výstupního sinku nebo vysoké využití CPU Platí to samé jako výše.

  5. Extrapolovat kapacitu lineárně. Jakmile určíte, jaké zatížení zvládne 1 SU V2, přidejte úměrně další SU za předpokladu, že mezi particemi nedochází k nerovnoměrnému rozložení dat.

Poznámka:

Zvolte správný počet jednotek SU V2: Azure Stream Analytics vytvoří jeden uzel pro zpracování pro každou jednotku SU V2. Nastavte počet jednotek SU V2 tak, aby byl dělitelem počtu vstupních oddílů, aby byly oddíly rovnoměrně rozděleny.

Příklad: Úloha 1 SU V2 zpracovává 4 MB/s ve 4 vstupních oddílech. Použijte 2 SU V2 pro ~8 MB/s nebo 4 SU V2 pro ~16 MB/s. Počet jednotek SU V2 zvolte podle cílové vstupní rychlosti.

Škálování neparallelového dotazu

Pokud váš dotaz není triviálně paralelizovatelný, postupujte takto:

  1. Začněte bez funkce PARTITION BY , abyste se vyhnuli složitosti. Spuštěním dotazu s 1 SU V2 změřte maximální propustnost. Zkontrolujte stejné příznaky limitu prostředků popsané v předchozí části (využití SU nad 80%, prodleva časového razítka výstupu, zvýšení backlogu).

  2. Pokud dosáhnete cílové propustnosti, máte hotovo. Volitelně můžete testovat s 2/3 SU V2 a 1/3 SU V2 a najít minimální počet SU V2 pro váš scénář.

  3. Pokud nemůžete dosáhnout požadované propustnosti, rozdělte dotaz do několika kroků. Pro každý krok přidělte až 1 SU V2. Například třístupňový dotaz potřebuje 3 SU V2. Azure Stream Analytics umístí každý krok na vlastní vyhrazený uzel.

  4. Pokud jste stále ještě nedosáhli cílové propustnosti, přidejte PARTITION BY do kroků blíže ke vstupu. V případě operací GROUP BY , které nejsou přirozeně dělitelné, použijte místní/globální agregační vzor: nejprve proveďte dělenou funkci GROUP BY a pak skupinu GROUP BY, která není rozdělena do oddílů. Pokud například chcete každé 3 minuty počítat auta projíždějící každou mýtnou bránou, když objem překročí kapacitu, kterou zvládne 1 SU V2:

    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

    Tento dotaz v kroku Step1 počítá počet aut pro každou mýtnou bránu v každém oddílu a v posledním kroku potom agreguje počty podle oddílů.

    Po rozdělení dotazu přidělte každému oddílu každého kroku 1 SU V2, aby každý oddíl běžel na vlastním uzlu zpracování.

    Poznámka:

    Pokud dotaz nejde rozdělit na oddíly, přidání dalších jednotek SU V2 do vícekrokového dotazu nemusí zvýšit propustnost. Pokud chcete dosáhnout výkonu, snižte objem v počátečních krocích pomocí místního nebo globálního agregačního vzoru zobrazeného v kroku 4.

Škálování více nezávislých dotazů v jedné úloze

V případě scénářů nezávislých dodavatelů softwaru (ISV) s více tenanty, ve kterých zpracováváte data z více tenantů v jedné úloze Azure Stream Analytics (s samostatnými vstupy a výstupy na tenanta), je zatížení jednotlivých poddotazů obvykle malé. Postupujte takto:

  1. Nepoužívejte funkci PARTITION BY v dotazu.

  2. Pokud používáte Azure Event Hubs, snižte počet vstupních oddílů na minimální hodnotu 2.

  3. Spusťte dotaz s 1 SU V2. Přidejte poddotazy, dokud úloha nenarazí na limity prostředků. Příznaky jsou stejné jako u plně paralelizovatelného dotazu: využití SU nad 80%, prodleva časového razítka výstupu nebo zvýšení backlogu.

  4. Po dosažení limitu poddotazů přidejte nové poddotazy do samostatné úlohy. Počet úloh se škáluje lineárně s počtem nezávislých dotazů (za předpokladu, že nedojde ke nerovnoměrné distribuci zatížení). Pak můžete předpovědět, kolik úloh SU V2 potřebujete spustit v závislosti na počtu tenantů, které chcete obsloužit.

  5. Pro propojení referenčních dat sjednocujte všechny vstupy před připojením s referenčními daty a potom události rozdělte. Jinak každé spojení referenčních dat uchovává samostatnou kopii referenčních dat v paměti, což může způsobit zbytečné využití paměti.

Poznámka:

Maximální počet tenantů na jednu úlohu: Nepřekračujte 40 tenantů pro úlohu 1/3 SU V2 a 60 tenantů pro úlohy 2/3 SU V2 a 1 SU V2. Velký počet poddotazů vytváří komplexní topologie, které kontroler úloh nemusí zpracovat, což brání spuštění úlohy.

Získání pomoci

Pokud potřebujete další pomoc, vyzkoušejte stránku s dotazy microsoftu Q&A pro Azure Stream Analytics.

Související obsah

  • Last updated on