동적 테이블 성능 모니터링¶

성능 모니터링은 다음 작업에 도움이 됩니다.

느리거나 비용이 많이 발생하는 동적 테이블 새로 고침을 식별합니다.
병목 현상을 진단합니다.
최적화의 영향을 측정합니다.

이 항목에서는 동적 테이블 성능을 모니터링하기 위해 확인해야 할 사항과 문제를 진단하는 방법에 대해 설명합니다. 모니터링 도구에 대한 자세한 내용은 동적 테이블 모니터링하기 섹션을 참조하세요.

팁

실습 예제는 자습서 SCD 유형 1 워크로드를 위한 동적 테이블 성능 최적화 섹션을 참조하세요.

핵심 성과 지표¶

동적 테이블 성능을 모니터링하려면 이 섹션에 설명된 메트릭에 집중합니다.

새로 고침 기간¶

새로 고침 기간은 각 새로 고침을 완료하는 데 걸리는 시간을 측정한 것입니다. 성능 저하를 파악하려면 시간 경과에 따른 새로 고침 기간을 추적합니다.

경고 신호:

시간이 지남에 따라 기간 증가: 데이터 볼륨 증가 또는 데이터 지역성 저하로 인해 새로 고침 시간이 꾸준히 증가할 수 있습니다.
기간이 목표 지연 시간에 가까워짐: 새로 고침에 걸리는 시간이 목표 지연 시간 만큼 오래 걸리는 경우, 데이터 최신성 요구 사항을 충족하지 못할 수 있습니다.
기간의 높은 가변성: 새로 고침 시간의 큰 변동은 워크로드 급증 또는 리소스 경합을 나타낼 수 있습니다.

새로 고침 기간을 보려면 동적 테이블의 새로 고침 상태 모니터링 섹션을 참조하세요.

지연 메트릭¶

지연 시간 메트릭은 동적 테이블이 최신성 목표를 얼마나 잘 충족하는지 보여줍니다. 목표 지연 시간의 작동 방식에 대한 자세한 내용은 동적 테이블 목표 지연 이해하기 섹션을 참조하세요.

주요 메트릭:

실제 지연: 소스 데이터가 변경된 시점과 동적 테이블에 이 변경 사항이 반영된 시점 사이의 시간 간격입니다.
목표 지연 시간 준수 비율: 테이블이 목표 지연 시간 내로 유지된 시간의 백분율입니다. 1 미만의 비율은 파이프라인이 최신성 목표를 충족하지 못하고 있음을 나타냅니다.
최대 지연: 주어진 기간 내에 가장 긴 실제 지연 시간입니다.

지연 메트릭을 보려면 동적 테이블의 새로 고침 상태 모니터링 섹션을 참조하세요.

파티션 통계¶

증분 새로 고침의 경우 스캔된 파티션 수는 전체 테이블 크기가 아닌 변경된 데이터에 비례해야 합니다. 파티션 스캔 횟수가 많으면 데이터 지역성이 양호하지 않음을 나타냅니다.

경고 신호:

증분 새로 고침 중에 전체 파티션의 많은 부분을 스캔합니다.
데이터 증가 없이 시간이 지날수록 파티션 스캔 횟수가 증가합니다.

파티션 통계를 보려면 쿼리 프로필 분석하기 섹션을 참조하세요.

데이터 지역성 개선에 대한 지침은 데이터 지역성 개선 섹션을 참조하세요.

새로 고침 모드¶

새로 고침 모드는 성능에 직접적인 영향을 미칩니다. 동적 테이블이 예상 모드를 사용하는지 확인합니다.

새로 고침 모드를 확인하려면 SHOW DYNAMIC TABLES 를 활용하고 refresh_mode 및 refresh_mode_reason 열을 검토합니다. Snowsight 의 오브젝트 헤더에서 새로 고침 모드를 확인합니다.

올바른 새로 고침 모드 선택에 대한 지침은 새로 고침 모드 선택 섹션을 참조하세요.

느린 새로 고침 원인 진단¶

새로 고침이 예상보다 오래 걸리면 다음 단계에 따라 원인을 식별합니다.

새로 고침 기록에서 점진적 증가 또는 갑작스러운 급증과 같은 새로 고침 기간의 추세를 확인합니다(동적 테이블의 새로 고침 상태 모니터링).
쿼리 프로필을 검토하여 병목 현상을 식별합니다(쿼리 프로필 분석하기).
- 파티션 스캔 횟수가 많으면 :ref:`데이터 지역성 <label-dt-optimize-locality>`이 양호하지 않음을 나타냅니다.
- 유출된 바이트는 웨어하우스가 너무 작음을 나타냅니다.
- 특정 연산자의 시간이 오래 걸리면 :ref:`동적 테이블 쿼리를 최적화 <label-dt-optimize-query>`할 수 있는 기회를 나타낼 수 있습니다.
지연 시간이 지속적으로 목표를 초과하는지 확인합니다. 이는 새로 고침이 데이터 볼륨을 따라잡지 못할 수 있음을 나타냅니다(동적 테이블의 새로 고침 상태 모니터링).
업스트림 종속성을 검토하여 업스트림 테이블이 지연을 유발하거나 대량의 변경을 생성하는지 확인합니다.

