Spuštění několika dotazů strukturovaného streamování ve stejném clusteru

Mnoho zákazníků spouští ve stejném clusteru Azure Databricks několik dotazů strukturovaného streamování. I když se tento model podporuje, Databricks doporučuje omezit počet dotazů na cluster, aby nedocházelo k problémům se škálováním a kritickým bodům výkonu. Na výpočetních prostředcích bez serveru Azure Databricks automaticky spravuje škálování, takže tyto aspekty se za vás zpracují. Pokud používáte klasické výpočetní prostředky, kde řídíte velikost ovladače a exekutoru, tato stránka popisuje klíčové kritické body, které je potřeba mít na paměti a jak je řešit.

Note

Databricks doporučuje používat deklarativní kanály Sparku Lakeflow pro nové úlohy streamování, které spravují složitost infrastruktury automaticky. Viz Lakeflow Spark deklarativní kanály.

Kdy použít více dotazů ve stejném clusteru

Spouštění více dotazů streamování na stejném clusteru snižuje náklady na infrastrukturu, zejména pokud máte mnoho malých datových proudů, které nevyžadují vyhrazené výpočetní prostředky. Klíčovým kompromisem je sdílené selhání: pokud cluster selže, každý datový proud v něm selže. Pro klíčové kanály je tento režim sdíleného selhání často nepřijatelný.

Pro úlohy, které kombinují kritické a nekritické streamy, doporučuje Databricks následující:

  • Přiřaďte každému datovému proudu prioritu na základě jejího obchodního dopadu.
  • Umístěte klíčové datové proudy na vyhrazené clustery, a to i za vyšší cenu.
  • Umístěte streamy s nižší prioritou společně, aby sdílely výpočetní prostředky a snížily náklady.

Dimenzování ovladače

Ovladač je sdílený prostředek. Několik dotazů sdílí stejný procesor, paměť, plánovač DAG, plánovač úloh a provádění UDF na straně ovladače (například foreachBatch). Při spouštění mnoha souběžných datových proudů sledujte tyto konkrétní kritické body nad rámec standardního zřizování procesoru a paměti:

  • Režie nástroje Auto Loader: Pokud vaše datové proudy používají Auto Loader, zjišťování souborů a procházení adresářů zvyšují zatížení řídicího uzlu.
  • Limity prostředků na úrovni operačního systému (otevřené soubory): Současné spuštění velkého počtu streamů pracujících se soubory (například FileStreamSource nebo Auto Loaderu) na jednom driveru může vyčerpat limity počtu otevřených deskriptorů souborů pro uživatele, což může způsobovat náhodná selhání streamů.
  • Zahlcení sběrnice procesů naslouchání: Velký počet souběžných streamovacích dotazů může způsobit zahlcení sběrnice jediné relace SparkuStreamingQueryListener. Všechny události (včetně onQueryIdle) se odesílají do této jediné sběrnice a velké nahromadění událostí může výrazně zpozdit asynchronní obsluhy onQueryProgress a ovlivnit stabilitu clusteru.
  • Nákladné operace ovladače: Vyhněte se volání collect() nebo jiným nákladným operacím datového rámce na ovladači, pokud není nezbytně nutné, abyste se vyhnuli materializaci velkých sad výsledků a způsobujícím chyby OOM (nedostatek paměti).

Řešení problémů s konfliktem ovladačů

Pokud dochází k chybovému ukončení ovladače kvůli problémům s OOM nebo kolizí:

  1. Monitorování metrik ovladačů v uživatelském rozhraní Sparku Pokud se zobrazí vysoké využití procesoru, paměti nebo disku, upravte velikost ovladače v nastavení výpočetních prostředků clusteru.
  2. Pokud problémy přetrvávají, zkontrolujte, zda váš kód nespouští na driveru operace náročné na paměť ani uživatelsky definované funkce (UDF).
  3. Pokud ovladač nemůžete vertikálně škálovat, Databricks důrazně doporučuje rozdělit úlohy mezi několik clusterů, aby tyto kritické body škálování sdílených uzlů obešly.

