Stream Analytics-streamelési egységek megismerése és módosítása

Cikk
07/27/2022
8 perc alatt elolvasható

A streamelési egység és a streamelési csomópont ismertetése

A streamelési egységek (SU-k) a Stream Analytics-feladatok végrehajtásához lefoglalt számítási erőforrásokat jelölik. Minél magasabb az SU-k száma, annál több processzor- és memória-erőforrás van lefoglalva a feladathoz. Ez a kapacitás lehetővé teszi, hogy a lekérdezési logikára összpontosítson, és elvonja a hardver felügyeletének szükségességét a Stream Analytics-feladat időben történő futtatásához.

Minden 6 termékváltozat egy streamelési csomópontnak felel meg a feladathoz. Az 1 és 3 termékváltozattal rendelkező feladatok szintén csak egy streamelési csomóponttal rendelkeznek, de a számítási erőforrások töredékével a 6 termékváltozathoz képest. Az 1 és 3 SU-feladat költséghatékony megoldást kínál a kisebb skálázást igénylő számítási feladatokhoz. A feladat 6 termékváltozatnál nagyobb skálázható 12,18-ra, 24-re és többre, ha több streamelési csomópontot ad hozzá, amelyek több elosztott számítási erőforrást biztosítanak, így a feladat több adatkötetet képes feldolgozni.

A kis késésű streamfeldolgozás érdekében az Azure Stream Analytics-feladatok minden feldolgozást a memóriában hajtanak végre. Ha elfogy a memória, a streamelési feladat meghiúsul. Az éles feladatok esetében ezért fontos figyelni a streamelési feladatok erőforrás-használatát, és gondoskodni arról, hogy elegendő erőforrás legyen lefoglalva a feladatok folyamatos futtatásához.

A 0% és 100% közötti SU-kihasználtság metrika a számítási feladat memóriahasználatát írja le. A minimális erőforrásigényű streamelési feladatok esetében ez a metrika általában 10–20% között van. Ha az SU%-os kihasználtsága magas (80% felett van), vagy ha a bemeneti események visszaszorulnak (még alacsony SU%-os kihasználtság mellett is, mivel nem mutatja a processzorhasználatot), akkor a számítási feladat valószínűleg több számítási erőforrást igényel, amihez növelnie kell a termékváltozatok számát. A legjobb, ha az SU-metrikát 80% alatt tartja, hogy figyelembe vegye az alkalmi kiugró értékeket. A megnövekedett számítási feladatokra való reagáláshoz és a streamelési egységek számának növeléséhez érdemes lehet 80%-os riasztást beállítani az SU-kihasználtsági metrika alapján. Emellett a vízjel késleltetését és a hátraírt események metrikáit is használhatja annak megtekintéséhez, hogy van-e hatása.

Stream Analytics-streamelési egységek (SU-k) konfigurálása

Jelentkezzen be az Azure Portalra.
Az erőforrások listájában keresse meg a skálázni kívánt Stream Analytics-feladatot, majd nyissa meg.
A feladatlap Konfigurálás fejléce alatt válassza a Méretezés lehetőséget. Feladat létrehozásakor a termékváltozatok alapértelmezett száma 3.
Válassza az SU lehetőséget a legördülő listában a feladat termékváltozatainak beállításához. Figyelje meg, hogy adott SU-beállításokra van korlátozva.
A feladathoz rendelt termékváltozatok számát akkor is módosíthatja, ha fut. Ez nem lehetséges, ha a feladat nem particionált kimenetet használ, vagy többlépéses lekérdezést használ különböző PARTITION BY értékekkel. Előfordulhat, hogy a feladat futtatásakor su-értékek közül kellett választania.

Feladat teljesítményének monitorozása

A Azure Portal segítségével nyomon követheti a feladatok teljesítményével kapcsolatos metrikákat. A metrikák definíciójának megismeréséhez tekintse meg az Azure Stream Analytics feladatmetrikáit. A metrikák monitorozásával kapcsolatos további információk a portálon: Stream Analytics-feladat monitorozása Azure Portal.

Számítsa ki a számítási feladat várható átviteli sebességét. Ha az átviteli sebesség a vártnál kisebb, hangolja a bemeneti partíciót, hangolja a lekérdezést, és adja hozzá a termékváltozatokat a feladathoz.

Hány SU-ra van szükség egy feladathoz?

Az adott feladathoz szükséges termékváltozatok számának kiválasztása a bemenetek partíciókonfigurációjától és a feladatban definiált lekérdezéstől függ. A Méretezés lapon megadhatja a megfelelő számú termékváltozatot. Ajánlott a szükségesnél több termékváltozatot lefoglalni. A Stream Analytics feldolgozási motorja a késésre és az átviteli sebességre optimalizál a további memória kiosztásának költségén.

