2. 虚拟仓库选型与弹性伸缩工程

虚拟仓库是 Snowflake 中真正执行计算资源的单元，它决定了查询的并发能力、单查询的算力上限以及成本消耗速度。数据建模再合理，如果仓库选型与伸缩策略不匹配工作负载，性能与成本都会失控。本节围绕四个工程问题展开：按负载类型选仓库规模、用多集群仓库承接并发、用自动挂起与恢复控制空闲成本、用资源监控把成本关进笼子。

一、先分清工作负载类型，再谈规模

Snowflake 仓库规模从 XS 到 6XL，每升一级计算资源翻倍，计费也近似翻倍（按秒计费，最低 60 秒）。规模选择的核心不是“越大越快”，而是判断负载属于哪一类：

• 交互式分析（BI 看板、即席查询）：单查询数据量中等，但对延迟敏感，且并发用户多。重点在并发，而非单查询极限速度。
• 批量 ETL/ELT：单条语句处理海量数据，通常并发低。重点在单查询算力，加规模收益明显。
• 混合负载：白天 BI、夜间 ETL。应通过多仓库隔离，而不是一个仓库硬扛。

一个实用的判断方法是看查询的“并行度瓶颈”。如果一条查询在 XS 上耗时 10 分钟，升到 M 后降到 5 分钟，说明它可被更多计算节点并行拆分，继续升规模仍有收益；如果升到 L 后只降到 4.5 分钟，说明已接近单查询并行上限，再加规模是浪费。经验上，ETL 类大查询升规模收益显著，而大量小查询升规模几乎无感——它们需要的是更多集群，而不是更大的集群。

二、多集群仓库：用集群数承接并发

多集群仓库（Multi-Cluster Warehouse, MCW）解决的是“并发排队”问题。当单集群的查询队列变长、排队时间上升时，Snowflake 自动拉起额外集群，让新查询落到空闲集群上执行。关键参数有三个：

• 最小集群数（MIN_CLUSTER_COUNT）：常驻集群数量。设为 1 表示空闲时保留一个集群，设为 0 表示可缩到零（需配合自动挂起）。
• 最大集群数（MAX_CLUSTER_COUNT）：并发高峰的上限，决定成本天花板。
• 扩展模式（SCALING_POLICY）：STANDARD 偏向快速扩容、优先降延迟；ECONOMY 偏向保守扩容、优先省成本。

配置示例（BI 仓库，预期 20～30 并发用户）：

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

-- ETL 仓库：单查询重、并发低，用大集群单实例
CREATE OR REPLACE WAREHOUSE ETL_WH
  WAREHOUSE_SIZE = 'LARGE'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 1
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

注意：多集群仓库的每个集群都是独立计费的。MAX_CLUSTER_COUNT=4 意味着峰值成本是单集群的 4 倍。因此最大集群数应基于“可接受的峰值成本”反推，而不是拍脑袋设大。

三、自动挂起与恢复：把空闲成本压到最低

仓库空闲时仍在计费，自动挂起（AUTO_SUSPEND）是成本控制的第一道闸门。它有两个关键点：

• 挂起延迟：从最后一次查询结束到仓库挂起的秒数。设得太短，查询间隙频繁挂起/恢复，恢复有约几秒冷启动延迟，影响体验；设得太长，空闲计费累积。
• 最低计费 60 秒：即使仓库只运行 10 秒就挂起，也按 60 秒计费。因此对“查询间隔短于 60 秒”的场景，频繁挂起反而更贵。

经验取值：BI 仓库设 300 秒（5 分钟），因为用户操作间隙通常在这个量级；ETL 仓库设 60 秒，因为批处理任务之间往往有较长间隔，且任务本身运行时间长，冷启动影响可忽略。自动恢复（AUTO_RESUME）应始终开启，否则用户查询会直接报错。

四、资源监控与成本控制

Snowflake 提供资源监视器（Resource Monitor）对仓库用量设阈值告警或直接挂起。建议按“仓库分组 + 月度配额”配置：

CREATE OR REPLACE RESOURCE MONITOR RM_BI_MONTHLY
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE BI_WH SET RESOURCE_MONITOR = RM_BI_MONTHLY;

阈值设计上，75% 通知用于提前预警，90% 再次通知留出调整窗口，100% 挂起是硬止损。注意 DO SUSPEND 会中断正在运行的查询，生产环境应谨慎，或改用 DO SUSPEND_IMMEDIATE 的替代策略（先通知、人工介入）。

日常监控应关注三个视图：WAREHOUSE_METERING_HISTORY（仓库信用点消耗）、QUERY_HISTORY（查询排队与执行时间）、WAREHOUSE_LOAD_HISTORY（仓库负载与排队情况）。当 WAREHOUSE_LOAD_HISTORY 显示“排队查询数”持续大于 0，说明并发已超出现有集群能力，应考虑提高 MAX_CLUSTER_COUNT 或改用更大规模。

五、一个可复用的选型与调优流程

把上述内容串成可执行流程：

1. 分类：把现有查询按 BI、ETL、混合三类归入不同仓库，避免互相干扰。
2. 定规模：ETL 从 LARGE 起步，BI 从 MEDIUM 起步，用真实查询测响应时间，观察升规模是否带来线性收益。
3. 定并发：BI 仓库设 MAX_CLUSTER_COUNT，观察 WAREHOUSE_LOAD_HISTORY 排队数，逐步调整到排队基本为 0。
4. 定挂起：BI 设 300 秒，ETL 设 60 秒，用计量历史验证空转比例。
5. 设配额：按仓库组配置资源监视器，75%/90% 通知，100% 挂起。
6. 持续复盘：每周看一次信用点消耗与查询性能趋势，负载结构变化时重新回到第 1 步。

虚拟仓库工程化的本质，是让计算资源随负载形态变化而伸缩，同时用配额和监控守住成本底线。选型不是一次性的，而是随业务负载演进而持续调整的过程。