동적 테이블에 대한 모범 사례¶

메타데이터 보기에 MONITOR 권한 사용¶

사용자가 동적 테이블의 메타데이터 및 Information Schema만 확인하면 되는 시나리오(예: 데이터 과학자가 보유한 역할)의 경우 해당 동적 테이블에 MONITOR 권한이 있는 역할을 사용합니다. OPERATE 권한은 이 액세스 권한을 부여하지만 동적 테이블을 변경하는 기능도 포함하므로 MONITOR가 사용자가 동적 테이블을 변경할 필요가 없는 시나리오에 더 적합한 옵션이 됩니다.

자세한 내용은 동적 테이블 액세스 제어 섹션을 참조하십시오.

그룹화 키의 복합 식 단순화¶

그룹화 키에 기본 열이 아닌 복합 식이 포함된 경우, 하나의 동적 테이블에서 식을 구체화한 다음 다른 동적 테이블의 구체화된 열에 그룹화 작업을 적용합니다. 자세한 내용은 연산자의 증분 새로 고침 방법 섹션을 참조하십시오.

동적 테이블을 사용하여 느리게 변경되는 차원을 구현합니다.¶

동적 테이블을 사용하여 느리게 변경되는 유형 1 및 2 차원(SCDs)을 구현할 수 있습니다. 변경 스트림에서 읽을 때 변경 타임스탬프에 따라 정렬된 레코드별 키에 대해 윈도우 함수를 사용합니다. 이 방법을 사용하면 동적 테이블은 순서에 맞지 않게 발생하는 삽입, 삭제 및 업데이트를 원활하게 처리하여 SCD 만들기를 간소화합니다. 자세한 내용은 동적 테이블을 사용하여 느리게 변경되는 차원 섹션을 참조하십시오.

동적 테이블의 파이프라인 연결¶

새로운 동적 테이블을 정의할 때는 많은 중첩된 명령이 있는 대규모 동적 테이블을 정의하는 대신 파이프라인이 있는 작은 동적 테이블을 사용합니다.

다른 동적 테이블을 쿼리하도록 동적 테이블을 설정할 수 있습니다. 예를 들어, 데이터 파이프라인이 스테이징 테이블에서 데이터를 추출하여 다양한 차원 테이블(예: 고객, 제품, 날짜 및 시간)을 업데이트하는 상황을 생각해 보겠습니다. 또한, 파이프라인은 이러한 차원 테이블의 정보를 기반으로 집계 판매 테이블을 업데이트합니다. 차원 테이블이 스테이징 테이블을 쿼리하도록 구성하고 집계 판매 테이블이 차원 테이블을 쿼리하도록 구성하면 작업 그래프와 유사한 캐스케이드 효과를 만들 수 있습니다.

이 설정에서 집계 매출 테이블에 대한 새로 고침은 차원 테이블에 대한 새로 고침이 성공적으로 완료된 후에만 실행됩니다. 이를 통해 데이터 일관성을 보장하고 지연 목표를 충족할 수 있습니다. 자동화된 새로 고침 프로세스를 통해 원본 테이블의 모든 변경 사항은 적절한 시간에 모든 종속 테이블에서 새로 고침을 트리거합니다.

복잡한 작업 그래프에 “컨트롤러” 동적 테이블 사용¶

많은 루트와 리프가 있는 동적 테이블의 복잡한 그래프가 있고 단일 명령으로 전체 작업 그래프에서 작업(예: 지연 변경, 수동 새로 고침, 일시 중단)을 수행하려면 다음을 수행합니다.

1. 모든 동적 테이블의 TARGET_LAG 값을 DOWNSTREAM 으로 설정합니다.

2. 작업 그래프의 모든 리프에서 읽는 “컨트롤러” 동적 테이블을 만듭니다. 이 컨트롤러가 리소스를 소모하지 않도록 하려면 다음을 수행합니다.

   CREATE DYNAMIC TABLE controller
     TARGET_LAG = <target_lag>
     WAREHOUSE = <warehouse>
     AS
       SELECT 1 A FROM <leaf1>, …, <leafN> LIMIT 0;
   

   Copy

3. 컨트롤러를 사용하여 전체 그래프를 제어합니다. 예:

