다이나믹 테이블용 웨어하우스 선택과 크기 조정

다이나믹 테이블용 웨어하우스 선택과 크기 조정

모든 다이나믹 테이블에는 리프레시를 실행할 웨어하우스가 필요해요. 할당한 웨어하우스가 각 리프레시가 얻는 메모리와 병렬성을 결정하며, 리프레시 속도와 크레딧 소비에 직접 영향을 줍니다.

출처: Snowflake 문서

본문

WAREHOUSE vs INITIALIZATION_WAREHOUSE

다이나믹 테이블은 두 개의 웨어하우스 매개변수를 지원합니다. WAREHOUSE는 정기적인 증분 리프레시(incremental refresh)를 실행합니다. INITIALIZATION_WAREHOUSE는 설정 시 초기 리프레시와 이후의 모든 재초기화를 실행하는데, 이 작업들은 소스 데이터 전체 스캔을 수행하고 보통 더 리소스 집약적이에요. 일반적인 재초기화 트리거에는 기본 테이블 재생성, 상위 뷰 변경, 마스킹 정책 변경이 포함됩니다. 전체 목록은 재초기화 트리거를 참고하세요.

CREATE OR REPLACE DYNAMIC TABLE dt_orders
    TARGET_LAG = '10 minutes'
    WAREHOUSE = transform_wh                    -- steady-state 증분 리프레시
    INITIALIZATION_WAREHOUSE = transform_wh_xl  -- 초기 빌드와 재초기화
    REFRESH_MODE = INCREMENTAL
AS
SELECT ...
FROM raw_orders ...;

다음 표는 각 유형의 리프레시 작업을 실행하는 웨어하우스를 보여 줍니다.

INITIALIZATION_WAREHOUSE를 설정하지 않으면 모든 리프레시 작업이 WAREHOUSE가 지정한 웨어하우스에서 실행됩니다.

초기화용과 정상 리프레시용 웨어하우스를 분리하기

초기화는 소스 데이터셋 전체를 스캔하고, 증분 리프레시는 변경된 행만 처리해요. 두 워크로드에 단일 웨어하우스를 쓰면 일상 리프레시에는 과도하게 프로비저닝되거나 초기화에는 부족하게 프로비저닝됩니다.

초기 빌드와 재초기화가 빨리 끝나도록 큰 INITIALIZATION_WAREHOUSE를 사용하고, 비용 효율적인 증분 리프레시를 위해 작은 WAREHOUSE를 유지하세요. 이 패턴은 보조 다이나믹 테이블을 주 테이블로 승격한 뒤 빠른 복구가 필요하거나, 정상 상태 비용을 늘리지 않고 엄격한 RTO/RPO(복구 시간 목표/복구 지점 목표) 요구사항을 충족해야 할 때 특히 유용해요.

다이나믹 테이블을 다시 만들지 않고 언제든 <C>ALTER DYNAMIC TABLE <name> SET INITIALIZATION_WAREHOUSE = <warehouse></C>를 실행해 초기화 웨어하우스를 추가하거나 변경할 수 있어요. 제거하고 모든 작업을 기본 웨어하우스에서 실행하려면 <C>ALTER DYNAMIC TABLE <name> UNSET INITIALIZATION_WAREHOUSE</C>를 실행하세요.

존재하지 않는 웨어하우스를 참조하면 문이 실패합니다:

ALTER DYNAMIC TABLE dt_orders
    SET INITIALIZATION_WAREHOUSE = nonexistent_wh;

Object 'NONEXISTENT_WH' does not exist or not authorized.

WAREHOUSE와 INITIALIZATION_WAREHOUSE 모두 소유자 역할이 할당된 웨어하우스에 대한 USAGE를 가져야 합니다. 없으면 CREATE나 ALTER 문이 'does not exist or not authorized' 오류로 실패합니다.

크기가 작은 웨어하우스 감지하기

웨어하우스에 리프레시를 위한 메모리가 부족하면 Snowflake는 중간 데이터를 로컬 디스크나 원격 스토리지로 spill합니다. Spilling은 리프레시를 느리게 하고 target lag를 초과하게 만들 수 있어요.

Spilling을 확인하려면 최근 리프레시의 쿼리 프로필을 열고(실행 시간 살펴보기) Statistics 섹션을 보세요. 주의할 두 신호는 다음과 같습니다:

• 로컬 스토리지로 spill된 바이트: 웨어하우스 메모리가 부족했지만 로컬 디스크에서 오버플로를 처리했습니다. 특히 리프레시 지속 시간이 target lag에 가까우면 웨어하우스 확장을 고려하세요.
• 원격 스토리지로 spill된 바이트: 웨어하우스가 메모리와 로컬 디스크를 모두 소진했습니다. 정상 상태 증분 리프레시에서 반복적으로 발생하고 리프레시 지속 시간이 target lag를 초과하면 웨어하우스를 확장하세요. 일회성 초기화 중의 원격 spill은 예상된 것으로 반드시 변경이 필요한 건 아니에요.

