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

V tomto článku se dozvíte, jak vyladit dotaz Stream Analytics pro zvýšení propustnosti pro úlohy Stream Analytics. Pomocí následujícího průvodce můžete škálovat úlohu tak, aby zvládla vyšší zatížení a využila více systémových prostředků (například větší šířku pásma, více prostředků procesoru, více paměti).

Jako předpoklad si přečtěte následující články:

Případ 1 – Váš dotaz je ze své podstaty plně paralelizovatelný napříč vstupními oddíly.

Pokud je váš dotaz ze své podstaty plně paralelizovatelný napříč vstupními oddíly, můžete postupovat následovně:

  • Vytvořte dotaz tak, aby byl snadno paralelizovatelný pomocí klíčového slova PARTITION BY. Další informace najdete v tématu Použití paralelizace dotazů v Azure Stream Analytics.
  • 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. Výstup Power BI například nejde paralelizovat. Výstupy se před odesláním do výstupní jímky vždy sloučí. Objekty blob, tabulky, Azure Data Lake Storage, Service Bus a funkce Azure Functions se automaticky paralelizují. Výstupy SQL a Azure Synapse Analytics mají možnost paralelizace. Centrum událostí musí mít nastavenou konfiguraci PartitionKey tak, aby odpovídala poli PARTITION BY (obvykle PartitionId). U služby Event Hubs věnujte pozornost sladění počtu oddílů pro všechny vstupy a výstupy, abyste se vyhnuli překryvu mezi oddíly.
  • Spusťte dotaz s 1 jednotkou streamování (SU) V2 (což je plná kapacita jednoho výpočetního uzlu) pro měření maximální dosažitelné propustnosti a pokud používáte GROUP BY, změřte, kolik skupin (kardinalita) může úloha zpracovat. Obecné příznaky narážení na limity systémových prostředků jsou následující.
    • Metrika využití jednotky streamu (SU) % je více než 80%. Označuje vysoké využití paměti. Faktory přispívající k růstu této metriky jsou popsány v dokumentu Pochopte a upravte jednotky streamování Stream Analytics.
    • Výstupní časové razítko zaostává za reálný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. V tuto chvíli neposkytujeme metriku využití procesoru, takže může být obtížné tyto dvě metriky odlišit.
      • Pokud příčinou problému je omezování jímky, musíte zvýšit počet výstupních oddílů (a také vstupní oddíly, aby byla úloha plně paralelizovatelná), nebo zvýšit množství prostředků jímky (například počet jednotek žádostí pro Cosmos DB).
    • V diagramu úloh existuje metrika události backlogu jednotlivých oddílů pro každý vstup. Pokud se metrika událostí backlogu stále zvyšuje, je to také indikátor, že systémový prostředek je omezený (z důvodu omezování výstupní jímky nebo vysokého využití procesoru).
  • Jakmile určíte limity toho, co může dosáhnout jedna úloha SU V2, můžete při přidávání dalších jednotek SU extrapolovat lineárně kapacitu zpracování úlohy za předpokladu, že nemáte žádnou nerovnoměrnou distribuci dat, která způsobí, že určitý oddíl je "horký".

Poznámka:

Zvolte správný počet jednotek streamování: Protože Stream Analytics vytvoří výpočetní uzel pro každou přidanou jednotku SU V2, je nejlepší, aby počet uzlů byl dělitelem počtu vstupních oddílů, aby bylo možné oddíly rovnoměrně rozdělit mezi uzly. Například jste změřili, že úloha v 1 SU V2 dokáže dosáhnout rychlosti zpracování 4 MB/s a počet vstupních oddílů je 4. Pokud chcete dosáhnout přibližně 8 MB/s rychlosti zpracování, můžete spustit úlohu s 2 SU V2 nebo 4 SU V2, abyste dosáhli 16 MB/s. Pak se můžete rozhodnout, kdy zvýšit počet jednotek SU pro úlohu a na jakou hodnotu jako funkci vaší vstupní rychlosti.

Případ 2 – Pokud váš dotaz není snadno paralelizovatelný.

