Account Usage¶
在 SNOWFLAKE 数据库中, ACCOUNT_USAGE 和 READER_ACCOUNT_USAGE 架构支持查询账户,以及与该账户关联的所有阅读者账户(如有)的对象元数据以及历史使用数据。
本主题内容:
Account Usage 架构概述¶
- ACCOUNT_USAGE:
显示账户的对象元数据和使用情况指标的视图。
一般来说,这些视图镜像了 Snowflake Information Schema 中相应的视图和表函数,但有以下区别:
每个视图中包含已删除对象的记录。
更长的历史使用数据保留时间。
数据延迟。
有关更多详细信息,请参阅 `Account Usage 与 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 中的相应视图(或表函数)使用相同的结构和命名约定,但有一些关键差异,如本节所述:
差异 |
Account Usage |
Information Schema |
---|---|---|
包括已删除对象 |
是 |
否 |
数据延迟 |
45 分钟至 3 小时(因视图而异) |
无 |
历史数据的保留 |
1 年 |
7 天到 6 个月(因视图/表函数而异) |
有关更多详细信息,请参阅以下部分。
已删除的对象记录¶
Account Usage 视图包括所有已删除对象的记录。许多对象类型的视图包含一个额外的 DELETED
列,显示删除对象的时间戳。
此外,由于可以删除对象,然后以相同名称重新创建对象,为了区分具有相同名称的对象记录,Account Usage 视图在适当时包括 ID 列,用于显示系统生成并分配给各记录的内部 IDs。
如果存储对象名称的列(例如 TABLE_NAME
列)为 NULL,则表示该对象已被删除。在这种情况下,存储父对象的名称和 IDs 的列(例如 DATABASE_NAME
和 SCHEMA_NAME
列)也是 NULL。
请注意,在某些视图中,即使对象已被删除,存储对象名称的列可能仍包含对象的名称。
数据延迟¶
由于从 Snowflake 的内部元数据存储中提取数据的过程,Account Usage 视图存在一些自然延迟:
对于大多数视图,延迟为 2 小时(120 分钟)。
对于其余视图,延迟在 45 分钟到 3 小时之间不等。
有关详细信息,请参阅各架构的视图列表(本主题内容)。另请注意,这些都是最大时间长度;查询给定视图时,视图的实际延迟可能会更短。
相反, Snowflake Information Schema 中的视图/表函数没有任何延迟。
历史数据保留¶
某些 Account Usage 视图提供历史使用情况指标。这些视图的保留期为 1 年(365 天)。
相比之下, Snowflake Information Schema 的保留期要短得多,从 7 天到 6 个月不等,具体取决于视图。
ACCOUNT_USAGE 视图¶
ACCOUNT_USAGE 架构包含以下视图:
视图 |
类型 |
延迟 [1] |
版本:sup:[3] |
备注 |
---|---|---|---|---|
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
历史数据 |
3 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
3 小时 |
数据保留 1 年。 |
||
对象 |
3 小时 |
数据保留 1 年。 |
||
对象 |
90 分钟 |
|||
历史数据 |
45 分钟 |
数据保留 1 年。 |
||
历史数据 |
2 小时:sup:[2] |
数据保留 1 年。 |
||
对象 |
3 小时 |
Enterprise Edition(或更高版本) |
只要表存在,数据就会保留。 |
|
对象 |
3 小时 |
Enterprise Edition(或更高版本) |
||
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
对象 |
3 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
2 小时 |
数据保留 1 年。 |
||
对象 |
90 分钟 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
2 小时 |
数据保留 1 年。 |
||
对象 |
90 分钟 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
3 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
3 小时 |
|||
对象 |
3 小时 |
|||
历史数据 |
90 分钟:sup:[2] |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
2 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
45 分钟 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
Enterprise Edition(或更高版本) |
数据保留 1 年。 |
|
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
对象 |
3 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
2 小时 |
数据保留 1 年。 |
||
历史数据 |
12 小时 |
数据保留 1 年。 |
||
对象 |
2 小时 |
|||
历史数据 |
2 小时 |
数据保留 1 年。 |
||
历史数据 |
2 小时 |
所有数据库表和内部暂存区的综合使用情况。数据保留 1 年。 |
||
对象 |
90 分钟 |
|||
对象 |
2 小时 |
|||
对象 |
90 分钟 |
|||
对象 |
2 小时 |
|||
对象 |
2 小时 |
|||
历史数据 |
45 分钟 |
|||
对象 |
3 小时 |
|||
对象 |
2 小时 |
|||
对象 |
90 分钟 |
|||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
||
历史数据 |
3 小时 |
数据保留 1 年。 |
[1] 所有延迟时间均为近似值;在某些情况下,实际延迟可能会更低。
[2] 如果满足以下两个条件,则给定表的视图延迟可能长达 2 天:1.自上次在 LOAD_HISTORY 或者 COPY_HISTORY 中更新以来,添加到给定表中的 DML 语句少于 32 条。2. 自上次在 LOAD_HISTORY 或者 COPY_HISTORY 中更新以来,添加到给定表中的行数少于 100 行。
[3] 除非另有说明,否则 Account Usage 视图适用于所有账户。
Account Usage 表函数¶
目前,Snowflake 支持一种 ACCOUNT_USAGE 表函数:
表函数 |
数据 保留 |
备注 |
---|---|---|
不适用 |
仅对有权访问指定对象的角色返回结果。 |
备注
与 Account Usage 视图类似,请考虑调用此表函数时的延迟。该表函数的预期延迟与 TAG_REFERENCES 视图的延迟相似。
READER_ACCOUNT_USAGE 视图¶
READER_ACCOUNT_USAGE 架构包含以下视图:
视图 |
类型 |
延迟 [1] |
备注 |
---|---|---|---|
历史数据 |
2 小时 |
数据保留 1 年。 |
|
历史数据 |
45 分钟 |
数据保留 1 年。 |
|
对象 |
2 小时 |
||
历史数据 |
2 小时 |
所有数据库表和内部暂存区的综合使用情况。数据保留 1 年。 |
|
历史数据 |
3 小时 |
数据保留 1 年。 |
[1] 所有延迟时间均为近似值;在某些情况下,实际延迟可能会更低。
为其他角色启用 SNOWFLAKE 数据库使用¶
默认情况下, SNOWFLAKE 数据库对所有用户均为可见,但具有 ACCOUNTADMIN 角色的用户可通过以下方法之一,授予对此数据库中架构的访问权限:
授予对 SNOWFLAKE 数据库的 IMPORTED PRIVILEGES 权限。
向账户角色授予 SNOWFLAKE 数据库角色。
重要
在启用了 ORGADMIN 角色的 账户内,授予对 SNOWFLAKE 数据库的权限时要小心。在该账户中,任何有 SNOWFLAKE 数据库权限的人员均可访问 ORGANIZATION_USAGE 架构。
为避免无意中授予对组织级数据的访问权限,请考虑使用 SNOWFLAKE 数据库角色 授予对 ACCOUNT_USAGE 架构中视图的访问权限。
有关更多信息,请参阅 GRANT DATABASE ROLE。
例如,将 SNOWFLAKE 数据库的 IMPORTED PRIVILEGES 权限授予两个额外的角色:
USE ROLE ACCOUNTADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SYSADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE customrole1;
获授 customrole1
角色的用户可按如下方式查询视图:
USE ROLE customrole1; SELECT database_name, database_owner FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASES;
有关其他示例,请参阅 查询 Account Usage 视图。
ACCOUNT_USAGE 架构 SNOWFLAKE 数据库角色¶
此外,您可以使用 SNOWFLAKE 数据库角色对账户进行更精细的控制。有关数据库角色的更多信息,请参阅 数据库角色。
ACCOUNT_USAGE 架构有四个已定义的 SNOWFLAKE 数据库角色,每个角色均被授予特定视图的 SELECT 权限。
角色 |
目的和描述 |
---|---|
OBJECT_VIEWER |
OBJECT_VIEWER 角色提供对对象元数据的可见性。 |
USAGE_VIEWER |
USAGE_VIEWER 角色提供对历史使用信息的可见性。 |
GOVERNANCE_VIEWER |
GOVERNANCE_VIEWER 角色提供对策略相关信息的可见性。 |
SECURITY_VIEWER |
SECURITY_VIEWER 角色提供对基于安全的信息的可见性。 |
按数据库角色划分的 ACCOUNT_USAGE 视图¶
OBJECT_VIEWER、USAGE_VIEWER、GOVERNANCE_VIEWER 和 SECURITY_VIEWER 角色具有在共享 SNOWFLAKE 数据库中查询 Account Usage 视图的 SELECT 权限。
复选标记(即 ✔)表示该角色已被授予视图的 SELECT 权限。
视图 |
OBJECT_VIEWER 角色 |
USAGE_VIEWER 角色 |
GOVERNANCE_VIEWER 角色 |
SECURITY_VIEWER 角色 |
---|---|---|---|---|
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
READER_ACCOUNT_USAGE 架构 SNOWFLAKE 数据库角色¶
READER_USAGE_VIEWER SNOWFLAKE 数据库角色已被授予所有 READER_ACCOUNT_USAGE 视图的 SELECT 权限。由于阅读者账户由客户创建,READER_USAGE_VIEWER 角色预计会被授予那些用于监控阅读者账户使用情况的角色。
视图 |
---|
查询 Account Usage 视图¶
本部分包括查询 Account Usage 视图时的注意事项以及查询示例。
选择列¶
Snowflake 特定的视图可能会发生变化。避免从这些视图中选择所有列。相反,请选择所需的列。例如,如果您想选择 name
列,请使用 SELECT name
,而不是 SELECT *
。
费用核对视图¶
有多个 Account Usage 视图,其中包含与计算资源、存储和数据传输费用相关的数据。如果您尝试将这些视图与 ORGANIZATION_USAGE 架构 进行核对,则必须首先将会话的时区设置为 UTC。
例如,如果您要尝试将 ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY 与 ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY 中的账户数据进行核对,则在查询 Account Usage 视图之前,必须运行以下命令:
ALTER SESSION SET TIMEZONE = UTC;
示例¶
以下示例显示了使用 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()
替换为仓库名称,以计算该仓库的指标。此外,更改 WITH 子句中的 time_from
和 time_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。观察比率变化或与平均值的偏差。
如果 QUEUED_RATIO 较高,则可能代表仓库容量不足。添加更多群集或增加仓库大小。
示例:仓库 Credit 使用量¶
账户中每个仓库使用的 credit(月初至今):
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;
账户中每个仓库在一段时间内使用的 credit(月初至今):
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;
示例:数据存储的使用情况¶
在一段时间内,账户中存储的可计费数据 TB 数:
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 ;