Account Usage

Dans la base de données SNOWFLAKE, les schémas ACCOUNT_USAGE et READER_ACCOUNT_USAGE permettent d’interroger les métadonnées des objets, ainsi que les données historiques d’utilisation, pour votre compte et tous les comptes de lecteurs (le cas échéant) associés au compte.

Dans ce chapitre :

Aperçu des schémas Account Usage

ACCOUNT_USAGE

Vues qui affichent les métadonnées de l’objet et les métriques d’utilisation pour votre compte.

En général, ces vues reflètent les vues et les fonctions de table correspondantes dans le Schéma d’information de Snowflake Snowflake, mais avec les différences suivantes :

  • Enregistrements pour les objets déposés inclus dans chaque vue.

  • Durée de conservation plus longue pour les données historiques d’utilisation.

  • Latence des données.

Pour plus de détails, voir Différences entre Account Usage et Information Schema (dans ce chapitre). Pour plus de détails sur chaque vue, voir Vues ACCOUNT_USAGE (dans ce chapitre).

READER_ACCOUNT_USAGE

Vues qui affichent les métadonnées de l’objet et les métriques d’utilisation pour tous les comptes lecteurs qui ont été créés pour votre compte (en tant que fournisseur de Secure Data Sharing).

Ces vues sont un petit sous-ensemble des vues ACCOUNT_USAGE qui s’appliquent aux comptes de lecteurs, à l’exception de la vue RESOURCE_MONITORS, qui n’est disponible qu’en format READER_ACCOUNT_USAGE. De plus, chaque vue de ce schéma contient une colonne READER_ACCOUNT_NAME supplémentaire pour filtrer les résultats par compte de lecteur.

Pour plus de détails sur chaque vue, voir READER_ACCOUNT_USAGE Vues (dans ce chapitre).

Notez que ces vues sont vides si aucun compte lecteur n’a été créé pour votre compte.

Différences entre Account Usage et Information Schema

Les vues Account Usage et les vues correspondantes (ou fonctions de tables) dans Schéma d’information de Snowflake utilisent des structures et des conventions d’appellation identiques, mais avec quelques différences importantes, comme le décrit cette section :

Différence

Utilisation du compte

Information Schema

Inclut les objets détruits

Oui

Non

Latence des données

Entre 45 minutes et 3 heures (varie selon la vue)

Aucun

Conservation des données historiques

1 an

Entre 7 jours et 6 mois (varie selon la vue/la fonction de table)

Pour plus de détails, voir les sections suivantes.

Enregistrements d’objets détruits

Les vues d’utilisation de compte comprennent des enregistrements pour tous les objets qui ont été détruits. Une colonne DELETED supplémentaire affiche l’horodatage lorsque l’objet a été détruit.

En outre, comme les objets peuvent être détruits et recréés avec le même nom, les vues d’utilisation des comptes comprennent des colonnes ID pour différencier les enregistrements d’objets portant le même nom, qui affichent les IDs internes générés et affectés à chaque enregistrement par le système, le cas échéant.

Latence des données

En raison du processus d’extraction des données de l’entrepôt interne de métadonnées de Snowflake, les vues Account Usage ont une certaine latence naturelle :

  • Pour la plupart des vues, la latence est de 2 heures (120 minutes).

  • Pour les autres vues, la latence varie entre 45 minutes et 3 heures.

Pour plus de détails, voir la liste des vues pour chaque schéma (dans cette rubrique). Notez également qu’il s’agit de longueurs maximales ; la latence réelle d’une vue donnée au moment où la vue est interrogée peut être inférieure.

En revanche, les vues/fonctions de la table dans le Schéma d’information de Snowflake n’ont pas de latence.

Conservation des données historiques

Certaines des vues d’utilisation du compte fournissent des métriques historiques d’utilisation. La période de conservation limite pour ces vues est d’un an (365 jours).

En revanche, les vues correspondantes et les fonctions de tables dans le Schéma d’information de Snowflake ont des périodes de coupure beaucoup plus courtes, allant de 7 jours à 6 mois, selon la vue.

Vues ACCOUNT_USAGE

Le schéma ACCOUNT_USAGE contient les vues suivantes :

Vue

Type

Latence [1]

Remarques

