Snowflake 앱의 가시성¶

원격 분석 데이터 타입¶

수집한 원격 분석 데이터가 광범위하게 유용하게 사용될 수 있도록 Snowflake 원격 분석은 표준 OpenTelemetry (OTel) 프레임워크, Cloud Native Compute Foundation의 인큐베이팅 프로젝트에 기반합니다. 이 프레임워크와 API 및 이를 위해 설계된 도구를 통해 Snowflake 외에 도구 를 사용하여 수집된 데이터를 재사용할 수 있습니다. OpenTelemetry 를 통해 애플리케이션 코드를 계측하여 원하는 곳에 가시성을 추가할 수 있습니다.

Snowflake 이벤트 테이블은 OpenTelemetry 데이터 모델링에서 로그, 범위 및 메트릭 데이터를 수집합니다. 다음은 이벤트 테이블에서 수집되는 각 원격 분석 데이터 타입에 대해 설명합니다.

로그	로그는 코드가 수행한 개별 작업을 기록합니다. 각 로그 메시지는 코드가 실행되는 동안 개별 지점에서 생성됩니다. 계측 코드 처리기 코드에서 기록하기 에 나열된 대로 사용 중인 언어에 대한 표준 라이브러리를 사용하여 코드에서 로깅할 수 있습니다. 데이터 보기 이벤트 테이블을 쿼리하거나 Snowsight 에서 제공되는 시각화를 보고 로그 메시지를 확인하여 분석할 수 있습니다. Snowsight 의 다음 이미지는 단일 데이터베이스에서 2시간 동안 수집된 로그 메시지 목록을 보여줍니다.
메트릭	메트릭은 일정 기간 동안 계산된 측정값입니다. 이러한 값에는 CPU 및 메모리 측정값이 포함됩니다. 코드 계측 Snowflake는 코드가 실행될 때 자동으로 메트릭 데이터를 전송하므로 코드를 계측할 필요가 없습니다. 데이터 보기 이벤트 테이블을 쿼리하거나 Snowsight 에서 제공되는 시각화를 보고 메트릭 데이터를 확인하여 분석할 수 있습니다. Snowsight 의 다음 이미지는 사용자 정의 함수 실행 시 수집된 메트릭 데이터의 변화를 보여줍니다.
추적	추적은 데이터가 시스템을 통해 흐르면서 분산된 이벤트를 보여줍니다. 추적에서는 구성 요소에서 구성 요소로 처리 흐름이 이동하면서 시간이 소요되는 위치를 확인할 수 있습니다. 처리기 코드에서 기록하기 에 나열된 대로 사용 중인 언어에 대한 표준 라이브러리를 사용하여 Snowflake가 생성하는 기본 범위 또는 사용자가 생성하는 사용자 지정 범위에서 추적 이벤트를 내보낼 수 있습니다. 계측 코드 처리기 코드에서 이벤트 추적 에 나열된 대로 사용 중인 언어에 대한 표준 라이브러리를 사용하여 코드에서 추적 이벤트를 방출할 수 있습니다. 데이터 보기 이벤트 테이블을 쿼리하거나 Snowsight 에서 제공되는 시각화를 보고 추적 이벤트를 확인하여 분석할 수 있습니다. Snowsight 의 다음 이미지는 UDF 실행의 범위 결과를 보여줍니다.

필요하기 전에 원격 분석 데이터를 캡처하도록 환경 설정하기¶

수집하지 않은 데이터는 분석할 수 없으므로 필요할 때 사용할 수 있도록 원격 분석 데이터 수집을 시작하는 것이 가장 좋습니다. 배포 규모가 커질수록 코드의 성능을 이해해야 할 필요성도 커집니다.

다음 모범 사례를 사용하십시오.

• Snowflake 환경에 대해 원격 분석 데이터 수집을 활성화합니다.

  필요한 데이터를 수집하려면 활동 중인 이벤트 테이블이 있는지 확인하십시오.