Snowsight 의 Graph 뷰에서 다음과 같은 상태가 나타나는지 확인합니다.
- 새로 고침을 실행하는 업스트림 테이블(executing 상태로 표시됨).
- 실패하거나 일시 중단된 업스트림 테이블.
- 평소보다 새로 고침 시간이 오래 걸리는 업스트림 테이블.
Graph 뷰에 액세스하려면 뷰 동적 테이블에 연결된 테이블의 그래프 보기 섹션을 참조하세요.
동적 테이블이 처리하는 변경 사항의 볼륨을 확인합니다. 업스트림 종속성으로 인한 변경 사항이 많으면 새로 고침 속도가 느려질 수 있습니다.

DYNAMIC_TABLE_REFRESH_HISTORY 함수를 사용하여 최근 새로 고침에서 변경된 행 수를 확인합니다.
```
SELECT
  name,
  data_timestamp,
  statistics:numInsertedRows::INT AS rows_inserted,
  statistics:numDeletedRows::INT AS rows_deleted,
  refresh_action
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
ORDER BY data_timestamp DESC
LIMIT 10;
```
Copy
변경 볼륨이 전체 테이블 크기에 비해 높은 경우(테이블 행의 5% 이상) 전체 새로 고침 모드를 대신 사용하는 것이 좋습니다.

일반적인 패턴 및 권장 작업¶

새로 고침 기간은 안정적이지만 지연 시간이 높음: 목표 지연 시간이 현재 웨어하우스 크기와 데이터 볼륨에 비해 너무 촉박합니다. 새로 고침이 성공적으로 완료되지만 수신되는 변경 사항을 따라잡을 수 없습니다. 목표 지연 시간 및 웨어하우스 리소스 가 데이터 볼륨과 일치하는지 확인합니다.
새로 고침 기간이 갑자기 급증하고 유출된 바이트가 높음: 웨어하우스가 너무 작거나 다른 쿼리가 동시에 실행 중이기 때문에 새로 고침을 처리하기에 충분한 메모리가 없습니다. 웨어하우스 크기를 늘리거나 동적 테이블 새로 고침을 전용 웨어하우스로 이동시킵니다.
파티션 스캔은 시간이 지남에 따라 증가하지만 데이터 볼륨은 동일하게 유지됨: 데이터 지역성이 양호하지 않아 Snowflake가 필요 이상으로 많은 파티션을 스캔해야 합니다. :ref:`클러스터링 키 및 데이터 지역성 <label-dt-optimize-locality>`을 확인합니다. 또한 업스트림 변경 사항이 몇 개의 연속된 파티션이 아닌 분산된 수많은 파티션에 영향을 주고 있는지 확인합니다.
새로 고칠 때마다 테이블의 많은 부분(행 또는 파티션의 5% 이상)이 처리됨: 대부분의 테이블이 자주 변경되는 경우 증분 새로 고침의 이점은 거의 없습니다. :ref:`전체 새로 고침 모드로 전환 <label-dt-optimize-refresh>`하거나 파이프라인을 다시 설계하여 새로 고칠 때마다 변경되는 데이터의 양을 줄입니다.

조사 결과를 바탕으로 동적 테이블 성능 최적화 섹션을 참조하여 적절한 수정을 적용합니다.

참고

*건너뛰거나 실패한 새로 고침*은 일반적으로 성능 문제가 아닌 구성 문제로 인해 발생합니다. Troubleshooting skipped or failed dynamic table refreshes 섹션을 참조하십시오.

쿼리 프로필 분석하기¶

쿼리 프로필 은 각 새로 고침에 대한 상세한 실행 통계를 보여줍니다. 새로 고침이 느릴 때 쿼리 프로필을 통해 최적화 기회를 식별할 수 있습니다.

쿼리 프로필에 액세스하려면 다음을 수행합니다.

Transformation » Dynamic Tables 으로 이동합니다.
동적 테이블을 선택하고 Refresh History 탭으로 이동합니다.
분석하려는 새로 고침 옆에 있는 :ui:`Show query profile`을 클릭합니다.

먼저 새로 고침 기록에서 쿼리 ID를 가져옵니다.

