Menangani kueri besar dalam alur kerja interaktif

Tantangan dengan alur kerja data interaktif adalah menangani kueri besar. Ini termasuk kueri yang menghasilkan terlalu banyak baris output, mengambil banyak partisi eksternal, atau menghitung pada himpunan data yang sangat besar. Kueri ini bisa sangat lambat, sumber daya komputasi jenuh, dan menyulitkan orang lain untuk berbagi komputasi yang sama.

Query Watchdog adalah proses yang mencegah kueri memonopoli sumber daya komputasi dengan memeriksa penyebab paling umum kueri besar dan mengakhiri kueri yang melewati ambang batas. Artikel ini menjelaskan cara mengaktifkan dan mengonfigurasi Query Watchdog.

Contoh kueri yang mengacau

Seorang analis melakukan beberapa kueri ad hoc di gudang data tepat waktu. Analis menggunakan komputasi penskalaan otomatis bersama yang memudahkan beberapa pengguna untuk menggunakan satu komputasi secara bersamaan. Misalkan ada dua tabel yang masing-masing memiliki satu juta baris.

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

Ukuran tabel ini dapat dikelola di Apache Spark. Namun, masing-masing menyertakan kolom join_key dengan string kosong di setiap baris. Ini dapat terjadi jika data tidak sepenuhnya bersih atau jika ada kecenderungan data yang signifikan di mana beberapa kunci lebih sering muncul daripada yang lainnya. Kunci gabungan kosong ini jauh lebih lazim daripada nilai lainnya.

Dalam kode berikut, analisis menggabungkan kedua tabel ini berdasarkan kuncinya, menghasilkan output satu triliun hasil, dan semuanya diproses pada satu eksekutor (eksekutor yang mendapatkan kunci " ").

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

Kueri ini sepertinya sedang berjalan. Tetapi tanpa mengetahui tentang data, analis melihat bahwa ada "hanya" satu tugas yang tersisa selama menjalankan pekerjaan. Kueri tidak pernah selesai, membuat analis frustrasi dan bingung tentang mengapa kueri tidak berfungsi.

Dalam hal ini hanya ada satu kunci gabungan yang bermasalah. Lain kali mungkin ada banyak lagi.

Mengaktifkan dan mengonfigurasi Query Watchdog

Untuk mengaktifkan dan mengonfigurasi Query Watchdog, langkah-langkah berikut diperlukan.

• Aktifkan Watchdog dengan spark.databricks.queryWatchdog.enabled.
• Konfigurasikan runtime tugas dengan spark.databricks.queryWatchdog.minTimeSecs.
• Tampilkan output dengan spark.databricks.queryWatchdog.minOutputRows.
• Konfigurasikan rasio output dengan spark.databricks.queryWatchdog.outputRatioThreshold.

Untuk mencegah kueri membuat terlalu banyak baris output untuk jumlah baris input, Anda dapat mengaktifkan Query Watchdog dan mengonfigurasi jumlah maksimum baris output sebagai kelipatan jumlah baris input. Dalam contoh ini kita menggunakan rasio 1000 (default).

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

Konfigurasi terakhir menyatakan bahwa tugas tertentu tidak boleh menghasilkan lebih dari 1000 kali jumlah baris input.

Query Watchdog tidak hanya mencegah pengguna memonopoli sumber daya komputasi untuk pekerjaan yang tidak akan pernah selesai, hal ini juga menghemat waktu dengan segera menggagalkan kueri yang tidak akan pernah selesai. Misalnya, kueri berikut akan gagal setelah beberapa menit karena melebihi rasio.

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

Berikut adalah apa yang akan Anda lihat:

Biasanya cukup untuk mengaktifkan Query Watchdog dan mengatur rasio ambang output/input, tetapi Anda juga memiliki opsi untuk mengatur dua properti tambahan: spark.databricks.queryWatchdog.minTimeSecs dan spark.databricks.queryWatchdog.minOutputRows. Properti ini menentukan waktu minimum tugas tertentu dalam kueri harus berjalan sebelum membatalkannya dan jumlah minimum baris output untuk tugas dalam kueri tersebut.

Misalnya, Anda dapat mengatur minTimeSecs ke nilai yang lebih tinggi jika Anda ingin memberinya kesempatan untuk menghasilkan sejumlah besar baris per tugas. Demikian juga, Anda dapat mengatur spark.databricks.queryWatchdog.minOutputRows ke sepuluh juta jika Anda ingin menghentikan kueri hanya setelah tugas dalam kueri tersebut telah menghasilkan sepuluh juta baris. Jika tidak lebih dari itu, maka kueri akan berhasil, bahkan jika rasio keluaran/masukan terlampaui.

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

Mendeteksi kueri pada himpunan data yang sangat besar

Kueri besar umum lainnya dapat memindai sejumlah besar data dari tabel besar/himpunan data. Operasi pemindaian dapat berlangsung untuk waktu yang lama dan sumber daya komputasi jenuh (bahkan membaca metadata tabel Apache Hive besar dapat memakan waktu yang signifikan). Anda dapat mengatur maxHivePartitions untuk mencegah pengambilan terlalu banyak partisi dari tabel besar di Apache Hive. Demikian pula, Anda juga dapat mengatur maxQueryTasks untuk membatasi kueri pada himpunan data yang sangat besar.

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

Kapan Anda harus mengaktifkan Query Watchdog?

Pengawas Kueri harus diaktifkan untuk komputasi analitik ad hoc di mana analis SQL dan ilmuwan data berbagi komputasi tertentu dan administrator perlu memastikan bahwa kueri "bermain dengan baik" satu sama lain.

Kapan Anda harus menonaktifkan Query Watchdog?

Secara umum, kami tidak menyarankan pembatalan kueri yang digunakan dalam skenario ETL karena biasanya tidak ada manusia dalam proses untuk memperbaiki kesalahan. Kami menyarankan agar Anda menonaktifkan Query Watchdog untuk semua komputasi, kecuali analitik ad hoc.