Több strukturált streamelési lekérdezés futtatása ugyanazon a fürtön

Sok ügyfél több strukturált streamelési lekérdezést futtat ugyanazon a Azure Databricks fürtön. Bár ez a minta támogatott, a Databricks javasolja a fürtönkénti lekérdezések számának korlátozását a skálázási problémák és a teljesítmény szűk keresztmetszeteinek elkerülése érdekében. Kiszolgáló nélküli számítás esetén Azure Databricks automatikusan kezeli a skálázást, így ezeket a szempontokat önnek kell kezelnie. Ha klasszikus számítást használ, ahol az illesztőprogramok és a végrehajtók méretezését vezérli, ez a lap ismerteti a legfontosabb szűk keresztmetszeteket, amelyeket szem előtt kell tartani, és hogyan lehet kezelni őket.

Mikor érdemes több lekérdezést használni ugyanazon a fürtön?

Ha több streamlekérdezést futtat ugyanazon a fürtön, azzal csökkenti az infrastruktúra költségeit, különösen akkor, ha sok olyan kis stream van, amely nem igényel dedikált számítást. A legfőbb hátrány a közös hibakockázat: ha a fürt meghibásodik, az összes rajta futó adatfolyam is meghibásodik. Kritikus fontosságú folyamatok esetén ez a megosztott hibamód gyakran elfogadhatatlan.

A kritikus és nem kritikus streameket keverő számítási feladatok esetében a Databricks a következőket javasolja:

• Minden streamhez rendeljen prioritást az üzleti hatása alapján.
• A küldetéskritikus adatfolyamokat dedikált klaszterekre helyezze, még magasabb költség mellett is.
• Az alacsonyabb prioritású streamek együttes megkeresése a számítási és költségcsökkentési feladatok megosztásához.

Illesztőprogram méretezése

Az illesztőprogram egy megosztott erőforrás. Több lekérdezés ugyanazt a CPU-t, memóriát, DAG-ütemezőt, feladatütemezőt és illesztőprogram oldali UDF-végrehajtást használja (például foreachBatch). Ha több egyidejű streamet futtat, figyelje meg ezeket a szűk keresztmetszeteket a szabványos PROCESSZOR- és memóriakiépítésen túl:

• Automatikus betöltő többletterhelése: Ha a streamek automatikus betöltőt használnak, a fájlfelderítés és a címtárlista növeli az illesztőprogramok terhelését.
• Operációsrendszer-szintű erőforráskorlátok (megnyitott fájlok): Ha nagy mennyiségű fájlalapú streamet (például FileStreamSource vagy automatikus betöltőt) futtat egyszerre egy illesztőprogramon, az kimerítheti a felhasználószintű nyitott fájlleíró korlátait, ami véletlenszerű streamhibákat okozhat.
• Figyelőbusz háttérnyomása: Az egyidejű streamelési lekérdezések nagy száma okozhat háttérnyomást az egyetlen Spark-munkamenet buszán StreamingQueryListener . Minden eseményt (beleértve a(z) onQueryIdle elemet is) erre az egyetlen buszra küldenek, és a nagy eseménytorlódás súlyosan késleltetheti az aszinkron onQueryProgress kezelőket, valamint befolyásolhatja a fürt stabilitását.
• Költséges illesztőprogram-műveletek: Kerülje a hívásokat collect() vagy más költséges DataFrame-műveleteket az illesztőprogramon, kivéve, ha feltétlenül szükséges, hogy elkerülje a nagy eredményhalmazok materializálását és a memóriahiányos (OOM) hibákat.

Illesztőprogram-versengés hibaelhárítása

Ha OOM vagy erőforrás-ütközési problémák miatt illesztőprogram-összeomlásokat tapasztal:

1. Illesztőprogram-metrikák monitorozása a Spark felhasználói felületén. Ha magas processzor-, memória- vagy lemezhasználatot lát, módosítsa az illesztőprogramok méretezését a fürt számítási beállításai között.
2. Ha a problémák továbbra is fennállnak, ellenőrizze, hogy a kód nem futtat-e memóriaigényes műveleteket vagy UDF-eket az illesztőprogramon.
3. Ha az illesztőprogram vertikálisan nem skálázható tovább, a Databricks határozottan javasolja a feladatok több fürtre való felosztását a megosztott csomópontok méretezési szűk keresztmetszeteinek megkerülése érdekében.

