策略与最佳实践 9 分钟阅读高级

2026年云数据仓库成本优化实战指南：Snowflake/BigQuery/Redshift省钱全攻略

把Snowflake、BigQuery、Redshift的年度账单砍掉40-70%？三管齐下：Snowflake虚拟仓库激进auto-suspend、BigQuery Editions槽预留、Redshift RA3或Serverless。附2026最新定价机制、告警规则、右调SQL与FinOps治理清单，含多个真实客户案例总结。

Sara Al-Mahmoud审校 Jordan Reeves, Jul 2026
云数仓成本优化指南：Snowflake/BQ/Redshift 2026

最后更新：2026年7月31日

云数据仓库成本优化的核心，其实就是把计算与存储解耦之后，按秒计费的资源精准匹配到查询负载。三管齐下（Snowflake 虚拟仓库设置激进的 auto-suspend、BigQuery 采购 Editions 槽预留、Redshift 迁移到 RA3 或 Serverless），多数团队都能在不牺牲 SLA 的前提下，把年度数仓账单压缩 40%–70%。这份指南面向多账户、多区域的复杂数据平台，给出 2026 年最新版本的定价机制、告警规则、右调 SQL 与治理清单。我会把这几年在金融、SaaS、广告平台踩过的坑一并写进来，方便你少走弯路。

  • Snowflake 2026 年 auto-suspend 最小粒度已降至 30 秒，配合按秒计费，开发仓库月度账单能降 55% 以上。
  • BigQuery Editions（Standard/Enterprise/Enterprise Plus）加上槽 Autoscaler 取代了旧版 Flat-Rate，1 年承诺再省 20%，3 年承诺再省 40%。
  • Redshift RA3 + Managed Storage 让存储按 GB 独立计费；Serverless 模式按 RPU-小时计费，最小 8 RPU，以 8 RPU 为增量伸缩。
  • 查询级成本归因（Query Tag、Job Labels、Query Group）是数仓 FinOps 的第一性原理，比 tag 更精细。
  • 物化视图、结果缓存、聚簇/分区键这三大免费的降本杠杆，落地成本不高，但常被忽略。
  • ML 驱动的自动化推荐（Snowflake Cortex Cost Insights、BigQuery Recommender、Redshift Advisor）已经是 2026 年 FinOps 的标配。

Snowflake、BigQuery、Redshift 2026 年定价模型对比

要谈优化，先得谈计费单位。三家云数仓的定价范式差异其实很大。Snowflake 按信用点（credit）计费虚拟仓库的计算时长；BigQuery 采用按 TB 扫描（On-demand）或按槽-小时（Editions）双轨；Redshift 则从传统按节点小时过渡到 RA3 + Managed Storage 与 Serverless按 RPU-小时。理解每种模型的最小计费粒度、承诺折扣，以及存储/计算解耦程度，是选型和优化的第一步。

维度Snowflake（2026）BigQuery（2026）Redshift（2026）
计费单位Credit（按仓库大小 × 秒）TB 扫描量 或 Slot-小时节点-小时 或 RPU-小时
最小计费粒度60 秒起算，随后按秒10 MB 起（On-demand）；1 秒（Editions）1 秒（RA3/Serverless）
Auto-Suspend 最小值30 秒不适用（无常驻集群）Serverless 自动挂起（1 分钟）
承诺折扣Capacity（预付）最多 30%+1 年 20%、3 年 40%Reserved Node 1 年 30%、3 年 60%
存储计费$23/TB/月（美区，压缩后）$20/TB/月（Active）$10（Long-term）$24/TB/月（Managed Storage）
ML 成本推荐Cortex Cost InsightsBigQuery RecommenderAmazon Redshift Advisor
典型甜点突发型 BI、Data App大规模即席查询 + ML常态化 ETL、企业数仓

三个平台在 2026 年都进一步细化了计算与存储的解耦。Snowflake 支持从存储层单独订阅 Iceberg External Tables；BigQuery 允许把 Storage 计费独立在 project.location 级；Redshift RA3 让 SSD 缓存与 S3 Managed Storage 分离，冷数据自动下沉。这个趋势意味着 2026 年的成本优化重心，正从"节点砍半"转向"查询/仓库/存储三维分析"。多账户成本归因方案的完整做法，可以看我之前写的云成本标签与成本分摊实战指南。