• 원하는 원격 분석 데이터를 수집하려면 원격 분석 수준 을 유용한 임계값으로 설정하십시오.

  처음에는 데이터를 수집할 수 있도록 이 수준을 설정하는 것이 좋습니다. 예를 들어 프로덕션 또는 비즈니스 크리티컬 작업에 대해 로그 수준을 WARN 이상으로 설정하십시오. 시간이 지남에 따라 변화하는 요구 사항을 충족하기 위해 이러한 수준을 조정할 수 있습니다.

  프로덕션 저장 프로시저, UDF 및 기타 오브젝트를 데이터베이스 또는 스키마 아래에 조직화하여 해당 데이터베이스 또는 스키마에 대한 경고 로그를 간단히 활성화할 수 있습니다. 이렇게 하면 별도의 오브젝트에 대한 설정을 관리해야 하는 수고를 덜 수 있습니다.

• 문제 해결을 위한 데이터를 생성하려면 로그 문 또는 추적 이벤트 를 프로덕션 작업에 추가하십시오.

  Java의 SLF4J 또는 Python의 로깅 라이브러리와 같은 표준 로깅 라이브러리 를 사용하는 경우, Snowflake는 해당 패키지의 로그를 이벤트 테이블로 자동 라우팅합니다.

  추적을 위해 Snowflake에 포함된 원격 분석 라이브러리 를 사용할 수 있습니다.

• 측정하려는 처리기 처리의 일부 데이터를 추적 데이터에 포함하려면 저장 프로시저 처리기 코드에 사용자 지정 범위 를 추가하십시오.

  Snowflake 오브젝트의 기본 제공 범위와 함께 추적 다이어그램에서 생성한 사용자 지정 범위를 나타냅니다. 사용자 지정 범위를 사용하면 코드 처리의 임의 부분에 대한 데이터를 캡처하여 해당 부분이 실행되는 데 걸리는 시간을 확인할 수 있습니다. 또한 사용자 지정 범위에 임의의 메타데이터를 첨부하여 문제 해결 및 최적화를 위해 데이터에 설명을 추가할 수도 있습니다.

쿼리 원격 분석을 통한 프로시저 최적화하기¶

쿼리 원격 분석 추적 다이어그램에서 쿼리에서 방출된 모든 범위에 대한 데이터를 확인할 수 있습니다.

• 가로축은 기간을 표시합니다. 가로로 길게 표시되는 범위는 짧은 범위보다 완료하는 데 시간이 더 오래 걸립니다.

• 세로축에는 호출 계층 구조가 표시됩니다. 해당 계층 구조에서 다른 범위 바로 아래에 있는 모든 범위는 그 위에 있는 ‘상위’ 범위의 ‘하위’입니다.

이 다이어그램을 사용하여 저장 프로시저에서 최적화할 기회를 찾을 수 있습니다. 다이어그램에 표시된 내용을 시작점으로 삼아 코드를 최적화하는 단계를 수행할 수 있습니다.

예를 들어, joblib와 같은 라이브러리를 사용하여 순차적 작업을 병렬로 실행하도록 조직할 수 있습니다. Joblib 는 Python 코드에 파이프라이닝을 추가하기 위한 도구 세트입니다. 이를 통해 병렬 코드를 더 쉽게 작성할 수 있습니다.

캐시 중복 DataFrame 작업¶

여러 번 사용되는 DataFrame 작업 체인이 있는 경우 추적 다이어그램에서 각 DataFrame 작업에 대한 범위로 표시됩니다. 쿼리의 복잡성에 따라 이 범위는 상당히 길어질 수 있습니다.

예를 들어, 아래 코드에서는 동일한 DataFrame 체인이 여러 컨텍스트에서 호출됩니다.

count = session.table(...).select().filter().join().count()

if count > 0:
  session.table(...).select().filter().join().write.save_as_table(...) # same query as the count, this will execute again
else:
  session.table(...).select().filter('other criteria').join() # nearly same query as the count

캐싱을 사용하면 중간 DataFrame 을 임시 테이블로 캐시하여 중복 쿼리를 줄임으로써 성능이 향상됩니다.

cached_df = session.table(...).select().filter().join().cache_result()
count = df.count()

if count > 0:
  cached_df.write.save_as_table() # reuses the cached DF
else:
  cached_df

UDF에 대해 수신되는 원격 분석 데이터의 양 관리하기¶

UDF로 원격 분석 데이터를 수집하는 코드를 추가할 때 UDF 실행 모델은 프로시저보다 이벤트 테이블에 더 많은 행을 의미할 수 있다는 점을 기억하십시오.

