Share via

Azure Stream Analytics-feladat skálázása az átviteli sebesség növelése érdekében

  • Cikk

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