Általában az ajánlott eljárás 6 termékváltozattal kezdeni a PARTITION BY-t nem használó lekérdezések esetében. Ezután állapítsa meg az édes helyet egy olyan próba- és hibametódussal, amelyben módosítja a termékváltozatok számát, miután reprezentatív mennyiségű adatot adott át, és megvizsgálta az SU%-os kihasználtsági metrikát. A Stream Analytics-feladatok által használható streamelési egységek maximális száma a feladathoz definiált lekérdezés lépéseinek számától és az egyes lépések partícióinak számától függ. A korlátokról itt tudhat meg többet.

A megfelelő számú termékváltozat kiválasztásával kapcsolatos további információkért tekintse meg ezt a lapot: Azure Stream Analytics-feladatok méretezése az átviteli sebesség növeléséhez

Megjegyzés

Az adott feladathoz szükséges termékváltozatok száma a bemenetek partíciókonfigurációjától és a feladathoz definiált lekérdezéstől függ. Egy feladathoz a termékváltozatokban legfeljebb a kvótát választhatja ki. Alapértelmezés szerint minden Azure-előfizetés legfeljebb 500 termékváltozatú kvótával rendelkezik az adott régióban lévő összes elemzési feladathoz. Ha a kvótán túl szeretné növelni az előfizetések termékváltozatait, lépjen kapcsolatba Microsoft ügyfélszolgálata. A termékváltozatok feladatonkénti érvényes értéke 1, 3, 6 és 6-os növekményekben felfelé.

A streamelési egységek százalékos kihasználtságát növelő tényezők

A időbeli (időorientált) lekérdezési elemek a Stream Analytics által biztosított állapotalapú operátorok alapvető készletei. A Stream Analytics belsőleg kezeli a műveletek állapotát a felhasználó nevében a memóriahasználat kezelésével, a rugalmasság ellenőrzésével és az állapot helyreállításával a szolgáltatásfrissítések során. Bár a Stream Analytics teljes mértékben felügyeli az állapotokat, a felhasználóknak számos ajánlott eljárást kell figyelembe venniük.

Vegye figyelembe, hogy az összetett lekérdezési logikával rendelkező feladatok magas SU%-os kihasználtsággal rendelkezhetnek akkor is, ha nem fogad folyamatosan bemeneti eseményeket. Ez a bemeneti és kimeneti események hirtelen megugrása után fordulhat elő. Ha a lekérdezés összetett, előfordulhat, hogy a feladat továbbra is megőrzi az állapotot a memóriában.

Az SU%-kihasználtság rövid időre hirtelen 0-ra csökkenhet, mielőtt visszatér a várt szintre. Ez átmeneti hibák vagy a rendszer által kezdeményezett frissítések miatt fordul elő. A feladatok streamelési egységeinek számának növelése nem csökkentheti az SU%-os kihasználtságát, ha a lekérdezés nem teljesen párhuzamos.

Egy adott időszakra vonatkozó kihasználtság összehasonlítása során használjon eseménysebesség-metrikákat. Az InputEvents és az OutputEvents metrikák azt mutatják, hogy hány esemény lett beolvasva és feldolgozva. Vannak olyan metrikák, amelyek a hibaesemények számát is jelzik, például deszerializálási hibákat. Ha az események száma időegységenként nő, az SU%a legtöbb esetben nő.

Állapotalapú lekérdezési logika időbeli elemekben

Az Azure Stream Analytics-feladat egyik egyedi képessége az állapotalapú feldolgozás, például az ablakos összesítések, az időbeli illesztések és a temporális elemzési függvények végrehajtása. Ezek az operátorok állapotinformációkat őriznek meg. Ezeknek a lekérdezési elemeknek a maximális ablakmérete hét nap.

A temporális ablak fogalma számos Stream Analytics-lekérdezési elemben megjelenik:

Ablakos összesítések: Csoportosítási szempont az átfedésmentes, a felugró és a csúszóablakok alapján
Időbeli illesztések: JOIN a DATEDIFF függvénnyel
Historikus elemzési függvények: ISFIRST, LAST és LAG limit DURATION

Az alábbi tényezők befolyásolják a Stream Analytics-feladatok által használt memóriát (a streamelési egységek metrikáinak egy részét):

Ablakos összesítések

Az ablakos összesítéshez felhasznált memória (állapotméret) nem mindig arányos közvetlenül az ablak méretével. Ehelyett a felhasznált memória arányos az adatok számosságával vagy az egyes időablakokban lévő csoportok számával.

A következő lekérdezésben például a lekérdezés számossága van társítva clusterid .

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

Az előző lekérdezés magas számossága által okozott problémák megoldásához eseményeket küldhet az Event Hubsnak particionált clusteridmódon, és horizontálisan felskálázhatja a lekérdezést azáltal, hogy lehetővé teszi a rendszer számára, hogy az egyes bemeneti partíciókat külön dolgozza fel a PARTITION BY használatával, ahogy az alábbi példában látható:

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

A lekérdezés particionálása után több csomópontra oszlik el. Ennek eredményeképpen az egyes csomópontokba érkező értékek száma clusterid csökken, ami csökkenti a csoport operátoronkénti számosságát.

