동적 테이블 새로 고침 이해하기

동적 테이블 콘텐츠는 특정 쿼리의 결과를 기반으로 합니다. 동적 테이블의 기반이 되는 기본 데이터가 변경되면 해당 변경 사항을 반영하도록 테이블이 업데이트됩니다. 이러한 업데이트를 새로 고침 이라고 합니다. 이 프로세스는 자동화되어 있으며 테이블의 기반이 되는 쿼리를 분석하는 작업을 포함합니다. 다음 섹션에서는 동적 테이블을 새로 고치는 방식과 동적 테이블에 대한 SELECT 문으로 사용되는 새로 고침 유형을 결정하는 방법을 설명합니다.

동적 테이블 초기화

CREATE DYNAMIC TABLE 문을 사용하여 동적 테이블을 생성하면 처음에는 기본 테이블의 데이터를 사용하여 동적 테이블이 채워집니다. 생성 후, 동적 테이블은 다운스트림 지연이 있는 동적 테이블을 포함하여 전체 새로 고침을 거칩니다. 새로 고침으로 스냅샷 격리가 보장되고, 관련된 모든 동적 테이블이 동기화되며, 업스트림 동적 테이블에 대한 데이터 없는 새로 고침으로 비용이 절감됩니다.

이 초기 새로 고침은 특히 광범위한 데이터 검사가 필요한 경우 다소 시간이 걸릴 수 있으며, 동적 테이블 생성 기간은 검사한 데이터의 크기에 따라 다릅니다. 진행 상황을 추적하려면 information_schema.dynamic_table_refresh_history() 를 사용하여 새로 고침 기록을 쿼리하고 refresh_trigger = INITIAL 이 포함된 항목을 찾으십시오.

초기화에 실패하면 테이블 생성 프로세스가 중지되고 잘못된 정의에 대한 즉각적인 피드백이 제공됩니다. 기존 동적 테이블의 새 버전을 초기화하는 동안 새 버전이 제공될 때까지 기존 버전에 계속 액세스할 수 있으므로 새 버전을 만들지 못해도 현재 인스턴스에 영향을 미치지 않습니다.

동적 테이블 새로 고침 유형

동적 테이블 새로 고침 프로세스는 다음 두 가지 방식 중 하나로 작동합니다.

  1. 증분 새로 고침: 이 자동화된 프로세스에서는 동적 테이블의 쿼리를 분석하고 마지막 새로 고침 이후의 변경 사항을 계산합니다. 그런 다음 이러한 변경 사항을 테이블에 병합합니다. 지원되는 쿼리에 대한 자세한 내용은 증분 새로 고침을 지원하는 쿼리 유형 섹션을 참조하십시오.

  2. 전체 새로 고침: 자동화된 프로세스가 증분 새로 고침을 수행할 수 없는 경우 전체 새로 고침을 수행합니다. 여기에는 동적 테이블에 대한 쿼리를 실행하고 이전에 구체화된 결과를 완전히 바꾸는 작업이 포함됩니다.

쿼리에 사용된 구문에 따라 증분 새로 고침을 사용할 수 있는지 결정됩니다. 동적 테이블을 만든 후 테이블을 모니터링 하여 증분 또는 전체 새로 고침이 해당 테이블을 업데이트하는 데 사용되는지 여부를 결정할 수 있습니다.

목표 지연 이해하기

동적 테이블 새로 고침은 데이터가 얼마나 오래되었는지 또는 일반적으로 지연 또는 목표 지연 이라고 부르는 것에 따라 트리거됩니다.

