Account Usage

In der SNOWFLAKE-Datenbank ermöglichen die Schemas ACCOUNT_USAGE und READER_ACCOUNT_USAGE die Abfrage von Objektmetadaten sowie von historischen Nutzungsdaten für Ihr Konto und für alle mit dem Konto verbundenen Leserkonten (falls vorhanden).

Unter diesem Thema:

Überblick über Account Usage-Schemas

ACCOUNT_USAGE

Ansichten, in denen Objektmetadaten und Nutzungsdaten für Ihr Konto angezeigt werden.

Im Allgemeinen spiegeln diese Ansichten die entsprechenden Ansichten und Tabellenfunktionen im Snowflake Snowflake Information Schema wider, allerdings mit folgenden Unterschieden:

  • Datensätze für gelöschte Objekte, die in einzelnen Ansichten enthalten sind.

  • Längere Aufbewahrungszeit für historische Nutzungsdaten.

  • Datenlatenz.

Weitere Informationen dazu finden Sie unter Unterschiede zwischen Account Usage und Information Schema (unter diesem Thema). Weitere Informationen zu den einzelnen Ansichten finden Sie unter ACCOUNT_USAGE Ansichten (unter diesem Thema).

READER_ACCOUNT_USAGE

Ansichten, in denen Objektmetadaten und Nutzungsmetriken für alle Leserkonten angezeigt werden, die für Ihr Konto erstellt wurden (als ein Anbieter von Secure Data Sharing).

Diese Ansichten sind eine kleine Teilmenge der ACCOUNT_USAGE-Ansichten, die mit Ausnahme der RESOURCE_MONITORS-Ansicht, die nur in READER_ACCOUNT_USAGE verfügbar ist, für Leserkonten verfügbar sind. Außerdem enthält jede Ansicht in diesem Schema eine zusätzliche READER_ACCOUNT_NAME-Spalte zum Filtern von Ergebnissen nach Leserkonten.

Weitere Informationen zu den einzelnen Ansichten finden Sie unter READER_ACCOUNT_USAGE-Ansichten (unter diesem Thema).

Beachten Sie, dass diese Ansichten leer sind, wenn für Ihr Konto keine Leserkonten erstellt wurden.

Unterschiede zwischen Account Usage und Information Schema

Die Account Usage-Ansichten und die entsprechenden Ansichten (oder Tabellenfunktion) im Snowflake Information Schema basieren auf identischen Strukturen und Namenskonventionen, jedoch mit einigen wesentlichen Unterschieden, die in diesem Abschnitt beschrieben werden.

Unterschied

Kontonutzung

Information Schema

Enthält gelöschte Objekte

Ja

Nein

Latenz der Daten

45 Minuten bis 3 Stunden (variiert je nach Ansicht)

Keine

Aufbewahrung historischer Daten

1 Jahr

7 Tage bis 6 Monate (variiert je nach Ansicht/Tabellenfunktion)

Weitere Details dazu finden Sie in den folgenden Abschnitten.

Gelöschte Objektdatensätze

Account Usage-Ansichten enthalten Datensätze für alle Objekte, die gelöscht wurden. In einer zusätzlichen DELETED-Spalte wird der Zeitstempel dafür angezeigt, wann das Objekt gelöscht wurde.

Da Objekte gelöscht und mit dem gleichen Namen neu angelegt werden können, beinhalten die Account Usage-Ansichten ggf. auch ID-Spalten, in denen die intern generierten und vom System den einzelnen Datensätzen zugeordneten IDs angezeigt werden. Dadurch kann zwischen Objektdatensätzen mit dem gleichen Namen unterschieden werden.

Datenlatenz

Aufgrund der Extraktion der Daten aus dem internen Metadatenspeicher von Snowflake weisen die Kontonutzungsansichten eine natürliche Latenzzeit auf:

  • Bei den meisten Ansichten beträgt die Latenz 2 Stunden (120 Minuten).

  • Bei den anderen Ansichten variiert die Latenz zwischen 45 Minuten und 3 Stunden.

Weitere Informationen dazu finden Sie in der Ansichtsliste des jeweiligen Schemas (unter diesem Thema). Beachten Sie zudem, dass es sich dabei um maximale Werte handelt. Die tatsächliche Latenz einer bestimmten Ansicht zum Zeitpunkt der Abfrage kann geringer sein.

Im Gegensatz dazu weisen Ansichten/Tabellenfunktionen im Snowflake Information Schema keine Latenzen auf.

Aufbewahrung historischer Daten

Manche Kontonutzungsansichten bieten historische Nutzungsdaten. Die Aufbewahrungsfrist für diese Ansichten beträgt 1 Jahr (365 Tage).

Im Gegensatz dazu haben die zugehörigen Ansichten und Tabellenfunktionen im Snowflake Information Schema deutlich kürzere Aufbewahrungsfristen, die je nach Ansicht zwischen 7 Tagen und 6 Monaten liegen.

