스노우플레이크(Snowflake) 기본개념 (2)

Task (반복 작업 예약)

• 실행 대상: DDL/DML/SQL 구문, Stored Procedure, 스크립팅 코드
• 단일 Task뿐 아니라 여러 Task를 연결해 그래프 형태로 실행 가능
• COPY INTO와 함께 사용 시 데이터 중복 적재 방지 매커니즘 제공 → 같은 구문 반복 실행 가능
• 스케줄이 있는 Task는 루트 Task, 루트 밑에 다른 Task 연결 가능
• 실행 방식:
  • Virtual Warehouse 사용 또는 Serverless 실행 선택 가능
  • Serverless는 과거 실행 기록 기반으로 리소스 자동 사이징
• 스케줄 방식: Crontab / n분 단위

TASK 생성

• Root Task: 실행환경, 스케줄 설정
• Child Task: 선행 태스크를 지정(AFTER)

Task 실행

• 기본 suspend 상태로 생성
• → RESUME 시 스케줄 시작, EXECUTE로 즉시 실행 가능

---

Stream

• CDC(Change Data Capture) 패턴 구현 시 활용
• 테이블/뷰에 생성 시 변경 이력 추적용 히든 컬럼 추가
• 일반적으로 Stream → Task 조합으로 변경분 처리

---

Dynamic Table

• 기존 CDC 방식(Stream+Task) 없이 베이스 테이블 변경 내용을 자동 반영
• 여러 Dynamic Table을 연결해 Task처럼 사용 가능
• Target Lag(목표 지연 시간) 지정 가능 → 해당 주기로 데이터 갱신
• 스토리지 / 가상 웨어하우스 컴퓨팅 / 클라우드 서비스 컴퓨팅 비용 고려 필요

Dynamic vs Stream+Task

• Dynamic: 선언형, 쿼리 구문에 의한 제약, 목표 지연으로 제어되는 자동화된 갱신
• Stream+Task: 명령형, 코드로 자유롭게 구성 가능, 스트림 태스크 일정으로 갱신

Dynamic Table vs Materialized View

구분	Dynamic Table	Materialized View
목적	변환용 테이블	성능 개선
조인	가능(여러 테이블)	단일 테이블
실행	가상 웨어하우스	Serverless 가능
데이터 최신성	Lag 존재	항상 최신(아니면 원본 참조)
쿼리 리라이트	없음	있음

---

반정형 데이터(Semi-structured Data)

• VARIANT 타입에 저장되며, 내부적으로 OBJECT/ARRAY 구조를 포함할 수 있음
• 마이크로 파티셔닝: Semi-structured 필드와 그 하위 필드까지도 통계(min/max 등)를 기록 → 프루닝에 활용 → 중첩 키 기준의 범위 스캔 최소화
• 조회: : 경로 연산자로 필드를 접근
• FLATTEN: 중첩 배열/오브젝트를 행으로 펼쳐 조인/집계가 가능
• JSON, Avro, Parquet, ORC, XML 등의 포맷 사용 가능

---

보안·권한

인증(Authentication)

• 인간 사용자: MFA 필수 적용 가능
• 프로그래밍 방식 사용자: OAuth, Key-Pair, PAT 지원

암호화

• 계층적 키 모델: 서버 → 계정 → 테이블 → 마이크로 파티션 단위
• Trust Center: 업계 모범사례 기반 보안·컴플라이언스 준수

Managed Access Schema

• 스키마 오너와 테이블 생성자가 다를 경우, 기본 권한 모델에서는 스키마 오너라도 테이블 접근 불가
• Managed Access 활성화 시 스키마 오너가 권한 관리 주체가 됨

오브젝트 생성 시 주의

• 생성 시 어떤 Role로 만들었는지 확인 필요
• Role이 다르면 접근 불가능할 수 있음

---

가상하우스 규모 조정 유형

• MPP 구조라 수직 확장도 여러 노드에서 병렬 처리(스펙이 좋아지는게 아니라 노드가 늘어남) → 노드 수·자원량이 늘어나 속도가 빨라짐

수직 확장

• 성능 향상이 필요할 경우
• 크기 한단계 확장할 때마다 리소스 2배 증가 (비용도 2배 증가)

수평 확장 또는 축소

• 많은 사용자가 동일한 가상 웨어하우스를 사용할 경우(동시성 확대)
• 기본적으로 auto-scaling을 지원

Auto-Scaling

• 정책
  • standard: 대기열 최소화
  • economy: 크레딧 사용 최소화