Snowflake 成本优化：虚拟仓库、Resource Monitor 与 Query Tag

Snowflake 90% 以上的账单都来自虚拟仓库（Virtual Warehouse）的运行时长。X-Small 每小时 1 credit，而 4X-Large 每小时 128 credit，也就是说同一条 SQL 在错误的仓库上跑，成本可以差 128 倍（是的，真的是 128 倍）。这一节我会给出在多个金融和 SaaS 客户上验证过的四板斧：激进 auto-suspend、按团队拆仓、Query Tag 归因、Resource Monitor 熔断。

1. 把 Auto-Suspend 调到 60 秒或更低

2024 年默认值仍是 600 秒；2026 年 ALTER WAREHOUSE 已经允许把 AUTO_SUSPEND 降到 30 秒。对开发/BI 仓库，我推荐 60 秒；对 Airflow 等间断触发的 ETL，推荐 30 秒。示例：

-- 把 BI 团队仓库改成积极挂起 + 弹性并发
ALTER WAREHOUSE BI_WH SET
    WAREHOUSE_SIZE      = 'MEDIUM'
    AUTO_SUSPEND        = 60           -- 秒
    AUTO_RESUME         = TRUE
    MIN_CLUSTER_COUNT   = 1
    MAX_CLUSTER_COUNT   = 4            -- 多集群并发
    SCALING_POLICY      = 'ECONOMY';   -- ECONOMY 更省，STANDARD 更快

陷阱：短时挂起会略微增加冷启动感知；对时延敏感的Data App，需要评估 300–600 ms 的冷启动能否接受。我上个季度就遇到过一个电商实时看板，把 auto-suspend 从 300 秒改到 30 秒之后，账单降了 40%，但 P95 冷启动多了大概 500 ms，最后折中在了 120 秒。

2. 用 Query Tag 做查询级成本归因

Tag 挂在仓库/角色上只能拿到粗粒度账单，真正的归因要靠 QUERY_TAG。做法很简单：在会话级设置团队/流水线名，然后从 ACCOUNT_USAGE.QUERY_HISTORY 聚合。

-- 在会话开头打标签（可从 dbt profiles 或 Airflow operator 注入）
ALTER SESSION SET QUERY_TAG = '{"team":"marketing","pipeline":"attribution_daily"}';

-- 按 Query Tag 聚合可归因的 credit 消耗
SELECT
    PARSE_JSON(query_tag):team::string   AS team,
    PARSE_JSON(query_tag):pipeline::string AS pipeline,
    SUM(credits_used_cloud_services + credits_used) AS total_credits
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 3 DESC;

3. Resource Monitor：给账单装个熔断器

2025 年年底那次"某 BI 报表死循环烧掉 $18k"事故（真事，客户找上门时账单已经在跑第二天），让我把这个作为治理红线。Resource Monitor 支持在 credit 达到阈值时挂起仓库，是最后一道防线。

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

ALTER WAREHOUSE BI_WH SET RESOURCE_MONITOR = BI_MONTHLY;

4. 别忘了 Cortex Cost Insights

Snowflake 在 2026 年把 Cortex Cost Insights 从 Preview 转正，可以基于最近 90 天的查询画像自动推荐仓库尺寸和 auto-suspend。我实测在一个 40 TB 的电商仓库上给出的推荐能再省 12%，且推荐值可以一键 apply。类似的 AI 驱动自动化推荐思路，我在AI 驱动的 FinOps 指南里有更系统的介绍。

BigQuery 成本优化：Editions、槽预留与查询分析

BigQuery 的历史包袱是"扫描 1 TB 付 $6.25"的 On-demand 模型，查询写不好可以在几分钟内烧掉几千美元（说实话，我第一次遇到这种情况的时候整个人是懵的）。2026 年主推的 Editions 模型（Standard / Enterprise / Enterprise Plus）把定价切换成槽（Slot）- 小时：Standard $0.04/slot-hour、Enterprise $0.06、Enterprise Plus $0.10。搭配 Autoscaler 与承诺折扣，稳定负载下比 On-demand 便宜 40%–60%。