ACCESS_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

AUTOMATIC_CLUSTERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

COLUMNS

Objet

90 minutes

COMPLETE_TASK_GRAPHS

Historique

45 minutes

Données conservées pendant 1 an.

COPY_HISTORY

Historique

2 heures [2]

Données conservées pendant 1 an.

DATABASES

Objet

3 heures

DATABASE_STORAGE_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

DATA_TRANSFER_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

FILE_FORMATS

Objet

2 heures

FUNCTIONS

Objet

2 heures

GRANTS_TO_ROLES

Objet

2 heures

GRANTS_TO_USERS

Objet

2 heures

LOAD_HISTORY

Historique

90 minutes [2]

Données conservées pendant 1 an.

LOGIN_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

MASKING_POLICIES

Objet

2 heures

MATERIALIZED_VIEW_REFRESH_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

METERING_DAILY_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

METERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

OBJECT_DEPENDENCIES

Historique

3 heures

PIPES

Objet

2 heures

PIPE_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

POLICY_REFERENCES

Objet

2 heures

QUERY_ACCELERATION_ELIGIBLE

Historique

3 heures

Données conservées pendant 1 an.

QUERY_ACCELERATION_HISTORY

Historique

3 heures

Disponible dans le cadre de l’avant-première du service Query Acceleration. Données conservées pendant 1 an.

QUERY_HISTORY

Historique

45 minutes

Données conservées pendant 1 an.

REFERENTIAL_CONSTRAINTS

Objet

2 heures

REPLICATION_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

ROLES

Objet

2 heures

ROW_ACCESS_POLICIES

Objet

2 heures

SCHEMATA

Objet

2 heures

SEARCH_OPTIMIZATION_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

SEQUENCES

Objet

2 heures

SERVERLESS_TASK_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

SESSIONS

Historique

3 heures

Données conservées pendant 1 an.

STAGES

Objet

2 heures

STAGE_STORAGE_USAGE_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

STORAGE_USAGE

Historique

2 heures

Utilisation combinée de toutes les tables de la base de données et des zones de préparation internes. Données conservées pendant 1 an.

TABLES

Objet

90 minutes

TABLE_CONSTRAINTS

Objet

2 heures

TABLE_STORAGE_METRICS

Objet

90 minutes

TAG_REFERENCES

Objet

2 heures

TAGS

Objet

2 heures

TASK_HISTORY

Historique

45 minutes

USERS

Objet

2 heures

VIEWS

Objet

90 minutes

WAREHOUSE_EVENTS_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

WAREHOUSE_LOAD_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

WAREHOUSE_METERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

[1] Tous les temps de latence sont approximatifs. Dans certains cas, la latence réelle peut être inférieure.

[2] Pour les tables comportant 32 instructions DML ou moins ou 100 lignes ou moins, la latence de ces vues peut atteindre 1 jour.

Fonctions de table Account Usage

Actuellement, Snowflake prend en charge une fonction de table ACCOUNT_USAGE :

Fonction de la table

Données Conservation

Remarques

TAG_REFERENCES_WITH_LINEAGE

N/A

Les résultats ne sont renvoyés que pour le rôle qui a accès à l’objet spécifié.

Note

Comme pour les vues Account Usage, veuillez tenir compte de la latence lorsque vous appelez cette fonction de table. La latence attendue pour cette fonction de table est similaire à la latence pour la vue TAG_REFERENCES.

Vues READER_ACCOUNT_USAGE

Le schéma READER_ACCOUNT_USAGE contient les vues suivantes :

Vue

Type

Latence [1]

Remarques

LOGIN_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

QUERY_HISTORY

Historique

45 minutes

Données conservées pendant 1 an.

RESOURCE_MONITORS

Objet

2 heures

STORAGE_USAGE

Historique

2 heures

Utilisation combinée de toutes les tables de la base de données et des zones de préparation internes. Données conservées pendant 1 an.

WAREHOUSE_METERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

[1] Tous les temps de latence sont approximatifs. Dans certains cas, la latence réelle peut être inférieure.

Activation de l’utilisation de la base de données Snowflake pour d’autres rôles

Par défaut, la base de données SNOWFLAKE n’est disponible que pour le rôle ACCOUNTADMIN.

