동적 테이블 성능 최적화¶

개별 쿼리 간소화¶

• 외부 조인 대신 내부 조인을 사용합니다. 내부 조인은 증분 새로 고침을 사용하면 성능이 향상됩니다. 외부 조인을 방지할 수 있도록 소스 데이터의 참조 무결성을 확인합니다.

• 불필요한 작업을 피합니다. 중복 DISTINCT 절 및 사용되지 않는 열을 제거합니다. 자주 쿼리되지 않는 넓은 열을 제외합니다(예: 큰 JSON blob).

• 중복을 효율적으로 제거합니다. 가능한 경우 DISTINCT 대신 순위 지정 함수를 사용합니다.

특정 SQL 연산자가 증분 새로 고침 성능에 미치는 영향에 대한 자세한 지침은 증분 새로 고침을 위한 쿼리 최적화 섹션을 참조하세요.

여러 동적 테이블에 걸쳐 변환 분할¶

복잡한 변환을 여러 동적 테이블로 나누면 병목 현상을 더 쉽게 식별하고 디버깅을 개선할 수 있습니다. :ref:`불변성 제약 조건 <label-dt-optimize-immutability>`을 통해 스테이지마다 다른 새로 고침 모드를 사용할 수도 있습니다.

• 필터를 조기에 추가합니다. 다운스트림 테이블이 더 적은 행을 처리하도록 소스 데이터에 가장 가까운 동적 테이블에 WHERE 절을 적용합니다.

• 다운스트림 테이블에서 DISTINCT 작업이 반복되는 것을 방지하려면 파이프라인에서 조기에 중복 행을 제거합니다.

• 테이블당 작업 수를 줄입니다. 조인, 집계 또는 윈도우 함수를 하나의 쿼리로 모두 결합하는 대신 중간 동적 테이블로 이동합니다.

• 복합 식(예: DATE_TRUNC('minute', ts))을 사용해 그룹화하기 전에 중간 테이블에서 구체화합니다. 자세한 내용은 집계 최적화 섹션을 참조하십시오.

다음 예제에서는 복잡한 쿼리를 중간 동적 테이블로 분할하는 방법을 보여줍니다.

초기 복잡 쿼리:

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...
  JOIN another_table c ON ...
  GROUP BY ...;

중간 동적 테이블을 추가하여 복잡한 파이프라인을 분할합니다.

CREATE DYNAMIC TABLE intermediate_joined
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...;

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM intermediate_joined
  JOIN another_table c ON ...
  GROUP BY ...;

연산자가 성능에 미치는 영향에 대한 자세한 정보와 예제는 증분 새로 고침을 위한 쿼리 최적화 섹션을 참조하세요.

초기화를 위해 별도의 웨어하우스 사용¶

초기 새로 고침은 증분 새로 고침보다 훨씬 더 많은 데이터를 처리하는 경우가 많습니다. INITIALIZATION_WAREHOUSE를 사용하여 더 큰 웨어하우스에서 초기화를 실행합니다. 정기적인 새로 고침을 위해 더 작고 비용 효율적인 웨어하우스를 예약합니다.

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = 'DOWNSTREAM'
  WAREHOUSE = 'XS_WAREHOUSE'
  INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE'
  AS <query>;

기존 동적 테이블의 초기화 웨어하우스를 추가하거나 변경하려면 다음을 수행합니다.

ALTER DYNAMIC TABLE my_dynamic_table SET INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE';

초기화 웨어하우스를 제거하고 모든 새로 고침에 기본 웨어하우스를 사용하려면 다음을 수행합니다.

ALTER DYNAMIC TABLE my_dynamic_table UNSET INITIALIZATION_WAREHOUSE;

웨어하우스 구성을 보려면 SHOW DYNAMIC TABLES 를 사용하거나 DYNAMIC_TABLE_REFRESH_HISTORY 테이블 함수를 확인합니다.

필요할 때 크기 조정¶

비용과 성능의 균형을 맞추려면 바이트 유출을 방지하면서도 워크로드가 병렬로 사용할 수 있는 양을 초과하지 않는 웨어하우스 크기를 선택합니다. 더 빠른 새로 고침이 중요한 경우 비용 최적 지점을 약간 초과하여 크기를 늘립니다.

동적 테이블 새로 고침에 대한 고려 사항:

• 유출된 바이트: 쿼리 기록에 로컬 또는 원격 저장소로 유출된 바이트가 표시되면 새로 고침 중에 웨어하우스의 메모리가 부족해진 것입니다. 웨어하우스가 클수록 유출을 방지하기 위해 더 많은 메모리를 제공합니다. 자세한 내용은 너무 커서 메모리에 적합하지 않은 쿼리 섹션을 참조하십시오.

