대화형 워크플로에서 많은 쿼리 처리
대화형 데이터 워크플로의 문제는 대규모 쿼리를 처리하는 것입니다. 여기에는 너무 많은 출력 행을 생성하거나, 많은 외부 파티션을 가져오거나, 매우 큰 데이터 집합에서 컴퓨팅하는 쿼리가 포함됩니다. 이러한 쿼리는 매우 느리고 컴퓨팅 리소스를 포화 상태이며 다른 사용자가 동일한 컴퓨팅을 공유하기 어렵게 만들 수 있습니다.
Query Watchdog는 대규모 쿼리의 가장 일반적인 원인을 검사하고 임계값을 통과하는 쿼리를 종료하여 쿼리가 컴퓨팅 리소스를 독점하지 못하도록 하는 프로세스입니다. 이 문서에서는 Query Watchdog을 사용하도록 설정하고 구성하는 방법을 설명합니다.
Important
쿼리 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
이 쿼리가 실행 중인 것 같습니다. 그러나 데이터에 대해 알지 못한 채 분석가는 작업을 실행하는 과정에서 "단 하나의" 작업만 남아 있음을 알게 됩니다. 쿼리가 완료되지 않아 분석가는 쿼리가 작동하지 않는 이유에 대해 좌절하고 혼란스러워합니다.
이 경우 문제가 있는 조인 키가 하나만 있습니다. 다른 경우에는 더 많을 수 있습니다.
쿼리 Watchdog 사용 및 구성
쿼리 Watchdog를 사용하도록 설정하고 구성하려면 다음 단계가 필요합니다.
spark.databricks.queryWatchdog.enabled
를 사용하여 Watchdog를 사용하도록 설정합니다.spark.databricks.queryWatchdog.minTimeSecs
를 사용하여 작업 런타임을 구성합니다.spark.databricks.queryWatchdog.minOutputRows
를 사용하여 출력을 표시합니다.spark.databricks.queryWatchdog.outputRatioThreshold
를 사용하여 출력 비율을 구성합니다.
쿼리가 입력 행 수에 대해 너무 많은 출력 행을 만들지 않도록 하려면 쿼리 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
를 더 높은 값으로 설정할 수 있습니다. 마찬가지로, 해당 쿼리의 작업이 천만 행을 생성한 후에만 쿼리를 중지하려는 경우 spark.databricks.queryWatchdog.minOutputRows
를 천만으로 설정할 수 있습니다. 이보다 적으면 출력/입력 비율을 초과하더라도 쿼리가 성공합니다.
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를 사용하지 않도록 설정하는 것이 좋습니다.