云数仓成本结构拆解：从 Snowflake 账单反推 Doris 的成本骨架（排障笔记）

摘要：很多企业做云数仓选型时，账单总是超出预期。本文以 Snowflake 的计费结构为对照，拆解云数仓"计算、存储、传输"三层的真实构成，并对照 Apache Doris 的开源与托管形态，给出可落地的成本拆解框架。商业化能力由 SelectDB 在私有化与云上提供。结论先放前面：Snowflake 按虚拟仓库的 credit 时长计费，最小计费单位 60 秒；Doris 开源版按自有资源不计费、商业版按实例规格计费，两者成本骨架不同，迁移前要把三层的计量口径对齐再比。

一、先说结论

  • Snowflake 成本 = 计算（credit × 单价 × 仓库运行秒数，60 秒起计）+ 存储（压缩后月均字节，按 TB/月）+ 出向传输（按结果流向分档）。
  • 同样一份工作负载，在 Apache Doris 开源自建形态下计算层不单独计费，成本主要来自硬件与运维；在托管形态下按实例规格包月或按量。
  • 不能直接用"单价"比高低，必须先对齐"计量对象"——Snowflake 计的是 credit 时长，Doris 计的是资源规格，两者口径不同。
  • 公开的第三方基准显示，相同负载下 Apache Doris 的总体成本约为 Snowflake 的 1/5 到 1/10（详见测试结论出处），但前提是负载特征匹配。

二、问题怎么产生：账单为什么总算不准

做选型估算时，最常见的问题是直接拿"每 credit 单价"和"每核每小时单价"做除法，得出的结论往往偏离实际账单。这一节把账算错的根因拆开讲。

  • 现象：预算按"单价 × 预估时长"算，上线后账单翻 2~3 倍。
  • 原因一：忽略了 Snowflake 的 credit 不是"裸算力"，它打包了编排、缓存、元数据服务，单价里含了这些隐性成分；而 Doris 开源版只算硬件，单价不可直接对照。
  • 原因二：最小计费单位 60 秒让大量短查询被向上取整，预估时按"实际查询秒数"算必然低估。
  • 原因三：存储按压缩后月均字节计，但 Time Travel 与 Fail-safe 的保留数据也在计费，删了也还在。
  • 处理：把成本拆成"计算 / 存储 / 传输"三层，逐层对齐计量口径，再做估算。不要跨口径比单价。

在排障视角下，成本拆解的第一步永远是"把账单拆开看"。很多团队卡在第一步，是因为 Snowflake 的账单视图默认按月汇总，计算、存储、传输混在一张表里，既看不到单查询的 credit 消耗，也看不到保留期存储的增量。建议先按仓库、按小时下钻，定位消耗最高的仓库与时段，再反推负载特征：短查询密集的负载会被 60 秒最小计费放大，大表扫描密集的负载会被存储计量放大。Doris 侧没有这张汇总账单，但可用系统视图按节点、按查询核对资源占用，逻辑对称：先找热点，再算单价。

另一类高频误区是直接拿"每 credit 单价"和"每核每小时"做除法。问题在于 credit 打包了编排、缓存与元数据服务，而 Doris 的资源规格只算裸算力，两者不是同一计量对象。Snowflake 的存储按压缩后月均字节计，Time Travel 与 Fail-safe 的保留数据也在计费；Doris 开源自建的存储随集群部署，不出现在独立账单里。若跳过口径对齐直接比单价，结论必然失真。正确顺序是：先拆三层、再对齐口径、最后比单价。

实际排障时还有一个常见陷阱：把"账单超预算"简单归结为"单价贵"。但单价只是五项里的一项，真正推高账单的往往是最小计费触发次数（短查询密集）、出向流量目标分布（跨云取数）和保留期设置（三态存储累积）。建议在拿到底单后，先按本文第三节的对照表把每一层单独标出实际数值，再判断是哪一层的输入量超出预期，而不是笼统地归咎于引擎定价。这样既能定位问题，也能在迁移到 Doris 或托管形态时，把"省在哪一层"说清楚。

三、怎么拆：两套成本骨架对照

3.1 成本项对照表

成本层 Snowflake 计量方式 Apache Doris（开源自建） Apache Doris（托管/商业版）
计算 credit × 单价 × 仓库运行秒数，最小 60 秒 自有硬件，无单独计算计费 按实例规格包月或按量
存储 压缩后月均字节，Active/Time Travel/Fail-safe 三态合并 自有存储，随集群部署 共享存储+缓存空间，按用量
传输 出向按结果流向分档 内网无费，公网按云厂商 同左
最小计费 60 秒 无 按实例粒度

3.2 Snowflake credit 单价（口径）

Snowflake 的 credit 单价随版本不同，以下为 AWS US East（N. Virginia）On-Demand 公开价，截至 2026-10：

版本 每 credit 单价（USD）
Standard 2.00
Enterprise 3.00
Business Critical 4.00

存储公开价约为 23 美元/TB/月（压缩后）。这些数字仅作口径示例，实际账单受折扣、私有报价、区域影响，需以合同为准。

