다이나믹 테이블

다이나믹 테이블

다이나믹 테이블은 SELECT 쿼리의 결과를 구체화(materialize)하고 계속 최신 상태로 유지합니다. SELECT 쿼리와 target lag를 지정하면, Snowflake가 의존성을 추적하고 스케줄에 따라 데이터를 리프레시해요. 구체화 뷰, 스트림과 태스크, dbt와의 자세한 비교는 Decision guide for dynamic tables를 참고하세요.

출처: Snowflake 문서

본문

CREATE OR ALTER DYNAMIC TABLE dt_orders
  TARGET_LAG = '10 minutes'
  WAREHOUSE = transform_wh
  REFRESH_MODE = INCREMENTAL
AS
  SELECT
    order_id,
    customer_id,
    order_date,
    TRIM(UPPER(product_name)) AS product_name,
    quantity,
    unit_price,
    quantity * unit_price AS line_total,
    order_status
  FROM raw_orders
  WHERE order_status != 'returned';

이 문장은 테이블이 무엇을 담을지(SELECT 쿼리), 데이터가 얼마나 신선해야 하는지(TARGET_LAG), 그리고 Snowflake가 데이터를 어떻게 리프레시하는지(REFRESH_MODE)를 정의합니다. 일단 생성되면 Snowflake는 base table(이 예시에서는 raw_orders)을 모니터링하고 다이나믹 테이블을 자동으로 리프레시해요. 전체 튜토리얼은 Create a dynamic table을 참고하세요.

Snowflake가 다이나믹 테이블을 최신 상태로 유지하는 방법

다이나믹 테이블을 만들면 Snowflake가 쿼리를 분석하고, 읽는 base table을 식별하며, 리프레시를 위해 다이나믹 테이블을 등록합니다. 그 시점부터 Snowflake는 base table의 변경을 모니터링하고, 설정한 target lag 안에 머물도록 다이나믹 테이블을 리프레시해요.

각 리프레시는 다음 단계를 따릅니다:

  1. Snowflake가 base table이 변경되었음을 감지합니다.
  2. 다이나믹 테이블이 증가분 리프레시를 사용하면 변경된 행만 계산하고, 전체 리프레시를 사용하면 결과 집합 전체를 리프레시해요.
  3. 새 결과가 다이나믹 테이블에 원자적으로 적용되므로, 읽는 사람은 부분 리프레시를 절대 보지 못합니다.

서로 의존하는 다이나믹 테이블이 여러 개 있으면 Snowflake는 이를 파이프라인으로 취급합니다. 쿼리에서 의존성 그래프를 추론하고 일관된 스냅샷 타임스탬프를 선택해요. Snowflake는 의존성 순서대로 테이블을 리프레시해서, 하위 테이블이 항상 상위 입력의 일관된 뷰를 보도록 보장합니다.

다이나믹 테이블 파이프라인 구축

하나의 다이나믹 테이블은 하나의 데이터 소스를 정제하거나 변환합니다. 전체 파이프라인을 만들려면 서로를 읽는 다이나믹 테이블을 추가로 생성하세요. 예를 들어 dt_orders_daily는 dt_orders 위에서 일일 매출을 집계하면서, dim_customers에도 조인합니다. 전체 정의는 Create a dynamic table을 참고하세요.

Snowflake는 이 다이나믹 테이블들을 파이프라인으로 관리합니다: dt_orders → dt_orders_daily. Snowflake는 dim_customers도 dt_orders_daily의 의존성으로 추적해요. 각 다이나믹 테이블은 고유한 target lag를 가지며, 리프레시는 dt_orders_daily가 항상 입력의 일관된 스냅샷을 반영하도록 조정됩니다.

