优化成本¶
本主题讨论如何优化 Snowflake 以降低成本并最大限度地增加支出。
成本洞察：寻找节约机会¶
Snowflake 提供成本洞察，可识别在特定账户内优化 Snowflake 成本的机会。这些洞察每周都会进行计算和更新。
每个洞察都表明通过优化 Snowflake 可以节省多少 credit 或 TBs。
备注
您必须获授 ACCOUNTADMIN 角色才能查看成本洞察。
要访问 Cost Insights 磁贴，请执行以下操作：
登录 Snowsight。
切换到 ACCOUNTADMIN 角色。
在导航菜单中，选择 Admin » Cost Management。
选择 Account Overview 选项卡。
找到 Cost insights 磁贴。
以下每个洞察都包括如何优化支出的建议。
- 洞察：很少使用的支持自动聚类的表
该洞察可识别使用 自动聚类 的表，这些表每周被此账户查询的次数少于 100 次。
为表启用自动聚类可以显著提高针对该表的查询性能。不过，随着表的变化，Snowflake 必须使用无服务器计算资源来使其保持良好的聚类状态。如果对表执行的查询次数很少，所产生的成本可能不足以证明性能提升的合理性。
建议： 考虑禁用这些表的自动聚类。在关闭自动聚类之前，请确定表是否仅为灾难恢复目的而存在，或通过数据共享供其他 Snowflake 账户使用，这可能解释了该表不经常被访问的原因。
例如，要禁用名为
t1的表的自动聚类，请执行以下命令：ALTER TABLE t1 SUSPEND RECLUSTER;
- 洞察：很少使用的物化视图
该洞察可识别每周被此账户查询少于 10 次的 物化视图。
创建物化视图可以显著提高某些查询模式的性能。不过，物化视图会产生额外的存储成本，以及与保持物化视图与新数据同步相关的无服务器计算成本。如果对物化视图执行的查询次数很少，所产生的成本可能不足以证明性能提升的合理性。
建议： 考虑移除或暂停更新物化视图。在删除物化视图之前，请确定表是否仅为灾难恢复目的而存在，或通过数据共享供其他 Snowflake 账户使用，这可能解释了该表不经常被访问的原因。
例如，要删除名为
mv1的物化视图，请执行以下命令：DROP MATERIALIZED VIEW mv1;
- 洞察：很少使用的搜索优化路径
该洞察可识别每周被此账户使用少于 10 次的 搜索优化 搜索访问路径。
搜索优化使用搜索访问路径来提高某些类型的点查找和分析查询的性能。为表添加搜索优化可以显著提高这些查询的性能。然而，搜索优化会产生额外的存储成本，以及与保持存储更新相关的无服务器计算成本。如果使用由搜索优化创建的搜索访问路径的查询次数很少，所产生的成本可能不足以证明性能提升的合理性。
建议： 考虑从表中删除搜索优化。在删除搜索优化之前，请确定表是否仅为灾难恢复目的而存在，或通过数据共享供其他 Snowflake 账户使用，这可能解释了该表不经常被访问的原因。
例如，要从名为
t1的表中完全删除搜索优化，请执行以下命令：ALTER TABLE t1 DROP SEARCH OPTIMIZATION;
- 洞察：从未查询过的大型表
该洞察可识别该账户在过去一周内未查询过的大型表。
建议： 考虑删除未使用的表，这样可以降低存储成本，而不会影响任何工作负载。在删除这些表之前，请确定表是否仅为灾难恢复目的而存在，或通过数据共享供其他 Snowflake 账户使用，这可能解释了该表不经常被访问的原因。
例如，要删除名为
t1的表，请执行以下命令：DROP TABLE t1;
- 洞察：连续查询之间存在较大间隔的活动仓库
该洞察可识别已禁用自动暂停设置或将值设置为大于一分钟的仓库。此外，这些仓库必须至少有一个使用间隔大于自动暂停时间。
启用仓库自动暂停设置后，仓库在规定时间内不活动时会自动关闭。暂停的仓库不会消耗 credit，因此该仓库仅在处理工作负载时产生成本。
建议： 一般来说，应启用所有仓库的自动暂停设置。启用仓库设置或调整其自动暂停时间：
登录 Snowsight。
选择 Admin » Warehouses。
找到仓库，选择 ...，然后选择 Edit。
选择 Auto suspend。
要调整自动暂停时间，请修改 Suspend After 字段。
选择 Save Warehouse。
- 洞察：短期永久表
该洞察可识别出在创建后 24 小时内被删除的大小超过 100GB 的表。
建议： 如果只需要在短时间内持久化数据，可考虑为未来的表使用 临时表或瞬态表。使用临时表或瞬态表可能会帮助您节省 故障安全和 Time Travel 成本。
例如，要创建一个新的瞬态表
t1，请执行以下命令：CREATE TRANSIENT TABLE t1;
优化云服务成本¶
如果您发现 云服务使用量 高于预期，请检查您对 Snowflake 的使用是否遵循以下任一模式。每种模式都包含一项建议，可帮助您降低与云服务相关的成本。
- 模式：事务锁导致查询受阻
更新和合并命令会在表上加一个事务锁，在释放锁之前，其他命令无法在该表上执行。查询在等待锁释放的过程中会使用云服务 credit。查询在云服务层等待锁定的时间越长，使用的 credit 就越多。
建议： 当用户在单个表上并发运行更新/合并命令时，尤其是当每个命令只更新几行时，经常会出现事务锁。通过使用批处理命令而不是单个更新，可以最大限度地减少这些锁。在该策略中，您将执行以下操作：
使用批处理 INSERT 语句将新数据加载到临时表中。避免使用单行插入即使是连续加载新数据的 API 调用，其设计方式也应是提交批处理插入，而不是单行插入。
使用临时表更新/合并目标表。
如果数据源全天不断发送新数据，可考虑使用 任务 定期更新目标表。
- 模式：选择性较差的复制命令
执行复制命令需要列出 Amazon Simple Storage Service (S3) 中的文件。由于列出文件只使用云服务计算，因此执行选择性较差的复制命令会增加云服务使用量。
建议： 考虑更改 S3 桶的结构，使其包含某种日期前缀，以便只列出所需的目标文件。
- 模式：高频率 DDL 操作和克隆
数据定义语言 (DDL) 操作，尤其是克隆，完全是元数据操作，这意味着它们只使用云服务计算。经常创建或删除大型架构或表，或克隆数据库进行备份，都会导致大量云服务使用量。
建议： 克隆仅使用深度复制所需资源的一小部分，因此您应该继续克隆。审查您的克隆模式，确保它们尽可能细化，并且不会被过于频繁地执行。例如，您可能只想克隆单个表，而不是整个架构。
- 模式：高频率、简单查询
单个简单查询的云服务使用量可以忽略不计，但以极高频率（每天数万次）运行
SELECT 1、SELECT sequence1.NEXTVAL或SELECT CURRENT_SESSION()等查询会产生极大的云服务使用量。建议： 审查您的查询频率，并确定频率设置是否适合您的用例。如果发现使用 JDBC 驱动程序的合作伙伴工具产生的
SELECT CURRENT_SESSION()查询频率很高，请确认合作伙伴已更新其代码，以使用 SnowflakeConnection 接口 中的getSessionId()方法。这样可以利用缓存，减少云服务的使用量。
- 模式：高频率 INFORMATION_SCHEMA 查询
针对 Snowflake Information Schema 的查询只使用云服务资源。针对 INFORMATION_SCHEMA 视图的单次查询对云服务的使用量可能可以忽略不计，但以极高的频率（每天数万次）运行这些查询，会导致大量云服务使用量。
建议： 审查您的查询频率，并确定频率设置是否适合您的用例。另外，也可以查询 ACCOUNT_USAGE 架构 中的视图，而不是 INFORMATION_SCHEMA 视图。查询 ACCOUNT_USAGE 架构使用的是虚拟仓库而不是云服务。
- 模式：高频率 SHOW 命令（由数据应用程序和第三方工具发出）
SHOW 命令完全是元数据操作，这意味着它们只使用云服务计算。这种模式通常发生在您在 Snowflake 之上构建的应用程序高频率执行 SHOW 命令时。这些命令也可能由第三方工具启动。
建议： 审查您的查询频率，并确定频率设置是否适合您的用例。如果是合作伙伴的工具，请与合作伙伴联系，了解他们是否有调整使用量的计划。
- 模式：单行插入和碎片化架构（由数据应用程序提供）
Snowflake 并非 OLTP 系统，因此单行插入并不理想，而且会使用大量云服务资源。
若构建一个为每个客户定义一个架构的数据应用程序，可能会导致在给定时间段内出现多个数据负载，从而造成云服务的高使用量。
这种模式也使得 Snowflake 需要维护更多的元数据，而元数据操作会使用云服务资源。每个元数据操作单独使用的资源极少，但总体使用量可能很大。
建议： 一般情况下，进行批处理或批量加载，而不是单行插入。
使用共享架构可大大提高效率，从而节省成本。您可能希望基于
customer_ID对所有表进行聚类，并使用 安全视图。
- 模式：复杂 SQL 查询
如果查询包含大量联接/笛卡尔积、使用 IN 运算符和大型列表，或者是超大型查询，则会使用大量云服务计算。这些查询类型的编译时间都比较长。
建议： 审查您的查询，以确认它们正在按照您的意图进行操作。Snowflake 支持这些查询，并且只对使用的资源收费。