• 느린 초기 새로 고침: 초기 새로 고침이 느릴 때는 초기 생성 시 INITIALIZATION_WAREHOUSE를 설정하거나 웨어하우스의 크기를 일시적으로 조정한 다음 테이블이 생성된 후 크기를 줄입니다.

• 포화 병렬 처리: 특정 시점 이후에는 병렬 처리를 추가해도 효과가 감소합니다. 웨어하우스 크기를 두 배로 늘리면 런타임을 절반으로 줄이지 않고도 비용이 두 배로 증가할 수 있습니다. 새로 고침이 병렬 처리를 사용하는 방식을 확인하려면 :ref:`쿼리 프로필 <label-dt-performance-monitor-query-profile>`을 검토합니다.

웨어하우스의 크기를 조정하려면 웨어하우스 크기 늘리기 섹션을 참조하세요.

비용 고려 사항은 가상 웨어하우스 크레딧 사용 및 웨어하우스 관련 작업하기 섹션을 참조하세요.

멀티 클러스터 웨어하우스로 동시 새로 고침 처리¶

여러 동적 테이블이 웨어하우스를 공유하고 큐를 자주 새로 고치는 경우 :doc:`멀티 클러스터 웨어하우스 </user-guide/warehouses-multicluster>`를 사용하는 것이 좋습니다. 멀티 클러스터 웨어하우스는 쿼리가 큐에 추가될 때 클러스터를 자동으로 추가하고 수요가 감소하면 클러스터를 제거합니다. 이를 통해 사용량이 적은 기간 동안 사용하지 않은 용량에 대한 요금을 지불하지 않고도 피크 기간 동안 새로 고침 대기 시간을 개선할 수 있습니다.

큐 식별 및 줄이기에 대한 지침은 큐 줄이기 섹션을 참조하세요.

멀티 클러스터 웨어하우스에는 Enterprise Edition 이상이 필요합니다. 비용 고려 사항은 멀티 클러스터 웨어하우스에 대한 크기 조정 정책 설정하기 섹션을 참조하세요.

목표 지연 시간 변경¶

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';

다운스트림 수요에 따라 새로 고치도록 동적 테이블을 설정하려면 다음을 수행합니다.

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;

클러스터 소스 테이블¶

지역성을 개선하는 가장 효과적인 방법은 동적 테이블 쿼리에 사용되는 키(JOIN, GROUP, BY 또는 PARTITION, BY 키)로 소스 테이블을 클러스터링하는 것입니다.

ALTER TABLE my_source_table CLUSTER BY (join_key_column);

여러 열을 기준으로 조인을 수행하지만 모든 열을 기준으로 클러스터링할 수 없는 경우 다음을 수행합니다.

• 가장 선택적인 키로 더 큰 테이블을 클러스터링하는 우선 순위를 지정합니다.

• 다른 동적 테이블에서 사용하기 위해 다른 키로 클러스터링된 동일한 데이터의 별도 복사본을 만드는 것이 좋습니다.

자세한 내용은 클러스터링 키 및 클러스터링된 테이블 섹션을 참조하십시오. 자동 재클러스터링을 활성화하려면 자동 클러스터링 섹션을 참조하세요.

지역성에 영향을 미치는 요소¶

소스 테이블 클러스터링 외에도 두 가지 다른 요소가 지역성에 영향을 미칩니다. 이는 데이터 패턴에 따라 달라지며 직접 변경하기가 더 어렵습니다.

• 새 데이터가 파티션 키에 맞춰 조정되는 방식: 새 행이 테이블의 작은 부분에만 영향을 미치는 경우 증분 새로 고침이 더 빨라집니다. 이는 쿼리 구조가 아닌 데이터 수집 패턴에 따라 다릅니다.

  예를 들어, 시간별로 그룹화된 시계열 데이터는 새 행이 최근 타임스탬프를 공유하므로 지역성이 양호합니다. 전체 테이블에 걸쳐 값이 분산된 열로 그룹화된 데이터의 지역성은 양호하지 않습니다.

• 변경 사항이 동적 테이블 클러스터링에 맞춰 조정되는 방식: Snowflake는 동적 테이블에 업데이트 또는 삭제를 적용할 때 영향을 받는 행을 찾아야 합니다. 변경된 행이 서로 가깝게 저장되면 속도가 더 빨라집니다.

  예를 들어, 동적 테이블이 시간을 기준으로 자연스럽게 정렬되면 최근 행에 대한 업데이트가 잘 수행됩니다. 전체 테이블에 걸쳐 분산된 업데이트는 더 느립니다. 이 요인은 변경되는 행과 빈도를 포함한 워크로드 패턴에 따라 달라집니다.

이러한 요인으로 인해 지역성이 양호하지 않은 경우 데이터 모델 또는 수집 패턴을 업스트림으로 조정할 수 있는지 여부를 고려합니다.