1. 什么时候切 On-demand，什么时候切 Editions

  • 扫描量 < 10 TB/月：继续 On-demand，享受 1 TB/月免费额度。
  • 扫描量 10–100 TB/月且波峰明显：Enterprise Edition + Autoscaler，baseline 100 slots + max 500 slots。
  • 扫描量 > 100 TB/月或需要 CMEK/Data Governance：Enterprise Plus + 1 年承诺，起步 500 baseline。

2. 用 Reservation 与 Autoscaler 切分工作负载

Editions 的核心是把槽划成 reservation，不同项目/团队分不同预留，避免"批处理挤兑 BI"这种事情。示例（bq CLI）：

# 创建 Enterprise Edition 容量承诺
bq mk --project_id=my-proj \
      --location=us \
      --capacity_commitment \
      --plan=ANNUAL \
      --edition=ENTERPRISE \
      --slots=500

# 创建 reservation 并把 baseline/max 分给 BI 项目
bq mk --project_id=my-proj \
      --location=us \
      --reservation \
      --slots=100 \
      --autoscale_max_slots=400 \
      bi_reservation

# 把 project 分配到 reservation
bq mk --project_id=my-proj \
      --location=us \
      --reservation_assignment \
      --reservation_id=bi_reservation \
      --job_type=QUERY \
      --assignee_id=my-bi-project \
      --assignee_type=PROJECT

3. 查询级瘦身：分区、聚簇、SELECT 列

下面这四个模式在过去一年里，帮我把某广告平台的 BigQuery 账单砍掉了 62%：

  • 用 _PARTITIONTIME 过滤：把 WHERE date >= '2026-07-01' 换成 WHERE _PARTITIONDATE >= '2026-07-01' 才能真正裁剪分区。
  • 聚簇键放在 WHERE 顺位第一：只有聚簇字段的过滤才走 block pruning。
  • 禁用 SELECT *：BigQuery 按列计费，列越多扫描越贵。
  • 物化视图（Materialized Views）：常见聚合走 MV 走缓存，能省 5–10 倍。

4. BigQuery Recommender 的三条自动化推荐

BigQuery Recommender 在 2026 年可以给出：分区/聚簇建议、capacity-commitment 建议、reservation right-sizing 建议。可以通过 gcloud recommender recommendations list 定期拉取到 Data Studio 面板做治理。我自己习惯把它跑成一个每周五的 cron 任务，Slack 通知给 FinOps 频道，问责起来简单直接。

Redshift 成本优化：RA3、Serverless 与并发缩放

Redshift 是三家里最"传统"的产品，但 2026 年也彻底转向存算解耦。RA3 + Managed Storage 让你按 GB 单独付存储费；Serverless 按 RPU（Redshift Processing Unit）小时计费，起步 8 RPU、$0.375/RPU-小时（us-east-1）。选型逻辑主要看两个维度：负载稳定性与治理复杂度。

1. DC2/DS2 迁移到 RA3 的 3 步走

  1. 用 ANALYZE COMPRESSION 摸清当前存储画像，估算迁移后的 Managed Storage 费用。
  2. 使用 Elastic Resize 或 Classic Resize 迁移；RA3 的最小节点数为 2。
  3. 迁移后开启 Automatic WLM，让 Redshift 用 ML 自动分配内存与并发。

2. Redshift Serverless：什么时候适合

Serverless 的甜点是不可预测的、间歇性的分析负载，比如季度盘点、事件驱动的 Lakehouse 查询。缺点是最小 8 RPU 意味着"启动一次至少烧几美元"，不适合秒级碎片查询。示例 CLI：

# 创建 Serverless namespace + workgroup
aws redshift-serverless create-namespace \
    --namespace-name analytics-ns \
    --admin-username admin \
    --admin-user-password 'REDACTED'

aws redshift-serverless create-workgroup \
    --workgroup-name analytics-wg \
    --namespace-name analytics-ns \
    --base-capacity 32 \
    --max-capacity 128 \
    --config-parameters parameterKey=auto_mv,parameterValue=true

# 设置每日成本上限（Usage Limit）作为熔断器
aws redshift-serverless create-usage-limit \
    --resource-arn "arn:aws:redshift-serverless:us-east-1:123456789012:workgroup/analytics-wg" \
    --usage-type "serverless-compute" \
    --amount 200 \
    --period daily \
    --breach-action deactivate

