Dynamic Tables (TARGET_LAG, 새로 고침 모드, 파이프라인 설계)

무엇인가

Dynamic Table 은 AS SELECT ... 로 결과를 정의해 두면, Snowflake 가 원본이 바뀔 때 목표 지연(TARGET_LAG) 안에 들도록 알아서 결과를 갱신하는 테이블입니다. 스트림과 태스크로 짜던 증분 파이프라인을 선언형으로 바꿔 줍니다.

CREATE OR REPLACE DYNAMIC TABLE mart.daily_revenue
  TARGET_LAG = '15 minutes'
  WAREHOUSE  = transform_wh
  REFRESH_MODE = AUTO
  AS
  SELECT DATE_TRUNC('day', o.ordered_at) AS d, c.country,
         SUM(o.amount) AS revenue, COUNT(*) AS orders
  FROM raw.orders o
  JOIN raw.customers c ON c.id = o.customer_id
  WHERE o.status = 'PAID'
  GROUP BY 1, 2;

TARGET_LAG

• '60 seconds' 부터 'n days' 까지 시간으로 정합니다. 최소값은 60초입니다.
• DOWNSTREAM 으로 두면 자기 일정은 없고, 이 테이블을 읽는 하위 Dynamic Table 이 새로 고칠 때만 따라서 갱신됩니다. 파이프라인 중간 단계에 씁니다.
• 하위 테이블의 지연은 상위 테이블의 지연보다 짧을 수 없습니다.
• 지연을 짧게 할수록 새로 고침이 잦아지고 웨어하우스가 자주 깨어나 비용이 오릅니다. 대시보드가 실제로 몇 분 지연까지 괜찮은지 먼저 정합니다.

새로 고침 모드

모드는 만든 뒤 ALTER 로 바꿀 수 없습니다. 바꾸려면 다시 만듭니다. AUTO 가 실제로 무엇을 골랐는지는 SHOW DYNAMIC TABLES 의 refresh_mode 와 refresh_mode_reason 열로 확인합니다. 2026년 9월부터는 EXPLAIN CHANGES 로 새로 고침이 어떻게 동작할지 미리 볼 수 있습니다 (GA).

증분이 되는 쿼리 만들기

2026년 들어 증분 지원 범위가 계속 넓어졌습니다. MIN_BY, MAX_BY(3월), VOLATILE 스칼라 UDF(7월), 비결정적 집계 함수와 VALUES 절(9월) 등이 증분에서 지원됩니다. 그래도 다음은 전체 새로 고침으로 떨어지기 쉬우니 확인합니다.

• 일부 윈도 함수 조합, 아주 복잡한 중첩 서브쿼리
• 외부 함수, 일부 비결정적 표현
• 원본이 매번 통째로 바뀌는 테이블 (증분 이점이 없음)

2026년에 바뀐 것

-- 90일 지난 행은 다시 계산하지 않음
CREATE OR REPLACE DYNAMIC TABLE mart.events_enriched
  TARGET_LAG = '30 minutes'
  WAREHOUSE  = transform_wh
  INITIALIZATION_WAREHOUSE = transform_xl_wh   -- 처음 채울 때만 큰 웨어하우스
  FROZEN WHERE (event_date < CURRENT_DATE() - 90)
  AS SELECT ...;

INITIALIZATION_WAREHOUSE 는 첫 적재와 재초기화에만 쓰는 별도 웨어하우스로, 평소에는 작은 웨어하우스로 증분만 돌리게 해 줍니다.

운영 명령

ALTER DYNAMIC TABLE mart.daily_revenue SUSPEND;
ALTER DYNAMIC TABLE mart.daily_revenue RESUME;
ALTER DYNAMIC TABLE mart.daily_revenue REFRESH;          -- 수동 새로 고침
ALTER DYNAMIC TABLE mart.daily_revenue SET TARGET_LAG = '1 hour';

-- 최근 새로 고침 이력과 실패
SELECT name, state, refresh_action, refresh_trigger,
       DATEDIFF('second', refresh_start_time, refresh_end_time) AS sec, state_message
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(NAME_PREFIX => 'ANALYTICS.MART.'))
ORDER BY refresh_start_time DESC
LIMIT 50;

Snowsight 의 Dynamic Table 그래프 화면에서 상하위 관계와 각 단계의 지연, 실패를 한눈에 볼 수 있습니다.

Streams 와 Tasks, Materialized View 와 비교

비용

• 새로 고침은 지정한 웨어하우스 크레딧을 씁니다. 바뀐 것이 없으면 새로 고침을 건너뛰고 웨어하우스를 깨우지 않습니다.
• 여러 Dynamic Table 이 같은 웨어하우스를 쓰면 새로 고침이 겹쳐 효율이 좋아집니다. 반대로 지연이 아주 짧은 테이블 하나가 웨어하우스를 계속 깨워 두기도 합니다.
• 목표 지연을 업무 시간에만 짧게 하고 밤에는 길게 하는 식의 조정을 태스크로 걸 수 있습니다.

트러블슈팅

• 증상: 증분으로 만들었는데 매번 전체 새로 고침이 돌고 오래 걸립니다.

• 원인: AUTO 가 쿼리를 증분 불가로 판단했거나, 원본 테이블이 INSERT OVERWRITE 처럼 통째로 바뀝니다.

• 해결: refresh_mode_reason 을 확인하고, 막는 구문을 앞 단계 Dynamic Table 로 나눕니다. 원본을 통째로 바꾸는 작업은 MERGE 로 바꿉니다.

• 증상: 상태가 SUSPENDED 이고 하위 테이블도 멈췄습니다.

• 원인: 연속 실패로 자동 일시 중지되었거나, 원본 테이블이 바뀌어(열 삭제, 교체) 재초기화가 필요합니다.

• 해결: 새로 고침 이력의 state_message 로 원인을 고친 뒤 RESUME 합니다. 원본을 CREATE OR REPLACE 하면 재초기화가 일어나므로 큰 테이블은 INITIALIZATION_WAREHOUSE 를 지정해 둡니다.

공식 문서

• Dynamic tables
• CREATE DYNAMIC TABLE
• Dynamic table refresh modes