• 작업 그래프에 대한 새로운 목표 지연을 설정합니다.

  ALTER DYNAMIC TABLE controller SET
    TARGET_LAG = <new_target_lag>
  

  Copy

• 작업 그래프를 수동으로 새로 고칩니다.

  ALTER DYNAMIC TABLE controller REFRESH
  

  Copy

동적 테이블의 파이프라인 복제 정보¶

파이프라인을 다시 초기화하지 않으려면 동일한 복제 명령으로 동적 테이블 파이프라인의 모든 요소를 복제합니다. 파이프라인의 모든 요소(예: 기본 테이블, 뷰, 동적 테이블)를 동일한 스키마 또는 데이터베이스에 통합하여 이를 수행할 수 있습니다. 자세한 내용은 동적 테이블의 알려진 제한 사항 섹션을 참조하십시오.

일시적 동적 테이블을 사용하여 저장소 비용 절감¶

일시적 동적 테이블은 시간이 지나도 데이터를 안정적으로 유지하고 데이터 보존 기간 내에서 Time Travel을 지원하지만, Fail-safe 기간 이후에는 데이터를 보존하지 않습니다. 기본적으로 동적 테이블 데이터는 fail-safe 저장소에 7일 동안 보관됩니다. 새로 고침 처리량이 높은 동적 테이블의 경우 저장소 사용량이 크게 늘어날 수 있습니다. 따라서 동적 테이블은 영구 테이블에서 제공하는 것과 동일한 수준의 데이터 보호 및 복구가 필요하지 않은 경우에만 일시적 테이블로 설정해야 합니다.

CREATE DYNAMIC TABLE 문을 사용하여 일시적 동적 테이블을 만들거나 기존 동적 테이블을 일시적 동적 테이블로 복제할 수 있습니다.

새로 고침을 위한 전용 웨어하우스 사용¶

동적 테이블에는 새로 고침을 수행하기 위해 가상 웨어하우스가 필요합니다. 동적 테이블 파이프라인과 관련된 비용을 명확하게 파악하려면 전용 웨어하우스를 사용하여 동적 테이블에 특화된 가상 웨어하우스 사용량을 격리하도록 동적 테이블을 테스트해야 합니다. 자세한 내용은 동적 테이블의 비용 이해하기 섹션을 참조하십시오.

다운스트림 지연 사용¶

다운스트림 지연은 다른 종속 동적 테이블을 새로 고쳐야 할 때 동적 테이블도 새로 고쳐야 함을 나타냅니다. 다운스트림 지연은 사용 편의성과 비용 효율성 측면에서 모범 사례로 사용하는 것이 좋습니다. 다운스트림 지연을 사용하지 않는 경우, 복잡한 동적 테이블 체인을 관리하려면 최종 테이블의 데이터 최신성만 모니터링하는 대신 각 테이블에 개별적으로 목표 지연을 할당하고 관련 제약 조건을 관리해야 합니다. 자세한 내용은 목표 지연 이해하기 섹션을 참조하십시오.

모든 프로덕션 동적 테이블에 대한 새로 고침 모드 설정¶

동적 테이블의 실제 새로 고침 모드 는 생성 시점에 결정되며 이후에는 변경할 수 없습니다. 명시적으로 지정하지 않으면 새로 고침 모드는 쿼리 복잡성, 지원되지 않는 구조체, 연산자 또는 함수 등 다양한 요소에 따라 새로 고침 모드를 선택하는 AUTO 가 기본값으로 설정됩니다.

사용 사례에 가장 적합한 모드를 결정하려면 새로 고침 모드와 자동 권장 사항을 실험해 보십시오. Snowflake 릴리스 전반에서 일관적인 동작을 유지하려면 모든 프로덕션 테이블에서 새로 고침 모드를 명시적으로 설정해야 합니다. AUTO 의 동작은 Snowflake 릴리스 간에 변경될 수 있으며, 프로덕션 파이프라인에서 사용할 경우 예기치 않은 성능 변경이 발생할 수 있습니다.

동적 테이블의 새로 고침 모드를 확인하려면 동적 테이블 새로 고침 모드 보기 섹션을 참조하십시오.

새로 고침 모드 선택¶

