Clustering
한 줄 정의
Clustering = 비슷한 데이터를 같은 "서랍(micro-partition)"에 모아두는 것
→ 찾을 때 모든 서랍을 뒤지지 않고 필요한 서랍만 열면 됨 (= 빠른 쿼리)
1. 왜 필요할까?
도서관에서 책을 찾는다고 생가해보자
| 상황 | 결과 |
|---|---|
| 📚 책이 무작위로 꽂혀있음 | 원하는 책 찾으려면 책장 전부 뒤져야 함 (느림) |
| 📚 책이 가나다순으로 정렬됨 | 해당 칸만 가서 찾으면 됨 (빠름) |
Snowflake도 똑같습니다. 데이터를 잘 정렬해두면 → 불필요한 부분은 건너뛰고(pruning) 필요한 곳만 스캔 → 쿼리가 빨라집니다.
2. 핵심 용어
① Micro-partition → 데이터가 담기는 "서랍" (50~500MB)
② Clustering Key → "어떤 기준으로 정렬할지" 정하는 컬럼
③ Clustering → 비슷한 데이터를 같은 서랍에 모으는 행위Clustering Key 예시:
CREATE TABLE 주문 (...) CLUSTER BY (주문날짜);
-- → "주문날짜" 기준으로 비슷한 날짜끼리 같은 서랍에 모아라3. Clustering Depth (⭐⭐⭐)
서랍들끼리 값이 얼마나 "겹치는지(overlap)"를 나타내는 숫자
핵심 규칙
숫자가 작을수록 = 잘 정렬됨 = 좋음 ✅
숫자가 클수록 = 뒤죽박죽 = 나쁨 ❌
빈 테이블 = 0그림으로 이해
❌ 나쁨 (Depth 높음) ✅ 좋음 (Depth = 1)
[A~~~~~~~~~~Z] [A~D]
[A~~~~~~~~~~Z] [E~~K]
[A~~~~~~~~~~Z] [Z]
↑ 다 겹침 → 다 뒤져야 함 ↑ 안 겹침 → 한 곳만 보면 됨겹침이 전혀 없는 상태 = Constant State (더 이상 개선 불가, 최고 상태)
4. 어떤 쿼리가 빨라지나? (⭐)
클러스터링 키를 이 4가지에 자주 쓰는 쿼리가 빨라집니다:
🔍 WHERE (필터링)
🔗 JOIN (조인)
📊 ORDER BY (정렬)
📑 GROUP BY (그룹화)💡 이 중 WHERE / JOIN이 ORDER BY / GROUP BY보다 효과가 더 큽니다.
5. 좋은 Clustering Key 고르는 법
규칙 ① 컬럼 개수
최대 3~4개까지만! (그 이상은 비용만 증가)
규칙 ② 카디널리티 (= 고유값 개수) ⭐
"적당히 다양해야" 합니다.
| 종류 | 예시 | 평가 |
|---|---|---|
| 너무 적음 | 성별, True/False | ❌ 구분 효과 없음 |
| 너무 많음 | 나노초 timestamp | ❌ 그룹화 안 됨 |
| 적당함 | 날짜(TO_DATE) | ✅ 딱 좋음 |
💡 고유값이 너무 많으면 → 표현식으로 줄이기
예: 정확한 시간 대신TO_DATE()로 날짜만 추출
규칙 ③ 여러 컬럼 쓸 때 순서
낮은 카디널리티 → 높은 카디널리티 순서로!
6. 비용과 Reclustering
Reclustering (재정렬)
- 데이터를 자꾸 바꾸면(INSERT/UPDATE/DELETE) → 정렬이 흐트러짐
- Snowflake가 자동으로 다시 정렬해줌 (Automatic)
💸 비용 발생
Compute 크레딧 + Storage 크레딧 모두 소모Storage 비용이 드는 이유: 옛날 micro-partition을 Time Travel/Fail-safe 때문에 바로 안 지우고 보관하기 때문
7. 언제 클러스터링을 써야 하나? (결론)
"크고, 자주 보고, 잘 안 바꾸는" 테이블
✅ 멀티 테라바이트(>1TB) 대형 테이블
✅ 자주 쿼리됨 (frequently queried)
✅ 자주 변경 안 됨 (infrequently changed)❌ 반대로 자주 바뀌는 작은 테이블엔 비용만 들고 비효율적!
8. 헷갈리기 쉬운 포인트
| 테이블 종류 | 클러스터링 키 |
|---|---|
| 일반 Table | ✅ 가능 |
| Materialized View | ✅ 가능 |
| Hybrid Table | ❌ 불가 (Primary Key로 정렬됨) |
모니터링 함수 2개:
SYSTEM$CLUSTERING_INFORMATION -- 전체 정보 (depth 포함)
SYSTEM$CLUSTERING_DEPTH -- depth만🎯 핵심 포인트
| 키워드 | 답 |
|---|---|
| 클러스터링 한 줄 | 비슷한 데이터를 같은 micro-partition에 co-locate |
| 컬럼 최대 개수 | 3~4개 |
| 카디널리티 | 너무 높지도 낮지도 않게 |
| 다중 컬럼 순서 | 낮은 → 높은 카디널리티 |
| Depth | 작을수록 좋음, 빈 테이블 = 0 |
| 혜택 쿼리 | WHERE, JOIN, ORDER BY, GROUP BY |
| 권장 대상 | >1TB, 자주 쿼리, 드물게 변경 |
| Reclustering | 자동, Compute+Storage 비용 |
| Hybrid Table | 클러스터링 키 불가 ❌ |
Automatic Clustering Service (자동 클러스터링 서비스)
한 줄 정의
Automatic Clustering = clustered table의 재클러스터링을 Snowflake가 "알아서 + 지속적으로(continually)" 관리해주는 서비스
비유하자면 "자동 정리 로봇" 입니다. 내가 정리 기준(클러스터링 키)만 정해주면, 데이터가 흐트러질 때마다 로봇이 알아서 다시 정리해줍니다.
📖 중요: 클러스터링 키를 정의해도 재클러스터링이 즉시 시작되는 건 아닙니다. Snowflake는 테이블이 혜택을 받을 때만(if it will benefit) 재클러스터링을 수행합니다.
✅ 4가지 핵심 이점 (⭐⭐)
| 이점 | 설명 |
|---|---|
| ① Ease-of-maintenance (유지보수 불필요) | 테이블 상태를 직접 모니터링할 필요 없음. DML이 일어나면 Snowflake가 알아서 평가하고 재클러스터링 |
| ② Full control (완전한 제어) | 언제든 SUSPEND(중지) / RESUME(재개) 가능 |
| ③ Non-blocking DML (DML 차단 없음) | 재클러스터링 중에도 INSERT/UPDATE/DELETE 등 DML이 차단되지 않음 (투명하게 동작) |
| ④ Optimal efficiency (최적 효율) | Snowflake가 내부적으로 서버/메모리 등 리소스를 동적 할당. 불필요한 재클러스터링은 안 함 |
🔑 가장 헷갈리는 포인트: 재클러스터링 중에도 테이블 사용 가능 (DML 안 막힘)
⚙️ Enabling (활성화 방법)
클러스터링 키만 정의하면 끝! (별도 작업 불필요)
-- 이것만 하면 Automatic Clustering 자동 활성화
ALTER TABLE t1 CLUSTER BY (c1, c2);CLONE 예외 (⭐)
CREATE TABLE ... CLONE으로 복제한 테이블은
원본이 켜져 있어도 → 복제본은 Automatic Clustering이 SUSPEND(중지) 상태로 시작
(table/schema/database 어느 단위로 clone해도 동일)
→ 복제 후에는 수동으로 RESUME 해야 자동 클러스터링이 동작합니다.
SUSPEND / RESUME (중지 / 재개)
-- 중지 (재클러스터링 안 함 → 크레딧 비용도 안 듦)
ALTER TABLE t1 SUSPEND RECLUSTER;
-- 재개
ALTER TABLE t1 RESUME RECLUSTER;| 동작 | 효과 |
|---|---|
| SUSPEND | 클러스터링 상태와 무관하게 재클러스터링 안 함 → 관련 크레딧 비용 발생 X |
| RESUME | 다시 자동 재클러스터링 시작 |
| DROP CLUSTERING KEY | 향후 모든 재클러스터링 영구 중단 |
⚠️ 함정: 클러스터링 키를 변경하면 자동으로 RESUME되어 크레딧이 소모될 수 있음.
ALTER TABLE ... CLUSTER BY문에 LINEAR라는 단어를 포함하면, 컬럼이 안 바뀌어도 키 변경으로 간주됨.
상태 확인 (Viewing Status)
SHOW TABLES LIKE 't1';AUTO_CLUSTERING_ON컬럼 → 자동 클러스터링 ON/OFF 확인CLUSTER_BY(SHOW TABLES) 또는CLUSTERING_KEY(TABLES view) → 클러스터링 키 확인
비용 (Costs) ⭐ 중요
Compute 비용
- ⭐ Serverless compute 리소스 사용 → 가상 웨어하우스(Virtual Warehouse) 지정 불필요!
- Snowflake가 내부적으로 리소스 관리, 실제 소비한 크레딧만 청구
- 변경(DML)이 많을수록 유지 비용 ↑
Storage 비용
- 기존 데이터를 재구성하는 것이므로 대부분 추가 스토리지 비용 없음
- 단, Fail-safe 스토리지가 증가하면 추가 비용 발생 가능
🔑 시험 핵심: Automatic Clustering은 별도 웨어하우스가 필요 없는 Serverless 기능
비용 관련 함수/뷰
| 함수/뷰 | 용도 |
|---|---|
SYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTS | 비용 추정 (단, 실제와 최대 100%까지 차이날 수 있음) |
AUTOMATIC_CLUSTERING_HISTORY (함수/뷰) | 소비된 크레딧 이력 조회 |
⚠️ Resource Monitor로는 Automatic Clustering 크레딧을 제어할 수 없음 (Snowflake 제공 웨어하우스이기 때문)
🎯 핵심 포인트
| 키워드 | 답 |
|---|---|
| 정의 | 재클러스터링을 Snowflake가 자동·지속 관리하는 서비스 |
| 활성화 | 클러스터링 키만 정의하면 끝 |
| 4대 이점 | 유지보수 불필요 / 완전제어 / DML 안 막힘 / 최적효율 |
| 중지·재개 | ALTER TABLE ... SUSPEND / RESUME RECLUSTER |
| CLONE 함정 | 복제본은 SUSPEND 상태로 시작 |
| Compute | Serverless → 웨어하우스 불필요 |
| Storage | 대부분 추가 비용 없음 (Fail-safe 증가 시 예외) |
| 비용 추정 | SYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTS |
| 제어 한계 | Resource Monitor로 제어 불가 |
