스토리지와 SQL Warehouse 최적화

-- Liquid Clustering 적용 (새 테이블)
CREATE TABLE sales.gold.daily_revenue (
  sale_date DATE,
  region STRING,
  product_category STRING,
  revenue DECIMAL(18,2)
)
CLUSTER BY (sale_date, region);

-- 기존 테이블에 Liquid Clustering 추가
ALTER TABLE sales.gold.daily_revenue
CLUSTER BY (sale_date, region);

-- 자동 키 선택 (Databricks가 쿼리 패턴 분석 후 최적 키 결정)
ALTER TABLE sales.gold.daily_revenue
CLUSTER BY AUTO;

-- OPTIMIZE: 작은 파일들을 병합하여 읽기 성능 향상
OPTIMIZE catalog.schema.table_name;

-- VACUUM: 더 이상 참조되지 않는 오래된 파일 삭제 (스토리지 비용 절감)
VACUUM catalog.schema.table_name RETAIN 168 HOURS;  -- 7일 보존

-- 테이블 통계 재수집 (쿼리 옵티마이저 성능 향상)
ANALYZE TABLE catalog.schema.table_name COMPUTE DELTA STATISTICS;

-- 카탈로그 수준에서 Predictive Optimization 활성화
ALTER CATALOG my_catalog ENABLE PREDICTIVE OPTIMIZATION;

-- 스키마 수준에서 활성화
ALTER SCHEMA my_catalog.my_schema ENABLE PREDICTIVE OPTIMIZATION;

-- 특정 스키마만 비활성화 (비용 민감한 경우)
ALTER SCHEMA my_catalog.temp_schema DISABLE PREDICTIVE OPTIMIZATION;

시나리오: Medium Warehouse, 하루 8시간 업무 시간 중 실제 쿼리 4시간

[Always On]
  24시간 × 365일 = 8,760시간/년 과금

[Auto Stop 10분]
  ~4.5시간/일 × 250 업무일 = 1,125시간/년 과금
  → 약 87% 비용 절감!

[Serverless + Auto Stop 5분]
  ~4.2시간/일 × 250 업무일 = 1,050시간/년
  → 즉시 시작으로 사용자 경험 유지 + 비용 최적화

-- Materialized View로 반복 쿼리 비용 제거
CREATE MATERIALIZED VIEW sales.gold.monthly_summary AS
SELECT
  date_trunc('month', sale_date) AS month,
  region,
  SUM(revenue) AS total_revenue,
  COUNT(DISTINCT customer_id) AS unique_customers
FROM sales.silver.transactions
GROUP BY 1, 2;

-- Materialized View는 자동으로 증분 갱신됩니다
-- 동일한 쿼리를 100명이 실행해도 사전 계산된 결과를 반환

Q1: 동시 사용자가 10명 이상인가?
  → No: Small 또는 Medium
  → Yes: Q2로

Q2: 대부분의 쿼리가 1TB 이상 테이블을 스캔하는가?
  → No: Medium (클러스터 수 2-3)
  → Yes: Large 이상

Q3: Serverless를 사용하는가?
  → Yes: Medium-Large 단일 Warehouse (IWM이 자동 관리)
  → No: 여러 Warehouse 분리 전략 필요

[오토스케일링 시나리오]

시나리오: 대시보드 50명 동시 접속 + Ad-hoc 분석 10명

권장 설정:
  Size: Medium
  Min clusters: 1 (항상 1개 유지)
  Max clusters: 10 (50명 기준)
  Auto Stop: 10분

동작:
  09:00 - 업무 시작, 1개 클러스터로 시작
  09:30 - 대시보드 접속 증가, 3개로 스케일 아웃
  10:00 - 피크 시간, 7개 클러스터
  12:00 - 점심시간, 2개로 스케일 인
  18:00 - 퇴근, 1개로 축소
  18:10 - Auto Stop, 0개로 종료

-- Result Cache가 무효화되는 경우
-- 1. 테이블 데이터가 변경됨 (INSERT, UPDATE, DELETE, MERGE)
-- 2. 비결정적 함수 사용 (CURRENT_TIMESTAMP(), RAND(), UUID())
-- 3. 쿼리 텍스트가 다름 (공백, 대소문자 차이도 미스)

-- ✅ Cache 친화적 쿼리 패턴
SELECT region, SUM(revenue) AS total
FROM sales.gold.daily_revenue
WHERE sale_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY region;

-- ❌ Cache 비친화적 쿼리 패턴 (매번 다른 결과)
SELECT region, SUM(revenue) AS total
FROM sales.gold.daily_revenue
WHERE sale_date >= current_date() - INTERVAL 90 DAYS  -- 매일 다른 결과
GROUP BY region;

-- Disk Cache는 자주 접근하는 데이터를 로컬 SSD에 저장
-- Classic SQL Warehouse에서 자동 동작
-- 확인 방법: Query Profile에서 "bytes read from cache" 지표

-- Disk Cache를 극대화하려면:
-- 1. Storage-optimized 인스턴스 사용 (로컬 SSD 보유)
-- 2. Warehouse 재시작 최소화 (재시작 시 Cache 초기화)
-- 3. 자주 조인하는 디멘션 테이블은 캐시에 자동 로드

[통합 전]
wh-team-a (Small, 10명)  → 월 $500
wh-team-b (Small, 10명)  → 월 $500
wh-team-c (Small, 5명)   → 월 $500
합계: 월 $1,500

[통합 후]
wh-analytics (Medium, 25명) → 월 $800
합계: 월 $800 (47% 절감)

이유: 각 팀의 피크 타임이 다르므로, 통합하면 리소스 활용률이 높아짐

-- Serverless 비용 모니터링 (시스템 테이블)
SELECT
  date_trunc('day', usage_date) AS day,
  warehouse_id,
  SUM(usage_quantity) AS total_dbus,
  SUM(usage_quantity * list_price) AS estimated_cost
FROM system.billing.usage
WHERE usage_type = 'SQL_WAREHOUSE'
AND usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY 1, 2
ORDER BY estimated_cost DESC;