Vysvětlení a úprava jednotek streamování Stream Analytics

Vysvětlení jednotky streamování a uzlu streamování

Jednotky streamování (SU) představují výpočetní prostředky přidělené ke spuštění úlohy Stream Analytics. Čím vyšší je počet SU, tím více prostředků CPU a paměti se úloze přidělí. Tato kapacita vám umožní zaměřit se na logiku dotazů a abstrahuje potřebu správy hardwaru pro včasné spuštění úlohy Stream Analytics.

Azure Stream Analytics podporuje dvě struktury jednotek streamování: SU V1 (zastaralá) a SU V2 (doporučeno).

Model SU V1 je původní nabídkou ASA, kde každé 6 jednotek SU odpovídá jednomu uzlu streamování pro úlohu. Úlohy můžou běžet i s 1 a 3 SU a odpovídají desetinným uzlům streamování. Škálování probíhá v přírůstcích po 6 úlohách SU až 12, 18, 24 a novějších přidáním dalších uzlů streamování, které poskytují distribuované výpočetní prostředky.

Model SU V2 (doporučeno) je zjednodušená struktura s příznivými cenami pro stejné výpočetní prostředky. V modelu SU V2 odpovídá 1 SU V2 jednomu uzlu streamování pro vaši úlohu. 2 SU V2 odpovídá 2, 3 až 3 atd. Úlohy s 1/3 a 2/3 SU V2 jsou k dispozici také s jedním uzlem streamování, ale zlomkem výpočetních prostředků. Úlohy 1/3 a 2/3 SU V2 poskytují nákladově efektivní možnost pro úlohy, které vyžadují menší škálování.

Základní výpočetní výkon jednotek streamování V1 a V2 je následující:

SU V1 and SU V2 mapping.

Informace o cenách SU najdete na stránce s cenami služby Azure Stream Analytics.

Vysvětlení převodů jednotek streamování a jejich použití

K automatickému převodu jednotek streamování dochází z vrstvy rozhraní REST API na uživatelské rozhraní (Azure Portal a Visual Studio Code). Tento převod si všimnete v protokolu aktivit a také tam, kde se hodnoty SU zobrazují jinak než hodnoty v uživatelském rozhraní. Důvodem je návrh a důvod, proč jsou pole rozhraní REST API omezena na celočíselné hodnoty a úlohy ASA podporují desetinné uzly (1/3 a 2/3 jednotky streamování). Uživatelské rozhraní ASA zobrazuje hodnoty uzlů 1/3, 2/3, 1, 2, 2, 3, ... atd, zatímco back-end (protokoly aktivit, vrstva rozhraní REST API) zobrazuje stejné hodnoty vynásobené hodnotou 10 jako 3, 7, 10, 20, 30.

Standard Standard V2 (UI) Standard V2 (back-end, jako jsou protokoly, rozhraní REST API atd.)
0 1/3 3
3 2/3 7
6 1 10
12 2 20
18 3 30
... ... ...

Díky tomu můžeme vyjádřit stejnou členitost a eliminovat desetinnou čárku ve vrstvě rozhraní API pro skladové položky V2. Tento převod je automatický a nemá žádný vliv na výkon vaší úlohy.

Vysvětlení využití a využití paměti

Aby se dosáhlo nízké latence zpracování streamů, provádějí úlohy Stream Analytics veškeré zpracování v paměti. Při nedostatku paměti se úloha streamování nezdaří. V případě produkční úlohy je proto důležité monitorovat využití prostředků úlohy streamování a ujistit se, že je přidělen dostatečný počet prostředků, aby úlohy běžely 24/7.