목표 지연은 다음 두 가지 방법 중 하나로 지정됩니다.

  1. 최신성 척도: 동적 테이블의 콘텐츠가 기본 테이블에 대한 업데이트보다 지연되어야 하는 최대 시간을 정의합니다.

    동적 테이블을 변경하거나 처음 정의할 때 TARGET_LAG = { num { seconds | ... | days } 매개 변수를 사용하여 지정됩니다.

  2. DOWNSTREAM: 이 동적 테이블에 따라 다른 동적 테이블을 새로 고쳐야 할 때 동적 테이블을 온디맨드 방식으로 새로 고쳐야 함을 지정합니다. 업데이트는 업스트림 데이터베이스 오브젝트에서 유추됩니다. 다운스트림 동적 테이블은 업스트림 컨슈머가 요구할 때만 업데이트됩니다.

동적 테이블 1(DT1)을 기반으로 동적 테이블 2(DT2)를 정의하는 다음 예를 살펴보십시오. DT2는 DT1에서 읽어 그 내용을 구체화해야 합니다. 또한 보고서는 쿼리를 통해 DT2 데이터를 사용합니다.

Simple example of two dynamic tables, DT2 which is defined based on DT1.

각각의 동적 테이블이 지연을 지정하는 방식에 따라 다음 결과가 가능합니다.

DT1(동적 테이블 1)

DT2(동적 테이블 2)

새로 고침 결과

TARGET_LAG = DOWNSTREAM

TARGET_LAG = 10minutes

DT2는 최대 10분마다 업데이트됩니다. DT1은 DT2에서 지연을 얻거나 유추 하고 DT2에 업데이트가 필요할 때마다 업데이트됩니다.

TARGET_LAG = 10minutes

TARGET_LAG = DOWNSTREAM

이런 상황을 방지해야 합니다. 보고서 쿼리는 어떤 데이터도 수신하지 않습니다. DT2 위에 빌드된 DT가 없으므로 DT2가 새로 고쳐지지 않습니다. 더욱이, DT1은 자주 새로 고쳐집니다.

TARGET_LAG = 5minutes

TARGET_LAG = 10minutes

DT2는 약 10분마다 DT1에서 길어야 5분 이내의 최신 데이터로 업데이트됩니다.

TARGET_LAG = DOWNSTREAM

TARGET_LAG = DOWNSTREAM

DT1은 지연이 정의된 다운스트림 하위 항목이 없으므로 DT2가 주기적으로 새로 고쳐지지 않습니다.

증분 새로 고침을 지원하는 쿼리 유형

다음 표에는 현재 증분 새로 고침을 지원하는 식, 키워드, 절에 대해 설명되어 있습니다.

참고

쿼리에서 증분 새로 고침에 지원되지 않는 식을 사용하는 경우 자동 새로 고침 프로세스는 전체 새로 고침을 대신 사용합니다. 사용되는 새로 고침 모드를 확인하려면 증분 또는 전체 새로 고침이 사용되는지 확인하기 섹션을 참조하십시오.

키워드/절

증분 새로 고침 지원

WITH

하위 쿼리에서 증분 새로 고침 지원 기능을 사용하는 CTE(공통 테이블 식).

SELECT의 식

결정적 기본 제공 함수 및 변경이 불가능한 사용자 정의 함수 를 사용하는 식을 포함한 식.

FROM

원본 테이블, 뷰, 기타 동적 테이블.

OVER

모든 윈도우 함수.

WHERE

SELECT에서 유효한 동일한 식이 있는 필터.

JOIN(그리고 테이블 조인을 위한 다른 식)

동적 테이블은 현재 증분 새로 고침을 위한 내부 조인, 외부 조인, 교차 조인만 지원합니다.

참고

증분 새로 고침을 사용하려면 다른 유형의 조인을 사용하는 동적 테이블을 다시 만들어야 합니다.

동적 테이블을 다시 만들어야 할지 결정하려면 다음 프로시저 중 하나를 사용하여 동적 테이블이 전체 새로 고침을 사용하는지 확인 하십시오.

조인에 테이블을 원하는 수만큼 지정할 수 있습니다.

조인의 모든 테이블에 대한 업데이트는 쿼리 결과에 반영됩니다.

UNION ALL

동적 테이블이 UNION ALL을 지원합니다.

GROUP BY

동적 테이블이 GROUP BY를 지원합니다.

중요

증분 새로 고침에서 변경이 불가능한 UDF를 사용 중인 동안 이를 바꾸면 UDF를 사용하는 동적 테이블에서 정의되지 않은 동작이 발생합니다.

현재, 다음 구문과 쿼리 유형은 증분 새로 고침에서 지원되지 않습니다. 쿼리에서 이들을 지정하면 자동 새로 고침 프로세스에서 (더 높은 비용이 발생할 수 있는) 전체 새로 고침 을 사용하여 테이블을 업데이트합니다.

  • LATERAL 조인

  • FROM 절 외부의 하위 쿼리(예: WHERE EXISTS)

  • VOLATILE 사용자 정의 함수

동적 테이블이 다른 동적 테이블에 종속될 때 데이터를 새로 고치는 방법

동적 테이블 지연이 시간 척도로 지정된 경우 자동 새로 고침 프로세스에서는 동적 테이블의 목표 지연 시간을 기준으로 새로 고침 일정을 결정합니다. 이 프로세스에서는 테이블의 목표 지연 시간에 가장 적합한 일정을 선택합니다.

참고

목표 지연이 보장되는 것은 아닙니다. 다만, Snowflake가 달성하려는 목표입니다. 동적 테이블의 데이터는 목표 지연 내에서 최대한 가깝게 새로 고쳐집니다. 하지만 웨어하우스 크기, 데이터 크기, 쿼리 복잡성 및 이와 유사한 요인과 같은 요인으로 인해 목표 지연이 초과될 수 있습니다.

한 동적 테이블이 다른 동적 테이블에 종속된 경우에 데이터 일관성을 유지하기 위해, 프로세스에서는 호환 가능한 시간에 계정의 모든 동적 테이블을 새로 고칩니다. 덜 자주 새로 고치는 타이밍이 더 자주 새로 고치는 타이밍과 일치합니다.

예를 들어 동적 테이블 A는 목표 지연 시간이 2분이고 목표 지연 시간이 1분인 동적 테이블 B를 쿼리한다고 가정합니다. 이 프로세스에서는 A를 96초마다, B를 48초마다 새로 고쳐야 한다고 결정할 수 있습니다. 결과적으로, 프로세스에서 다음 일정을 적용할 수 있습니다.

특정 시점

새로 고친 동적 테이블

2022-12-01 00:00:00

A, B

2022-12-01 00:00:48

B

2022-12-01 00:01:36

A, B

2022-12-01 00:02:24

B

이는 주어진 시간에 서로 종속된 일련의 동적 테이블을 쿼리할 때 이들 테이블 전체에서 데이터의 동일한 《스냅샷》을 쿼리하고 있다는 의미입니다.

동적 테이블의 목표 지연 시간은 이 테이블이 종속된 동적 테이블의 목표 지연 시간보다 짧을 수 없습니다. 예를 들어 다음과 같이 가정합니다.

  • 동적 테이블 A는 동적 테이블 B와 C를 쿼리합니다.

  • 동적 테이블 B의 목표 지연 시간은 5분입니다.

  • 동적 테이블 C의 목표 지연 시간은 1분입니다.

이는 A의 목표 지연 시간이 5분보다 짧으면 안 된다는 뜻입니다(즉, B와 C의 지연 시간 중 더 긴 시간보다 짧지 않아야 함).

A에 대한 지연을 5분으로 설정하면 프로세스에서 이러한 다음과 같은 목표로 새로 고침 일정을 설정합니다.

  • 지연 시간이 1분 미만으로 유지하기에 충분할 만큼 자주 C를 새로 고칩니다.

  • A와 B를 함께, 그리고 지연 시간을 5분 미만으로 유지하기에 충분할 만큼 자주 새로 고칩니다.

  • 스냅샷 격리를 보장하기 위해 A와 B의 새로 고침이 C의 새로 고침과 일치하도록 합니다.

참고: 새로 고침이 너무 오래 걸리면 스케줄러가 최신 상태를 유지하려고 새로 고침을 건너뛸 수도 있습니다. 하지만 스냅샷 격리는 유지됩니다.