3. Reserved Node 承诺折扣的采买节奏

对稳态 Redshift Cluster 集群，Reserved Node 是最直接的降本手段：1 年 All-Upfront 约 30% 折扣，3 年 All-Upfront 约 60%。我一般用"三段式采买"的思路，先按 baseline 采 3 年，再按季度覆盖 6 个月的增量。承诺策略与 EC2 类似，可以参考之前那篇AWS Savings Plans vs Reserved Instances 对比。

4. Concurrency Scaling 与 Data Sharing

Concurrency Scaling 每 24 小时提供 1 小时免费额度，可以吸收高并发，但要注意 concurrency_scaling 需要设为 auto。Data Sharing 让生产集群与 BI 集群通过共享 datashare 隔离负载，避免 BI 拖垮 ETL，这是我在多账户架构里必开的一项。

如何降低云数据仓库成本？12 条通用杠杆

无论用哪家数仓，下面这 12 条几乎都能立刻见效。我按落地成本从低到高排列，先做前 6 条通常就能实现 30% 以上降本。

  1. 开启结果缓存：三家默认都有 24 小时结果缓存，避免 dbt/BI 重复执行相同 SQL。
  2. 启用查询超时：Snowflake STATEMENT_TIMEOUT_IN_SECONDS、BigQuery --maximum_bytes_billed、Redshift WLM Query Monitoring Rule。
  3. 拆分开发/生产仓库：让开发和 CI 走 X-Small / 8 RPU，生产走单独仓库。
  4. 清理僵尸表：90 天未查询的表下沉到冷存储或 Iceberg External Table。
  5. 合理设置分区/聚簇键：大表必须按查询模式选择分区列，减少扫描量。
  6. 物化视图 & 汇总表：高频聚合走 MV，尤其是 dashboard/embed 场景。
  7. 按团队/管道打标签：Query Tag / Job Labels / Query Group 三选一。
  8. 承诺折扣分层采买：baseline 3 年、增量 1 年、突发按需。
  9. Auto-Suspend 与最小 RPU：永远设置激进的挂起策略。
  10. 负载隔离：用 reservation、workgroup、multi-cluster 隔离批处理与 BI。
  11. 接入成本熔断：Resource Monitor / Usage Limit / Budget Alert。
  12. 建立 FinOps Ritual：每周成本会议 + 月度采买复盘。

BigQuery 比 Snowflake 便宜吗？三种典型工作负载测算

这个问题在 2026 年仍然是 CFO 最常问的（也是最难一句话回答的），但答案完全取决于工作负载画像。我用最近三个客户的真实数据算了三种场景，以下均为 us-east-1 / us-central1 月度公开列表价，未考虑企业折扣。

场景数据量Snowflake（月）BigQuery（月）Redshift（月）最省
SaaS 分析平台，稳态 BI5 TB 存 / 每天 200 GB 扫描$1,850（Medium × 8h × 30 天）$1,920（Enterprise 100 slot 承诺）$1,540（RA3 2 节点 RI）Redshift
广告平台，突发 Ad-hoc40 TB 存 / 每天 4 TB 扫描$8,600（多集群 Large）$6,900（Standard On-demand）$9,800（RA3 4 节点 + Concurrency Scaling）BigQuery
金融 ETL，全天候批处理120 TB 存 / 稳定 500 slot 等价$27,400（3XL 24×7）$16,800（EE 承诺 500 slot）$22,300（RA3 8 节点 3 年 RI）BigQuery

结论：BI 稳态负载下 Redshift RA3 RI 常常最优；突发/即席场景 BigQuery On-demand 或 Standard 更甜；ETL 密集稳态 BigQuery Editions + 承诺往往赢。但只要工作负载画像一变，答案就翻转，所以别拿别人的账单当参考。跨云成本比价的方法论，建议参考 FinOps Framework 的 unit-economics 章节。

数仓成本监控与治理：告警、预算与自动化

光优化不监控，账单三个月又会反弹（我见过太多次了）。一套成熟的数仓 FinOps 治理，至少要包含四块：成本可视化、异常告警、预算强制、周期性复盘。下面是我常用的最小可行栈。