Metrika využití SU v procentech, která se pohybuje od 0 % do 100 %, popisuje spotřebu paměti vaší úlohy. U úlohy streamování s minimálními nároky je tato metrika obvykle mezi 10 až 20 %. Pokud je využití SU % vysoké (nad 80 %) nebo pokud se vstupní události získají backloggované (i s nízkým využitím SU, protože nezobrazuje využití procesoru), vaše úloha pravděpodobně vyžaduje více výpočetních prostředků, což vyžaduje zvýšení počtu jednotek streamování. Nejlepší je zachovat metriku SU nižší než 80 % a počítat s občasnými špičkami. Pokud chcete reagovat na zvýšené úlohy a zvýšit jednotky streamování, zvažte nastavení upozornění na 80 % na metrikě využití SU. Můžete také použít metriky zpoždění vodoznaku a nevyřízených událostí a zjistit, jestli to má dopad.

Konfigurace jednotek streamování Stream Analytics (SU)

  1. Přihlaste se na portál Azure.

  2. V seznamu prostředků vyhledejte úlohu Stream Analytics, kterou chcete škálovat, a pak ji otevřete. 

  3. Na stránce úlohy v části Konfigurovat vyberte Škálovat. Výchozí počet jednotek SU je při vytváření úlohy 1.

screen shot of menu on ASA portal.

  1. V rozevíracím seznamu zvolte možnost SU a nastavte SU pro úlohu. Všimněte si, že jste omezeni na konkrétní rozsah SU. 

  2. Během běhu můžete změnit počet jednotek SU přiřazených k vaší úloze. Pokud vaše úloha používá nedělený výstup, může být omezena na výběr ze sady hodnot SU, pokud vaše úloha používá nedělený výstup. Nebo má vícekrokový dotaz s různými hodnotami PARTITION BY.

Monitorování výkonu úloh

Pomocí webu Azure Portal můžete sledovat metriky související s výkonem úlohy. Další informace o definici metrik najdete v tématu Metriky úlohy Azure Stream Analytics. Další informace o monitorování metrik na portálu najdete v tématu Monitorování úlohy Stream Analytics pomocí webu Azure Portal.

Screenshot of monitor job performance.

Vypočítejte očekávanou propustnost úlohy. Pokud je propustnost nižší, než se čekalo, vylaďte vstupní oddíl, vylaďte dotaz a přidejte do úlohy SU.

Kolik SU je pro úlohu potřeba?

Volba počtu požadovaných jednotek SU pro konkrétní úlohu závisí na konfiguraci oddílu pro vstupy a na dotazu definovaném v rámci úlohy. Stránka Měřítko umožňuje nastavit správný počet jednotek SU. Osvědčeným postupem je přidělit více jednotek SU, než je potřeba. Modul pro zpracování Stream Analytics optimalizuje latenci a propustnost za cenu přidělení další paměti.

Obecně platí, že osvědčeným postupem je začít s 1 SU V2 pro dotazy, které nepoužívají PARTITION BY. Pak určete sladké místo pomocí metody pokusu a chyby, ve které upravíte počet jednotek SU po předání reprezentativních objemů dat a prozkoumáte metriku využití SU %. Maximální počet jednotek streamování, které může úloha Stream Analytics použít, závisí na počtu kroků v dotazu definovaném pro úlohu a počtu oddílů v jednotlivých krocích. Další informace o omezeních najdete tady.

Další informace o výběru správného počtu jednotek SU najdete na této stránce: Škálování úloh Azure Stream Analytics za účelem zvýšení propustnosti.

Poznámka:

Volba počtu jednotek SU vyžadovaných pro konkrétní úlohu závisí na konfiguraci oddílu pro vstupy a na dotazu definovaném pro úlohu. Pro úlohu můžete vybrat až kvótu v SU. Informace o kvótě předplatného Azure Stream Analytics najdete v limitech Stream Analytics. Pokud chcete zvýšit SU pro vaše předplatná nad rámec této kvóty, kontaktujte podpora Microsoftu. Platné hodnoty pro SU na úlohu jsou 1/3, 2/3, 1, 2, 3 atd.

Faktory, které zvyšují procentuální využití SU

