Hantera stora frågor i interaktiva arbetsflöden
En utmaning med interaktiva dataarbetsflöden är att hantera stora frågor. Detta inkluderar frågor som genererar för många utdatakolumner, hämtar många externa partitioner eller beräknar mycket stora datamängder. Dessa frågor kan vara mycket långsamma, mätta beräkningsresurser och göra det svårt för andra att dela samma beräkning.
Query Watchdog är en process som förhindrar att frågor monopoliserar beräkningsresurser genom att undersöka de vanligaste orsakerna till stora frågor och avsluta frågor som passerar ett tröskelvärde. I den här artikeln beskrivs hur du aktiverar och konfigurerar Query Watchdog.
Viktigt!
Query Watchdog är aktiverat för alla beräkningsfunktioner som skapats med hjälp av användargränssnittet.
Exempel på en störande fråga
En analytiker utför vissa ad hoc-frågor i ett just-in-time-informationslager. Analytikern använder en delad autoskalningsberäkning som gör det enkelt för flera användare att använda en enda beräkning samtidigt. Anta att det finns två tabeller som var och en har en miljon rader.
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")
Dessa tabellstorlekar är hanterbara i Apache Spark. De innehåller dock var och en en join_key kolumn med en tom sträng i varje rad. Detta kan inträffa om data inte är helt rena eller om det finns betydande datasnedvridning där vissa nycklar är vanligare än andra. Dessa tomma kopplingsnycklar är mycket vanligare än något annat värde.
I följande kod ansluter analytikern dessa två tabeller till sina nycklar, vilket ger utdata på en biljon resultat, och alla dessa skapas på en enda exekutor (den köre som hämtar " " nyckeln):
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
Den här frågan verkar köras. Men utan att känna till data ser analytikern att det "bara" finns en enda uppgift kvar under körningen av jobbet. Frågan avslutas aldrig, vilket gör analytikern frustrerad och förvirrad över varför den inte fungerade.
I det här fallet finns det bara en problematisk kopplingsnyckel. Andra gånger kan det finnas många fler.
Aktivera och konfigurera Query Watchdog
Följande steg krävs för att aktivera och konfigurera Query Watchdog.
- Aktivera Vakthund med
spark.databricks.queryWatchdog.enabled. - Konfigurera aktivitetskörningen med
spark.databricks.queryWatchdog.minTimeSecs. - Visa utdata med
spark.databricks.queryWatchdog.minOutputRows. - Konfigurera utdataförhållandet med
spark.databricks.queryWatchdog.outputRatioThreshold.
Om du vill förhindra att en fråga skapar för många utdatarader för antalet indatarader kan du aktivera Query Watchdog och konfigurera det maximala antalet utdatarader som en multipel av antalet indatarader. I det här exemplet använder vi ett förhållande på 1 000 (standardvärdet).
spark.conf.set("spark.databricks.queryWatchdog.enabled", true)
spark.conf.set("spark.databricks.queryWatchdog.outputRatioThreshold", 1000L)
Den senare konfigurationen deklarerar att en viss uppgift aldrig ska generera mer än 1 000 gånger så många indatarader.
Dricks
Utdataförhållandet är helt anpassningsbart. Vi rekommenderar att du börjar lägre och ser vilken tröskel som fungerar bra för dig och ditt team. Ett intervall på 1 000 till 10 000 är en bra utgångspunkt.
Query Watchdog hindrar inte bara användare från att monopolisera beräkningsresurser för jobb som aldrig kommer att slutföras, det sparar också tid genom att snabbt misslyckas med en fråga som aldrig skulle ha slutförts. Följande fråga misslyckas till exempel efter flera minuter eftersom den överskrider förhållandet.
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
Här är vad du skulle se:
Det räcker vanligtvis för att aktivera Query Watchdog och ange tröskelvärdet för utdata/indata, men du har också möjlighet att ange två ytterligare egenskaper: spark.databricks.queryWatchdog.minTimeSecs och spark.databricks.queryWatchdog.minOutputRows. Dessa egenskaper anger den minsta tid som en viss aktivitet i en fråga måste köras innan den avbryts och det minsta antalet utdatarader för en aktivitet i frågan.
Du kan till exempel ange minTimeSecs ett högre värde om du vill ge det en chans att skapa ett stort antal rader per aktivitet. På samma sätt kan du ange spark.databricks.queryWatchdog.minOutputRows tio miljoner om du bara vill stoppa en fråga efter att en uppgift i frågan har genererat tio miljoner rader. Allt mindre och frågan lyckas, även om utdata/indata-förhållandet överskreds.
spark.conf.set("spark.databricks.queryWatchdog.minTimeSecs", 10L)
spark.conf.set("spark.databricks.queryWatchdog.minOutputRows", 100000L)
Dricks
Om du konfigurerar Query Watchdog i en notebook-fil bevaras inte konfigurationen mellan omstarter av beräkning. Om du vill konfigurera Query Watchdog för alla användare av en beräkning rekommenderar vi att du använder en beräkningskonfiguration.
Identifiera fråga på extremt stor datauppsättning
En annan vanlig stor fråga kan genomsöka en stor mängd data från stortabeller/datauppsättningar. Genomsökningsåtgärden kan pågå under lång tid och mätta beräkningsresurser (även läsning av metadata för en stor Hive-tabell kan ta lång tid). Du kan ställa in maxHivePartitions för att förhindra att för många partitioner hämtas från en stor Hive-tabell. På samma sätt kan du också ange maxQueryTasks för att begränsa frågor på en extremt stor datamängd.
spark.conf.set("spark.databricks.queryWatchdog.maxHivePartitions", 20000)
spark.conf.set("spark.databricks.queryWatchdog.maxQueryTasks", 20000)
När ska du aktivera Query Watchdog?
Query Watchdog bör aktiveras för ad hoc-analysberäkning där SQL-analytiker och dataforskare delar en viss beräkning och en administratör måste se till att frågor "spelas upp bra" med varandra.
När ska du inaktivera Query Watchdog?
I allmänhet rekommenderar vi inte att du ivrigt avbryter frågor som används i ett ETL-scenario eftersom det vanligtvis inte finns någon människa i loopen för att korrigera felet. Vi rekommenderar att du inaktiverar Query Watchdog för alla utom ad hoc-analysberäkning.