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 utdatarader, hämtar många externa partitioner eller beräknar på extremt 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.

Viktig

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 betydligt vanligare än något annat värde.

I följande kod sammansluter analytikern dessa två tabeller på deras nycklar, vilket ger utdata av en biljon resultat, och alla dessa skapas på en enda utförare (den utföraren 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 sökfrågan verkar köras. Men utan att känna till data ser analytikern att det "bara" finns en enda uppgift kvar under genomförandet av uppgiften. 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 körningen av uppgifter 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.

Tips

Utmatningsfö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 till 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 till 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 sökfrågan lyckas, även om förhållandet mellan utdata och indata överskrids.

spark.conf.set("spark.databricks.queryWatchdog.minTimeSecs", 10L)
spark.conf.set("spark.databricks.queryWatchdog.minOutputRows", 100000L)

Tips

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 ange 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 datauppsättning.

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 vara aktivt för ad hoc-analysberäkningar där SQL-analytiker och dataforskare delar ett gemensamt beräkningsutrymme och en administratör måste se till att frågor samarbetar väl 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.