Account Usage

SNOWFLAKE 데이터베이스에서 ACCOUNT_USAGE 및 READER_ACCOUNT_USAGE 스키마를 사용하면 계정, 그리고 계정과 연결된 모든 독자 계정(있는 경우)에 대한 오브젝트 메타데이터와 과거 사용 데이터를 쿼리하는 것이 가능합니다.

이 항목의 내용:

Account Usage 스키마 개요

ACCOUNT_USAGE

계정에 대한 오브젝트 메타데이터와 사용량 메트릭을 표시하는 뷰입니다.

일반적으로, 이러한 뷰는 Snowflake Snowflake Information Schema 의 해당 뷰와 테이블 함수를 미러링하지만 다음과 같은 차이점이 있습니다.

  • 각각의 뷰에 포함된 삭제된 오브젝트에 대한 레코드

  • 과거 사용량 데이터에 대해 더욱 길어진 보존 기간

  • 데이터 대기 시간

자세한 내용은 이 항목에 있는 Account Usage와 Information Schema의 차이점 섹션을 참조하십시오. 각 뷰에 대한 자세한 내용은 이 항목에 있는 ACCOUNT_USAGE 뷰 섹션을 참조하십시오.

READER_ACCOUNT_USAGE

Secure Data Sharing 공급자로서 귀하의 계정을 위해 생성된 모든 독자 계정에 대한 오브젝트 메타데이터와 사용량 메트릭을 표시하는 뷰입니다.

이러한 뷰는 READER_ACCOUNT_USAGE에서만 사용할 수 있는 RESOURCE_MONITORS 뷰를 제외하고 독자 계정에 적용되는 ACCOUNT_USAGE 뷰의 소규모 서브세트입니다. 또한, 이 스키마의 각 뷰에는 독자 계정별로 결과를 필터링하기 위한 추가적인 READER_ACCOUNT_NAME 열이 있습니다.

각 뷰에 대한 자세한 내용은 이 항목에 있는 READER_ACCOUNT_USAGE 뷰 섹션을 참조하십시오.

귀하의 계정을 위해 생성된 독자 계정이 없는 경우 이러한 뷰는 비어 있습니다.

Account Usage와 Information Schema의 차이점

Snowflake Information Schema 의 Account Usage 뷰 및 해당 뷰(또는 테이블 함수)는 동일한 구조와 명명 규칙을 사용하지만, 이 섹션에 설명된 대로 몇 가지 주요 차이점이 있습니다.

차이점

Account Usage

Information Schema

삭제된 오브젝트 포함

아니요

데이터 대기 시간

45분~3시간(뷰에 따라 다름)

없음

과거 데이터 보존 기간

1년

7일~6개월(뷰/테이블 함수에 따라 다름)

자세한 내용은 다음 섹션을 참조하십시오.

삭제된 오브젝트에 대한 레코드

계정 사용량 뷰에는 삭제된 모든 오브젝트에 대한 레코드가 포함됩니다. 오브젝트 유형에 대한 많은 뷰에는 오브젝트가 삭제되었을 때의 타임스탬프를 표시하는 추가적인 DELETED 열이 포함됩니다.

또한, 오브젝트를 삭제하고 똑같은 이름으로 다시 만들 수 있으므로 같은 이름을 가진 오브젝트 레코드를 구별하기 위해 해당되는 경우 계정 사용량 뷰에는 시스템에서 생성해 각각의 레코드에 할당하는 내부 IDs를 표시하는 ID 열이 포함 됩니다.

오브젝트 이름의 열(예: TABLE_NAME 열)이 NULL이라면 그 오브젝트가 삭제된 것입니다. 이 경우에는 상위 오브젝트의 이름과 ID의 열(예: DATABASE_NAMESCHEMA_NAME 열)도 NULL입니다.

어떤 뷰에서는 오브젝트가 삭제되었더라도 오브젝트 이름 열에 여전히 오브젝트 이름이 포함될 수 있습니다.

데이터 대기 시간

Snowflake의 내부 메타데이터 저장소에서 데이터를 추출하는 프로세스로 인해, 계정 사용량 뷰에는 자연스러운 대기 시간이 있습니다.

  • 대부분의 뷰에서 대기 시간은 2시간(120분)입니다.

  • 나머지 뷰의 대기 시간은 45분에서 3시간 사이입니다.

자세한 내용은 이 항목에 있는 각 스키마에 대한 뷰 목록을 참조하십시오. 또한, 이러한 대기 시간은 모두 최대 시간이라는 점에 유의하십시오. 주어진 뷰를 쿼리할 때 해당 뷰의 실제 대기 시간은 더 짧을 수 있습니다.