SELECT
  name,
  refresh_start_time,
  query_id
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
WHERE state = 'SUCCEEDED'
ORDER BY refresh_start_time DESC
LIMIT 5;

Copy

그런 다음 GET_QUERY_OPERATOR_STATS 함수를 사용하여 쿼리 프로필을 분석합니다.

SELECT *
FROM TABLE(GET_QUERY_OPERATOR_STATS('<query_id>'));

Copy

확인해야 할 사항¶

스캔된 파티션 및 정리된 파티션: 파티션 스캔이 전체 파티션 수에 비해 높으면 일반적으로 :ref:`데이터 지역성 <label-dt-optimize-locality>`이 양호하지 않거나 클러스터링이 누락된 것입니다.
시간 분포: 가장 많은 시간을 소비하는 연산자를 확인합니다. 지나치게 오래 걸리는 연산자는 쿼리를 최적화할 수 있는 기회를 나타낼 수 있습니다. 연산자별 지침은 증분 새로 고침을 위한 쿼리 최적화 섹션을 참조하세요.
로컬 또는 원격 저장소로 유출된 바이트: 높은 바이트 유출은 대개 웨어하우스가 새로 고침 워크로드에 비해 너무 작거나 동일한 웨어하우스에서 실행 중인 다른 쿼리로 인해 새로 고침에 사용할 수 있는 메모리가 부족함을 나타냅니다. 웨어하우스 크기를 늘리거나 전용 웨어하우스에서 동적 테이블 새로 고침을 실행하여 경합을 줄이는 것이 좋습니다.

쿼리 프로필에서 발견된 문제를 해결하는 방법에 대한 자세한 지침은 동적 테이블 성능 최적화 섹션을 참조하세요.

웨어하우스 사용량 모니터링¶

웨어하우스가 동적 테이블 워크로드를 처리할 수 있는지 확인하고 비용을 절감하는 방법을 찾으려면 웨어하우스 사용량을 모니터링합니다.

모니터링할 주요 메트릭¶

유출된 바이트: 로컬 또는 원격 저장소로 유출된 바이트는 웨어하우스가 너무 작음을 의미합니다. 웨어하우스 크기를 늘리는 것이 좋습니다. 유출된 바이트 식별 및 문제 해결에 대한 자세한 내용은 저장소로 유출되는 쿼리 찾기 섹션을 참조하세요.
웨어하우스 활용률: 웨어하우스에 워크로드를 새로 고칠 충분한 리소스가 있는지 확인합니다. 활용률이 낮다는 것은 웨어하우스가 너무 크다는 뜻입니다. 큐 시간이 길다는 것은 웨어하우스가 너무 작거나 너무 많은 동시 쿼리를 실행한다는 의미입니다.
쿼리 큐 대기: 큐에 대기 중인 쿼리는 새로 고침을 지연시킵니다. 새로 고침이 큐에 자주 대기하면 웨어하우스 크기를 늘리거나, 동적 테이블 새로 고침을 위한 전용 웨어하우스를 사용하거나, 멀티 클러스터 웨어하우스를 통해 가변 워크로드를 처리하는 것이 좋습니다.
크레딧 사용: 크레딧을 추적하여 성능과 비용의 균형을 맞춥니다. 정기적으로 모니터링하여 적절한 규모로 웨어하우스를 조정하거나 새로 고침 일정을 조정할 수 있습니다.

웨어하우스 사용량 및 큐 시간을 보려면 큐 줄이기 섹션을 참조하세요. 동적 테이블 성능 최적화 섹션을 참조하여 동적 테이블에 대한 웨어하우스 구성을 최적화합니다.

종속성 모니터링¶

동적 테이블 간의 종속성은 성능에 영향을 줄 수 있습니다. 다운스트림 테이블은 자체 새로 고침을 시작하기 전에 업스트림 테이블이 새로 고침을 완료할 때까지 기다려야 하므로 업스트림 테이블의 성능 문제는 다운스트림 테이블에서 연속적으로 발생합니다.

업스트림 종속성과 관련된 성능 문제를 진단하려면 느린 새로 고침 원인 진단 섹션을 참조하세요.

종속성 그래프를 보려면 동적 테이블에 연결된 테이블의 그래프 보기 섹션을 참조하세요.

성능 문제에 대한 경고 설정¶

성능이 저하될 때 알림을 받도록 경고를 설정할 수 있습니다. 다음 조건에 대한 경고를 생성하는 것이 좋습니다.

새로 고침 기간이 임계값을 초과합니다.
지연 시간으로 인해 지속적으로 목표를 달성하지 못합니다.

경고는 이벤트 테이블을 사용하여 새로 고침 이벤트를 추적합니다. 설정 지침은 동적 테이블에 대한 이벤트 테이블 모니터링 및 경고 섹션을 참조하세요.