모든 입력 행에서 UDF 가 호출되면 처리기 코드는 입력 데이터 세트의 모든 행에 대해 로그 문자 또는 범위 이벤트를 내보냅니다. 예를 들어, UDF 로 전달된 1,000만 행의 데이터 세트는 1,000만 개의 로그 항목을 생성합니다.

UDF에 로그 및 범위 이벤트를 추가할 때 다음 패턴을 사용하는 것을 고려하십시오.

• 처음에는 기록되는 항목 수를 줄이도록 설계된 로깅 수준 을 사용하십시오.

  DEBUG 수준 또는 INFO 수준 로깅 문을 사용하고 프로덕션에서는 로깅 수준을 WARN 으로 설정하십시오. 문제가 발견되면 디버깅 세션이 진행되는 동안 로깅 수준을 DEBUG 또는 INFO 로 낮출 수 있습니다.

• try/catch 블록을 사용하여 로그 데이터를 방출하려는 코드를 분리하십시오.

  try/catch를 사용하면 예기치 않은 UDF 입력을 포착하여 WARN 수준 로그로 기록하여 인지하고 기본값을 반환하는 데 유용할 수 있습니다.

• 조건 문을 사용하여 의미 있는 시나리오에 대해서만 로그를 기록하십시오.

  if/else 문이나 기타 제약 조건을 사용하여 로그 출력의 양을 제어할 수 있습니다.

쿼리 원격 분석을 통한 사용자 정의 함수 최적화하기¶

UDF 가 호출되면 Snowflake는 각 입력 행에 대해 처리기 코드의 인스턴스를 생성하여 병렬로 실행합니다. 추적 다이어그램에서 이러한 각 인스턴스가 자체 범위로 표시되는 것을 볼 수 있습니다.

이러한 범위를 사용하여 느린 쿼리 문제를 해결하고 성능을 개선할 기회를 찾을 수 있습니다. 예를 들어 다음과 같은 시나리오가 표시될 수 있습니다.

• UDF 코드의 하나 이상의 인스턴스에 나머지 데이터와 달리 상당히 크거나 다른 데이터가 포함된 행이 수신될 수 있습니다. 이 경우 해당 인스턴스를 완료하는 데 훨씬 더 오랜 시간이 걸릴 수 있으며, 따라서 그 기간도 훨씬 길어집니다.

• 쿼리의 입력 파티션 및 선행 절에 따라 일부 인스턴스가 엄청난 양의 입력 데이터를 수신할 수 있습니다.

다음 이미지는 UDF 에 전달된 각 행의 범위를 보여주며, 한 범위의 기간이 길면 해당 행에 다른 행보다 더 큰 데이터가 있을 수 있음을 나타냅니다.

경고 및 알림 모범 사례¶

시스템에서 수신하는 정보의 양을 세분화하고 늘려서 가시성을 개선하려면 다음 방법을 사용하십시오.

• 이벤트 평가가 중복되지 않도록 하십시오.

  경고 예약과 실행 사이의 지연 시간을 고려하여 이벤트에 대한 중복 평가를 피할 수 있습니다. 이렇게 하려면 CURRENT_TIMESTAMP 대신 SCHEDULED_TIME 및 LAST_SUCCESSFUL_SCHEDULED_TIME 을 사용하여 경고 타임스탬프를 지정합니다.

  자세한 내용은 경고 일정을 기반으로 타임스탬프 지정하기 섹션을 참조하십시오.

• 쿼리 결과로 경고 작업 또는 알림을 보강하십시오.

  경고 조건으로 지정된 SQL 문에서 결과를 확인할 수 있습니다. 쿼리 결과를 얻으려면 다음과 같이 하십시오.

  1. GET_CONDITION_QUERY_UUID 를 호출하여 경고 조건의 SQL 문에 대한 쿼리 ID 를 검색합니다.

  2. ID 쿼리를 RESULT_SCAN 으로 전달하여 쿼리 결과를 얻습니다.

• 결과를 로그하거나 알림을 보내는 것 외에 자동화된 작업을 수행합니다.

  경고 조건이 충족될 때마다 경고 작업이 작업을 실행 하거나 새 행을 테이블에 로그하도록 지정할 수 있습니다. 예를 들어 경고 조건이 충족될 때마다 Snowflake에서 작업을 수행하는 경우 이 작업을 수행할 수 있습니다.

  조건이 충족된 후 복잡한 작업을 수행하려는 경우 웨어하우스가 적절한 크기인지 확인하십시오.