Dočasné (časově orientované) prvky dotazu jsou základní sadou stavových operátorů poskytovaných Stream Analytics. Stream Analytics spravuje stav těchto operací interně jménem uživatele tím, že během upgradů služeb spravuje spotřebu paměti, kontrolní body pro odolnost a obnovení stavu. I když Stream Analytics plně spravuje stavy, existuje mnoho doporučení osvědčených postupů, která by uživatelé měli zvážit.

Všimněte si, že úloha s komplexní logikou dotazů může mít vysoké využití SU, i když nepřetržitě nepřijímá vstupní události. K tomu může dojít po náhlém nárůstu vstupních a výstupních událostí. Pokud je dotaz složitý, může úloha i nadále udržovat stav v paměti.

Procento využití SU může na krátkou dobu na krátkou dobu klesnout na 0, než se vrátíte k očekávaným úrovním. K tomu dochází kvůli přechodným chybám nebo upgradům iniciovaným systémem. Zvýšení počtu jednotek streamování pro úlohu nemusí snížit využití SU v případě, že váš dotaz není plně paralelní.

Při porovnávání využití v určitém časovém období používejte metriky četnosti událostí. Metriky InputEvents a OutputEvents ukazují, kolik událostí bylo přečteno a zpracováno. Existují metriky, které označují také počet chybových událostí, jako jsou chyby deserializace. Když se počet událostí na časovou jednotku zvýší, ve většině případů se SU % zvýší.

Logika stavového dotazu v dočasných prvech

Jednou z jedinečných funkcí úlohy Azure Stream Analytics je provádění stavového zpracování, jako jsou agregace s časovými okny, dočasné spojení a dočasné analytické funkce. Každý z těchto operátorů uchovává informace o stavu. Maximální velikost okna pro tyto prvky dotazu je sedm dní.

Koncept dočasného okna se zobrazí v několika prvcích dotazu Stream Analytics:

  1. Agregace oken: GROUP BY of Tumbling, Hopping a Sliding windows

  2. Časová spojení: JOIN s funkcí DATEDIFF

  3. Dočasné analytické funkce: ISFIRST, LAST a LAG s LIMIT DURATION

Využití paměti (součást metriky jednotek streamování) úlohami Stream Analytics ovlivňují následující faktory:

Agregace s okny

Spotřebovaná paměť (velikost stavu) pro agregaci s okny není vždy přímo úměrná velikosti okna. Místo toho je spotřebovaná paměť úměrná kardinalitě dat nebo počtu skupin v každém časovém intervalu.

Například v následujícím dotazu je číslo přidružené clusterid kardinalitě dotazu. 

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Pokud chcete zmírnit všechny problémy způsobené vysokou kardinalitou v předchozím dotazu, můžete odesílat události do služby Event Hubs dělené podle clusterida škálovat dotaz tím, že systému umožníte zpracovat každý vstupní oddíl samostatně pomocí funkce PARTITION BY , jak je znázorněno v následujícím příkladu:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Jakmile je dotaz rozdělený na oddíly, rozdělí se do několika uzlů. V důsledku toho se sníží počet hodnot přicházejících clusterid do každého uzlu, čímž se sníží kardinalita skupiny operátorem. 

Oddíly služby Event Hubs by měly být rozdělené podle klíče seskupení, aby se zabránilo nutnosti kroku redukce. Další informace najdete v tématu Přehled služby Event Hubs. 

Časová spojení

Spotřebovaná paměť (velikost stavu) dočasného spojení je úměrná počtu událostí v dočasné místnosti spojení, což je míra vstupu událostí vynásobená velikostí místnosti. Jinými slovy, paměť spotřebovaná spojeními je úměrná časovému rozsahu DateDiff vynásobeným průměrnou mírou událostí.

Počet nepřiřazených událostí ve spojení má vliv na využití paměti pro dotaz. Následující dotaz hledá imprese reklamy, které generují kliknutí:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