Végrehajtó méretezése

Ha több lekérdezés is fut ugyanazon a fürtön, az összes lekérdezés feladathelyeket oszt meg a végrehajtókon. Egy lekérdezés fázisai elfoglalhatják a rendelkezésre álló kapacitást, ez pedig késedelmet és kiéheztetést okozhat a többi lekérdezésnél. A Spark 1:1-alapú leképezést használ a feladathelyek és az elérhető magok között. Győződjön meg arról, hogy elegendő mag áll rendelkezésre, ha a lekérdezéseknek egyidejűleg kell futniuk.

A végrehajtók általában több memóriaigényes műveletet hajthatnak végre, mint az illesztőprogram-csomópont. Szükség esetén hangolja a végrehajtó JVM-et és a halomon kívüli memórialefoglalási paramétereket az alkalmazás terhelésének kezeléséhez. Győződjön meg arról, hogy a végrehajtó csomópontok mérete a processzor, a memória és a lemezterület szempontjából megfelelő, és szükség esetén vertikálisan skálázható. Ha a vertikális skálázás nem lehetséges, fontolja meg további feldolgozó csomópontok hozzáadását a fürthöz.

Ütemezőcsoportok használata

Konfigurálhatja az ütemezőkészleteket úgy, hogy számítási kapacitást rendeljenek a lekérdezésekhez, ha több streamelési lekérdezést futtat ugyanazon forráskódból.

Alapértelmezés szerint az összes lekérdezés ugyanabban a tisztességes ütemezési csoportban fut egy jegyzetfüzetben. A jegyzetfüzetben lévő összes streamlekérdezés eseményindítói által létrehozott Apache Spark-feladatok egymás után futnak "first in, first out" (FIFO) sorrendben. Ez szükségtelen késéseket okozhat a lekérdezésekben, mert nem hatékonyan osztják meg a fürt erőforrásait.

A Scheduler-készletek lehetővé teszik, hogy deklarálja, mely strukturált streaming lekérdezések osztanak meg számítási erőforrásokat.

Az alábbi példa query1 dedikált készlethez rendel, míg query2 és query3 megosztanak egy ütemezőkészletet.

:::megjegyzés Kiszolgáló nélküli kompatibilitás

A Databricks azt javasolja, hogy hagyja el a(z) spark.sparkContext használatát, mivel az nem kompatibilis a Databricks szerver nélküli számítási architektúrával. Ehelyett közvetlenül a spark (SparkSession) elemet használja. A Scheduler-készletek klasszikus számítási koncepciók; kiszolgáló nélküli eszközökön a Databricks automatikusan kezeli a skálázást és az erőforrás-lefoglalást.

:::

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

A tisztességes ütemezőkészletekkel kapcsolatos további információkért tekintse meg az Apache Spark fair scheduler dokumentációját.

Állapotalapú lekérdezési szempontok

Az ugyanazon a fürtön futó állapotalapú lekérdezések esetében tartsa szem előtt az alábbiakat:

• Az OOM-problémák és a GC-szüneteltetések elkerülése érdekében használja a RocksDB-t állapottár-szolgáltatóként. A RocksDB az alapértelmezett állapottároló-szolgáltató a Databricks Runtime 17.3-ban és újabb verziókban. Lásd: A RocksDB állapottároló konfigurálása az Azure Databricksben.
• Hangolja a shuffle partíciókat az alkalmazás követelményeinek megfelelően. Állapotalapú szakaszok esetén a Spark a feladatokat az shuffle partíciók számával arányosan ütemezi.
• Korlátozza a RocksDB memóriahasználatát csomópontonként a heapen kívüli memóriahasználatból eredő OOM-hibák elkerülése érdekében. Ezt a rendszer automatikusan kezeli a Databricks Runtime 17.3-ban és újabb verzióiban, de a korábbi kiadások manuális konfigurálását igényli. Lásd: Cap RocksDB memóriahasználat.
• Ne csomagoljon túl sok partíciót ugyanazon a végrehajtó csomóponton. Az állapottároló karbantartási műveletei, beleértve a pillanatképek feltöltését és törlését, csomópontonként futnak. Ha túl sok partíciót rendel egy végrehajtó csomóponthoz, az karbantartási éhezést és hosszabb helyreállítási időt okozhat, mivel kevesebb teljes pillanatkép érhető el.