Nagyméretű lekérdezések kezelése interaktív munkafolyamatokban

Az interaktív adat-munkafolyamatokkal kapcsolatos kihívás a nagy lekérdezések kezelése. Ide tartoznak azok a lekérdezések, amelyek túl sok kimeneti sort generate, sok külső partíciót lekérnek, vagy rendkívül nagy adatkészleteken számolnak. Ezek a lekérdezések rendkívül lassúak lehetnek, telíthetik a számítási erőforrásokat, és megnehezíthetik mások számára ugyanazt a számítást.

A Lekérdezésfigyelő egy olyan folyamat, amely megakadályozza, hogy a lekérdezések monopolizálják a számítási erőforrásokat a nagy méretű lekérdezések leggyakoribb okainak vizsgálatával és a küszöbértéket átlépő lekérdezések megszüntetésével. Ez a cikk a Query Watchdog engedélyezését és konfigurálását ismerteti.

Példa egy zavaró lekérdezésre

Az elemzők alkalmi lekérdezéseket hajtanak végre egy igény szerint használható adattárházban. Az elemző megosztott automatikus skálázási számítást használ, amely megkönnyíti, hogy több felhasználó egyszerre egyetlen számítást használjon. Tegyük fel, hogy két tables van, amelyek mindegyike egymillió sorból áll.

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

Ezek a table méretek kezelhetők az Apache Sparkban. Ezek azonban minden sorban egy üres karakterláncot tartalmazó join_keycolumn-et tartalmaznak. Ez akkor fordulhat elő, ha az adatok nem teljesen tisztaak, vagy ha jelentős adateltérés áll fenn, where egyes kulcsok elterjedtebbek, mint mások. Ezek az üres join kulcsok sokkal elterjedtebbek, mint bármely más érték.

A következő kódban az elemző összekapcsolja ezt a két tables-t a kulcsuk alapján, ami egy billió eredményt eredményez, és ezek mindegyik egyetlen végrehajtón fut le (az a végrehajtó, amelyik a " " kulcsot kapja):

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

Úgy tűnik, hogy ez a lekérdezés fut. Az adatok ismerete nélkül azonban az elemző azt látja, hogy "csak" egyetlen feladat maradt a feladat végrehajtása során. A lekérdezés soha nem fejeződik be, így az elemző csalódott és összezavarodott azzal kapcsolatban, hogy miért nem működött.

Ebben az esetben csak egy problémás join kulcs van. Máskor lehet, hogy még sok más.

Lekérdezésfigyelő engedélyezése és konfigurálása

A Query Watchdog engedélyezéséhez és konfigurálásához a következő lépések szükségesek.

• A Watchdog engedélyezése spark.databricks.queryWatchdog.enabled-tal.
• Konfigurálja a feladat futási környezetét a spark.databricks.queryWatchdog.minTimeSecs-val.
• Kimenet megjelenítése spark.databricks.queryWatchdog.minOutputRows.
• Konfigurálja a kimeneti arányt a spark.databricks.queryWatchdog.outputRatioThreshold.

Ha meg szeretné akadályozni, hogy egy lekérdezés túl sok kimeneti sort hozzon létre a bemeneti sorok számára, engedélyezheti a Lekérdezésfigyelőt, és a kimeneti sorok maximális számát a bemeneti sorok számának többszöröseként konfigurálhatja. Ebben a példában 1000 arányt használunk (ez az alapértelmezett érték).

spark.conf.set("spark.databricks.queryWatchdog.enabled", true)
spark.conf.set("spark.databricks.queryWatchdog.outputRatioThreshold", 1000L)

Az utóbbi konfiguráció azt deklarálja, hogy egy adott tevékenységnek soha nem szabad 1000-nél több értéket előállítania a bemeneti sorok számánál.

A Query Watchdog nem csak azt akadályozza meg, hogy a felhasználók monopolizálják a számítási erőforrásokat olyan feladatokhoz, amelyek soha nem fejeződnek be, hanem időt takarít meg azzal is, hogy gyorsan meghiúsul egy olyan lekérdezés, amely soha nem fejeződött volna be. A következő lekérdezés például több perc után meghiúsul, mert meghaladja az arányt.

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

A következőt fogja látni:

Általában elegendő engedélyezni a Query Watchdogot, és set a kimeneti/bemeneti küszöbérték arányát, de két további tulajdonságot is set: spark.databricks.queryWatchdog.minTimeSecs és spark.databricks.queryWatchdog.minOutputRows. Ezek a tulajdonságok határozzák meg azt a minimális időt, amikor egy adott tevékenységnek le kell futnia a lekérdezésben a megszakítás előtt, valamint a lekérdezésben szereplő tevékenység kimeneti sorainak minimális számát.

Magasabb értékre állíthatja setminTimeSecs, ha lehetőséget szeretne adni neki, hogy tevékenységenként nagy számú sort állítson elő. Hasonlóképpen, beállíthatja tízmillióra is a setspark.databricks.queryWatchdog.minOutputRows-t, ha csak akkor szeretné leállítani a lekérdezést, amikor a lekérdezésben végrehajtott feladat tízmillió sort állított elő. Bármivel kevesebb esetén a lekérdezés sikeres lesz, még akkor is, ha a kimeneti/bemeneti arányt túllépte.

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

Lekérdezés észlelése rendkívül nagy adathalmazon

Egy másik tipikus nagy lekérdezés nagy mennyiségű adatot vizsgálhat nagy tables/adathalmazokból. A vizsgálati művelet hosszú ideig tarthat, és telítheti a számítási erőforrásokat (még a nagy Hive-table metaadatainak olvasása is jelentős időt vehet igénybe). A setmaxHivePartitions megakadályozható a túl sok partíció beolvasása egy nagy Hive table-től. Hasonlóképpen, a setmaxQueryTasks a limit lekérdezéseket egy rendkívül nagy adatkészleten.

spark.conf.set("spark.databricks.queryWatchdog.maxHivePartitions", 20000)
spark.conf.set("spark.databricks.queryWatchdog.maxQueryTasks", 20000)

Mikor érdemes engedélyezni a Query Watchdogot?

A Lekérdezésfigyelőt engedélyezni kell az alkalmi elemzésekhez, where SQL-elemzők és adattudósok megosztanak egy adott számítást, és a rendszergazdának gondoskodnia kell arról, hogy a lekérdezések "jól játsszanak" egymással.

Mikor kell letiltani a Query Watchdogot?

Általában nem javasoljuk az ETL-forgatókönyvben használt lekérdezések hirtelen lemondását, mert általában nincs ember, aki beavatkozhatna a hiba kijavításához. Javasoljuk, hogy minden esetben, kivéve az ad hoc elemzési számításokat, tiltsa le a Query Watchdogot.