Azure Stream Analytics-feladat skálázása az átviteli sebesség növelése érdekében
Ez a cikk bemutatja, hogyan hangolhat Stream Analytics-lekérdezéseket a Stream Analytics-feladatok átviteli sebességének növelése érdekében. Az alábbi útmutató segítségével skálázhatja a feladatát a nagyobb terhelés kezelésére, és kihasználhatja a több rendszererőforrást (például nagyobb sávszélességet, több CPU-erőforrást, több memóriát).
Előfeltételként olvassa el a következő cikkeket:
1. eset – A lekérdezés eredendően teljesen párhuzamos a bemeneti partíciók között
Ha a lekérdezés eredendően teljesen párhuzamos a bemeneti partíciók között, kövesse az alábbi lépéseket:
- Hozza létre a lekérdezést, hogy kínosan párhuzamos legyen a PARTITION BY kulcsszóval. További információ: Lekérdezés-párhuzamosítás használata az Azure Stream Analyticsben.
- A lekérdezésben használt kimeneti típustól függően előfordulhat, hogy egyes kimenetek nem párhuzamosíthatók, vagy további konfigurációra van szükség ahhoz, hogy kínosan párhuzamosak legyenek. A Power BI-kimenet például nem párhuzamosítható. A kimenetek mindig egyesülnek, mielőtt elküldené a kimeneti fogadóba. A blobok, táblák, Azure Data Lake Storage, Service Bus és Azure-függvények automatikusan párhuzamosak lesznek. Az SQL- és az Azure Synapse Analytics-kimenetek párhuzamosításra is lehetőséget adnak. Az eseményközpontnak rendelkeznie kell a PartitionKey konfigurációval, hogy megfeleljen a PARTITION BY mezőnek (általában
PartitionId
). Az Event Hubs esetében is ügyeljen arra, hogy az összes bemenet és kimenet partícióinak számával egyezzen, hogy elkerülje a partíciók közötti keresztátvételt. - Futtassa a lekérdezést 1 streamelési egység (SU) V2 -vel (amely egy számítási csomópont teljes kapacitása) a maximális elérhető átviteli sebesség méréséhez, és ha GROUP BY-t használ, mérje meg, hogy hány csoportot (számosságot) képes kezelni a feladat. A rendszererőforrás-korlátokat elérő feladat általános tünetei a következők.
- A streamegység (SU) kihasználtsági mutatója több mint 80%. Azt jelzi, hogy a memóriahasználat magas. A metrika növekedéséhez hozzájáruló tényezőket a Stream Analytics streamelési egységeinek megismerése és módosítása ismerteti.
- A kimeneti időbélyeg a fal óraideje szempontjából elmarad. A lekérdezési logikától függően a kimeneti időbélyeg logikai eltolással rendelkezhet a fali óra időtől. Azonban nagyjából ugyanolyan ütemben kell haladniuk. Ha a kimeneti időbélyeg egyre tovább csökken, az azt jelzi, hogy a rendszer túlterjedt. Ez lehet az alsó kimeneti fogadó szabályozásának vagy a magas processzorhasználatnak az eredménye. Jelenleg nem biztosítunk cpu-kihasználtsági metrikát, így nehéz lehet megkülönböztetni a kettőt.
- Ha a problémát a fogadó szabályozása okozza, növelnie kell a kimeneti partíciók számát (és a bemeneti partíciókat is, hogy a feladat teljes mértékben párhuzamos maradjon), vagy növelnie kell a fogadó erőforrásainak mennyiségét (például a Cosmos DB kérelemegységeinek számát).
- A feladatdiagramban minden bemenethez egy partíciónkénti teendőlista-eseménymetrika tartozik. Ha a hátralékesemény metrika folyamatosan növekszik, az azt is jelzi, hogy a rendszererőforrás korlátozott (akár a kimeneti fogadó szabályozása, akár a magas CPU miatt).
- Miután meghatározta, hogy egy SU V2-feladat milyen korlátokat érhet el, lineárisan extrapolálhatja a feladat feldolgozási kapacitását, miközben további termékváltozatokat ad hozzá, feltéve, hogy nincs olyan adateltérés, amely bizonyos partíciót "forróvá" tesz.
Feljegyzés
Válassza ki a megfelelő számú streamelési egységet: Mivel a Stream Analytics minden hozzáadott 1 SU V2-hez létrehoz egy feldolgozási csomópontot, a legjobb, ha a csomópontok számát a bemeneti partíciók számának osztójának tekinti, így a partíciók egyenletesen eloszthatók a csomópontok között. Az 1 SU V2-feladat például 4 MB/s feldolgozási sebességet érhet el, a bemeneti partíciók száma pedig 4. Dönthet úgy, hogy 2 SU V2-vel futtatja a feladatát, hogy nagyjából 8 MB/s feldolgozási sebességet érjen el, vagy 4 SU V2-t a 16 MB/s eléréséhez. Ezután eldöntheti, hogy mikor növeli a feladat su-számát a bemeneti sebesség függvényeként.
2. eset – Ha a lekérdezés nem kínosan párhuzamos.
Ha a lekérdezés nem kínosan párhuzamos, kövesse az alábbi lépéseket.
- A partíciók összetettségének elkerülése érdekében először egy PARTÍCIÓ BY nélküli lekérdezéssel kezdje, és futtassa a lekérdezést 1 SU V2-vel a maximális terhelés méréséhez az 1. esethez hasonlóan.
- Ha az átviteli sebesség alatt el tudja érni a várt terhelést, akkor készen áll. Azt is megteheti, hogy a 2/3 SU V2-n és 1/3 SU V2-n futtatott tört csomópontokkal futtatott feladatot méri, hogy megtudja, hány streamelési egység működik a forgatókönyvben.
- Ha nem tudja elérni a kívánt átviteli sebességet, próbálja meg több lépésre bontani a lekérdezést, ha még nem rendelkezik több lépéssel, és a lekérdezés minden lépéséhez legfeljebb egy SU V2-t foglaljon le. Ha például három lépéssel rendelkezik, foglal le három SU V2-t a "Skálázás" beállításban.
- Egy ilyen feladat futtatásához a Stream Analytics minden lépést a saját csomópontjára helyez egy dedikált SU V2-erőforrással.
- Ha még mindig nem érte el a betöltési célt, a partíciót a bemenethez közelebbi lépésekkel próbálja meg használni. A GROUP BY operátor esetében, amely nem természetes módon particionálható, használhatja a helyi/globális összesítő mintát egy particionált GROUP BY, majd egy nem particionált GROUP BY végrehajtásához. Ha például meg szeretné számolni, hogy hány autó halad át az egyes fizetős standokon 3 percenként, és az adatok mennyisége meghaladja azt, amit egy SU V2 kezelhet.
Lekérdezés:
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
A lekérdezésben az autókat egy fizetős standra számítja partíciónként, majd összeadja az összes partíció darabszámát.
A particionálás után a lépés minden partíciója számára foglal le egy SU V2-t, hogy minden partíció a saját feldolgozási csomópontjára helyezhető legyen.
Feljegyzés
Ha a lekérdezés nem particionálható, előfordulhat, hogy egy többlépéses lekérdezésben további su hozzáadása nem mindig javítja az átviteli sebességet. A teljesítmény elérésének egyik módja, ha az 5. lépésben leírt helyi/globális összesítési minta használatával csökkenti a kezdeti lépések mennyiségét.
3. eset – Sok független lekérdezést futtat egy feladatban.
Bizonyos ISV-használati eseteknél, ahol költséghatékonyabb egyetlen feladat több bérlőjéből származó adatokat feldolgozni, az egyes bérlőkhöz külön bemeneteket és kimeneteket használva, végül elég sok (például 20) független lekérdezést futtat egyetlen feladatban. A feltételezés az, hogy az egyes alhálózatok terhelése viszonylag kicsi.
Ebben az esetben kövesse az alábbi lépéseket.
- Ebben az esetben ne használja a PARTITION BY parancsot a lekérdezésben
- Az Event Hubs használata esetén csökkentse a bemeneti partíciók számát a lehető legalacsonyabb 2 értékre.
- Futtassa a lekérdezést egy SU V2-vel. Az egyes al lekérdezések várható terhelésével adjon hozzá minél több ilyen al lekérdezést, amíg a feladat nem éri el a rendszer erőforráskorlátait. A tüneteket az 1. esetnél kell keresni.
- Miután elérte a mért subquery-korlátot, kezdje el hozzáadni az al lekérdezést egy új feladathoz. A független lekérdezések számának függvényeként futtatandó feladatok számának meglehetősen lineárisnak kell lennie, feltéve, hogy nincs terheléseltérés. Ezután előre jelezheti, hogy hány SU V2-feladatot kell futtatnia a kiszolgálni kívánt bérlők számának függvényében.
- Ha referenciaadat-illesztéseket használ az ilyen lekérdezésekkel, egyesíti a bemeneteket, mielőtt ugyanazokkal a referenciaadatokkal csatlakozna. Ezután bontsa fel az eseményeket, ha szükséges. Ellenkező esetben minden referenciaadat-illesztés megőrzi a referenciaadatok másolatát a memóriában, ami valószínűleg szükségtelenül robbantja fel a memóriahasználatot.
Feljegyzés
Hány bérlőt kell elhelyezni az egyes feladatokban? Ez a lekérdezési minta gyakran nagy számú al lekérdezéssel rendelkezik, és nagyon nagy és összetett topológiát eredményez. Előfordulhat, hogy a feladat vezérlője nem képes kezelni egy ilyen nagy topológiát. Ökölszabályként egy 1/3 SU V2-feladatnál 40 bérlőnél, a 2/3-as és 1 SU V2-feladatoknál pedig 60 bérlőnél marad. Ha túllépi a vezérlő kapacitását, a feladat nem indul el sikeresen.
Segítség kérése
További segítségért próbálja ki a Microsoft Q&A kérdésoldalát az Azure Stream Analyticshez.
Következő lépések
- Az Azure Stream Analytics bemutatása
- Get started using Azure Stream Analytics (Bevezetés az Azure Stream Analytics használatába)
- Azure Stream Analytics Query Language Reference (Referencia az Azure Stream Analytics lekérdezési nyelvhez)
- Az Azure Stream Analytics felügyeleti REST API referenciája