Zpracování rozsáhlých dotazů v interaktivních pracovních postupech
Výzvou s interaktivními datovými pracovními postupy je zpracování velkých dotazů. To zahrnuje dotazy, které generují příliš mnoho výstupních řádků, načítají mnoho externích oddílů nebo provádějí výpočty s velmi velkými datovými sadami. Tyto dotazy můžou být extrémně pomalé, nasytit výpočetní prostředky a znesnadnit ostatním sdílení stejného výpočetního výkonu.
Watchdog dotazů je proces, který brání dotazům v monopolizaci výpočetních prostředků prozkoumáním nejběžnějších příčin velkých dotazů a ukončením dotazů, které předávají prahovou hodnotu. Tento článek popisuje, jak povolit a nakonfigurovat watchdog dotazů.
Důležité
Služba Watchdog pro dotazy je povolená pro všechny výpočetní funkce vytvořené pro všechny účely vytvořené pomocí uživatelského rozhraní.
Příklad rušivého dotazu
Analytik provádí některé ad hoc dotazy v datovém skladu za běhu. Analytik používá sdílené výpočetní prostředky automatického škálování, které více uživatelům usnadňuje použití jednoho výpočetního výkonu najednou. Předpokládejme, že existují dvě tabulky, které mají každý milion řádků.
import org.apache.spark.sql.functions._
spark.conf.set("spark.sql.shuffle.partitions", 10)
spark.range(1000000)
.withColumn("join_key", lit(" "))
.createOrReplaceTempView("table_x")
spark.range(1000000)
.withColumn("join_key", lit(" "))
.createOrReplaceTempView("table_y")
Tyto velikosti tabulek se dají spravovat v Apache Sparku. Každý z nich ale obsahuje join_key sloupec s prázdným řetězcem v každém řádku. K tomu může dojít v případě, že data nejsou dokonale čistá nebo pokud dochází k významné nerovnoměrné distribuci dat, kde jsou některé klíče častější než jiné. Tyto prázdné klíče spojení jsou mnohem častější než jakákoli jiná hodnota.
Analytik v následujícím kódu spojuje tyto dvě tabulky na svých klíčích, což vytváří výstup jednoho trilionu výsledků a všechny se vytvoří na jednom exekutoru (exekutor, který klíč získá " " ):
SELECT
id, count(id)
FROM
(SELECT
x.id
FROM
table_x x
JOIN
table_y y
on x.join_key = y.join_key)
GROUP BY id
Zdá se, že tento dotaz je spuštěný. Ale bez znalosti dat analytik vidí, že v průběhu provádění úlohy zbývá jen jeden úkol. Dotaz se nikdy nedokončí, analytik je frustrovaný a zmatený o tom, proč nefungoval.
V tomto případě existuje pouze jeden problematický klíč spojení. Jindy může existovat mnohem víc.
Povolení a konfigurace watchdogu dotazu
Pokud chcete povolit a nakonfigurovat watchdog dotazu, je potřeba provést následující kroky.
- Povolte watchdog s
spark.databricks.queryWatchdog.enabled. - Nakonfigurujte modul runtime úlohy pomocí
spark.databricks.queryWatchdog.minTimeSecsmodulu runtime . - Zobrazit výstup s
spark.databricks.queryWatchdog.minOutputRows. - Nakonfigurujte výstupní poměr pomocí
spark.databricks.queryWatchdog.outputRatioThresholdfunkce .
Pokud chcete zabránit, aby dotaz vytvářel příliš mnoho výstupních řádků pro počet vstupních řádků, můžete povolit watchdog dotazu a nakonfigurovat maximální počet výstupních řádků jako násobek počtu vstupních řádků. V tomto příkladu používáme poměr 1 000 (výchozí).
spark.conf.set("spark.databricks.queryWatchdog.enabled", true)
spark.conf.set("spark.databricks.queryWatchdog.outputRatioThreshold", 1000L)
Druhá konfigurace deklaruje, že každý daný úkol by nikdy neměl generovat více než 1000krát počet vstupních řádků.
Tip
Výstupní poměr je zcela přizpůsobitelný. Doporučujeme začít s nižší hodnotou a zjistit, jaká prahová hodnota pro vás a váš tým dobře funguje. Dobrým výchozím bodem je rozsah 1 000 až 10 000.
Kromě toho, že query Watchdog brání uživatelům v monopolizaci výpočetních prostředků pro úlohy, které se nikdy nedokončí, šetří také čas tím, že rychle selhává dotaz, který by se nikdy nedokončil. Například následující dotaz po několika minutách selže, protože překračuje poměr.
SELECT
z.id
join_key,
sum(z.id),
count(z.id)
FROM
(SELECT
x.id,
y.join_key
FROM
table_x x
JOIN
table_y y
on x.join_key = y.join_key) z
GROUP BY join_key, z.id
Podívejte se, co byste viděli:
Obvykle stačí povolit watchdog dotazu a nastavit poměr prahových hodnot výstupu a vstupu, ale máte také možnost nastavit dvě další vlastnosti: spark.databricks.queryWatchdog.minTimeSecs a spark.databricks.queryWatchdog.minOutputRows. Tyto vlastnosti určují minimální čas, po který musí být daný úkol v dotazu spuštěný, a minimální počet výstupních řádků úkolu v daném dotazu.
Pokud například chcete dát šanci vytvořit velký počet řádků na úkol, můžete ji nastavit minTimeSecs na vyšší hodnotu. Podobně můžete nastavit spark.databricks.queryWatchdog.minOutputRows na deset milionů, pokud chcete zastavit dotaz až po úkolu v daném dotazu, který vytvořil deset milionů řádků. Cokoliv menšího a dotaz bude úspěšný, i když byl překročen poměr výstupu a vstupu.
spark.conf.set("spark.databricks.queryWatchdog.minTimeSecs", 10L)
spark.conf.set("spark.databricks.queryWatchdog.minOutputRows", 100000L)
Tip
Pokud v poznámkovém bloku nakonfigurujete watchdog dotazu, konfigurace se při restartování výpočetních prostředků neuchová. Pokud chcete nakonfigurovat watchdog dotazu pro všechny uživatele výpočetních prostředků, doporučujeme použít konfiguraci výpočetních prostředků.
Detekce dotazu na extrémně velkou datovou sadu
Dalším typickým velkým dotazem může prohledávat velké množství dat z velkých tabulek nebo datových sad. Operace prohledávání může trvat dlouhou dobu a saturovat výpočetní prostředky (i čtení metadat velké tabulky Hive může trvat značné množství času). Můžete nastavit maxHivePartitions , aby se zabránilo načtení příliš velkého počtu oddílů z velké tabulky Hive. Podobně můžete také nastavit maxQueryTasks omezení dotazů na extrémně velkou datovou sadu.
spark.conf.set("spark.databricks.queryWatchdog.maxHivePartitions", 20000)
spark.conf.set("spark.databricks.queryWatchdog.maxQueryTasks", 20000)
Kdy byste měli povolit watchdog dotazu?
Služba Watchdog dotazů by měla být povolená pro výpočetní výkon ad hoc analýzy, kdy analytici SQL a datoví vědci sdílejí daný výpočetní výkon a správce musí zajistit, aby se dotazy vzájemně "dobře hrály".
Kdy byste měli zakázat watchdog dotazu?
Obecně nedoporučujeme dychtivě rušit dotazy používané ve scénáři ETL, protože obvykle není člověk ve smyčce k opravě chyby. Doporučujeme zakázat watchdog dotazů pro výpočetní prostředky ad hoc.