Azure Stream Analytics-feladat skálázása az átviteli sebesség növeléséhez

  • Cikk
  • 5 perc alatt elolvasható

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 feladatot a nagyobb terhelés kezelésére, és kihasználhatja a rendszererőforrások (például nagyobb sávszélesség, több CPU-erőforrás, több memória) előnyeit. Előfeltételként előfordulhat, hogy el kell olvasnia a következő cikkeket:

1. eset – A lekérdezés eredendően teljes mértékben párhuzamosítható a bemeneti partíciók között

Ha a lekérdezés eredendően teljes mértékben párhuzamosítható a bemeneti partíciók között, kövesse az alábbi lépéseket:

  1. Hozza létre a lekérdezést, hogy kínosan párhuzamos legyen a PARTITION BY kulcsszóval. További részleteket a lap kínosan párhuzamos feladatok szakaszában talál.
  2. A lekérdezésben használt kimeneti típusoktó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 zavaróan párhuzamos legyen. A PowerBI-kimenet például nem párhuzamosítható. A kimenetek mindig egyesítve lesznek, mielőtt elküldené a kimeneti fogadónak. A blobok, táblák, ADLS, Service Bus és Azure-függvények automatikusan párhuzamosak. Az SQL- és az Azure Synapse Analytics-kimenetek párhuzamosítási lehetőséget is választhatnak. Az eseményközpontnak be kell állítania a PartitionKey konfigurációt, hogy megfeleljen a PARTITION BY mezőnek (általában PartitionId). Az Event Hub esetében is ügyeljen arra, hogy az összes bemenet és kimenet partícióinak száma egyezzen a partíciók számával, hogy elkerülje a partíciók közötti keresztátvételt.
  3. Futtassa a lekérdezést 6 SU-val (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 a GROUP BY-t használja, mérje meg, hogy a feladat hány csoportot (számosságot) képes kezelni. A rendszererőforrás-korlátokat elérő feladat általános tünetei a következők.
    • Az SU %-os kihasználtsági metrika több mint 80%. Ez azt jelzi, hogy a memóriahasználat magas. A metrika növekedéséhez hozzájáruló tényezőket itt ismertetjük.
    • A kimeneti időbélyeg a falióra időéhez képest elmarad. A lekérdezési logikától függően a kimeneti időbélyegnek a falióra-időtől eltérő logikai eltolása lehet. Ugyanakkor nagyjából ugyanolyan ütemben kell haladniuk. Ha a kimeneti időbélyeg tovább csökken, az azt jelzi, hogy a rendszer túldolgozott. Ez lehet az alsóbb rétegbeli kimeneti fogadó szabályozása vagy a magas CPU-kihasználtság 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 fogadószabályozás okozza, előfordulhat, hogy 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ítható maradjon), vagy növelnie kell a fogadó erőforrásainak mennyiségét (például a CosmosDB kérelemegységeinek számát).
    • A feladatábrában minden bemenethez tartozik egy partíciónkénti teendőlista-eseménymetrika. Ha a hátralékesemény metrikája folyamatosan növekszik, az azt is jelzi, hogy a rendszererőforrás korlátozott (a kimeneti fogadó szabályozása vagy a magas cpu-használat miatt).
  4. Miután meghatározta, hogy milyen korlátokat érhet el egy 6 SU-feladat, lineárisan extrapolálhatja a feladat feldolgozási kapacitását további termékváltozatok hozzáadásakor, feltéve, hogy nincs olyan adateltérés, amely bizonyos partíciókat "gyakori elérésűvé" tesz.

Megjegyzés

Válassza ki a megfelelő számú streamelési egységet: Mivel a Stream Analytics létrehoz egy feldolgozási csomópontot minden egyes hozzáadott 6 SU-hoz, a legjobb, ha a csomópontok számát a bemeneti partíciók számának osztójaként hozza létre, így a partíciók egyenletesen eloszthatók a csomópontok között. A 6 SU-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 a feladatot 12 SU-val futtatja, hogy nagyjából 8 MB/s feldolgozási sebességet érjen el, vagy 24 SU-t a 16 MB/s eléréséhez. Ezután eldöntheti, hogy mikor növelje a feladat SU-számát a bemeneti sebesség függvényeként.