1. 成本可视化：三仓合一的数据模型

把 Snowflake ACCOUNT_USAGE.QUERY_HISTORY、BigQuery INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION、Redshift SYS_QUERY_HISTORY/SYS_SERVERLESS_USAGE 每天导入到统一的 fact_query_costs 表，字段包括 team、pipeline、warehouse、slots、bytes_scanned、cost_usd。dbt 里维护 3 个 source + 1 个 union model 即可，工作量比想象中少很多。

2. 异常告警：statistical + budget 双轨

-- 简版：日环比涨幅 > 50% 且金额 > $200 就告警
WITH daily AS (
    SELECT DATE_TRUNC('day', query_ts) AS d,
           team,
           SUM(cost_usd)                AS c
    FROM fact_query_costs
    WHERE query_ts >= CURRENT_DATE - INTERVAL '14 day'
    GROUP BY 1, 2
),
diff AS (
    SELECT d, team, c,
           LAG(c) OVER (PARTITION BY team ORDER BY d) AS c_prev
    FROM daily
)
SELECT *
FROM diff
WHERE c > 200
  AND c > c_prev * 1.5;

3. 预算强制：三家的熔断能力

  • Snowflake：Resource Monitor 支持仓库级/账号级熔断。
  • BigQuery：--maximum_bytes_billed + Cloud Billing Budget Alert；对 Editions 用 Reservation 硬上限。
  • Redshift：Serverless 的 Usage Limit 可以直接 deactivate workgroup。

4. 周期性复盘：数仓 FinOps 周会议程

我给每个客户都定了一个 45 分钟的固定议程：Top 10 昂贵查询责任人对齐 (10 min) → 承诺覆盖率 & 空闲槽复盘 (10 min) → 本周异常告警回顾 (10 min) → 未来 4 周采买/退订建议 (10 min) → Action Items (5 min)。老实说，光是把这个会开起来，多数团队三个月内的单位查询成本就能持续下降。会议纪要落到 Confluence 或 Notion，问责人一列出来，扯皮的空间就小了很多。

常见问题

Snowflake 每月大概多少钱？

Snowflake 账单 = 存储费（$23/TB/月，压缩后）+ 计算 credit（Standard Edition $2.0/credit，Enterprise $3.0/credit）+ Cloud Services（超过 10% 免费额度后按 credit 计费）。以 5 TB 存储 + 每天 8 小时 Medium 仓库为例，月账单大约 $1,800–$2,000。

如何降低 BigQuery 成本？

三条最直接：切换到 Editions + Autoscaler + 1/3 年承诺可减少 20%–40%；给大表加 partition 和 clustering 减少扫描；用 --maximum_bytes_billed 或 Reservation 硬上限阻断失控查询。物化视图与结果缓存也是免费杠杆。

Snowflake 和 BigQuery 有什么定价差异？

Snowflake 按虚拟仓库的运行秒数计费，仓库尺寸决定 credit 倍数；BigQuery 有 On-demand（按 TB 扫描）与 Editions（按 slot-小时）两种模式。Snowflake 适合可预测的短时高频负载，BigQuery Editions 更适合稳态大规模负载，On-demand 更适合偶发即席查询。

Redshift Serverless 和 RA3 集群哪个更便宜？

负载稳定（>60% 利用率）时 RA3 + Reserved Node 更便宜，3 年 All-Upfront 大约 60% 折扣。负载间歇（<30% 利用率）且不能长期承诺时，Serverless 按 RPU-小时更划算，同时省去容量规划成本。转折点大约在 40%–50% 利用率。

如何监控云数据仓库的成本？

把 Snowflake ACCOUNT_USAGE、BigQuery INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION、Redshift SYS_QUERY_HISTORY 每日抽取到统一的 fact_query_costs 表，按 team/pipeline 打标签后接 Looker/Metabase 面板，并配套日环比异常告警与 Budget 熔断，形成"看得见 + 拦得住"的双层治理。

Sara Al-Mahmoud
关于作者 Sara Al-Mahmoud

Cloud cost architect specialising in the gnarly multi-account, multi-region setups. Spreadsheet enthusiast.

相关文章