동적 테이블 새로 고침 경계¶

개요¶

기본적으로, 동적 테이블이 다른 동적 테이블에서 읽을 때 Snowflake는 다음을 수행합니다.

• 단일 파이프라인의 일부로 두 테이블을 함께 새로 고칩니다.

• 파이프라인의 모든 업스트림 동적 테이블에서 다운스트림 동적 테이블이 스냅샷 격리 를 확인할 수 있도록 좌표가 새로 고침됩니다.

• 대상 지연 검사와 같은 파이프라인 수준 규칙을 적용합니다.

일부 파이프라인에서는 모든 관계로 인해 두 동적 테이블이 동시에 새로 고침되는 것이 바람직하지 않을 수 있습니다. 일반적인 몇 가지 예는 다음과 같습니다.

• 한 팀에서 다른 팀이 사용하는 동적 테이블을 게시하지만 다운스트림 동적 테이블이 업스트림 파이프라인에 영향을 미치거나 상속해서는 안 되는 팀 간 파이프라인.

• 업스트림 파이프라인 단계를 동적 테이블로 변환하지만 다운스트림 컨슈머가 새로 고침 조정을 시작하지 않도록 하려는 증분 마이그레이션.

• 동적 테이블이 다른 동적 테이블을 쿼리하는 뷰에서 읽는 Dynamic-table-on-view-on-dynamic-table 패턴. 이 패턴은 뷰가 DYNAMIC_TABLE_REFRESH_BOUNDARY() 로 래핑되지 않는 한 지원되지 않습니다.

새로 고침 경계는 이러한 구분을 명시적으로 만듭니다. 경계 내부의 입력은 별도의 파이프라인에 속한 것으로 처리되고 일반 테이블처럼 읽습니다.

구문¶

DYNAMIC_TABLE_REFRESH_BOUNDARY( <object_name> )

여기서

object_name

테이블, 뷰, 동적 테이블 또는 공통 테이블 식(CTE) 이름입니다.

동적 테이블 정의의 FROM/JOIN 절(CTEs 및 UNION 분기 내 포함)에 이 키워드를 사용합니다.

예¶

다음 예제에서는 다른 동적 테이블을 쿼리하는 뷰에서 입력을 읽어옵니다. 새로 고침 경계가 없는 경우 다른 동적 테이블의 뷰에서 읽어오는 동적 테이블 생성은 지원되지 않습니다. DYNAMIC_TABLE_REFRESH_BOUNDARY() 로 뷰를 래핑하면 이 패턴이 가능해집니다.

CREATE DYNAMIC TABLE analytics.click_analytics_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT *
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(analytics.enriched_clicks_view);

다음 예제에서는 더 긴 일정으로 업스트림 동적 테이블을 새로 고치는 뷰와 직접 참조된 동적 테이블을 조인합니다. DYNAMIC_TABLE_REFRESH_BOUNDARY() 로 뷰를 래핑하면 다운스트림 동적 테이블이 5분마다 비용이 많이 드는 업스트림 새로 고침을 트리거하는 것을 방지하면서 사용 가능한 최신 버전을 읽을 수 있도록 허용합니다. 스냅샷 격리는 새로 고침 경계를 넘어서 보장되지 않습니다.

CREATE DYNAMIC TABLE data_eng.enriched_clicks_dt
  WAREHOUSE = de_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM data_eng.clickstream_dt AS c
LEFT JOIN DYNAMIC_TABLE_REFRESH_BOUNDARY(product_db.active_products_view) AS p
  ON c.product_id = p.product_id;

동작¶

사용 사례¶

CREATE VIEW v_orders AS
SELECT *
FROM orders_dt;

CREATE DYNAMIC TABLE order_summary_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '15 minutes'
AS
SELECT
  customer_id,
  COUNT(*) AS num_orders
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(v_orders)
GROUP BY customer_id;

-- Team A: owns product_catalog_dt and publishes a boundary view
CREATE DYNAMIC TABLE product.product_catalog_dt
  WAREHOUSE = product_wh
  TARGET_LAG = '1 hour'
AS
SELECT *
FROM product.raw_products;

CREATE VIEW product.active_products_public_v AS
SELECT * FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(product.product_catalog_dt)
WHERE is_active = TRUE;

-- Team B: consumes Team A's view in their own dynamic table
CREATE DYNAMIC TABLE analytics.active_product_clicks_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM analytics.clickstream_dt AS c
JOIN product.active_products_public_v AS p
  ON c.product_id = p.product_id;

목표 지연¶

새로 고침 경계는 목표 지연이 적용되는 방식에도 영향을 미칩니다.

업스트림 동적 테이블의 목표 지연은 동일한 파이프라인 내의 모든 다운스트림 동적 테이블의 목표 지연과 동일하거나 더 짧아야 합니다. DYNAMIC_TABLE_REFRESH_BOUNDARY() 를 통해 참조되는 동적 테이블은 동일한 파이프라인에 속하지 않으므로 이 규칙은 경계 전체에 적용되지 않습니다.

새로 고침 경계 내의 업스트림 동적 테이블은 자체 목표 지연 및 일정 동작을 유지하며, 경계를 넘어서는 다운스트림 선택에 의해 강화되거나 완화되지 않습니다.

제약 및 제한 사항¶

새로 고침 경계에는 몇 가지 중요한 규칙이 적용됩니다.

새로 고침 경계 내부와 외부 모두에서 동일한 동적 테이블은 허용되지 않음

단일 정의 내의 동일한 업스트림 동적 테이블에 대한 모든 참조는 정의에 직접 포함되거나 DYNAMIC_TABLE_REFRESH_BOUNDARY() 로 래핑되어야 합니다. 둘 다 혼합하면 동일한 동적 테이블을 다른 버전에서 읽을 수 있습니다. Snowflake는 이러한 정의를 차단하고 설명이 포함된 오류를 반환합니다.

지원되지 않는 경계 대상

DYNAMIC_TABLE_REFRESH_BOUNDARY() 는 명명된 오브젝트(테이블, 뷰, 동적 테이블 또는 CTE )를 래핑해야 합니다. 다음은 래핑할 수 없습니다.

• 인라인 하위 쿼리.

• 테이블 함수 또는 UDTFs.

• 임의의 TABLE(...) 호출.

동적 테이블 외부의 효과

일반 SELECT 쿼리에서 DYNAMIC_TABLE_REFRESH_BOUNDARY() 를 호출할 수 있지만, 동적 테이블 정의 외부에서는 작업이 수행되지 않습니다.

모범 사례¶

동적 테이블 파이프라인에서 새로 고침 경계를 사용하는 경우:

다음과 같은 경우 새로 고침 경계 사용:

• 파이프라인에 조인하지 않고 다른 팀의 동적 테이블을 사용하려고 합니다.

• 특정 업스트림 종속성에서 스냅샷을 격리할 필요가 없습니다.

• 동적 테이블이 다른 동적 테이블을 참조하는 뷰에 종속됩니다. 이 패턴은 뷰 또는 업스트림 동적 테이블이 DYNAMIC_TABLE_REFRESH_BOUNDARY() 로 래핑된 경우에만 지원됩니다.

다음과 같은 경우 새로 고침 경계 사용 안 함:

• 해당 종속성에 대한 스냅샷 격리가 필요합니다.

• 다운스트림 새로 고침을 업스트림 동적 테이블과 연동하고 필요한 경우 연속 새로 고침을 수행하려고 합니다.

• 전체 파이프라인에서 전역 목표 지연 관계를 사용합니다.