Dimenzování vykonavatele

Když na stejném clusteru běží více dotazů, všechny dotazy sdílejí sloty úloh na exekutorech. Fáze jednoho dotazu mohou obsadit dostupné sloty, což může způsobit zpoždění a vyhladovění ostatních dotazů. Spark používá mapování 1:1 mezi sloty úloh a dostupnými jádry. Ujistěte se, že je k dispozici dostatek jader, pokud se dotazy musí spouštět souběžně.

Obecně platí, že exekutory můžou provádět více operací náročných na paměť než uzel ovladače. V případě potřeby vylaďte parametry JVM exekutoru a přidělení paměti mimo haldu tak, aby odpovídaly zatížení vaší aplikace. Ujistěte se, že uzly exekutoru mají v případě potřeby odpovídající velikost procesoru, paměti a místa na disku a v případě potřeby škálují vertikálně. Pokud vertikální škálování není možné, zvažte přidání dalších pracovních uzlů do clusteru.

Note

Některé z těchto změn můžou vyžadovat restartování clusteru, aby se projevilo.

Použití fondů plánovače

Fondy plánovačů můžete nakonfigurovat tak, aby přiřazovat výpočetní kapacitu dotazům při spouštění více streamovaných dotazů ze stejného zdrojového kódu.

Ve výchozím nastavení se všechny dotazy spouštějí v notebooku ve stejném vyváženém plánovacím fondu. Úlohy Apache Sparku generované triggery ze všech streamovaných dotazů v poznámkovém bloku běží jeden po druhém v pořadí "first in, first out" (FIFO). To může způsobit zbytečné zpoždění v dotazech, protože nesdílí prostředky clusteru efektivně.

Fondy scheduleru umožňují deklarovat, které dotazy strukturovaného streamování sdílejí výpočetní prostředky.

Následující příklad přiřazuje query1 do vyhrazeného fondu, zatímco query2 a query3 sdílejí fond plánovače.

:::Poznámka Bezserverová kompatibilita

Databricks doporučuje přestat používat spark.sparkContext, protože není kompatibilní s architekturou Databricks Serverless Compute. Použijte spark (SparkSession) přímo místo toho. Fondy plánovače jsou konceptem klasických výpočetních prostředků; v bezserverovém prostředí Databricks automaticky spravuje škálování a přidělování prostředků.

:::

# 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")

Note

Konfigurace místní vlastnosti musí být ve stejné buňce poznámkového bloku, ve které spustíte dotaz streamování.

Další informace o fondech spravedlivého plánovače naleznete v dokumentaci ke spravedlivému plánovači Apache Spark.

Aspekty stavových dotazů

U stavových dotazů spuštěných ve stejném clusteru mějte na paměti následující skutečnosti:

  • Jako poskytovatele úložiště stavů použijte RocksDB , abyste se vyhnuli problémům s OOM a pozastavením GC. RocksDB je výchozí zprostředkovatel úložiště stavů v Databricks Runtime 17.3 a novější. Viz Konfigurace úložiště stavů RocksDB v Azure Databricks.
  • Nastavte oddíly pro operaci shuffle podle požadavků vaší aplikace. V případě stavových fází Spark naplánuje úlohy úměrné počtu oddílů náhodného prohazování.
  • Omezení využití paměti RocksDB na jednotlivé uzly, aby se zabránilo chybám OOM při využití paměti mimo haldu. To se zpracovává automaticky v Databricks Runtime 17.3 a novějších verzích, ale vyžaduje ruční konfiguraci v dřívějších verzích. Viz Využití paměti Cap RocksDB.
  • Vyhněte se umisťování příliš mnoha oddílů na stejný uzel executoru. Operace údržby v úložišti stavů, včetně nahrávání a čištění snímků, běží na jednotlivých uzlech. Přiřazení příliš velkého počtu oddílů k jednomu uzlu executoru může způsobit nedostatek prostředků pro údržbu a prodloužit dobu obnovení kvůli menšímu počtu dostupných úplných snapshotů.
  • Last updated on