Az Event Hubs-partíciókat a csoportosítási kulccsal kell particionolni, hogy ne legyen szükség csökkentési lépésre. További információt az Event Hubs áttekintésében talál.

Időbeli illesztések

A temporális illesztés által felhasznált memória (állapotméret) arányos az illesztés ideiglenes váltótermében lévő események számával, ami az eseménybemenet sebessége és a váltóterem méretének szorzata. Más szóval az illesztések által felhasznált memória arányos a DateDiff időtartomány és az átlagos eseménysebesség szorzatával.

Az illesztés nem egyező eseményeinek száma befolyásolja a lekérdezés memóriakihasználtságát. A következő lekérdezés a kattintásokat generáló oldalmegjelenéseket keresi:

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

Ebben a példában előfordulhat, hogy sok hirdetés jelenik meg, és kevesen kattintanak rá, és az összes eseményt az időkeretben kell tartani. A felhasznált memória arányos az ablak méretével és az események gyakoriságával.

A hiba elhárításához küldjön eseményeket az Event Hubsnak az illesztőkulcsok (ebben az esetben az azonosító) által particionált eseményközpontba, és horizontálisan skálázza fel a lekérdezést úgy, hogy lehetővé teszi a rendszer számára, hogy az egyes bemeneti partíciókat külön dolgozza fel a PARTITION BY használatával az alábbi módon:

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

A lekérdezés particionálása után több csomópontra oszlik el. Ennek eredményeképpen az egyes csomópontokba érkező események száma csökken, ami csökkenti az illesztésablakban tárolt állapot méretét.

Historikus elemzési függvények

A temporális elemzési függvény által felhasznált memória (állapotméret) arányos az eseménysebesség és az időtartam szorzatával. Az elemzési függvények által felhasznált memória nem arányos az ablak méretével, hanem az egyes időablakokban lévő partíciók számával.

A szervizelés hasonló a temporális illesztéshez. A lekérdezés horizontális felskálázható a PARTITION BY használatával.

Nincs sorrendben puffer

A felhasználó konfigurálhatja a sorrenden kívüli pufferméretet az Eseményrendezés konfigurációs paneljén. A puffer az ablak időtartamára vonatkozó bemenetek tárolására és átrendezésére szolgál. A puffer mérete arányos az eseménybemeneti sebesség és a sorrenden kívüli ablakméret szorzatával. Az alapértelmezett ablakméret 0.

A sorrenden kívüli puffer túlcsordulásának elhárításához horizontálisan felskálázza a lekérdezést a PARTITION BY használatával. A lekérdezés particionálása után több csomópontra oszlik el. Ennek eredményeképpen az egyes csomópontokba érkező események száma csökken, ami csökkenti az egyes átrendező pufferekben lévő események számát.

Bemeneti partíciók száma

A feladat bemenetének minden bemeneti partíciója rendelkezik pufferrel. Minél nagyobb a bemeneti partíciók száma, annál több erőforrást használ fel a feladat. Az Azure Stream Analytics minden streamelési egységhez körülbelül 1 MB/s bemeneti adatot képes feldolgozni. Ezért optimalizálhatja a Stream Analytics streamelési egységeinek számát és az eseményközpont partícióinak számát.

Az egy streamelési egységgel konfigurált feladatok általában elegendőek két partícióval rendelkező eseményközponthoz (ez az eseményközpont minimális értéke). Ha az eseményközpont több partícióval rendelkezik, a Stream Analytics-feladat több erőforrást használ fel, de nem feltétlenül használja az Event Hubs által biztosított extra átviteli sebességet.

A 6 streamelési egységből rendelkező feladatokhoz 4 vagy 8 partícióra lehet szükség az eseményközpontból. Kerülje azonban a túl sok szükségtelen partíciót, mivel az túlzott erőforrás-használatot okoz. Például egy 16 partícióval rendelkező vagy nagyobb eseményközpont egy 1 streamelési egységgel rendelkező Stream Analytics-feladatban.

Referenciaadatok

A gyors keresés érdekében a rendszer betölti a referenciaadatokat az ASA-ban a memóriába. A jelenlegi implementációval minden referenciaadatokkal rendelkező illesztési művelet megőrzi a referenciaadatok másolatát a memóriában, még akkor is, ha ugyanazokat a referenciaadatokat többször is összekapcsolja. A PARTITION BY használatával végzett lekérdezések esetében minden partíció rendelkezik a referenciaadatok másolatával, így a partíciók teljesen le vannak választva. A multiplikátor hatásával a memóriahasználat gyorsan nagyon magas lehet, ha több partícióval többször összekapcsolja a referenciaadatokat.

Az UDF-függvények használata

UDF-függvény hozzáadásakor az Azure Stream Analytics betölti a JavaScript-futtatókörnyezetet a memóriába. Ez hatással lesz az SU%- ra.