Account Usage

Snowflake stellt über eine gemeinsame Datenbank namens SNOWFLAKE Metadaten zu Datenwörterbuchobjekten sowie historische Nutzungsdaten für Ihr Konto zur Verfügung.

Unter diesem Thema:

Was ist die SNOWFLAKE-Datenbank?

SNOWFLAKE ist eine systemdefinierte, schreibgeschützte Mehrbenutzer-Datenbank, die von Snowflake bereitgestellt wird. Die Datenbank wird aus einer Freigabe namens ACCOUNT_USAGE automatisch in jedes Konto importiert. Die SNOWFLAKE-Datenbank ist ein Beispiel, wie Snowflake Secure Data Sharing verwendet, um Objektmetadaten und andere Nutzungsmetriken für Ihr Konto zur Verfügung zu stellen.

Die SNOWFLAKE-Datenbank enthält zwei Schemas (ebenfalls schreibgeschützt). Jedes Schema verschiedene Ansichten:

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 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.

Die Ansichten in den Schemata können wie alle anderen Ansichten in Snowflake abgefragt werden:

Beachten Sie, dass die SNOWFLAKE-Datenbank ein drittes Schema (INFORMATION_SCHEMA) enthält, das automatisch in allen Datenbanken erstellt wird. In gemeinsamen Datenbanken erfüllt dieses Schema keinen Zweck und kann ignoriert werden.

Bemerkung

Standardmäßig können nur Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) auf die SNOWFLAKE-Datenbank und Schemas innerhalb der Datenbank zugreifen bzw. Abfragen für die Ansichten vornehmen; Berechtigungen für die Datenbank können allerdings auch anderen Rollen in Ihrem Konto gewährt werden, um weiteren Benutzern Zugriff auf die Objekte zu ermöglichen. Weitere Informationen finden Sie unter Account Usage für andere Rollen aktivieren (unter diesem Thema).

Unterschiede zwischen Account Usage und Information Schema

Die Kontonutzungsansichten und die entsprechenden Ansichten (oder Tabellenfunktion) im 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 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 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

AUTOMATIC_CLUSTERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

COLUMNS

Objekt

90 Minuten

COPY_HISTORY

Historisch

2 Stunden

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

Daten werden für 1 Jahr aufbewahrt.

LOGIN_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

MATERIALIZED_VIEW_REFRESH_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

METERING_DAILY_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

PIPES

Objekt

2 Stunden

PIPE_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

REPLICATION_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

QUERY_HISTORY

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

REFERENTIAL_CONSTRAINTS

Objekt

2 Stunden

ROLES

Objekt

2 Stunden

SCHEMATA

Objekt

2 Stunden

SEARCH_OPTIMIZATION_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SEQUENCES

Objekt

2 Stunden

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

USERS

Objekt

2 Stunden

VIEWS

Objekt

90 Minuten

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.

: sub:[1] Alle Latenzen stellen ungefähre Werte dar. In einigen Fällen kann die tatsächliche Latenz geringer sein.

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.

: sub:[1] Alle Latenzen stellen ungefähre Werte dar. In einigen Fällen kann die tatsächliche Latenz geringer sein.

Aktivieren von Account Usage 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: 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.

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
;