redash에 연결된 데이터 소스를 운영 할 때 확인하고 싶은 redash metadata

이 기사는 Redash Advent Calendar 2017 20일째 기사입니다.

18일째의 Redash의 metadata에서 유용한 정보를 가져 오는 이야기 과 비슷한 내용이 되어 있습니다.

개요

Redash의 데이터 소스가 되는 데이터베이스(Redshift 등)를 운용하고 있으면, 드물게 심한 쿼리(실행에 시간이 걸리는 쿼리나, 에러가 되는 쿼리)도 정기적으로 칠 수 있게 되어 매운 생각을 하게 됩니다.

특히 Redshift를 운영하면 엄격하게 어떤 쿼리가 오류를 발생시켰는지 나중에 추적하기가 어렵거나 STL_ERROR 합니다.

여기에서는 그런 매운 생각을 할 때 자주 확인하는 쿼리를 정리해 둡니다.
버젼으로서는 schedule_failures 이 도입된 2.0 이후의 이용을 상정하고 있습니다.

사용하는 테이블

Redash의 데이터가 저장되는 PostgreSQL을 데이터 소스로 등록하고, 주로 다음의 2개의 테이블을 이용합니다.


테이블 이름
개요


query_results
Query 실행 결과가 저장됨

queries
조회 정보가 저장됨

주의점

이 2 개의 테이블을 Join 하는 경우는 QUERY_HASH 를 사용한다.
Query를 변경해 버리면 별개의 것이므로 주의가 필요합니다.

query_results는 실행에 실패한 정보를 저장하지 않습니다.

queries 의 SCHEDULE_FAILURES 에는 에러가 발생한 횟수가 누계로 등록되어 있습니다만, 실행이 성공하면(자) 0 이 됩니다.

Redash에서 확인할 수 있는 것은 거기까지 많지 않으므로 별도 데이터 소스 측의 시스템 테이블 등도 확인이 필요합니다.

일정 실행 중이고 오류가 있는 쿼리 찾기

오늘 발생한 오류를 확인합니다.
어떤 오류가 발생했는지는 DB에 저장되지 않으므로 주의가 필요합니다.

SELECT 
  id,
  name,
  query,
  query_hash,
  schedule,
  schedule_failures
FROM
  queries
WHERE
  schedule_failures != 0
  AND updated_at >= CURRENT_DATE
ORDER BY 
  schedule_failures DESC
;

queries.schedule_failures (은)는 쿼리의 실행에 성공했을 때에 0으로 돌아가기 그래서, 성공과 실패가 혼재하는 경우※라고 쿼리를 실행하는 타이밍에 따라서는 이 쿼리로 확인할 수 없을지도 모릅니다.

※ 예를 들면 데이터의 건수가 0건이라고 division by zero가 발생하지만, 항상 0건이라고 하는 경우는 없는 것 같은 경우.

당일 실행 횟수가 많은 쿼리 찾기

당일 실행 횟수가 많은 쿼리를 확인합니다.
다음 예제에서는 10회 이상 실행되는 쿼리만 추출합니다.
(그러나 실행에 실패하면 계산되지 않습니다.)

WITH q_r AS (
  SELECT
    query_hash AS q_r_hash,
    COUNT(query_hash) AS run_count,
    MAX(retrieved_at) AS recent_exec
  FROM
    query_results 
  WHERE
    retrieved_at >= CURRENT_DATE  -- 当日のデータのみを対象にする
  GROUP BY 
    query_hash
)
SELECT 
  q.id,
  q.query_hash,
  q_r.run_count,
  q_r.recent_exec,
  q.schedule
FROM
  queries as q
  JOIN q_r 
  ON query_hash = q_r_hash
WHERE
  run_count > 10 -- 10回より多く実行されたクエリのみ取得
ORDER BY 
  run_count DESC
;

이 쿼리나 아래의 실행시간이 걸리는 쿼리를 이용하여 DATA_SOURCE_ID 로 좁혀 QUERY 의 내용을 보고 불필요하게 자주 실행되어 부하를 걸고 있는 쿼리를 씻어내기도 합니다.
(실제로는, name나 query등 출력하는 형태로 이용할까라고 생각합니다.)

SCHEDULE을 보면, Every day at xx:xx와 같은 쿼리가 비교적 상위에 올라오거나 하고, 약간? 하지만 어느 정도의 경향은 보일까 생각합니다.

실행 시간이 걸리는 쿼리 찾기

지난 1주일 동안 평균적으로 시간이 오래 걸리는 검색어를 찾으려면 다음을 수행합니다.
실제로는, 이 정보를 바탕으로 접속처의 데이터 소스로 Slow Query가 되어 있지 않은지 별도 확인하는 등이 필요할까 생각합니다.

WITH q_r AS (
  SELECT
    query_hash AS q_r_hash,
    COUNT(query_hash) AS run_count,
    AVG(runtime) AS avg_spend -- 単位はsec
  FROM
    query_results 
  WHERE
    retrieved_at >= CURRENT_DATE - integer '7'  -- 過去1週間に実行されたクエリを対象にする
  GROUP BY
    query_hash
)
SELECT 
  q.id,
  q.query_hash,
  q_r.run_count,
  q_r.avg_spend,
  q.schedule
FROM
  queries as q
  JOIN q_r 
  ON query_hash = q_r_hash
WHERE
  run_count > 7
ORDER BY
  avg_spend DESC
;