반대로, Snowflake Information Schema 의 뷰/테이블 함수에는 대기 시간이 없습니다.

과거 데이터 보존

과거 사용량 메트릭을 제공하는 계정 사용량 뷰가 있습니다. 이러한 뷰의 보존 기간은 1년(365일)입니다.

반대로, Snowflake Information Schema 에 있는 해당 뷰와 테이블 함수는 뷰에 따라 7일에서 6개월 사이로, 보존 기간이 훨씬 짧습니다.

ACCOUNT_USAGE 뷰

ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.

타입

대기 시간 [1]

참고

ACCESS_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

AUTOMATIC_CLUSTERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

COLUMNS

오브젝트

90분

COMPLETE_TASK_GRAPHS

과거

45분

데이터는 1년간 보존됩니다.

COPY_HISTORY

과거

2시간 [2]

데이터는 1년간 보존됩니다.

DATABASES

오브젝트

3시간

DATABASE_REPLICATION_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

DATABASE_STORAGE_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

DATA_TRANSFER_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

FILE_FORMATS

오브젝트

2시간

FUNCTIONS

오브젝트

2시간

GRANTS_TO_ROLES

오브젝트

2시간

GRANTS_TO_USERS

오브젝트

2시간

LOAD_HISTORY

과거

90분:sup:[2]

데이터는 1년간 보존됩니다.

LOGIN_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

MASKING_POLICIES

오브젝트

2시간

MATERIALIZED_VIEW_REFRESH_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

METERING_DAILY_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

OBJECT_DEPENDENCIES

과거

3시간

PIPES

오브젝트

2시간

PIPE_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

POLICY_REFERENCES

오브젝트

2시간

QUERY_ACCELERATION_ELIGIBLE

과거

3시간

데이터는 1년간 보존됩니다.

QUERY_ACCELERATION_HISTORY

과거

3시간

Query Acceleration Service 미리 보기의 일부로 제공됩니다. 데이터는 1년간 보존됩니다.

QUERY_HISTORY

과거

45분

데이터는 1년간 보존됩니다.

REFERENTIAL_CONSTRAINTS

오브젝트

2시간

REPLICATION_GROUP_REFRESH_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

REPLICATION_GROUP_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

REPLICATION_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

ROLES

오브젝트

2시간

ROW_ACCESS_POLICIES

오브젝트

2시간

SCHEMATA

오브젝트

2시간

SEARCH_OPTIMIZATION_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

SEQUENCES

오브젝트

2시간

SERVERLESS_TASK_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

SESSIONS

과거

3시간

데이터는 1년간 보존됩니다.

STAGES

오브젝트

2시간

STAGE_STORAGE_USAGE_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

STORAGE_USAGE

과거

2시간

모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다.

TABLES

오브젝트

90분

TABLE_CONSTRAINTS

오브젝트

2시간

TABLE_STORAGE_METRICS

오브젝트

90분

TAG_REFERENCES

오브젝트

2시간

TAGS

오브젝트

2시간

TASK_HISTORY

과거

45분

USERS

오브젝트

2시간

VIEWS

오브젝트

90분

WAREHOUSE_EVENTS_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

WAREHOUSE_LOAD_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

WAREHOUSE_METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.

[2] DML 문이 32개 이하이거나 행 개수가 100개 이하인 테이블의 경우, 이러한 뷰의 대기 시간은 최대 1일까지 걸릴 수도 있습니다.

Account Usage 테이블 함수

현재, Snowflake는 다음 한 가지 ACCOUNT_USAGE 테이블 함수를 지원합니다.

테이블 함수

데이터 보존

참고

TAG_REFERENCES_WITH_LINEAGE

N/A

지정된 오브젝트에 액세스할 권한이 있는 역할에 대해서만 결과가 반환됩니다.

참고

Account Usage 뷰와 유사하게, 이 테이블 함수를 호출하는 경우에도 지연 시간을 고려해야 합니다. 이 테이블 함수의 예상 지연 시간은 TAG_REFERENCES 뷰의 지연 시간과 유사합니다.

READER_ACCOUNT_USAGE 뷰

READER_ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.

타입

대기 시간 [1]

참고

LOGIN_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

QUERY_HISTORY

과거

45분

데이터는 1년간 보존됩니다.

RESOURCE_MONITORS

오브젝트

2시간

STORAGE_USAGE

과거

2시간

모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다.

WAREHOUSE_METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.

다른 역할에 대해 Snowflake 데이터베이스 사용 활성화하기

기본적으로, SNOWFLAKE 데이터베이스는 ACCOUNTADMIN 역할에만 제공됩니다.