V tomto příkladu je možné, že se zobrazí spousta reklam a několik lidí na ni klikne a je nutné zachovat všechny události v časovém intervalu. Využitá paměť je přímo úměrná velikosti tohoto okna a frekvenci událostí. 

Chcete-li to napravit, odešlete události do služby Event Hubs rozdělené podle klíčů join (ID v tomto případě) a škálujte dotaz tak, že systému umožníte zpracovat každý vstupní oddíl samostatně pomocí partition BY , jak je znázorněno na obrázku:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

Jakmile je dotaz rozdělený na oddíly, rozdělí se do několika uzlů. Výsledkem je snížení počtu událostí přicházejících do každého uzlu, čímž se zmenší velikost stavu uchovávaného v okně spojení. 

Dočasné analytické funkce

Spotřebovaná paměť (velikost stavu) dočasné analytické funkce je úměrná rychlosti událostí vynásobené dobou trvání. Paměť spotřebovaná analytickými funkcemi není úměrná velikosti okna, ale spíše počtu oddílů v každém časovém intervalu.

Náprava se podobá dočasnému spojení. Dotaz můžete škálovat pomocí funkce PARTITION BY

Vyrovnávací paměť mimo pořadí

Uživatel může nakonfigurovat velikost vyrovnávací paměti mimo pořadí v podokně konfigurace řazení událostí. Vyrovnávací paměť se používá k uložení vstupů po dobu trvání okna a změnit jejich pořadí. Velikost vyrovnávací paměti je úměrná vstupní rychlosti události vynásobenou velikostí okna mimo pořadí. Výchozí velikost okna je 0. 

Pokud chcete napravit přetečení vyrovnávací paměti mimo pořadí, škálujte dotaz pomocí funkce PARTITION BY. Jakmile je dotaz rozdělený na oddíly, rozdělí se do několika uzlů. V důsledku toho se sníží počet událostí přicházejících do každého uzlu, čímž se sníží počet událostí v každé vyrovnávací paměti pro změny pořadí. 

Počet vstupních oddílů

Každý vstupní oddíl vstupu úlohy má vyrovnávací paměť. Čím větší počet vstupních oddílů, tím více prostředků úloha spotřebovává. Pro každou jednotku streamování může Azure Stream Analytics zpracovat přibližně 7 MB/s vstupu. Proto můžete optimalizovat podle počtu jednotek streamování Stream Analytics s počtem oddílů ve vašem centru událostí.

Úloha nakonfigurovaná s jednotkou streamování 1/3 je obvykle dostatečná pro centrum událostí se dvěma oddíly (což je minimum pro centrum událostí). Pokud má centrum událostí více oddílů, vaše úloha Stream Analytics spotřebovává více prostředků, ale nemusí nutně využívat dodatečnou propustnost poskytovanou službou Event Hubs.

Pro úlohu s jednotkou streamování 1 V2 možná budete potřebovat 4 nebo 8 oddílů z centra událostí. Vyhněte se ale příliš mnoha zbytečným oddílům, protože to způsobuje nadměrné využití prostředků. Například centrum událostí s 16 oddíly nebo většími v úloze Stream Analytics, která má 1 jednotku streamování.

Referenční data

Referenční data v ASA se načítají do paměti pro rychlé vyhledávání. Při aktuální implementaci každá operace spojení s referenčními daty uchovává kopii referenčních dat v paměti, i když se spojíte se stejnými referenčními daty vícekrát. U dotazů s funkcí PARTITION BY má každý oddíl kopii referenčních dat, takže oddíly jsou plně oddělené. S multiplikačním efektem může využití paměti rychle získat velmi vysoké, pokud se spojíte s referenčními daty vícekrát s více oddíly.  

Použití funkcí UDF

Když přidáte funkci definovanou uživatelem, Azure Stream Analytics načte modul runtime JavaScriptu do paměti. To ovlivní SU%.

Další kroky