ACCOUNT_USAGE-Ansichten

Das Schema ACCOUNT_USAGE enthält die folgenden Ansichten:

Ansicht

Typ

Latenz: sup:[1]

Anmerkungen

ACCESS_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

AUTOMATIC_CLUSTERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

COLUMNS

Objekt

90 Minuten

COMPLETE_TASK_GRAPHS

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

COPY_HISTORY

Historisch

2 Stunden [2]

Daten werden für 1 Jahr aufbewahrt.

DATABASES

Objekt

3 Stunden

DATABASE_STORAGE_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

DATA_TRANSFER_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

FILE_FORMATS

Objekt

2 Stunden

FUNCTIONS

Objekt

2 Stunden

GRANTS_TO_ROLES

Objekt

2 Stunden

GRANTS_TO_USERS

Objekt

2 Stunden

LOAD_HISTORY

Historisch

90 Minuten [2]

Daten werden für 1 Jahr aufbewahrt.

LOGIN_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

MASKING_POLICIES

Objekt

2 Stunden

MATERIALIZED_VIEW_REFRESH_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

METERING_DAILY_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

OBJECT_DEPENDENCIES

Historisch

3 Stunden

PIPES

Objekt

2 Stunden

PIPE_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

POLICY_REFERENCES

Objekt

2 Stunden

QUERY_ACCELERATION_ELIGIBLE

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

QUERY_ACCELERATION_HISTORY

Historisch

3 Stunden

Verfügbar als Teil der Vorschau des Query Acceleration Service. Daten werden für 1 Jahr aufbewahrt.

QUERY_HISTORY

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

REFERENTIAL_CONSTRAINTS

Objekt

2 Stunden

REPLICATION_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

ROLES

Objekt

2 Stunden

ROW_ACCESS_POLICIES

Objekt

2 Stunden

SCHEMATA

Objekt

2 Stunden

SEARCH_OPTIMIZATION_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SEQUENCES

Objekt

2 Stunden

SERVERLESS_TASK_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SESSIONS

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

STAGES

Objekt

2 Stunden

STAGE_STORAGE_USAGE_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

STORAGE_USAGE

Historisch

2 Stunden

Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt.

TABLES

Objekt

90 Minuten

TABLE_CONSTRAINTS

Objekt

2 Stunden

TABLE_STORAGE_METRICS

Objekt

90 Minuten

TAG_REFERENCES

Objekt

2 Stunden

TAGS

Objekt

2 Stunden

TASK_HISTORY

Historisch

45 Minuten

USERS

Objekt

2 Stunden

VIEWS

Objekt

90 Minuten

WAREHOUSE_EVENTS_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_LOAD_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

[1] Alle Latenzwerte sind ungefähre Werte. In einigen Fällen kann die tatsächliche Latenz geringer sein.

[2] Für Tabellen mit höchstens 32 DML-Anweisungen oder höchstens 100 Zeilen kann die Latenz dieser Ansichten bis zu 1 Tag betragen.

Account Usage-Tabellenfunktionen

Derzeit unterstützt Snowflake eine ACCOUNT_USAGE-Tabellenfunktion:

Tabellenfunktion

Datenaufbewahrung

Anmerkungen

TAG_REFERENCES_WITH_LINEAGE

N/A

Es werden nur Ergebnisse für die Rolle zurückgegeben, die Zugriff auf das angegebene Objekt hat.

Bemerkung

Ähnlich wie bei den Account Usage-Ansichten müssen Sie auch beim Aufruf dieser Tabellenfunktion die Latenz berücksichtigen. Die erwartete Latenz für diese Tabellenfunktion ist ähnlich der Latenz für die Ansicht TAG_REFERENCES.

READER_ACCOUNT_USAGE-Ansichten

Das Schema READER_ACCOUNT_USAGE enthält die folgenden Ansichten:

Ansicht

Typ

Latenz: sup:[1]

Anmerkungen

LOGIN_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

QUERY_HISTORY

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

RESOURCE_MONITORS

Objekt

2 Stunden

STORAGE_USAGE

Historisch

2 Stunden

Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

[1] Alle Latenzwerte sind ungefähre Werte. In einigen Fällen kann die tatsächliche Latenz geringer sein.

Aktivieren der Nutzung der Snowflake-Datenbank für andere Rollen

Standardmäßig ist die SNOWFLAKE-Datenbank nur für die Rolle ACCOUNTADMIN verfügbar.

Damit andere Rollen auf die Datenbank und Schemas zugreifen sowie die Ansichten abfragen können, muss ein Benutzer mit der Rolle ACCOUNTADMIN den gewünschten Rollen die folgende Berechtigung für Datenfreigaben gewähren:

IMPORTED PRIVILEGES