다른 역할이 이 데이터베이스와 스키마에 액세스하고 뷰를 쿼리할 수 있도록 하려면 ACCOUNTADMIN 역할을 가진 사용자가 원하는 역할에 다음 데이터 공유 권한을 부여해야 합니다.

IMPORTED PRIVILEGES

예:

USE ROLE ACCOUNTADMIN;

GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE SYSADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE customrole1;

USE ROLE customrole1;

SELECT * FROM snowflake.account_usage.databases;

Account Usage 뷰 쿼리

이 섹션에서는 ACCOUNT_USAGE 스키마의 뷰를 사용하는 몇 가지 일반적이고 유용한 쿼리의 예를 제시합니다.

참고

이러한 예에서는 SNOWFLAKE 데이터베이스와 ACCOUNT_USAGE 스키마가 현재 세션에 사용 중인 것으로 가정합니다. 또한, 이들 예에서는 ACCOUNTADMIN 역할(또는 데이터베이스에서 IMPORTED PRIVILEGES가 부여된 역할)이 사용 중이라고 간주합니다. 이들이 사용 중이지 않는 경우에는 다음 명령을 실행한 후에 예제의 쿼리를 실행하십시오.

USE ROLE ACCOUNTADMIN;

USE SCHEMA snowflake.account_usage;

예: 사용자 로그인 메트릭

사용자의 로그인 시도 실패 간 평균 시간(초)(당월 합계):

select user_name,
       count(*) as failed_logins,
       avg(seconds_between_login_attempts) as average_seconds_between_login_attempts
from (
      select user_name,
             timediff(seconds, event_timestamp, lead(event_timestamp)
                 over(partition by user_name order by event_timestamp)) as seconds_between_login_attempts
      from login_history
      where event_timestamp > date_trunc(month, current_date)
      and is_success = 'NO'
     )
group by 1
order by 3;

사용자별 로그인 실패 횟수(당월 합계):

select user_name,
       sum(iff(is_success = 'NO', 1, 0)) as failed_logins,
       count(*) as logins,
       sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate
from login_history
where event_timestamp > date_trunc(month, current_date)
group by 1
order by 4 desc;

사용자 및 연결 중인 클라이언트별 로그인 실패 횟수(당월 합계):

select reported_client_type,
       user_name,
       sum(iff(is_success = 'NO', 1, 0)) as failed_logins,
       count(*) as logins,
       sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate
from login_history
where event_timestamp > date_trunc(month, current_date)
group by 1,2
order by 5 desc;

예: 웨어하우스 성능

이 쿼리는 하루 동안 15분 간격으로 처리량 및 대기 시간과 같은 가상 웨어하우스 성능 메트릭을 계산합니다.

아래 코드 샘플에서 CURRENT_WAREHOUSE()'MY_WH' 로 대체하여 특정 웨어하우스에 대한 메트릭을 계산합니다. 또한 WITH 절에서 time_fromtime_to 날짜를 변경합니다.

WITH
params AS (
SELECT
    CURRENT_WAREHOUSE() AS warehouse_name,
    '2021-11-01' AS time_from,
    '2021-11-02' AS time_to
),

jobs AS (
SELECT
    query_id,
    time_slice(start_time::timestamp_ntz, 15, 'minute','start') as interval_start,
    qh.warehouse_name,
    database_name,
    query_type,
    total_elapsed_time,
    compilation_time AS compilation_and_scheduling_time,
    (queued_provisioning_time + queued_repair_time + queued_overload_time) AS queued_time,
    transaction_blocked_time,
    execution_time
FROM snowflake.account_usage.query_history qh, params
WHERE
    qh.warehouse_name = params.warehouse_name
AND start_time >= params.time_from
AND start_time <= params.time_to
AND execution_status = 'SUCCESS'
AND query_type IN ('SELECT','UPDATE','INSERT','MERGE','DELETE')
),

interval_stats AS (
SELECT
    query_type,
    interval_start,
    COUNT(DISTINCT query_id) AS numjobs,
    MEDIAN(total_elapsed_time)/1000 AS p50_total_duration,
    (percentile_cont(0.95) within group (order by total_elapsed_time))/1000 AS p95_total_duration,
    SUM(total_elapsed_time)/1000 AS sum_total_duration,
    SUM(compilation_and_scheduling_time)/1000 AS sum_compilation_and_scheduling_time,
    SUM(queued_time)/1000 AS sum_queued_time,
    SUM(transaction_blocked_time)/1000 AS sum_transaction_blocked_time,
    SUM(execution_time)/1000 AS sum_execution_time,
    ROUND(sum_compilation_and_scheduling_time/sum_total_duration,2) AS compilation_and_scheduling_ratio,
    ROUND(sum_queued_time/sum_total_duration,2) AS queued_ratio,
    ROUND(sum_transaction_blocked_time/sum_total_duration,2) AS blocked_ratio,
    ROUND(sum_execution_time/sum_total_duration,2) AS execution_ratio,
    ROUND(sum_total_duration/numjobs,2) AS total_duration_perjob,
    ROUND(sum_compilation_and_scheduling_time/numjobs,2) AS compilation_and_scheduling_perjob,
    ROUND(sum_queued_time/numjobs,2) AS queued_perjob,
    ROUND(sum_transaction_blocked_time/numjobs,2) AS blocked_perjob,
    ROUND(sum_execution_time/numjobs,2) AS execution_perjob
FROM jobs
GROUP BY 1,2
ORDER BY 1,2
)
SELECT * FROM interval_stats;

