다이나믹 테이블과 스토리지 라이프사이클 정책

다이나믹 테이블과 스토리지 라이프사이클 정책

다이나믹 테이블에 스토리지 라이프사이클 정책(storage lifecycle policy)을 연결하면, 다이나믹 테이블 리프레시와는 별개의 스케줄로 조건에 맞는 행을 삭제하거나 아카이빙할 수 있어요. 오래된 데이터만 남기고 싶은 보존 기간(retention) 기반 테이블을 만들기에 좋습니다.

출처: Snowflake 문서

본문

다이나믹 테이블에 스토리지 라이프사이클 정책을 연결하면, 리프레시와는 별개로 실행되는 일정에 따라 프레디킷(predicate)에 일치하는 행을 삭제하거나 아카이빙할 수 있어요.

Note Frozen region은 예전에 "immutability constraints"(불변성 제약)라고 불렸고, <C>FROZEN WHERE</C> 절은 예전에 <C>IMMUTABLE WHERE</C> 문법을 사용했어요. 레거시 <C>IMMUTABLE WHERE</C> 문법은 계속 지원되며, <C>SHOW DYNAMIC TABLES</C>도 여전히 immutable_where 컬럼을 사용합니다.

스토리지 라이프사이클 정책을 다이나믹 테이블에 직접 연결하려면, CREATE DYNAMIC TABLE 문의 WITH STORAGE LIFECYCLE POLICY 절이나 ALTER DYNAMIC TABLE 문의 ADD STORAGE LIFECYCLE POLICY 절을 사용하면 돼요.

스토리지 라이프사이클 정책이 다이나믹 테이블에서 동작하는 방식

정책의 프레디킷에 일치하는 행들이 다이나믹 테이블의 expired region(만료 영역)을 구성해요. expired region은 frozen region처럼 동작해서, 리프레시가 그 행들을 frozen으로 취급하고 절대 처리하지 않아요. 스토리지 라이프사이클 정책 실행은 자체 스케줄에 따라 비동기적으로 돌아가며(스토리지 라이프사이클 정책 참고), 다이나믹 테이블 리프레시와는 완전히 독립적입니다.

행 하나가 frozen region과 expired region 양쪽에 속할 수도 있어요. frozen region은 리프레시가 그 행을 처리하지 못하게 보호할 뿐, 정책이 만료시키는 건 막지 않아요. 정책이 실행되면 그 행들도 여전히 삭제되거나 아카이빙됩니다.

제약 사항

다이나믹 테이블에 스토리지 라이프사이클 정책을 연결할 때는 다음 제약이 적용돼요.

• 다이나믹 테이블을 BACKFILL FROM 절로 만들었다면, 백필 테이블의 스토리지 라이프사이클 정책은 새 다이나믹 테이블로 복사되지 않아요. 새 다이나믹 테이블에는 정책을 별도로 연결해야 합니다.
• 정책 프레디킷은 frozen region 프레디킷과 동일한 제약을 받아요. 지원되는 표현식에 대한 전체 제약 목록은 Frozen region 프레디킷 제약 사항을 참고하세요.
• 정책 프레디킷은 메타데이터 컬럼(예: METADATA$ROW_LAST_COMMIT_TIME)을 참조할 수 없어요. 표준 테이블은 행 타임스탬프 기준의 라이프사이클 정책을 지원하지만, 다이나믹 테이블은 지원하지 않으며 그런 정책을 연결하면 unsupported feature 오류가 나요. 대신 다이나믹 테이블의 정의에 일반 타임스탬프 컬럼을 사용하면 됩니다.

재초기화(reinitialization) 트리거

스토리지 라이프사이클 정책을 변경하거나 제거하면, 변경이 expired region에 어떤 영향을 주느냐에 따라 다이나믹 테이블의 다음 리프레시에서 재초기화가 일어날 수 있어요. 다음 표는 다이나믹 테이블에 가한 변경과 재초기화 여부를 보여줍니다.

스토리지 라이프사이클 정책 변경이 재초기화를 트리거하면, refresh-history의 REINIT_REASON 컬럼에 그 정책 변경을 식별하는 값이 들어가요. 리프레시 히스토리를 조회하려면 DYNAMIC_TABLE_REFRESH_HISTORY를 참고하세요.

모든 재초기화 트리거의 표준 목록은 무엇이 재초기화를 트리거하나요 문서를 참고하세요. 다이나믹 테이블 비용 가이드는 컴퓨팅 비용 이해하기를 참고합니다.

예시: 제한된 보존 기간(limited retention) 다이나믹 테이블

다음 다이나믹 테이블은 베이스 테이블에서 가장 최근 일주일치 주문만 담아요. 연결된 정책이 1주일보다 오래된 행을 만료시키므로, 다이나믹 테이블은 최근 일주일만 유지됩니다.

CREATE STORAGE LIFECYCLE POLICY expire_after_1w
  AS
  (ts TIMESTAMP)
  RETURNS BOOLEAN
  ->
  ts < CURRENT_TIMESTAMP() - INTERVAL '1 week';

CREATE OR REPLACE DYNAMIC TABLE dt_orders
  TARGET_LAG = '1 minute'
  WAREHOUSE = transform_wh
  WITH STORAGE LIFECYCLE POLICY expire_after_1w ON (order_date)
  AS
  SELECT order_id, customer_id, order_date, product_name, quantity, unit_price, order_status
  FROM raw_orders;

예시: 무제한 보존 다이나믹 테이블 + 제한 보존 베이스 테이블

다음 예시는 앞 예시에서 정의한 expire_after_1w 정책을 재사용해요. 이 정책을 raw_orders 베이스 테이블에 연결한 뒤, 그 주문들을 일별 요약으로 집계하고 무기한 보존하는 다이나믹 테이블을 만듭니다. 다이나믹 테이블은 frozen region을 사용해서 하루가 끝나면 그 집계 행이 더 이상 베이스 테이블에서 리프레시되지 않도록 해요. 덕분에 스토리지 라이프사이클 정책이 베이스 테이블의 오래된 행을 안전하게 만료시킬 수 있습니다.

ALTER TABLE raw_orders
  ADD STORAGE LIFECYCLE POLICY expire_after_1w ON (order_date);

CREATE OR REPLACE DYNAMIC TABLE dt_orders_daily
  (order_day DATE, region VARCHAR, order_count NUMBER, daily_revenue NUMBER)
  TARGET_LAG = '1 hour'
  WAREHOUSE = transform_wh
  FROZEN WHERE (order_day < DATEADD('day', -2, CURRENT_DATE))
  AS
  SELECT
    DATE_TRUNC('DAY', o.order_date) AS order_day,
    c.region,
    COUNT(*) AS order_count,
    SUM(o.quantity * o.unit_price) AS daily_revenue
  FROM raw_orders o
  JOIN dim_customers c ON o.customer_id = c.customer_id
  GROUP BY 1, 2;

스토리지 라이프사이클 정책의 보존 기간(1주일)은 frozen region의 lag보다 길어야 해요. 그래야 각 날짜의 집계가 해당 베이스 테이블 행이 만료되기 전에 확정됩니다.

더 알아보기 (Learn more)

• 컴퓨팅 비용 이해하기 — 다이나믹 테이블의 컴퓨팅·스토리지 비용
• Frozen regions 및 backfill — frozen region과 라이프사이클 정책의 상호작용
• 무엇이 재초기화를 트리거하나요 — 라이프사이클 정책 변경 포함 전체 재초기화 트리거 목록