3. 虚拟仓库的创建与配置实战

虚拟仓库是 Snowflake 中真正执行查询的计算资源，它不存储数据，只提供 CPU、内存和临时缓存。理解虚拟仓库的创建与配置，是成本优化的起点：仓库大小决定单集群算力，自动挂起与自动恢复决定空闲时是否烧钱，初始集群数与多集群扩展策略决定并发高峰时如何弹性伸缩。本章围绕这五个配置维度，给出可直接落地的创建语句与参数判断方法。

一、创建标准仓库：从一条 CREATE 语句开始

创建仓库使用 CREATE WAREHOUSE。一个最小可用的标准仓库如下：

CREATE WAREHOUSE IF NOT EXISTS wh_etl_small
  WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 1
  SCALING_POLICY = 'STANDARD'
  COMMENT = 'ETL 批处理专用，小规模';

其中 INITIALLY_SUSPENDED = TRUE 表示创建后不立即启动，避免刚建好就产生费用；AUTO_RESUME = TRUE 表示有查询提交时自动唤醒。这两项配合，使仓库在无人使用时保持零计算成本。创建完成后可用 SHOW WAREHOUSES 查看状态，或用 ALTER WAREHOUSE 修改任意参数，无需重建。

二、设置仓库大小：算力与成本的线性关系

仓库大小由 WAREHOUSE_SIZE 控制，从 XSMALL 到 6XLARGE 共多个档位。每提升一档，计算节点数量翻倍，算力约翻倍，单位时间信用点消耗也约翻倍。关键判断依据是：大仓库不一定更贵。若一个查询在小仓库跑 10 分钟，在大仓库可能 2.5 分钟完成，信用点消耗反而可能持平甚至更低，同时释放了并发资源。

选择大小的实用方法：先用 XSMALL 或 SMALL 跑代表性查询，记录执行时间；若查询受限于单节点算力（如大表扫描、复杂聚合），逐级放大观察时间是否近似减半。当放大后时间不再明显下降，说明瓶颈已转移到 I/O 或数据倾斜，继续加大仓库只是浪费。下表给出常见档位与相对算力的对照，信用点数值为示例假设，实际以 Snowflake 官方计费为准。

三、自动挂起与自动恢复：空闲成本的第一道闸门

AUTO_SUSPEND 定义仓库在无活动多少秒后自动挂起，单位是秒，设为 0 表示永不自动挂起。AUTO_RESUME 定义有新查询时是否自动唤醒。二者是成本控制中最直接的两个开关。

设置原则：交互式 BI 查询场景，用户可能随时点刷新，挂起时间可设 300～600 秒，避免频繁启停带来的冷启动等待；批处理 ETL 场景，任务集中且间隔明确，可设 60 秒甚至更短，任务结束立即释放算力。需要注意的是，挂起后再次恢复有数秒冷启动，若查询间隔短于挂起时间，反而会反复启停，此时应适当延长 AUTO_SUSPEND。

四、初始集群数与多集群扩展策略

当单集群算力不足以支撑并发查询时，Snowflake 通过多集群仓库横向扩展。MIN_CLUSTER_COUNT 是常驻集群数，MAX_CLUSTER_COUNT 是并发高峰时可扩展到的上限。当 MAX_CLUSTER_COUNT > 1 时，仓库进入多集群模式。

扩展策略由 SCALING_POLICY 决定：

• STANDARD：只要有查询排队就立即增加集群，追求低延迟，适合对响应时间敏感的交互场景，但可能因短时波动多开集群。
• ECONOMY：等待约 6 分钟，若排队持续才扩展，更节省信用点，适合批处理或对延迟不敏感的并发负载。

配置示例：一个面向 BI 的仓库，希望平时 1 个集群、高峰最多 4 个集群、优先低延迟：

CREATE WAREHOUSE wh_bi_multi
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4
  SCALING_POLICY = 'STANDARD'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE;

多集群的计费逻辑是：每个运行中的集群独立计费。若高峰时扩展到 4 个集群并持续 1 小时，按 MEDIUM 每小时 4 信用点计算，该小时消耗约 16 信用点。因此 MAX_CLUSTER_COUNT 不是越大越好，应结合并发查询数和可接受延迟来设定。若并发主要来自少量长查询，加大单集群大小往往比多开集群更划算；若并发来自大量短查询，多集群扩展更有效。

五、配置后的验证与调整

仓库创建并运行一段时间后，应回到数据中验证配置是否合理。常用手段包括：查询 QUERY_HISTORY 观察各仓库的平均排队时间与执行时间；查询 WAREHOUSE_LOAD_HISTORY 观察仓库活跃与空闲时段；查询 WAREHOUSE_METERING_HISTORY 查看信用点消耗趋势。若发现某仓库长期空闲却未挂起，检查 AUTO_SUSPEND 是否被设为 0；若发现频繁启停，适当延长挂起时间；若发现排队严重但 MAX_CLUSTER_COUNT 已到上限，考虑提高上限或改用 ECONOMY 策略平衡成本。