마이크로파티션과 컬럼형 저장 — 프루닝의 원리
55 Snowflake Interview Questions Hiring DEs Actually Ask (2026) — 미상 (데이터 엔지니어 인터뷰 준비 블로그, 2026) Core Architecture & Fundamentals Q4 (p.3); Performance & Optimization Q29 (p.10); [보조] Snowflake vs BigQuery vs Redshift - Storage Design and Query Execution Basics: Snowflake 절 (p.6)
이 모듈을 다 읽으면
- 마이크로파티션이 전통적인 사용자 정의 정적 파티션과 어떻게 다른지 설명할 수 있다
- 마이크로파티션 메타데이터(min/max, null count)가 프루닝에 어떻게 활용되는지 설명할 수 있다
- 벡터화 처리와 워커 간 직접 데이터 교환이 성능에 기여하는 방식을 설명할 수 있다
Snowflake는 테이블 데이터를 사용자가 지정하는 정적 파티션이 아니라, 시스템이 자동으로 나누는 50~500MB 크기의 불변(immutable) 컬럼형 저장 단위인 '마이크로파티션'으로 관리한다. 각 마이크로파티션마다 컬럼별 min/max/null count 같은 통계가 함께 저장되기 때문에, 쿼리 엔진은 실제 파일을 열어보기 전에 메타데이터만으로 스캔 대상을 좁힐 수 있다(프루닝). 여기에 배치 단위로 컬럼을 처리하는 벡터화 실행과, 전통적인 셔플을 최소화하는 워커 간 직접 데이터 교환이 더해져 대규모 분석 쿼리에서도 예측 가능한 성능을 낸다.
마이크로파티션이란 무엇인가
Hive 같은 시스템에서는 사용자가 파티션 컬럼(예: 날짜)을 직접 정의하고 그 경계를 관리해야 한다. Snowflake는 이와 다르게, 데이터가 적재되는 즉시 테이블 전체를 시스템이 자동으로 연속된 저장 단위로 나눈다 — 이것이 마이크로파티션이며, 일반적으로 압축 전 기준 50MB~500MB 크기를 갖는다. 각 마이크로파티션은 한 번 쓰이면 변경되지 않는(immutable) 컬럼형 포맷으로 저장된다. 즉 사용자는 '어떤 컬럼으로 파티셔닝할지'를 고민할 필요가 원칙적으로 없으며, 테이블이 매우 커진 이후에야(모듈 7에서 다룰 클러스터링 키) 선택적으로 개입한다.
핵심 포인트
- 마이크로파티션은 사용자가 아닌 Snowflake가 자동으로 나누는 50~500MB(압축 전 기준) 크기의 저장 단위다
- 각 마이크로파티션은 불변(immutable) 컬럼형 포맷으로 저장된다
- 전통적인 정적 파티션과 달리 사용자가 파티션 컬럼을 직접 관리할 필요가 원칙적으로 없다
메타데이터 기반 프루닝
Snowflake는 모든 마이크로파티션에 대해 컬럼별 min/max 값, distinct count, null count 같은 통계를 클라우드 서비스 계층의 메타데이터 캐시에 함께 저장해둔다. 쿼리에 WHERE transaction_date = '2023-01-01' 같은 필터가 있으면, 엔진은 실제 데이터 파일을 스캔하기 전에 이 메타데이터만 먼저 확인해 해당 날짜가 존재할 수 없는 마이크로파티션들을 통째로 건너뛴다 — 이 과정을 '프루닝(pruning)'이라 부른다. 프루닝이 잘 작동할수록 실제로 읽어야 할 IO 양이 줄어들어 쿼리가 빨라지고 컴퓨트 비용도 줄어든다.
핵심 포인트
- 모든 마이크로파티션은 컬럼별 min/max/null count 통계를 메타데이터로 함께 보유한다
- 쿼리 엔진은 실제 파일을 열기 전에 메타데이터만으로 무관한 마이크로파티션을 건너뛴다(프루닝)
- 프루닝 효율이 곧 스캔 IO 양과 컴퓨트 비용(쿼리 실행 시간)에 직접적인 영향을 준다
벡터화 실행과 셔플 최소화
행 단위로 데이터를 하나씩 처리하는 전통적인 OLTP 방식과 달리, Snowflake는 데이터를 배치 단위로 컬럼별로 묶어 처리하는 벡터화(vectorized) 실행 방식을 사용한다. 이는 CPU 캐시 활용을 극대화해 대규모 분석 스캔에 유리하다.
또한 Snowflake는 전통적인 분산 시스템에서 흔한, 중간 결과를 디스크에 내렸다가 다시 읽는 '셔플 무거운' 실행을 지양하고, 워커 노드끼리 데이터를 직접 교환하는 방식을 택해 중간 저장 오버헤드를 줄인다. 여기에 일관 해싱(consistent hashing)을 적용해 동일한 데이터가 가급적 같은 워커 노드에서 반복 처리되도록 유도하는데, 이는 모듈 4에서 다루는 로컬 디스크 캐시의 적중률을 높이는 효과로 이어진다.
핵심 포인트
- 벡터화 실행은 행 단위가 아니라 컬럼 배치 단위로 데이터를 처리해 CPU 효율을 높인다
- 워커 간 직접 데이터 교환으로 셔플 무거운 실행을 피해 중간 저장 오버헤드를 줄인다
- 일관 해싱으로 동일 데이터를 같은 노드가 반복 처리하게 해 로컬 캐시 적중률을 높인다