동적 테이블 새로 고침 이해하기¶
동적 테이블 콘텐츠는 특정 쿼리의 결과를 기반으로 합니다. 동적 테이블의 기반이 되는 기본 데이터가 변경되면 해당 변경 사항을 반영하도록 테이블이 업데이트됩니다. 이러한 업데이트를 새로 고침 이라고 합니다. 이 프로세스는 자동화되어 있으며 테이블의 기반이 되는 쿼리를 분석하는 작업을 포함합니다.
동적 테이블 새로 고침 시간 초과는 STATEMENT_TIMEOUT_IN_SECONDS 매개 변수에 의해 결정되며 자동으로 취소되기 전 계정 또는 웨어하우스의 최대 기간을 정의합니다.
다음 섹션에서는 동적 테이블 새로 고침을 더 자세히 설명합니다.
동적 테이블 새로 고침 유형¶
동적 테이블 새로 고침 프로세스는 다음 두 가지 방식 중 하나로 작동합니다.
증분 새로 고침: 이 자동화된 프로세스에서는 동적 테이블의 쿼리를 분석하고 마지막 새로 고침 이후의 변경 사항을 계산합니다. 그런 다음 이러한 변경 사항을 테이블에 병합합니다. 지원되는 쿼리에 대한 자세한 내용은 증분 새로 고침에서 지원되는 쿼리 섹션을 참조하십시오.
전체 새로 고침: 자동화된 프로세스가 증분 새로 고침을 수행할 수 없는 경우 전체 새로 고침을 수행합니다. 여기에는 동적 테이블에 대한 쿼리를 실행하고 이전에 구체화된 결과를 완전히 바꾸는 작업이 포함됩니다.
쿼리에 사용된 구문에 따라 증분 새로 고침을 사용할 수 있는지 결정됩니다. 동적 테이블을 만든 후 테이블을 모니터링 하여 증분 또는 전체 새로 고침이 해당 테이블을 업데이트하는 데 사용되는지 여부를 결정할 수 있습니다.
목표 지연 이해하기¶
동적 테이블 새로 고침은 데이터가 얼마나 오래되었는지 또는 일반적으로 지연 또는 목표 지연 이라고 부르는 것에 따라 트리거됩니다.
목표 지연은 다음 두 가지 방법 중 하나로 지정됩니다.
최신성 척도: 동적 테이블의 콘텐츠가 기본 테이블에 대한 업데이트보다 지연되어야 하는 최대 시간을 정의합니다.
동적 테이블을 변경하거나 처음 정의할 때
TARGET_LAG = { num { seconds | ... | days }매개 변수를 사용하여 지정됩니다.DOWNSTREAM: 이 동적 테이블에 따라 다른 동적 테이블을 새로 고쳐야 할 때 동적 테이블을 온디맨드 방식으로 새로 고쳐야 함을 지정합니다. 업데이트는 업스트림 데이터베이스 오브젝트에서 유추됩니다. 다운스트림 동적 테이블은 업스트림 컨슈머가 요구할 때만 업데이트됩니다.
동적 테이블 1(DT1)을 기반으로 동적 테이블 2(DT2)를 정의하는 다음 예를 살펴보십시오. DT2는 DT1에서 읽어 그 내용을 구체화해야 합니다. 또한 보고서는 쿼리를 통해 DT2 데이터를 사용합니다.
각각의 동적 테이블이 지연을 지정하는 방식에 따라 다음 결과가 가능합니다.
DT1(동적 테이블 1) |
DT2(동적 테이블 2) |
새로 고침 결과 |
|---|---|---|
|
|
DT2는 최대 10분마다 업데이트됩니다. DT1은 DT2에서 지연을 얻거나 유추 하고 DT2에 업데이트가 필요할 때마다 업데이트됩니다. |
|
|
이런 상황을 방지해야 합니다. 보고서 쿼리는 어떤 데이터도 수신하지 않습니다. DT2 위에 빌드된 DT가 없으므로 DT2가 새로 고쳐지지 않습니다. 더욱이, DT1은 자주 새로 고쳐집니다. |
|
|
DT2는 약 10분마다 DT1에서 길어야 5분 이내의 최신 데이터로 업데이트됩니다. |
|
|
DT1은 지연이 정의된 다운스트림 하위 항목이 없으므로 DT2가 주기적으로 새로 고쳐지지 않습니다. |
증분 새로 고침에서 지원되는 쿼리¶
다음 표에는 현재 증분 새로 고침을 지원하는 식, 키워드, 절에 대해 설명되어 있습니다. 증분 새로 고침을 지원하지 않는 쿼리 목록은 증분 새로 고침 지원 제한 사항 을 참조하십시오.
키워드/절 |
증분 새로 고침 지원 |
|---|---|
WITH |
하위 쿼리에서 증분 새로 고침 지원 기능을 사용하는 CTE(공통 테이블 식). |
SELECT의 식 |
|
FROM |
원본 테이블, 뷰, 기타 동적 테이블. FROM 절 외부의 하위 쿼리(예: WHERE EXISTS)는 지원되지 않습니다. |
OVER |
모든 윈도우 함수. |
WHERE/HAVING/QUALIFY |
SELECT에서 유효한 동일한 식이 있는 필터. |
JOIN(그리고 테이블 조인을 위한 다른 식) |
증분 새로 고침에 지원되는 조인 유형에는 내부 조인, 외부 동등 조인, 교차 조인이 포함됩니다. 조인에서 원하는 수의 테이블을 지정할 수 있으며 조인의 모든 테이블에 대한 업데이트는 쿼리 결과에 반영됩니다. |
UNION ALL |
동적 테이블이 UNION ALL을 지원합니다. |
GROUP BY |
동적 테이블이 GROUP BY를 지원합니다. |
중요
쿼리에서 증분 새로 고침에 지원되지 않는 식을 사용하는 경우 자동 새로 고침 프로세스는 전체 새로 고침을 사용하며 그에 따른 비용이 추가로 발생할 수 있습니다. 사용되는 새로 고침 모드를 확인하려면 증분 또는 전체 새로 고침이 사용되는지 확인하기 섹션을 참조하십시오.
증분 새로 고침을 사용하는 동적 테이블에서 사용 중인 IMMUTABLE 사용자 정의 함수(UDF)를 바꾸면 해당 테이블에서 정의되지 않은 동작이 발생합니다. VOLATILE UDF는 증분 새로 고침에서는 지원되지 않습니다.
전체 새로 고침에서 지원되는 비결정 함수¶
다음의 비결정적 함수가 동적 테이블에서 지원됩니다. 이러한 함수은 전체 새로 고침에만 지원됩니다. 증분 새로 고침이 지원되지 않는 목록은 증분 새로 고침 지원 제한 사항 을 참조하십시오.
동적 테이블이 다른 동적 테이블에 종속될 때 데이터를 새로 고치는 방법¶
동적 테이블 지연이 시간 척도로 지정된 경우 자동 새로 고침 프로세스에서는 동적 테이블의 목표 지연 시간을 기준으로 새로 고침 일정을 결정합니다. 이 프로세스에서는 테이블의 목표 지연 시간에 가장 적합한 일정을 선택합니다.
참고
목표 지연이 보장되는 것은 아닙니다. 다만, 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의 새로 고침과 일치하도록 합니다.
참고: 새로 고침이 너무 오래 걸리면 스케줄러가 최신 상태를 유지하려고 새로 고침을 건너뛸 수도 있습니다. 하지만 스냅샷 격리는 유지됩니다.