쿼리 기록에서 특정 웨어하우스의 spill 지표도 확인할 수 있어요. 단계별 모니터링 워크플로우는 다이나믹 테이블 모니터링을 참고하세요.

다이나믹 테이블 워크로드용 웨어하우스 크기 조정

spill을 막으면서도 target lag를 충족하는 가장 작은 웨어하우스를 선택하세요. 작게 시작해서 리프레시 기록과 쿼리 프로필의 증거에 따라 확장하세요. 리프레시가 스캔하는 데이터 양을 찾으려면 DYNAMIC_TABLE_REFRESH_HISTORY의 BYTES_SCANNED 컬럼이나 완료된 리프레시의 쿼리 프로필을 확인하세요.

다음 표는 일반적인 워크로드에 기반한 예시 시작점을 보여 줍니다.

참고 이는 시작점이지 보장이 아닙니다. 최적의 웨어하우스 크기는 쿼리 복잡성, 데이터 지역성, 변경량, 동시성에 따라 달라져요. 리프레시 기록을 모니터링하고 실제 성능에 따라 조정하세요.

컴파일 시간 vs 웨어하우스 시간

리프레시 시간이 전부 웨어하우스 컴퓨트인 것은 아니에요. 각 리프레시에는 두 단계가 있습니다:

• 컴파일(Compilation): Snowflake가 리프레시를 계획하고, 변경된 파티션을 식별하며, 실행 계획을 생성합니다. 컴파일은 웨어하우스가 아니라 Cloud Services에서 실행됩니다. 더 큰 웨어하우스는 컴파일 시간을 줄이지 않아요.
• 웨어하우스 실행(Warehouse execution): 웨어하우스가 리프레시 계산을 실행합니다. 더 큰 웨어하우스는 더 많은 메모리와 병렬성으로 이 단계를 줄일 수 있어요.

리프레시 시간의 대부분이 컴파일에 쓰였다면 확장해도 소용없어요. 쿼리 프로필에서 두 단계 사이의 시간 분할을 확인하세요. 컴파일이 지배한다면 정의를 단순화하거나 기본 테이블 수를 줄이는 것을 고려하세요.

전용 웨어하우스에서 다이나믹 테이블 워크로드 격리하기

다이나믹 테이블 리프레시에 전용 웨어하우스를 사용하면 다음 결과를 얻을 수 있어요:

• 비용 격리: 웨어하우스의 모든 크레딧을 특정 파이프라인이나 팀에 귀속시킬 수 있습니다. spill과 지속 시간 지표가 다이나믹 테이블 워크로드만 반영하므로 비용 모니터링이 단순해집니다.
• 리소스 경합 없음: 임시 쿼리와 다른 워크로드가 리프레시와 웨어하우스 리소스를 두고 경쟁하지 않습니다.
• 예측 가능한 크기 조정: 다른 사용자에게 영향을 주지 않고 다이나믹 테이블 워크로드에 맞게 웨어하우스를 적절히 크기 조정할 수 있습니다.

전용 리프레시 웨어하우스에는 AUTO_SUSPEND를 짧게(예: 60초) 설정해서 리프레시 사이의 유휴 시간 비용을 피하세요. Snowflake는 리프레시가 전달되면 웨어하우스를 자동으로 재개합니다.

여러 다이나믹 테이블이 웨어하우스를 공유하고 리프레시가 큐에 쌓이면 멀티 클러스터 웨어하우스를 고려해 동시성을 처리하세요. 멀티 클러스터 웨어하우스는 쿼리가 큐에 쌓이면 클러스터를 추가하고 수요가 줄면 제거합니다. Enterprise Edition 이상이 필요합니다.

다음 단계

• 리프레시 성능 모니터링과 병목 진단은 다이나믹 테이블 모니터링을 참고하세요.
• 리프레시 모드가 성능에 미치는 영향을 이해하려면 다이나믹 테이블 리프레시 모드를 참고하세요.
• 증분 리프레시를 위한 다이나믹 테이블 쿼리 최적화는 증분 리프레시 쿼리 최적화를 참고하세요.
• 일반적인 웨어하우스 크기 조정 지침은 웨어하우스 크기 늘리기를 참고하세요.

더 알아보기 (Learn more)

• 다이나믹 테이블 모니터링
• 다이나믹 테이블 리프레시 모드
• 증분 리프레시 쿼리 최적화