개시하다

BigQuery를 이용하여 분석, 데이터 생성 등을 하는 사람이라면 다음과 같은 문자열을 본 적이 있을 것이다

Resources exceeded during query execution: Not enough resources for query planning - 
too many subqueries or query is too complex

각양각색의 반복적인 실험 결과를 총결하여 몇 가지 회피 전략을 얻어냈다.
또 이번 회피 전략은 조회·처리 결과를 수행하는 프로그램에 지나치게 노력하는 것을 상정하지 않고 최대한 빅쿼리에서 달성하는 것을 목표로 삼았다.또 WITH 문장을 많이 활용한 보조 조회가 튕기는 경우를 목표로 이번 해결은 Order by 등을 활용해 발생하는 경우는 대상에서 제외하기로 했다.
또 이번 검증은 GitHub Activity Data을 사용할 예정이다.
이 글은 ZOZO 기술 #3 Advent Calendar 2020 14일째 되는 글이다.

TL;DR

가능하면 중간표마다 좋은 느낌 단위로 분할 조회

상황으로 인해 조회를 분할할 수 없으면 한 조회에 중간표를 위조적으로 만든다

1. 처리가 그다지 크지 않은 범위 내에서 조회를 분리하여 중간표를 토한다

이 방법은 WITH 문이 나타내는 임시 테이블을 대상 테이블에 명시적으로 저장하고 다른 질의에서 분할을 위해 조정하는 것입니다.
query1.sql

CREATE TABLE `dataset-name`.resource-name.extracted (
  commit String,
  tree String
);

INSERT INTO `dataset-name`.resource-name.extracted
SELECT commit, tree FROM `bigquery-public-data.github_repos.sample_commits` LIMIT 10;

query2.sql

SELECT * FROM `dataset-name`.resource-name.extracted

상술한 예에서query2는query1이 얻은 결과를 얻었다.

장점

무리하지 않아서 예뻐요

중간표 단위로 디버깅 가능
중간표는 실체가 있는 표로 토출되기 때문에 안의 데이터를 실제로 확인할 수 있다

결점

조회는 여러 개로 나뉘어진다

표는 여러 개로 나뉘어 있기 때문에 적당한 생존 기간을 설정하지 않으면 돈이 든다
CREATE TABLE 문장에서 생성된 수신자 표는 기본 설정에서 자동으로 사라지지 않기 때문에 적당한 기한을 설정해야 한다

2. 중간표를 시뮬레이션하여 1개의 조회 처리로 만든다

임시표를 사용하는 방법Create TEMP TABLE 문장.제작된 중간표는 WITH 문과 마찬가지로 24시간 안에 생존하고 이후 자동으로 삭제된다.
다른 한편, WITH 문장과 달리 다른 표를 사용하기 때문에 실행 계획은Queryis too complex의 회피 정책으로 사용할 수 있다.
query1.sql

CREATE TEMP TABLE extracted (
  commit String,
  tree String
);

INSERT INTO extracted
SELECT commit, tree FROM `bigquery-public-data.github_repos.sample_commits` LIMIT 10;

SELECT * FROM extracted;

장점

단일 SQL로 데이터 처리
CREATE TABLE 문장을 사용하는 조회는 두 가지로 나뉘는데, 제작된 중간 표를 사용하여 뒷처리를 할 수 있기 때문에 한 파일로 전체를 관리할 수 있다.

결점

조회에서 처리되는 데이터의 양을 사전에 모른다

CREATE TEMP TABLE 문을 사용하여 질의를 수행하려고 하면 스크립트에서 실행되므로 예상 바이트 수를 계산할 수 없습니다.

최후

본고는 BigQuery의 Queryis too complex를 피하는 두 가지 방법을 소개한다.용도에 따라 구분되지만, 개인적으로는 데이터 마트의 가독성을 포함해 1가지 방법을 취하는 경우가 많고, 빅큐리가 조회 분석을 위해 WITH 문장 최적화를 쉽게 얻을 수 있다는 장점도 이유 중 하나다.