쿼리 한 번에 수십 GB를 스캔하고 있다면, 설정부터 점검하세요
BigQuery 청구서를 열어보고 당황한 경험. 데이터 엔지니어라면 한 번쯤 겪는 일입니다. 분명 간단한 SELECT 쿼리였는데, 스캔량이 테이블 전체 크기와 맞먹는 경우가 허다합니다. 원인은 대부분 파티셔닝과 클러스터링 미설정에 있습니다.
이 글을 읽고 나면 BigQuery, Redshift, Snowflake 세 플랫폼에서 파티셔닝과 클러스터링을 올바르게 설정하고, 실제 쿼리 스캔량을 극적으로 줄이는 방법을 바로 적용할 수 있습니다. 각 플랫폼별 설정 문법, 적용 기준, 그리고 어떤 상황에서 어떤 전략이 유리한지를 비교 매트릭스로 정리했습니다.
파티셔닝 vs 클러스터링, 비교 기준부터 명확히 구분하기
두 기술이 스캔량을 줄이는 원리
파티셔닝은 테이블을 물리적으로 분리합니다. 날짜 기준으로 나누면, 특정 날짜 범위 쿼리 시 해당 파티션만 읽습니다. 반면 클러스터링은 파티션 내부 데이터를 정렬해서 저장합니다. WHERE 조건에 클러스터링 컬럼이 포함되면, 불필요한 블록을 건너뜁니다.
실제 적용 사례를 살펴보면, 일별 로그 테이블에 날짜 파티셔닝만 적용해도 스캔량이 1/30로 줄어드는 경우가 흔합니다. 여기에 user_id로 클러스터링을 추가하면 특정 사용자 조회 시 추가로 50~80%가 감소합니다.
비교 시 봐야 할 핵심 축
- 적용 대상: 파티셔닝은 시간/정수/범위 컬럼, 클러스터링은 카디널리티 높은 컬럼에 적합
- 효과 발현 조건: 파티셔닝은 WHERE 절에 파티션 키 포함 시, 클러스터링은 정렬 순서와 필터 조건이 일치할 때
- 유지보수: 파티셔닝은 파티션 만료 정책 관리 필요, 클러스터링은 대부분 자동 유지
- 플랫폼별 제한: 클러스터링 컬럼 수, 파티션 상한 등이 플랫폼마다 다름
데이터 웨어하우스 파티셔닝 설정 방법: 플랫폼별 실전 비교
BigQuery의 파티셔닝
BigQuery에서는 테이블 생성 시 PARTITION BY 절로 설정합니다. DATE, TIMESTAMP, DATETIME 컬럼 또는 정수 범위를 기준으로 나눌 수 있고, 파티션 만료일을 지정해 오래된 데이터를 자동 삭제할 수도 있습니다. 파티션 상한은 테이블당 10,000개입니다.
팁: BigQuery는 _PARTITIONTIME 의사 컬럼을 활용한 수집 시간 기반 파티셔닝도 지원합니다. 원본 데이터에 날짜 컬럼이 없을 때 유용합니다.
Redshift와 Snowflake는 어떻게 다른가
Redshift는 명시적 파티셔닝 문법이 없습니다. 대신 DISTKEY와 SORTKEY를 조합해 유사한 효과를 냅니다. SORTKEY로 지정한 컬럼 기준으로 데이터가 디스크에 정렬 저장되므로, 범위 스캔 시 존 맵(zone map)이 불필요한 블록을 건너뜁니다. Snowflake는 마이크로 파티셔닝을 자동으로 수행합니다. 수동 설정 없이도 데이터 적재 순서에 따라 파티션이 생성되며, 필요 시 CLUSTER BY 명령으로 재정렬할 수 있습니다.
정리하면 BigQuery는 설정이 명시적이고 직관적이며, Redshift는 분산 키 설계가 핵심이고, Snowflake는 자동화 수준이 가장 높습니다. BigQuery·Redshift·Snowflake 과금 구조 비교에서 각 플랫폼의 요금 체계를 함께 확인하면 비용 절감 효과를 더 정확히 계산할 수 있습니다.
클러스터링 설정으로 쿼리 스캔량 줄이는 실전 가이드
BigQuery 클러스터링 설정과 컬럼 선택 기준
BigQuery에서 클러스터링은 테이블 생성 시 CLUSTER BY 절에 최대 4개 컬럼을 지정합니다. 컬럼 순서가 중요합니다. 가장 자주 필터링하는 컬럼을 첫 번째에 놓아야 프루닝 효과가 극대화됩니다.
많은 사람이 처음에는 카디널리티가 높은 컬럼만 클러스터링 대상으로 고르는 실수를 합니다. 하지만 카디널리티가 너무 높으면(예: UUID) 오히려 효과가 떨어집니다. Google Cloud 공식 문서에서는 필터/집계에 자주 사용되는 컬럼을 우선 권장합니다.
Redshift SORTKEY와 Snowflake CLUSTER BY
Redshift의 COMPOUND SORTKEY는 클러스터링과 유사합니다. 첫 번째 컬럼 기준 정렬이 가장 강력하고, 뒤로 갈수록 효과가 줄어듭니다. INTERLEAVED SORTKEY는 여러 컬럼을 균등하게 처리하지만 VACUUM 비용이 높아 주의가 필요합니다.
Snowflake의 CLUSTER BY는 선언형입니다. 지정하면 백그라운드에서 자동 클러스터링 서비스가 데이터를 재정렬합니다. 편리하지만, 이 자동 클러스터링 자체에 크레딧이 소모된다는 점을 간과하면 안 됩니다. 쓰기가 잦은 테이블에 무분별하게 적용하면 오히려 비용이 증가할 수 있습니다.
- BigQuery: 클러스터링 무료, 자동 재클러스터링 지원, 컬럼 최대 4개
- Redshift: VACUUM 명령으로 수동 재정렬 필요, COMPOUND vs INTERLEAVED 선택
- Snowflake: 자동 클러스터링 크레딧 과금, 대형 테이블(1TB 이상)에서 효과 극대화
워크로드별 파티셔닝·클러스터링 조합 추천
시계열 분석이 주력인 경우
날짜 파티셔닝 + 고빈도 필터 컬럼 클러스터링이 정석입니다. 예를 들어 이커머스 주문 테이블이라면 order_date로 파티셔닝하고, store_id와 status로 클러스터링합니다. 이 조합만으로 “특정 매장의 최근 7일 주문 조회” 쿼리 스캔량이 전체 대비 95% 이상 감소한 사례가 보고됩니다.
애드혹 분석이 빈번한 환경
분석가들이 다양한 컬럼으로 탐색 쿼리를 실행하는 환경에서는 클러스터링 효과가 제한적입니다. 이런 경우 파티셔닝으로 시간 범위를 제한하는 것이 가장 확실한 방어선입니다. Snowflake 사용 환경이라면 Snowflake 마이크로 파티셔닝 문서를 참고해 자동 클러스터링 적용 여부를 판단하세요.
모든 테이블에 파티셔닝과 클러스터링을 적용할 필요는 없습니다. 1GB 미만의 소형 테이블은 풀스캔 비용 자체가 미미하므로 관리 복잡성만 늘어납니다. 반복적으로 대량 스캔이 발생하는 테이블을 먼저 식별하고, 해당 테이블부터 적용하는 것이 실질적입니다.
지금 바로 적용할 수 있는 최종 선택 체크리스트
의사결정 플로우
테이블 크기가 1GB 이상인가? 그렇다면 파티셔닝 적용을 검토합니다. 쿼리 패턴에서 특정 컬럼 필터가 80% 이상 반복되는가? 그렇다면 해당 컬럼으로 클러스터링을 추가합니다. 이 두 가지 질문만으로 대부분의 테이블에 대한 판단이 가능합니다.
플랫폼별 빠른 비교표
- 설정 난이도: BigQuery(쉬움) > Snowflake(보통) > Redshift(어려움, DISTKEY 설계 필요)
- 자동화 수준: Snowflake(자동 클러스터링) > BigQuery(자동 재클러스터링) > Redshift(수동 VACUUM)
- 추가 비용: BigQuery(없음) = Redshift(없음) < Snowflake(자동 클러스터링 크레딧)
- 파티션 제한: BigQuery 10,000개 / Redshift 해당 없음 / Snowflake 제한 없음(자동)
클라우드 데이터 웨어하우스 비용 최적화 전략에서 파티셔닝 외에도 슬롯 예약, 캐싱 등 추가 절감 방법을 확인할 수 있습니다.
결론
파티셔닝은 시간 범위로 스캔 대상을 물리적으로 격리하고, 클러스터링은 필터 조건에 맞는 블록만 읽도록 데이터를 정렬합니다. 두 기술을 함께 적용하면 쿼리 스캔량을 90% 이상 줄일 수 있습니다. 오늘 당장 가장 비용이 많이 드는 쿼리 상위 3개를 확인하고, 해당 테이블에 파티셔닝 키부터 설정해 보세요. 플랫폼별 과금 구조와 웨어하우스 크기 조정까지 함께 최적화하면 비용 절감 효과가 배가됩니다.