优化成本¶
本主题讨论如何优化 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;
- 洞察：超过 100GB 且写入数据但未读取数据的表
该洞察可识别此账户在过去一周内未查询过的大型表。
建议： 如果数据从未读取，则存储数据并将新数据引入 Snowflake，这样可能就有点浪费了。考虑删除这些表以节省存储成本，或者停止写入新数据以节省引入使用的 credit。在删除表之前，请确定该表是仅用于灾难恢复目的，还是通过数据共享供其他 Snowflake 账户使用，这也许可以解释为什么没有读取该表。
例如，要删除名为
t1的表，请执行以下命令：DROP TABLE t1;
- 洞察：短期永久表
该洞察可识别在创建后 24 小时内删除且大小超过 100 GB 的表。
建议： 如果只需要在短时间内持久化数据，可考虑为未来的表使用 临时表或瞬态表。使用临时表或瞬态表可能会帮助您节省 故障安全和 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 支持这些查询，并且只对使用的资源收费。