참고

다른 문 유형을 별도로 분석합니다(예: INSERT 또는 DELETE 또는 기타 문과 독립적인 SELECT 문).

  • NUMJOBS 값은 해당 시간 간격에 대한 처리량을 나타냅니다.

  • P50_TOTAL_DURATION(중앙값) 및 P95_TOTAL_DURATION(피크) 값은 대기 시간을 나타냅니다.

  • SUM_TOTAL_DURATION은 다양한 작업 스테이지(COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION)에 대한 SUM_<job_stage>_TIME 값의 합계입니다.

  • 부하(NUMJOBS)가 증가할 때 <job_stage>_RATIO 값을 분석합니다. 평균에서 비율 변경 또는 편차를 찾습니다.

    • COMPILATION_AND_SCHEDULING_RATIO가 높으면 웨어하우스는 높은 동시성과 낮은 대기 시간 변경의 이점을 얻을 수 있습니다. 이러한 개선 사항은 모든 리전의 웨어하우스에서 제공됩니다.

    • QUEUED_RATIO가 높으면 웨어하우스에 용량이 충분하지 않을 수 있습니다. 클러스터를 더 추가하거나 웨어하우스 크기를 늘리십시오.

예: 웨어하우스 크레딧 사용

계정의 각 웨어하우스에서 사용한 크레딧(당월 합계):

select warehouse_name,
       sum(credits_used) as total_credits_used
from warehouse_metering_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

계정의 각 웨어하우스에서 시간의 경과에 따라 사용한 크레딧(당월 합계):

select start_time::date as usage_date,
       warehouse_name,
       sum(credits_used) as total_credits_used
from warehouse_metering_history
where start_time >= date_trunc(month, current_date)
group by 1,2
order by 2,1;

예: 데이터 저장소 사용량

시간의 경과에 따라 계정에 저장된 청구 가능한 테라바이트 수:

select date_trunc(month, usage_date) as usage_month
  , avg(storage_bytes + stage_bytes + failsafe_bytes) / power(1024, 4) as billable_tb
from storage_usage
group by 1
order by 1;

예: 사용자 쿼리 합계 및 실행 시간

계정에서 실행된 총 작업 수(당월 합계):

select count(*) as number_of_jobs
from query_history
where start_time >= date_trunc(month, current_date);

계정의 각 웨어하우스에서 실행된 총 작업 수(당월 합계):

select warehouse_name,
       count(*) as number_of_jobs
from query_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

사용자별 평균 쿼리 실행 시간(당월 합계):

select user_name,
       avg(execution_time) as average_execution_time
from query_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

쿼리 유형 및 웨어하우스 크기별 평균 쿼리 실행 시간(당월 합계):

select query_type,
       warehouse_size,
       avg(execution_time) as average_execution_time
from query_history
where start_time >= date_trunc(month, current_date)
group by 1,2
order by 3 desc;

예: 모든 로그인 이벤트에 대한 쿼리 수 가져오기

LOGIN_HISTORY, QUERY_HISTORY, SESSIONS의 열을 조인하여 각 사용자 로그인 이벤트에 대한 쿼리 수를 가져옵니다.

참고

SESSIONS 뷰는 2020년 7월 20일~21일부터 정보를 기록하기 시작하므로, 쿼리 결과에는 이 날짜부터 시작해 세 가지 뷰 각각에 대해 겹치는 정보만 포함됩니다.

select l.user_name,
       l.event_timestamp as login_time,
       l.client_ip,
       l.reported_client_type,
       l.first_authentication_factor,
       l.second_authentication_factor,
       count(q.query_id)
from snowflake.account_usage.login_history l
join snowflake.account_usage.sessions s on l.event_id = s.login_event_id
join snowflake.account_usage.query_history q on q.session_id = s.session_id
group by 1,2,3,4,5,6
order by l.user_name
;
맨 위로 이동