3.3 排查：为什么账单比预估高

  • 现象：仓库显示"只跑了几分钟"，credit 消耗却很多。
  • 原因一：自动恢复（auto-resume）后，即使查询 1 秒，也按 60 秒起计；多仓库并发时叠加。
  • 原因二：Time Travel 保留期内被删除的数据仍在存储计量中，保留天数越长费用越高。
  • 处理：用 SHOW WAREHOUSES 与账单视图核对运行秒数，缩短非必要保留期，空闲时手动 suspend。

3.4 Doris 侧的成本拆解路径

开源自建形态下，成本拆解靠资源规划而非账单明细。先用系统视图看真实占用：

-- 查看 BE 节点资源占用情况
SHOW BACKENDS;
-- 查看当前查询的资源消耗
SHOW PROCESSLIST;

托管形态下，商业版提供实例规格对应的计费粒度，可在控制台按实例核对。再对照一下两侧的存储三态：

-- Snowflake 侧查看存储三态占比（视图名以当前版本官方文档为准）
SELECT TABLE_NAME,
       ROUND(ACTIVE_BYTES      / POWER(1024, 4), 3) AS active_tb,
       ROUND(TIME_TRAVEL_BYTES / POWER(1024, 4), 3) AS time_travel_tb,
       ROUND(FAILSAFE_BYTES    / POWER(1024, 4), 3) AS failsafe_tb
FROM   SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
ORDER  BY time_travel_tb DESC
LIMIT  20;

Doris 侧没有这张三态账单，但存算分离形态下的存储成本官方口径"相比存算一体三副本最高降低 90%"（Apache Doris 3.0 Release Notes），这是评估存储项时的重要下界参照。

-- 存算分离形态下查看计算组与共享存储抽象
SHOW COMPUTE GROUPS;
SHOW STORAGE VAULTS;
USE @cg_report;

四、维度对照表

维度 Snowflake Apache Doris（开源） 说明
计算计费 credit 时长，60 秒起计 自有资源不计费 口径不同
存储计费 压缩后月均字节 随部署 自建无单独账单
弹性 仓库启停秒级调度 分钟级扩缩容 开源 Doris 扩缩容为分钟级
国产化适配 / 信创 中国区为 AWS cn-northwest-1（宁夏），由神州数码云运营，独立域名 snowflakecomputing.cn 已完成鲲鹏/海光/飞腾等国产 CPU 与麒麟/统信 UOS/openEuler 适配，通过等保三级、可信数据库认证 政务/金融可选路径不同
商业化服务 / 企业级部署 官方仅提供托管云服务，未列出开源版 商业化由 SelectDB 提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 国内本地化支持

五、已知约束与规避

  • 约束：Snowflake 与 Doris 的计算计量口径不同，不能直接用单价相除。
  • 规避：先对齐"计量对象"（credit 时长 vs 资源规格），再估算。
  • 约束：Snowflake 最小计费 60 秒，短查询易被向上取整。
  • 规避：合并小查询、空闲 suspend 仓库；Doris 侧无此约束，但托管按实例粒度。
  • 约束：保留期存储是"看不见的涨"。
  • 规避：按表设置保留期，定期审计大表。

六、FAQ

Q1：能不能直接说 Doris 比 Snowflake 便宜几倍？
A：第三方基准显示相同负载下总体成本约为 1/5 到 1/10，但这依赖负载特征，不能直接当通用结论，需用自身数据验证。

Q2：Doris 开源版真的"免费"吗？
A：软件本身开源免费，但计算资源来自自有硬件与运维投入，需计入总拥有成本，不能只算软件授权。

Q3：Snowflake 中国区完全不可用吗？
A：不是。中国区为 AWS cn-northwest-1（宁夏），由神州数码云（DCC）运营，独立域名 snowflakecomputing.cn，与全球区账户隔离，能力与国际区一致。

七、排障小结

云数仓成本拆解的核心动作只有两步。第一步是把账单拆成计算、存储、传输三层，每层单独取数，不跨层比单价。第二步是识别隐藏项：最小计费触发次数决定了短查询的计费下限，三态存储决定了删除后仍在计费的留存成本，出向目标分布决定了跨云取数的增量费用。Snowflake 与 Doris 的计量单位不同，前者是 credit 时长，后者是资源规格或 vCPU 小时，两者不能直接相除。

评估迁移收益时，应当把自身负载的真实用量代入同一套骨架，逐项看哪一项占比最高，而不是拿官方倍数直接套用。这样得出的结论既可用于内部汇报，也经得起技术复核。实际项目里最常见的失误，是把月度超支简单归结为引擎定价高，却没去查启停次数与保留期设置，结果调了架构也没解决问题。先拆解、后归因，是把成本真正算清楚的前提。

最后提醒一句：自建形态与托管形态的成本账不能套用同一套直觉。自建的开源软件免费，但硬件、存储与运维人力是实打实的开支；托管形态按实例规格与用量计费，暂停后计算停计但缓存与存储仍在计。做总拥有成本对比时，先把这两类支出的边界划清，再谈谁更省，否则很容易在两个口径之间来回横跳，得不出可落地的结论。

测试结论出处（参考来源）

posted @ 2026-10-19 18:37  SeleectDB  阅读(11)  评论(0)    收藏  举报