동적 테이블 초기화 및 새로 고침 이해¶

동적 테이블 초기화 이해하기¶

동적 테이블 을 생성하면 초기 새로 고침이 생성 시 또는 예약된 시간에 동기적으로 수행됩니다. 초기 데이터 채우기 또는 초기화 는 이 초기 새로 고침이 발생하는 시기에 따라 달라집니다.

동적 테이블은 기본 테이블 업데이트와 동적 테이블의 내용 간에 허용되는 최대 지연을 설정하는 지정된 목표 지연 을 기준으로 새로 고쳐집니다. INITIALIZE = ON_CREATE (기본값)으로 설정하면 테이블이 즉시 초기화됩니다. INITIALIZE = ON_SCHEDULE 로 설정하면 지정된 목표 지연 시간 내에 초기화가 수행됩니다.

예를 들어, 목표 지연이 30분인 동적 테이블 DT1 을 예로 들어 보겠습니다. DT1 의 초기 데이터 채우기는 다음과 같이 발생할 수 있습니다.

• DT1 이 생성 시 동기적으로 새로 고침되도록 설정된 경우(ON_CREATE), 해당 항목은 생성 시 초기화됩니다.

• DT1 이 예약된 시간(ON_SCHEDULE)에 새로 고침되도록 설정된 경우 30분 이내에 초기화됩니다.

다운스트림 종속성이 있는 시나리오에서 새로 고침 동작은 종속성에 따라 달라집니다. 예를 들어, 동적 테이블 DT1 에 다운스트림 목표 지연이 있고 DT1 에 종속된 DT2 의 목표 지연이 30분인 경우 DT1 은 DT2 가 새로 고쳐질 때만 새로 고쳐집니다.

DT1 의 경우:

• 생성 시 동기식으로 새로 고침하도록 설정하면 즉시 초기화됩니다. 초기화에 실패하면 생성 프로세스가 중지되어 오류에 대한 즉각적인 피드백이 제공됩니다.

• 예약된 시간에 새로 고침하도록 설정된 경우 초기화는 DT2 새로 고침 시점에 따라 달라집니다.

검색되는 데이터의 양에 따라 초기화하는 데 다소 시간이 걸릴 수 있습니다. 진행 상황을 추적하려면 동적 테이블 생성 문제 해결 섹션을 참조하십시오.

수동 및 예약 새로 고침 옵션 이해하기¶

동적 테이블은 목표 지연 에 의해 결정된 예약에 따라 새로 고쳐집니다. 동적 테이블을 읽을 때마다 데이터 새로 고침은 목표 지연으로 정의된 기간 내에 수행됩니다.

ALTER DYNAMIC TABLE … REFRESH 명령 또는 Snowsight 를 사용하여 동적 테이블을 수동으로 새로 고쳐 최신 데이터를 가져올 수 있습니다. 자세한 내용은 동적 테이블 수동 새로 고침 섹션을 참조하십시오.

동적 테이블 새로 고침 시간 제한은 새로 고침이 자동으로 취소되기 전에 계정 또는 웨어하우스 수준에서 허용되는 최대 기간을 설정하는 STATEMENT_TIMEOUT_IN_SECONDS 매개 변수에 의해 제어됩니다.

CREATE TASK my_task
  SCHEDULE = 'USING CRON <expr> <time_zone>'
  AS
    ALTER DYNAMIC TABLE my_dynamic_table REFRESH;

동적 테이블 새로 고침 모드¶

동적 테이블은 증분 및 전체 새로 고침의 두 가지 새로 고침 모드를 지원합니다. 새로 고침 모드를 AUTO 로 설정하거나 명시적으로 설정할 수 있습니다.

• AUTO 새로 고침 모드: AUTO 매개 변수를 사용하면 Snowflake는 쿼리 복잡성, 지원되는 구조체, 연산자, 함수 및 예상 성능을 기준으로 가장 비용 및 시간 효율이 높은 새로 고침 모드를 자동으로 선택합니다. 증분 새로 고침이 지원되지 않거나 성능이 저하될 가능성이 있는 경우 Snowflake는 대신 전체 새로 고침을 자동으로 선택합니다.

• 증분 새로 고침 모드: 이 모드는 동적 테이블의 쿼리를 분석하여 마지막 새로 고침 이후의 변경 사항을 계산합니다. 그런 다음 이러한 변경 사항을 테이블에 병합합니다.

• 전체 새로 고침 모드: 이 모드는 동적 테이블의 쿼리를 실행하고 이전에 구체화된 결과를 완전히 대체합니다.

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

SHOW DYNAMIC TABLES;

동적 테이블이 다른 동적 테이블에 종속된 경우 데이터가 새로 고쳐지는 방법¶

동적 테이블의 지연을 시간 측정값으로 설정하면 자동 새로 고침 프로세스가 목표 지연 시간을 가장 잘 충족하도록 새로 고침을 예약합니다.

한 동적 테이블이 다른 동적 테이블에 종속된 경우에 데이터 일관성을 유지하기 위해, 프로세스에서는 호환 가능한 시간에 계정의 모든 동적 테이블을 새로 고칩니다. 덜 자주 새로 고치는 타이밍이 더 자주 새로 고치는 타이밍과 일치합니다. 새로 고침이 너무 오래 걸리면 스케줄러가 최신 상태를 유지하기 위해 새로 고침을 건너뛸 수 있습니다. 하지만 스냅샷 격리는 유지됩니다.

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

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

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

• DT1 은 동적 테이블 DT2 및 DT3 를 쿼리합니다.

• DT2 의 목표 지연 시간은 5분입니다.

• DT3 의 목표 지연 시간은 1분입니다.

즉, DT1 의 목표 지연 시간은 5분보다 짧아서는 안 됩니다(즉, DT2 및 DT3 의 지연 시간 중 더 긴 시간보다 짧아서는 안 됩니다).

DT1 의 지연을 5분으로 설정하면 프로세스에서 이러한 목표에 따라 새로 고침 예약을 설정합니다.

• DT3 를 자주 새로 고쳐 지연 시간을 1분 미만으로 유지하십시오.

• DT1 및 DT2 를 함께 새로고침하고 지연 시간을 5분 미만으로 유지할 수 있을 만큼 자주 새로 고치십시오.

• DT1 및 DT2 의 새로 고침이 DT3 의 새로 고침과 일치하는지 확인하여 스냅샷 격리를 보장합니다.

기본 테이블의 열 변경 사항의 영향 이해하기¶

동적 테이블과 연결된 기본 오브젝트가 변경되면 다음 동작이 적용됩니다.

동적 테이블 새로 고침의 모범 사례¶