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

  • Článek

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 svůj dotaz tak, aby byl trapný paralelně 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ýstupu použitých v dotazu můžou být některé výstupy buď paralelizovatelné, nebo potřebujete další konfiguraci, aby byla trapná paralelně paralelní. 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 také zvláštní pozornost počtu oddílů pro všechny vstupy a všechny výstupy, abyste se vyhnuli křížovému přecházení 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 dosažení limitů systémovýchprostředkůch
    • Metrika využití jednotky streamu (SU) % je přes 80 %. Označuje vysoké využití paměti. Faktory přispívající ke zvýšení této metriky jsou popsány vysvětlení a úprava jednotek streamování Stream Analytics.
    • Časové razítko výstupu padá s ohledem na hodinový čas zdi. V závislosti na logice dotazu může časové razítko výstupu mít odsazení logiky od hodinového času zdi. Měly by se ale postupovat přibližně stejným tempem. Pokud časové razítko výstupu dál a dál klesá, je to indikátor, že systém přepracovává. Může to být výsledek omezování výstupní jímky výstupu nebo vysoké 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 úlohu 1 SU V2, která 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 na jakou hodnotu, jako funkci vstupní rychlosti.

Případ 2 – Pokud váš dotaz není trapný paralelně.

Pokud váš dotaz není trapný 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 změřit stejnou úlohu spuštěnou s desetinnými uzly na 2/3 SU V2 a 1/3 SU V2, abyste zjistili minimální počet jednotek streamování, 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 možnosti Škálování.
  • Pokud chcete takovou úlohu spustit, Stream Analytics umístí každý krok na svůj vlastní uzel s vyhrazeným jední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ů blíže ke vstupu. U operátoru GROUP BY , který není přirozeně dělitelný, můžete použít místní/globální agregační vzor k provedení dělené skupiny BY následované nesouvisenou částí GROUP BY. Pokud například chcete spočítat, kolik aut procházejících jednotlivými placemi každých 3 minuty a objem dat je nad rámec toho, co může zpracovat jedna 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 placenou linku na oddíl a pak sečítá počet ze všech oddílů 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 některých případech použití nezávislých výrobců softwaru, kdy je nákladově efektivnější zpracovávat data z více tenantů v jedné úloze pomocí samostatných vstupů a výstupů pro každého tenanta, nakonec v jedné úloze spustíte poměrně několik nezávislých dotazů (například 20). 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 nejnižší možnou hodnotu 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ů. Pokud se to stane, projděte si případ 1.
  • 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 jako funkci počtu tenantů, které chcete použít.
  • 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, pravděpodobně zbytečně vyhodí využití paměti.

Poznámka:

Koliktenantch 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 zůstaňte pod 40 tenanty 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