2. eset – Ha a lekérdezés nem zavaróan párhuzamos.

Ha a lekérdezés nem zavaróan párhuzamos, kövesse az alábbi lépéseket.

  1. Először egy PARTITION BY nélküli lekérdezéssel kezdje a particionálás összetettségének elkerülése érdekében, és futtassa a lekérdezést 6 SU-val a maximális terhelés méréséhez, az 1. esethez hasonlóan.
  2. Ha az átviteli sebesség alatt el tudja érni a várható terhelést, akkor készen áll. Azt is megteheti, hogy megméri ugyanazt a feladatot, amely 3 SU-nál és 1 SU-nál fut, hogy megtudja, az adott forgatókönyvhöz minimálisan hány SU működik.
  3. 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 lehetséges, ha még nem rendelkezik több lépéssel, és foglaljon le legfeljebb 6 SU-t a lekérdezés minden lépéséhez. Ha például 3 lépéssel rendelkezik, foglal le 18 SU-t a "Skálázás" beállításban.
  4. Ilyen feladat futtatásakor a Stream Analytics minden lépést a saját csomópontjára helyez dedikált 6 SU-erőforrással.
  5. Ha még mindig nem érte el a betöltési célt, megpróbálhatja használni a PARTITION-t a bemenethez közelebbi lépésekből kiindulva. A GROUP BY operátor esetében, amely nem feltétlenül particionálható, használhatja a helyi/globális összesítési 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 6 SU 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 fenti lekérdezésben partíciónként számolja az autókat fizetős standonként, majd összeadja az összes partíció darabszámát.

A particionálást követően a lépés minden partíciója esetében legfeljebb 6 SU-t foglaljon le, a 6 SU-t tartalmazó partíciók a maximálisak, így minden partíció elhelyezhető a saját feldolgozási csomópontján.

Megjegyzé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 növeli az átviteli sebességet. A teljesítmény elérésének egyik módja a kötet csökkentése a kezdeti lépésekben helyi/globális összesítési minta használatával, az 5. lépésben leírtak szerint.

3. eset – Sok független lekérdezést futtat egy feladatban.

Bizonyos ISV-használati esetekben, ahol költséghatékonyabb egyetlen feladat több bérlőjéből származó adatokat feldolgozni, minden bérlőhöz külön bemeneteket és kimeneteket használva, előfordulhat, hogy egy feladatban elég sok (például 20) független lekérdezés fut. A feltételezés az, hogy az egyes al lekérdezések terhelése viszonylag kicsi. Ebben az esetben kövesse az alábbi lépéseket.

  1. Ebben az esetben ne használja a PARTITION BY parancsot a lekérdezésben
  2. Event Hub használata esetén csökkentse a bemeneti partíciók számát a lehető legalacsonyabb 2 értékre.
  3. Futtassa a lekérdezést 6 SU-val. Az egyes segéd lekérdezések várható terhelésével adjon hozzá annyi ilyen segéd lekérdezést, amennyit csak lehet, amíg a feladat el nem éri a rendszer erőforráskorlátait. Ebben az esetben a tüneteket lásd az 1. esetnél .
  4. Miután elérte a fent mért lekérdezési korlátot, kezdje el hozzáadni a segéd 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-feladatot kell futtatnia a kiszolgálni kívánt bérlők számának függvényében.
  5. Ha referenciaadat-illesztéseket használ az ilyen lekérdezésekkel, egyesítve kell lennie a bemeneteknek, mielőtt ugyanazokhoz a referenciaadatokhoz csatlakozna. Ezután bontsa szét 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.

Megjegyzés

Hány bérlőt kell elhelyezni az egyes feladatokban? Ez a lekérdezési minta gyakran nagy számú segéd 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 40 bérlő alatt maradhat 1 SU-feladathoz, 60 bérlőhöz pedig 3 SU- és 6 SU-feladathoz. 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