대화형 워크플로에서 대규모 쿼리 처리

아티클
01/21/2025

대화형 데이터 워크플로의 과제는 대규모 쿼리를 처리하는 것입니다. 여기에는 너무 많은 출력 행을 생성하거나, 많은 외부 파티션을 가져오거나, 매우 큰 데이터 집합에서 컴퓨팅하는 쿼리가 포함됩니다. 이러한 쿼리는 매우 느리고 컴퓨팅 리소스를 포화 상태이며 다른 사용자가 동일한 컴퓨팅을 공유하기 어렵게 만들 수 있습니다.

Query Watchdog는 대규모 쿼리의 가장 일반적인 원인을 검사하고 임계값을 통과하는 쿼리를 종료하여 쿼리가 컴퓨팅 리소스를 독점하지 못하도록 하는 프로세스입니다. 이 문서에서는 Query Watchdog를 사용하도록 설정하고 구성하는 방법을 설명합니다.

중요하다

쿼리 Watchdog는 UI를 사용하여 만든 모든 범용 컴퓨팅에 대해 활성화됩니다.

방해가 되는 쿼리의 예

분석가가 Just-In-Time 데이터 웨어하우스에서 일부 임시 쿼리를 수행하고 있습니다. 분석가는 여러 사용자가 동시에 단일 컴퓨팅을 쉽게 사용할 수 있도록 하는 공유 자동 크기 조정 컴퓨팅을 사용합니다. 각각 백만 개의 행이 있는 두 개의 테이블이 있다고 가정해 보겠습니다.

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

이러한 테이블 크기는 Apache Spark에서 관리할 수 있습니다. 그러나 각각은 모든 행에 빈 문자열이 있는 join_key 열을 포함합니다. 데이터가 완벽하게 정리되지 않았거나 일부 키가 다른 키보다 더 널리 퍼지는 중요한 데이터 편향이 있는 경우, 이 문제가 발생할 수 있습니다. 이러한 빈 조인 키는 다른 값보다 훨씬 더 널리 퍼집니다.

다음 코드에서 분석가는 키에 이러한 두 테이블을 조인하여1조 결과의 출력을 생성하며, 이러한 모든 테이블은 단일 실행기( 키를 가져오는 실행기)에서 생성됩니다.

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

이 쿼리가 실행 중인 것으로 보입니다. 하지만 분석가는 데이터에 대해 모르는 상태에서 작업이 실행되는 동안 '단일' 작업만 남아 있다는 것을 인지합니다. 쿼리가 완료되지 않아 분석가가 왜 작동하지 않는지 좌절하고 혼란스러워합니다.

이 경우 문제가 있는 조인 키가 하나만 있습니다. 다른 시간에는 더 많은 것이 있을 수 있습니다.

Query Watchdog 사용 및 구성

Query Watchdog를 사용하도록 설정하고 구성하려면 다음 단계가 필요합니다.

spark.databricks.queryWatchdog.enabled으로 Watchdog을 활성화합니다.
spark.databricks.queryWatchdog.minTimeSecs사용하여 작업 런타임을 구성합니다.
spark.databricks.queryWatchdog.minOutputRows로 출력을 표시합니다.
spark.databricks.queryWatchdog.outputRatioThreshold사용하여 출력 비율을 구성합니다.

쿼리가 입력 행 수에 대해 너무 많은 출력 행을 만들지 못하도록 하려면 Query Watchdog를 사용하도록 설정하고 최대 출력 행 수를 입력 행 수의 배수로 구성할 수 있습니다. 이 예제에서는 1000의 비율(기본값)을 사용합니다.

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

후자의 구성은 지정된 작업이 입력 행 수의 1000배 이상을 생성해서는 안 된다고 선언합니다.

팁

출력 비율은 완전히 사용자 지정할 수 있습니다. 더 낮게 시작하고 사용자와 팀에 적합한 임계값을 확인하는 것이 좋습니다. 1,000에서 10,000까지의 범위는 좋은 시작점입니다.

Query Watchdog는 사용자가 완료되지 않는 작업에 대한 컴퓨팅 리소스를 독점하는 것을 방지할 뿐만 아니라 완료되지 않은 쿼리를 빠르게 실패시켜 시간을 절약합니다. 예를 들어 다음 쿼리는 비율을 초과하므로 몇 분 후에 실패합니다.

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

표시되는 내용은 다음과 같습니다.

쿼리 감시자

일반적으로 Query Watchdog를 사용하도록 설정하고 출력/입력 임계값 비율을 설정하는 데 충분하지만 spark.databricks.queryWatchdog.minTimeSecs 및 spark.databricks.queryWatchdog.minOutputRows두 개의 추가 속성을 설정하는 옵션도 있습니다. 이러한 속성은 쿼리를 취소하기 전에 쿼리에서 지정된 작업이 실행되어야 하는 최소 시간 및 해당 쿼리의 작업에 대한 최소 출력 행 수를 지정합니다.

예를 들어 작업당 많은 수의 행을 생성할 수 있는 기회를 제공하려는 경우 minTimeSecs 더 높은 값으로 설정할 수 있습니다. 마찬가지로 해당 쿼리의 태스크에서 1,000만 개의 행을 생성한 후에만 쿼리를 중지하려는 경우 spark.databricks.queryWatchdog.minOutputRows 1,000만 으로 설정할 수 있습니다. 출력/입력 비율이 초과된 경우라도 조건이 덜 엄격하면 쿼리가 성공합니다.

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

팁

Notebook에서 Query Watchdog를 구성하는 경우 컴퓨팅 다시 시작에서 구성이 유지되지 않습니다. 컴퓨트의 모든 사용자에 대해 Query Watchdog를 구성하려면 컴퓨트 구성사용하는 것을 권장합니다.

매우 큰 데이터 세트에서 쿼리 검색

또 다른 일반적인 대규모 쿼리는 빅 테이블/데이터 세트의 많은 양의 데이터를 검색할 수 있습니다. 검사 작업은 오랜 시간 동안 지속될 수 있으며 컴퓨팅 리소스를 포화시킬 수 있습니다(큰 Hive 테이블의 메타데이터를 읽는 경우에도 상당한 시간이 걸릴 수 있음). 큰 Hive 테이블에서 너무 많은 파티션을 가져오지 않도록 maxHivePartitions 설정할 수 있습니다. 마찬가지로 매우 큰 데이터 세트에 대한 쿼리를 제한하도록 maxQueryTasks 설정할 수도 있습니다.

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

쿼리 Watchdog를 사용하도록 설정해야 하는 경우는 언제인가요?

쿼리가 서로 원활하게 작동하도록 하기 위해, SQL 분석가와 데이터 과학자가 특정 컴퓨팅 환경을 공유하는 경우 관리자는 임시 분석 컴퓨팅에서 Query Watchdog를 활성화해야 합니다.

쿼리 Watchdog를 사용하지 않도록 설정해야 하는 경우는 언제인가요?

일반적으로 ETL 시나리오에서 쿼리를 성급하게 취소하지 않는 것이 좋습니다. 이는 보통 오류를 수정할 사람이 루프에 없기 때문입니다. 임시 분석 컴퓨팅을 제외한 모든 컴퓨팅에 대해 Query Watchdog를 사용하지 않도록 설정하는 것이 좋습니다.

다음을 통해 공유