有没有优化的方法来识别 Snowflake 中长时间运行的查询?我注意到的是,查询information_schema.query_history
无论是否提供参数值,都会对产生的成本没有影响。
背景: 我们有一个 AWS lambda,它定期运行以利用 information_schema.query_history
来查找任何长时间运行的查询。但是每次执行都会花费 0.18 信用,无论您向参数提供的值如何end_time_range_start
等,以限制您返回的数据。
因此,这两个查询将产生相同的成本。
table(
information_schema.query_history
(
end_time_range_start=> dateadd('minutes',-5,current_timestamp()),
result_limit=>100
)
)
table(information_schema.query_history(result_limit=>100))
注意:我们已经使用 STATEMENT_TIMEOUT_IN_SECONDS
在仓库级别设置查询持续时间的限制。此外,我们制定了资源监视器来限制使用的配额,但我们需要一个更精细的解决方案来提醒我们是否有人运行长时间运行的查询。
您可以查询 SNOWFLAKE。ACCOUNT_USAGE。直接QUERY_HISTORY以更好地控制返回给您的查询。 这包含 1 年的数据,但在那里显示的数据最多有 45 分钟的延迟。
https://docs.snowflake.net/manuals/sql-reference/account-usage/query_history.html
在成本方面,如果您利用最常用于执行查询的仓库,那么它实际上不会花费您任何额外的积分。 如果可以的话,我会考虑切换到那个仓库。
访问视图SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
的查询修剪似乎仅在过滤START_TIME
时才有效,而不是END_TIME
。
因此,我不得不更改我的"每天保存查询历史记录"过程,
将执行时间加快> 4 倍。
我这样做的方法是先运行SHOW WAREHOUSES
。这不使用仓库,并允许您查看是否有任何仓库正在运行。如果没有正在运行,那么您肯定没有长时间运行的查询*,您可以在此处停止。如果有任何正在运行,那么您可以在该仓库上投机执行query_history查询,而不会产生 1 分钟的最低罚款。
有了这个,您应该能够以几乎零额外费用进行此运行。
*一个例外可能是,如果你有一个需要很长时间编译的查询 - 如果你担心这一点,那么这种方法将不起作用。