심심해서 본 논문 요약
Workload Insights From The Snowflake Data Cloud: What Do
Production Analytic Queries Really Look Like?
https://vldb.org/pvldb/vol18/p5126-bress.pdf
논문은 Snowflake에서 실행된 실제 BI 쿼리 6억 6,700만 개를 분석해, SELECT, JOIN, WHERE, GROUP BY, ORDER BY, LIMIT 같은 SQL 패턴이 실제로 어떻게 사용되는지 확인
1. 분석시 SELECT만 하지 않는다.
- 전체 쿼리 유형에서 SELECT가 47%, SHOW가 31% 전체의 78%가 읽기 중심.
- 실제 데이터를 조회하기 전에 대시보드 구성, 필드 목록 확인, 권한 확인, 테이블/뷰 구조 파악을 위해 메타데이터를 매우 자주 조회
2. 실제 BI 쿼리의 중심은 GROUP BY, ORDER BY, JOIN, LIMIT
SQL 기능 사용 비율
GROUP BY 55%
ORDER BY 54%
JOIN 46%
LIMIT 25%
WITH 25%
Window Function 11%
UNION ALL 6%
- 단일 쿼리 튜닝이 아니라 반복적으로 생성하는 SQL 패턴을 기준으로 마트와 테이블 구조를 설계하는게 가장 큰 문제
3. 실제 비용은 Table Scan & Filter가 가장 크게 좌우
연산자 CPU 시간 비중
Table Scan & Filter 48.2%
Join 16.4%
Aggregate 14.8%
Projection 10.1%
- 실제 비용 관점에서는 연산자보다 얼마나 많은 데이터를 읽고 얼마나 효율적으로 필터링하는가가 더 중요
- 불필요한 컬럼 스캔 줄이기
- WHERE 조건이 파티션 프루닝을 타도록 설계하기
- 클러스터링/정렬 키를 자주 쓰는 필터와 조인 조건에 맞추기
- 조인 전에 필터링이 먼저 적용되도록 쿼리와 마트 구조 설계하기
4. 기타
- BI 쿼리에서는 ORDER BY 없이 사용된 LIMIT 쿼리 중 상당수가 100만~1,000만 행을 요청
- WHERE 절에서 필터 대상 컬럼을 보면 텍스트가 58%, 숫자가 25%로 텍스트 처리가 관건
결론
분석 쿼리 최적화는 느린 쿼리 몇 개를 튜닝 보다 실제 쿼리 로그를 기반으로 메타데이터 조회, 스캔량, 필터 타입, 조인 키 타입, 집계 패턴, LIMIT 값까지 함께 분석하는 문제 제시 필요 및 최적화 테이블 설계 필요