Pokud váš dotaz není úplně paralelní, můžete postupovat podle těchto kroků.

  • Nejprve začněte dotazem bez funkce PARTITION BY , abyste se vyhnuli složitosti dělení, a spusťte dotaz s 1 SU V2, abyste změřili maximální zatížení jako v případě 1.
  • Pokud můžete dosáhnout očekávaného zatížení z hlediska propustnosti, máte hotovo. Případně můžete zvolit změřit stejnou úlohu běžící s frakčními uzly na 2/3 SU V2 a 1/3 SU V2, abyste zjistili minimální počet streamovacích jednotek, které ve vašem scénáři fungují.
  • Pokud nemůžete dosáhnout požadované propustnosti, zkuste dotaz rozdělit na několik kroků, pokud ještě nemá více kroků, a pro každý krok v dotazu přidělte až jednu SU V2. Pokud máte například tři kroky, přidělte tři jednotky SU V2 v sekci "Škálování".
  • Pokud chcete takovou úlohu spustit, Stream Analytics umístí každý krok na svůj vlastní uzel s vyhrazeným prostředkem SU V2.
  • Pokud jste ještě nedosáhli cíle načítání, můžete se pokusit použít PARTITION BY od kroků, které jsou blíže ke vstupu. U operátoru GROUP BY, který není přirozeně partitelný, můžete použít místní/globální agregační vzor k provedení partitní GROUP BY následované nepartitním GROUP BY. Pokud například chcete spočítat, čísla aut projíždějících jednotlivými mýtnými branami každé 3 minuty a objem dat je nad rámec toho, co může být zpracováno prostřednictvím jedné SU V2.

Dotaz:

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

V dotazu počítáte auta na mýtnou bránu na jednu partition a pak sečítáte počet ze všech partition dohromady.

Po dělení přidělte pro každý oddíl kroku jeden SU V2, aby každý oddíl mohl být umístěn na vlastním uzlu zpracování.

Poznámka:

Pokud dotaz nejde rozdělit na oddíly, přidání dalších jednotek SU do dotazu s více kroky nemusí vždy zlepšit propustnost. Jedním ze způsobů, jak dosáhnout výkonu, je snížit objem počátečních kroků pomocí místního nebo globálního agregačního vzoru, jak je popsáno v kroku 5.

Případ 3 : V úloze spouštíte spoustu nezávislých dotazů.

V určitých případech použití ISV, kdy je nákladově efektivnější zpracovávat data z více tenantů v jedné úloze, s použitím samostatných vstupů a výstupů pro každého tenanta, nakonec v jedné úloze spustíte značný počet (například 20) nezávislých dotazů. Předpoklad je, že zatížení každého takového poddotazu je relativně malé.

V takovém případě můžete postupovat podle těchto kroků.

  • V tomto případě nepoužívejte v dotazu funkci PARTITION BY .
  • Pokud používáte Event Hubs, snižte počet vstupních oddílů na minimální možnou hodnotu, která je 2.
  • Spusťte dotaz s jednou SU V2. S očekávaným zatížením pro každý poddotaz přidejte co nejvíce takových poddotazů, dokud úloha dosáhne limitů systémových prostředků. V případě, že se to stane, viz Případ 1 pro symptomy.
  • Jakmile dosáhnete naměřeného limitu poddotazů, začněte do nové úlohy přidávat poddotaz. Počet úloh, které se mají spustit jako funkce počtu nezávislých dotazů, by měl být poměrně lineární, za předpokladu, že nemáte žádnou nerovnoměrnou 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.
  • Při použití propojení referenčních dat s těmito dotazy sjednocujte vstupy před spojením se stejnými referenčními daty. Potom události v případě potřeby rozdělte. Jinak každé spojení referenčních dat uchovává kopii referenčních dat v paměti, což pravděpodobně neprospívá zbytečným navyšováním využití paměti.

Poznámka:

Kolik nájemníků umístit do každé úlohy? Tento vzor dotazu má často velký počet poddotazů a výsledkem je velmi velká a složitá topologie. Kontroler úlohy nemusí být schopen zpracovat takovou velkou topologii. Obecně platí, že byste neměli mít více než 40 tenantů pro úlohu 1/3 SU V2 a 60 tenantů pro úlohy 2/3 a 1 SU V2. Když překročíte kapacitu kontroleru, úloha se úspěšně nespustí.

Získání pomoci

Pokud potřebujete další pomoc, vyzkoušejte naši stránku pro otázky Microsoftu pro Azure Stream Analytics.

Další kroky

  • Last updated on