Beispiel:

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;

Abfragen der Account Usage-Ansichten

In diesem Abschnitt finden Sie Beispiele für typische/nützliche Abfragen unter Verwendung der Ansichten im Schema ACCOUNT_USAGE.

Bemerkung

In diesen Beispielen wird davon ausgegangen, dass die SNOWFLAKE-Datenbank und das ACCOUNT_USAGE-Schema für die aktuelle Sitzung aktiv sind. Außerdem wird vorausgesetzt, dass die ACCOUNTADMIN-Rolle (oder eine Rolle, der in der Datenbank IMPORTED PRIVILEGES gewährt wurden) zum Einsatz kommt. Wenn diese nicht verwendet werden, führen Sie folgende Befehle aus, bevor Sie die Abfragen in den Beispielen ausführen:

USE ROLE ACCOUNTADMIN;

USE SCHEMA snowflake.account_usage;

Beispiele: Benutzeranmeldemetriken

Durchschnittliche Anzahl von Sekunden zwischen fehlgeschlagenen Anmeldeversuchen nach Benutzern (aktueller Monat):

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;

Fehlgeschlagene Anmeldungen nach Benutzer (aktueller Monat):

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;

Fehlgeschlagene Anmeldungen nach Benutzern und zu verbindenden Clients (aktueller Monat):

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;

Beispiele: Performance von Warehouses

Diese Abfrage berechnet die Leistungsmetriken des virtuellen Warehouses wie Durchsatz und Latenz für 15-minütige Zeitintervalle im Verlauf eines Tages.

Ersetzen Sie im folgenden Codebeispiel CURRENT_WAREHOUSE() durch 'MY_WH', um die Metriken für ein bestimmtes Warehouse zu berechnen. Ändern Sie außerdem die Datumsangaben für time_from und time_to in der WITH-Klausel.

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;

Bemerkung

Analysieren Sie verschiedene Anweisungstypen getrennt (z. B. SELECT-Anweisungen unabhängig von INSERT oder DELETE oder anderen Anweisungen).

  • Der NUMJOBS-Wert stellt den Durchsatz für dieses Zeitintervall dar.

  • Die Werte P50_TOTAL_DURATION (Median) und P95_TOTAL_DURATION (Spitzenwert) stellen die Latenz dar.

  • Der Wert SUM_TOTAL_DURATION ist die Summe der SUM_<Jobphase>_TIME-Wert für die verschiedenen Jobphasen (COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION).

  • Analysieren Sie die <Jobphase>_RATIO-Werte, wenn der Workload (NUMJOBS) steigt. Achten Sie auf Verhältnisänderungen oder Abweichungen vom Durchschnitt:

    • Wenn der Wert für COMPILATION_AND_SCHEDULING_RATIO hoch ist, könnte das Warehouse von den Änderungen für hohe Parallelität bei geringer Latenz profitieren. Diese Verbesserungen sind für Warehouses in allen Regionen verfügbar.

    • Wenn der Wert für QUEUED_RATIO hoch ist, bietet das Warehouse möglicherweise nicht ausreichend Kapazität. Fügen Sie weitere Cluster hinzu, oder vergrößern Sie das Warehouse.

Beispiele: Credit-Nutzung von Warehouses

Credits, die von den einzelnen Warehouses in Ihrem Konto verbraucht werden (aktueller Monat):

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;

Credits, die im Zeitverlauf von einzelnen Warehouses in Ihrem Konto verbraucht wurden (aktueller Monat):

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;

Beispiele: Datenspeichernutzung

Abrechnungsfähige Terabyte, die im Zeitverlauf in Ihrem Konto gespeichert wurden:

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;

Beispiele: Gesamtzahl der Benutzerabfragen und Ausführungszeiten

Gesamtzahl der in Ihrem Konto ausgeführten Jobs (aktueller Monat):

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

Gesamtzahl der Aufträge, die von den einzelnen Warehouses in Ihrem Konto ausgeführt wurden (aktueller Monat):

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;

Durchschnittliche Ausführungszeit für Abfragen nach Benutzer (aktueller Monat):

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;

Durchschnittliche Ausführungszeit für Abfragen nach Abfragetyp und Warehouse-Größe (aktueller Monat):

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;

Beispiele: Abfrageanzahl für jedes Anmeldeereignis abrufen

Verknüpfen Sie Spalten aus LOGIN_HISTORY, QUERY_HISTORY und SESSIONS, um die Anzahl der Abfragen für jedes Benutzeranmeldeereignis zu erhalten.

Bemerkung

In der SESSIONS-Ansicht werden Informationen ab 20./21. Juli 2020 aufgezeichnet. Daher wird das Abfrageergebnis nur überlappende Informationen für jede der drei Ansichten ab diesem Datum enthalten.

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
;
Zurück zum Anfang