Nagy mé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. Ez lehet túl sok kimeneti sort létrehozó, sok külső partíciót lekérő vagy rendkívül nagy adathalmazokon számítási műveleteket végző lekérdezés. 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.

Fontos

A Lekérdezésfigyelő engedélyezve van a felhasználói felületen létrehozott összes összes célú számításhoz.

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 tábla 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 táblázatméretek kezelhetők az Apache Sparkban. Ezek azonban minden sorban egy üres sztringet join_key tartalmazó oszlopot tartalmaznak. Ez akkor fordulhat elő, ha az adatok nem teljesen tisztaak, vagy ha jelentős adateltérés áll fenn, ahol egyes kulcsok elterjedtebbek, mint mások. Ezek az üres illesztőkulcsok sokkal elterjedtebbek, mint bármely más érték.

A következő kódban az elemző összekapcsolja ezt a két táblát a kulcsukon, amely egy trillió eredményt ad ki, és ezek mindegyike egyetlen végrehajtón (a kulcsot lekérő " " végrehajtón) jön létre:

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 illesztő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 a spark.databricks.queryWatchdog.enabled.
• A feladat futtatókörnyezetének konfigurálása a következővel spark.databricks.queryWatchdog.minTimeSecs: .
• Kimenet megjelenítése a következővel spark.databricks.queryWatchdog.minOutputRows: .
• Konfigurálja a kimeneti arányt a következővel 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.

Tipp.

A kimeneti arány teljesen testreszabható. Javasoljuk, hogy kezdjen alacsonyabban, és tekintse meg, hogy melyik küszöbérték működik jól Önnek és a csapatának. Egy 1000 és 10 000 közötti tartomány jó kiindulópont.

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:

Ez általában elegendő a Lekérdezésfigyelő engedélyezéséhez és a kimeneti/bemeneti küszöbérték arányának beállításához, de két további tulajdonságot is beállíthat: 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.

Beállíthatja például a magasabb értéket, ha lehetőséget szeretne adni neki arra, minTimeSecs hogy tevékenységenként nagy számú sort állítson elő. Hasonlóképpen tízmilliót is beállíthat spark.databricks.queryWatchdog.minOutputRows , ha csak azt követően szeretné leállítani a lekérdezést, hogy a lekérdezésben lévő tevékenység tízmillió sort állított elő. Bármi kevesebb, és a lekérdezés sikeres, még akkor is, ha a kimeneti/bemeneti arány túllépte.

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

Tipp.

Ha egy jegyzetfüzetben konfigurálja a Query Watchdogot, a konfiguráció nem marad meg a számítási újraindítások során. Ha a Query Watchdogot a számítás összes felhasználója számára szeretné konfigurálni, javasoljuk, hogy használjon számítási konfigurációt.

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 táblákból/adathalmazokból. A vizsgálati művelet hosszú ideig tarthat, és telítheti a számítási erőforrásokat (még egy nagy Hive-tábla metaadatainak olvasása is jelentős időt vehet igénybe). maxHivePartitions Beállíthatja, hogy ne kelljen túl sok partíciót beolvasni egy nagy Hive-táblából. Hasonlóképpen beállíthatja maxQueryTasks a rendkívül nagy adathalmaz lekérdezéseinek korlátozását is.

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, ahol az SQL-elemzők és az 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 türelmetlen lemondását, mert általában nincs ember a hurokban a hiba kijavításához. Javasoljuk, hogy az ad hoc elemzési számítás ki nem tiltsa a Query Watchdogot.