핵심 개념

  • Target lag. target lag는 데이터가 얼마나 신선해야 하는지 Snowflake에 알려줍니다. 10분 target lag는 데이터를 base table보다 10분 이상 뒤처지지 않게 유지하려 한다는 뜻이지만, 리프레시가 예상보다 오래 걸리면 실제 lag가 target을 초과할 수 있어요. 중간 테이블에는 TARGET_LAG = DOWNSTREAM을 설정해 하위 종속자가 신선한 데이터를 필요로 할 때만 리프레시하도록 할 수도 있습니다. 자세한 내용은 Set the target lag for a dynamic table을 참고하세요.
  • Refresh modes. 다이나믹 테이블은 여러 리프레시 모드를 지원합니다. INCREMENTAL은 마지막 리프레시 이후 변경된 행만 처리하고, FULL은 결과 집합 전체를 리프레시하며, AUTO는 정의가 증가분 리프레시를 지원하는지에 따라 생성 시점에 Snowflake가 선택합니다.
  • ADAPTIVE 리프레시는 기본적으로 증가분 리프레시를 사용하지만, 큰 상위 변경이 감지되면 자동으로 재초기화합니다. 고급 사용 사례에서는 CUSTOM_INCREMENTAL로 DML 문을 이용해 자신만의 리프레시 로직을 정의할 수 있어요. 자세한 내용은 Dynamic table refresh modes를 참고하세요.
  • 자동 스케줄링. Snowflake가 다이나믹 테이블을 모니터링하고, 상위 변경을 감지하며, 의존성 그래프 순서로 리프레시를 자동으로 디스패치합니다. SCHEDULER = DISABLE로 설정하면 수동으로 또는 dbt·Airflow 같은 외부 도구로 리프레시를 관리할 수 있어요. 자세한 내용은 Manage dynamic tables를 참고하세요.
  • 파이프라인. 다이나믹 테이블들이 서로를 읽으면 파이프라인을 형성합니다. Snowflake는 작성한 쿼리에서 의존성 그래프를 자동으로 추론해요. 의존성을 선언하거나 실행 순서를 스크립트로 만들 필요가 없습니다.

비용 요약

다이나믹 테이블은 세 가지 유형의 비용이 발생합니다:

비용 범주 포함 내용 핵심 요인
웨어하우스 컴퓨팅 가상 웨어하우스가 각 리프레시 쿼리를 실행 웨어하우스 크기, 리프레시 실행 빈도, 쿼리 복잡도, 데이터 양
Cloud Services Snowflake가 리프레시 쿼리 컴파일, 의존성 추적, 변경 모니터링, 리프레시 조정 쿼리 복잡도, 다이나믹 테이블 수, 파이프라인 깊이, target lag (짧을수록 스케줄링 작업 증가)
스토리지 리프레시가 테이블의 마이크로파티션을 추가·교체·제거 다이나믹 테이블 크기, 리프레시 횟수, Time Travel 보존 기간

자세한 분석은 Understanding costs for dynamic tables를 참고하세요.

다이나믹 테이블을 사용해야 할 때

일반적으로 로직이 SQL SELECT 문으로 표현될 수 있다면 다이나믹 테이블의 후보가 될 수 있어요.

다이나믹 테이블은 다음과 같은 워크로드에 잘 맞습니다:

  • 커스텀 오케스트레이션 코드를 작성하지 않고도 최신 상태를 유지하는 쿼리 결과를 구체화하려 할 때
  • 조인, 집계, 윈도우 함수가 포함된 다단계 파이프라인을 만들어야 할 때
  • 원하는 결과를 정의하면 Snowflake가 스케줄링을 처리하는 선언적 접근을 선호할 때
  • 단일 파라미터(target lag)를 조정해 배치 처리에서 near-real-time 신선도로 전환하고 싶을 때

다이나믹 테이블이 지원하지 않는 워크로드:

  • 60초(최소 target lag)보다 신선한 데이터가 필요하거나 리프레시 시간이 엄격히 보장되어야 하는 경우
  • 정의에 프로시저(stored procedure)나 외부 함수가 필요한 경우
  • lateral join 밖에서 UDTF를 사용하는 경우. 자세한 내용은 Supported queries for dynamic tables 참고

스트림과 태스크, 구체화 뷰 및 다른 접근 방식과의 나란히 비교는 Decision guide for dynamic tables를 참고하세요.

더 알아보기 (Learn more)