사용 사례에 가장 적합한 모드를 결정하려면 자동 권장 사항과 구체적인 새로 고침 모드(전체 및 증분)를 실험해 보십시오. 동적 테이블 성능에 가장 적합한 모드는 데이터 변경량과 쿼리 복잡성에 따라 달라집니다. 또한 전용 웨어하우스에서 다양한 새로 고침 모드를 테스트하면 비용을 분리하고 실제 워크로드에 따라 성능 튜닝을 개선하는 데 도움이 됩니다.

동적 테이블의 새로 고침 모드를 확인하려면 동적 테이블 새로 고침 모드 보기 섹션을 참조하십시오.

• AUTO 새로 고침 모드: 시스템은 기본적으로 증분 새로 고침을 적용하려고 시도합니다. 증분 새로 고침이 지원되지 않거나 성능이 좋지 않을 수 있는 경우 동적 테이블이 자동으로 전체 새로 고침을 대신 선택합니다.

  • 일관적인 동작을 유지하려면 모든 프로덕션 테이블에서 새로 고침 모드를 명시적으로 설정해야 합니다. AUTO 의 동작은 Snowflake 릴리스 간에 변경될 수 있으며, 프로덕션 파이프라인에서 사용할 경우 예기치 않은 성능 변경이 발생할 수 있습니다.

• 증분식 새로 고침: 마지막 새로 고침 이후의 변경 사항만 동적 테이블에 업데이트하므로, 작은 업데이트가 자주 발생하는 대규모 데이터 세트에 적합합니다.

  • 증분 새로 고침과 호환되는 쿼리(예: 결정론적 함수, 단순 조인, SELECT, WHERE, GROUP BY 의 기본 식)에 가장 적합합니다. 지원되지 않는 기능이 있고 새로 고침 모드가 증분으로 설정된 경우 Snowflake는 동적 테이블을 생성하지 못합니다.

  • 증분식 새로 고침으로 성능을 최적화하기 위한 핵심 방법은 변경 볼륨을 소스 데이터의 약 5%로 제한하고 처리 오버헤드를 줄이기 위해 그룹화 키별로 데이터를 클러스터링하는 것입니다.

  • 여러 조인에서의 집계와 같은 특정 작업 조합은 효율적으로 실행되지 않을 수 있습니다.

• 전체 새로 고침: 전체 데이터 세트를 다시 처리하고 동적 테이블을 전체 쿼리 결과로 업데이트합니다. 복잡한 쿼리나 중요한 데이터 변경으로 전체 업데이트가 필요할 때 사용합니다.

  • 복잡한 쿼리, 비결정적 함수 또는 데이터의 주요 변경으로 인해 증분 새로 고침이 지원되지 않는 경우에 유용합니다.

자세한 내용은 새로 고침 모드가 동적 테이블 성능에 미치는 영향 섹션을 참조하십시오.

전체 새로 고침 성능¶

전체 새로 고침 동적 테이블은 CREATE TABLE … AS SELECT(CTAS라고도 함) 와 유사하게 수행됩니다. 전체 새로 고침은 다른 Snowflake 쿼리와 마찬가지로 최적화가 가능합니다.

증분 새로 고침 성능¶

동적 테이블에 대한 최적의 증분 새로 고침 성능을 달성하려면:

• 소스와 동적 테이블 모두에 대해 새로 고침 사이의 변경 사항을 최소한으로 유지합니다. 이상적으로는 전체 데이터 세트의 5% 미만으로 유지합니다.

• 행 수뿐만 아니라 수정된 마이크로 파티션의 수를 고려합니다. 증분 새로 고침이 수행해야 하는 작업의 양은 변경된 행뿐만 아니라 이러한 마이크로 파티션의 크기에 비례합니다.

• 쿼리에서 조인, GROUP BYs, PARTITION BYs와 같은 그룹화 작업을 최소화합니다. 큰 공통 테이블 식(CTEs)을 더 작은 부분으로 나누고 각각에 대한 동적 테이블을 만듭니다. 과도한 집계 또는 조인으로 단일 동적 테이블에 과부하가 걸리지 않도록 합니다.

• 테이블 변경 사항을 쿼리 키(예: 조인의 경우 GROUP BYs, PARTITION BYs)와 정렬하여 데이터 지역성을 보장합니다. 테이블이 이러한 키에 의해 자연스럽게 클러스터링되지 않는 경우 자동 클러스터링 을 사용하도록 설정하는 것이 좋습니다.