고려 사항

• 같은 데이터 집합을 반복 조회하는 경우 → 같은 웨어하우스를 사용해야 로컬 데이터 캐시가 재사용됨
• 웨어하우스를 자주 Suspend/Resume하면 캐시 유지율이 떨어짐 → 적절한 유지 전략 필요
• 수직 확장
  • 웨어하우스 크기 키움 (크레딧 ↑) → 더 많은 CPU/메모리 → 개별 쿼리 처리 속도 ↑
• 수평 확장
  • 멀티클러스터 모드로 클러스터 수를 늘림 → 동시 사용자/쿼리 수 처리량 ↑
• 작은 웨어하우스에서 큰 쿼리 실행 시
  • 메모리 부족 → 중간 데이터가 **로컬 디스크(SSD) 스필)**로 넘어감 → I/O 병목 → 성능 저하
  • 특히 대규모 조인, 정렬, 집계 쿼리는 영향이 큼
  • 대규모 분석 쿼리는 중간 데이터 크기에 맞춰 웨어하우스 크기 설정 필수
• 큰 웨어하우스 사용 시 주의점
  • 사용 리소스와 관계없이 웨어하우스 크기 기준으로 비용 과금
  • (예: XL 웨어하우스를 1초 쓰든 1분 쓰든, 1분 단위 크레딧 소모는 동일)
  • 즉, 쿼리가 빨리 끝나도 작업 볼륨 대비 과도한 크기 선택은 비용 낭비가 될 수 있음
• 웨어하우스는 하나의 쿼리만 도는 게 아니라 다양한 주기·규모의 쿼리가 혼합 실행됨
• 최적 사이즈는 워크로드 분석(동시성, 쿼리 패턴, 데이터 크기)이 필요

---

비용 구조

1. 스토리지 비용

• 영구 스토리지(Persistent Storage)
  • 테이블 데이터(정형·반정형 포함) 저장 공간
  • 압축 저장, 일별 평균 사용량 기준으로 월 단위 과금
• Time Travel 보관 공간
  • 변경·삭제 전 버전을 유지하기 위해 추가 스토리지 사용
  • 보관 기간: Standard Edition은 최대 1일, Enterprise 이상은 최대 90일
• Fail-safe 공간
  • Time Travel 기간 이후, 7일간 데이터 복구를 위한 영역
  • 읽기 전용, 추가 요금은 스토리지 요금에 포함

2. 컴퓨팅 비용

• 가상 웨어하우스(Virtual Warehouse)
  • 크기(예: XS, S, M, L, XL...) × 사용 시간 × 크레딧 단가
  • 1크레딧 = XS 1시간 실행
  • 최소 과금 단위 1분 (1분 미만은 1분으로 올림, 이후는 초 단위 청구)
  • 크레딧 단가는 Edition(Std/Ent/Business Critical) 및 Region에 따라 상이
• 서버리스(Serverless) 컴퓨팅
  • Snowpipe, Dynamic Table, Search Optimization, Materialized View 유지, Tasks 등 서버리스 작업은 사용한 만큼의 크레딧으로 과금
  • 웨어하우스 크기 대신 작업별 소요 리소스량을 기준으로 자동 청구

3. 데이터 전송/네트워크 비용

• 외부로 나가는 데이터(Egress)
  • 동일 리전 내에서는 무료
  • 다른 리전/클라우드로 전송 시 네트워크 비용 발생
• 내부 전송
  • Snowflake 내부 서비스 간 전송은 무료
• 데이터 전송/변환 비용
  • Snowpipe, Dynamic Table, COPY INTO 등 실행 시 컴퓨팅 크레딧 소비

4. 기타 기능/옵션 비용

• Search Optimization Service (인덱스)
  • 특정 컬럼·경로에 고속 검색 인덱스 생성
  • 인덱스 저장 공간 + 유지(백그라운드 갱신) 시 서버리스 크레딧 사용
  • ⚠️ 유지 비용 때문에 “실행시간=비용”이라고 해서 무조건 인덱스 쓰면 안 됨
  • 인덱스는 성능 최적화 목적으로, 고빈도·고비용 쿼리에만 전략적으로 적용
• Materialized View
  • 데이터 갱신 시 서버리스 크레딧 소모
• Replication / Failover
  • 스토리지 + 컴퓨팅 + 네트워크 비용 모두 발생
• Data Marketplace / Data Exchange
  • 외부 데이터 소비 시 네트워크·스토리지 요금 가능