アカウントの使用

SNOWFLAKE データベースでは、 ACCOUNT_USAGE スキーマと READER_ACCOUNT_USAGE スキーマを使用して、アカウントとアカウントに関連付けられているすべてのリーダーアカウント(存在する場合)のオブジェクトメタデータと履歴使用状況データをクエリできます。

このトピックの内容:

Account Usageスキーマの概要

ACCOUNT_USAGE

アカウントのオブジェクトメタデータと使用メトリックを表示するビュー。

一般的に、これらのビューはSnowflake Snowflake Information Schema の対応するビューとテーブル関数をミラーリングしますが、次の違いがあります。

  • 各ビューに含まれるドロップ済みオブジェクトの記録。

  • 履歴使用データの保持時間が長くなる。

  • データの待機時間。

詳細については、このトピック内の アカウントの使用と情報スキーマの違い をご参照ください。各ビューの詳細については、 ACCOUNT_USAGE ビュー (このトピック内)をご参照ください。

READER_ACCOUNT_USAGE

Secure Data Sharing(セキュアデータ共有) プロバイダーとして)アカウント用に作成されたすべてのリーダーアカウントのオブジェクトメタデータと使用メトリックを表示するビュー。

これらのビューは、リーダーアカウントに適用される ACCOUNT_USAGE ビューの小さなサブセットです。ただし、 RESOURCE_MONITORS ビューは例外で、 READER_ACCOUNT_USAGE でのみ使用できます。また、このスキーマの各ビューには、リーダーアカウントで結果をフィルタリングするための追加の READER_ACCOUNT_NAME 列が含まれています。

各ビューの詳細については、 READER_ACCOUNT_USAGE ビュー (このトピック内)をご参照ください。

アカウントにリーダーアカウントが作成されていない場合、これらのビューは空になります。

Account UsageとInformation Schemaの違い

Account Usageビューと Snowflake Information Schema にある対応するビュー(またはテーブル関数)は、同一の構造と命名規則を使用しますが、このセクションに記載されるように、いくつかの重要な違いがあります。

アカウント の使用

情報 スキーマ

ドロップされたオブジェクトを含む

はい

いいえ

データの待機時間

45分~3時間(ビューに応じて異なる)

なし

履歴データの保持

1年

7日~6か月(ビュー/テーブル関数に応じて異なる)

詳細については、次のセクションをご参照ください。

削除されたオブジェクトレコード

アカウント使用状況ビューには、削除されたすべてのオブジェクトの履歴が含まれます。オブジェクト型のビューの多くには、オブジェクトがドロップされたときのタイムスタンプを表示する追加の DELETED 列が含まれています。

さらに、オブジェクトは同じ名前で削除および再作成できるため、同じ名前のオブジェクト履歴を区別するために、アカウント使用状況ビューには ID 列が含まれ、必要に応じて、生成およびシステムにより各履歴に割り当てられた内部 IDs が表示されます。

オブジェクト名の列(例: TABLE_NAME 列)が NULL の場合、そのオブジェクトはドロップされています。この場合は、親オブジェクトの名前と IDs の列(例: DATABASE_NAME 列と SCHEMA_NAME 列)も NULL です。

一部のビューでは、オブジェクトがドロップされた場合でも、オブジェクト名の列にオブジェクトの名前が含まれている場合があることに注意してください。

データの待機時間

Snowflakeの内部メタデータストアからデータを抽出するプロセスにより、アカウント使用状況ビューには自然な待機時間が発生します。

  • ほとんどのビューでは、待機時間は2時間(120分)です。

  • 残りのビューでは、待機時間は45分~3時間の間になります。

詳細については、このトピック内の各スキーマのビューのリストをご参照ください。また、これらはすべて最長時間です。ビューがクエリされたときの特定のビューに対する実際の待機時間は、それよりも短い場合があります。

対照的に、 Snowflake Information Schema のビュー/テーブル関数には待機時間がありません。

履歴データ保持

特定のアカウント使用状況ビューは、使用状況の履歴メトリックを提供します。これらのビューの保持期間は1年(365日)です。

対照的に、 Snowflake Information Schema の対応するビューおよびテーブル関数は、ビューに応じて、7日~6か月の範囲の非常に短い保持期間となります。

ACCOUNT_USAGE ビュー

ACCOUNT_USAGE スキーマには次のビューが含まれます。

ビュー

待機時間:sup:[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 分 [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サービス プレビューの一部として利用できます。データは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] 32以下の DML ステートメントまたは100以下の行を持つテーブルの場合、これらのビューの待機時間は最大1日になる可能性があります。

Account Usageテーブル関数

現在、Snowflakeは ACCOUNT_USAGE テーブル関数を1つサポートしています。

テーブル関数

データ 保持

メモ

TAG_REFERENCES_WITH_LINEAGE

N/A

結果は、指定されたオブジェクトにアクセスできるロールに対してのみ返されます。

注釈

Account Usageビューと同様に、このテーブル関数を呼び出すときは待機時間を考慮してください。このテーブル関数の予想待機時間は、 TAG_REFERENCES ビューの待機時間と同様です。

READER_ACCOUNT_USAGE ビュー

READER_ACCOUNT_USAGE スキーマには次のビューが含まれます。

ビュー

待機時間:sup:[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 database_name, database_owner FROM snowflake.account_usage.databases;

アカウント使用状況ビューのクエリ

このセクションでは、 ACCOUNT_USAGE スキーマのビューを使用した一般的/有用なクエリの例を示します。

注釈

  • これらの例では、 SNOWFLAKE データベースと ACCOUNT_USAGE スキーマが現在のセッションで使用されていると想定しています。この例では、 ACCOUNTADMIN ロール(またはデータベースで IMPORTED PRIVILEGES が付与されたロール)が使用されていることも想定しています。使用されていない場合は、例にあるクエリを実行する前に次のコマンドを実行します。

    USE ROLE ACCOUNTADMIN;
    
    USE SCHEMA snowflake.account_usage;
    
  • Snowflake固有のビューは変更される可能性があります。これらのビューからすべての列を選択することは避けてください。代わりに、必要な列を選択します。たとえば、 name 列が必要な場合は、 SELECT * ではなく SELECT name を使用します。

例:ユーザーログインメトリック

ユーザーによるログイン失敗の試行間の平均秒数(今月現在):

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;

例: ウェアハウスのパフォーマンス

このクエリは、1日の間に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_<ジョブステージ>_TIME 値の合計です。

  • ロード(NUMJOBS)が増加したときに、<ジョブステージ>_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日以降の情報を記録します。したがって、クエリ結果には、この日付から始まる3つのビューのそれぞれで重複する情報のみが含まれます。

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
;
最上部に戻る