Pour permettre à d’autres rôles d’accéder à la base de données et aux schémas et d’interroger les vues, un utilisateur ayant le rôle ACCOUNTADMIN doit accorder le privilège de partage de données suivant aux rôles souhaités :

IMPORTED PRIVILEGES

Par exemple :

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;

Interrogation des vues d’utilisation du compte

Cette section fournit des exemples de requêtes typiques/utiles utilisant les vues dans le schéma ACCOUNT_USAGE.

Note

Ces exemples supposent que la base de données SNOWFLAKE et le schéma ACCOUNT_USAGE sont utilisés pour la session en cours. Les exemples supposent également que le rôle ACCOUNTADMIN (ou un rôle ayant obtenu des PRIVILEGES IMPORTED pour la base de données) est utilisé. S’ils ne sont pas utilisés, exécutez les commandes suivantes avant d’exécuter les requêtes dans les exemples :

USE ROLE ACCOUNTADMIN;

USE SCHEMA snowflake.account_usage;

Exemples : métriques de connexion utilisateur

Nombre moyen de secondes entre les tentatives de connexion échouées, par utilisateur (depuis le début du mois) :

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;

Échec de connexions, par utilisateur (depuis le début du mois) :

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;

Échec des connexions par utilisateur et client connecté (depuis le début du mois) :

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;

Exemples : performance des entrepôts

Cette requête calcule les métriques de performance de l’entrepôt virtuel comme le débit et la latence pour des intervalles de temps de 15 minutes au cours d’une journée.

Dans l’exemple de code ci-dessous, remplacez CURRENT_WAREHOUSE() par 'MY_WH' pour calculer les métriques d’un entrepôt spécifique. De plus, modifiez les dates time_from et time_to dans la clause WITH.

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;

Note

Analysez séparément les différents types d’instructions (par exemple, les instructions SELECT indépendamment des instructions INSERT ou DELETE ou autres).

  • La valeur NUMJOBS représente le débit pour cet intervalle de temps.

  • Les P50_TOTAL_DURATION (médiane) et P95_TOTAL_DURATION (pic) représentent la latence.

  • Le SUM_TOTAL_DURATION est la somme des valeurs SUM_<zone_de_préparation_tâche>_TIME pour les différentes zones de préparation de la tâche (COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION).

  • Analysez les valeurs de <zone_de_préparation_tâche>_RATIO lorsque la charge (NUMJOBS) augmente. Recherchez les changements de ratio ou les écarts par rapport à la moyenne :

    • Si le COMPILATION_AND_SCHEDULING_RATIO est élevé, l’entrepôt peut bénéficier des changements à grande simultanéité et faible latence. Ces améliorations sont disponibles dans les entrepôts de toutes les régions.

    • Si le QUEUED_RATIO est élevé, il se peut que la capacité de l’entrepôt soit insuffisante. Ajoutez plus de clusters ou augmentez la taille de l’entrepôt.

Exemple : utilisation du crédit d’entrepôt

Crédits utilisés par chaque entrepôt de votre compte (depuis le début du mois) :

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;

Crédits utilisés au fil du temps par chaque entrepôt de votre compte (depuis le début du mois) :

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;

Exemples : utilisation du stockage de données

Téraoctets facturables stockés dans votre compte au fil du temps :

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;

Exemples : totaux de requêtes utilisateur et temps d’exécution

Total des tâches exécutées sur votre compte (depuis le début du mois) :

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

Total des tâches exécutées par chaque entrepôt de votre compte (depuis le début du mois) :

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;

Temps moyen d’exécution des requêtes par utilisateur (depuis le début du mois) :

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;

Temps moyen d’exécution des requêtes par type de requête et taille de l’entrepôt (depuis le début du mois) :

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;

Exemples : obtenir un nombre de requêtes pour chaque événement de connexion

Joignez les colonnes de LOGIN_HISTORY, QUERY_HISTORY et SESSIONS pour obtenir un nombre de requêtes pour chaque événement de connexion utilisateur.

Note

La vue SESSIONS enregistre les informations à partir du 20-21 juillet 2020, par conséquent le résultat de la requête ne contiendra que des informations se chevauchant pour chacune des trois vues à partir de cette date.

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
;
Revenir au début