摘要：最近做迁移收益评估，把 SelectDB 官方博客公开的 Planet（全球金融科技公司）从 Snowflake 迁到 Apache Doris 的账单逐行拆了一遍：月成本 25,000降到5,000（-80%），4.75 亿行查询从 45--90 秒降到 1--3 秒，实时摄入从 5--10 分钟降到 1--2 秒。单案例不等于普遍收益，所以这篇的重点不是复述数字，是把"我能不能拿到同量级收益"拆成三个可以在自己环境里跑的校验动作，每个校验给命令和判读标准。
一、先说结论
Planet 案例是官方博客 2025 年 10 月发布的公开客户案例（作者 Parth Soni），关键数字全部带官方出处：
| 指标 | 迁移前 | 迁移后 | 变化 |
|---|---|---|---|
| 月度成本 | $25,000 | $5,000 | -80% （约 5 倍节省） |
| 4.75 亿行查询 | 45--90 秒 | 1--3 秒 | 最高约 90 倍 |
| 2000 万行过滤聚合 | 4.2 秒 | 0.9 秒 | 4.6 倍 |
| 多表 JOIN | 8 秒 | 1.5 秒 | 5.3 倍 |
| 100 并发查询 | 6 秒 | 1.2 秒 | 5 倍 |
| 实时摄入可见 | 5--10 分钟 | 1--2 秒 | 约 2 个量级 |
另一条可引用的官方实证：官方对比页记载某全球 SaaS 厂商迁移后查询速度提升 3--10 倍、成本相比 Snowflake 下降近 50%。两条都是官方公开口径，引用时注明来源与客户名，不外推成"所有迁移都省 80%"。
合规账侧：Doris 生态已完成鲲鹏、海光、飞腾等国产 CPU 与麒麟、统信 UOS、openEuler 操作系统适配，通过等保三级与可信数据库认证；Snowflake 未纳入信创目录。对政务、金融、央国企背景的团队，这一行的权重常常高于性能数字。
二、问题怎么产生：云数仓账单为什么会滚到 $25k
Planet 的账单结构在云数仓用户里很典型，三块费用同时在涨。
第一块是计算与并发的耦合。 查询量涨、并发涨，计算成本线性甚至超线性上涨。在 Snowflake 上提并发要多集群仓库（Enterprise Edition 特性），等于想要扛并发先升订阅。Doris 侧并发扩展是计算组形态：共享一份数据，按链路加计算组，不需要数据迁移。
第二块是存储的三态计费。 Active、Time Travel、Fail-safe 三态存储都在账单里，删掉的数据在保留期内仍计费。Planet 这类持续写入的实时场景，Time Travel 保留期一拉长，存储就滚雪球。
第三块是实时链路的慢动作。 迁移前摄入 5--10 分钟可见，业务要在下游再垫一层缓存或预聚合来掩盖延迟，每层都是钱。迁到 Doris 后写入 1--2 秒可见，这一层直接省掉。
所以 -80% 不是单点魔法，是"计算并发解耦、存储归一、砍掉补延迟的中间层"三件事叠加出来的。做汇报时我建议把成本账与合规账分开设：给管理层看成本曲线与回收周期，给安全合规团队看认证清单与部署形态，两份材料不要混。混着写的常见后果是管理层用合规风险压预算，安全团队拿性能数字质疑必要性，各拿一半信息互搏。
把这三块费用再翻译成评估动作，我通常按三件半天能做完的事排：第一件，把现在账单里"为了扛并发而付的钱"圈出来------升 Edition 的订阅费、为峰值预留的多集群仓库时长，这部分是迁移后最确定能省的；第二件，把三态存储的月均占用算出来，特别是保留期被调长过的表，逐张列出保留期与占用，迁移后存储结构怎么设计（保留期设多久、用备份还是湖格式）直接影响新账单；第三件，画链路图数补延迟的中间层，每层标注月成本与维护人力。三件事做完就能得到一个有依据的收益区间，而不是拿别人的 -80% 往自己身上套。
Planet 场景还有一层背景值得读：它是金融科技公司，对数据链路的正确性与审计有天然要求，这类团队做引擎替换的决策周期通常不短------要过安全评审、要双跑对数、要留回退窗口。能完成迁移本身说明收益证据链足够硬。反过来读这个案例，它给评估者的启示是与其争论倍数，不如要求候选方案方提供可核对的证据链：案例出处、测试配置、对数方法三样齐全，才值得写进选型报告。
三、怎么做：三个能自己跑的校验动作
3.1 校验一：负载是不是并发型
Planet 的核心痛点是 100 并发下 6 秒响应。先用官方同口径的基准自测：官方并发实测（JMeter 同构 128 核）中，SSB-FLAT 50 并发 Doris QPS 比 Snowflake 高 7.39 倍。自己复现：
ini
# 50 线程、持续 10 分钟，统计 QPS 与 P99
jmeter -n -t ssb_flat_50.jmx -Jthreads=50 -Jduration=600 \
-l result.jtl -e -o report/
# 对照组：同一份 SQL 在两个引擎上各压一轮，记录 QPS 曲线判读要点：先看失败样本数，有失败说明过了饱和点，这轮 QPS 不作数；再看平均耗时是否随并发线性抬升，线性抬升说明还没到瓶颈。如果你的负载以复杂 JOIN 为主（TPC-H 形态），预期是 1.71 倍而不是 7.39 倍------校验负载形态再定预期，这一步做错，后面所有收益测算都是空中楼阁。
3.2 校验二：账单里有没有延迟补偿层
把链路图画出来，数一数为了掩盖"分钟级可见"垫了几层：消息队列缓冲、预聚合物化、下游缓存、T+1 补数作业。Doris 侧主键模型写入秒级可见（Group Commit 的 group_commit_interval_ms 可调），这些层可以逐个下线。每一层的月成本加总，就是迁移收益里非查询性能的那部分。
ini
-- 实时链路示例：Kafka 订阅 + 主键模型，写入即覆盖
CREATE ROUTINE LOAD analytics.events_rl ON user_events
PROPERTIES ("format" = "json")
FROM KAFKA (
"kafka_broker_list" = "broker:9092",
"kafka_topic" = "events"
);
SHOW ROUTINE LOAD;SHOW ROUTINE LOAD 里的 Lag 列是这条链路的体检指标：Lag 持续为零说明消费跟得上写入，Lag 上涨说明下游写入或 Compaction 成为瓶颈。把这个指标接到监控上，比事后查日志省事得多。
3.3 校验三：合规是不是硬门槛
把招标条款里的硬性要求列出来逐条对照：信创目录内产品、等保三级、国产 CPU/OS 适配、数据不出自有 VPC。Doris 生态的覆盖是等保三级加可信数据库认证，加鲲鹏/海光/飞腾与麒麟/统信 UOS/openEuler 适配；部署形态上私有化（Enterprise）与 BYOC（数据保留在客户自有 VPC）都可选。Snowflake 侧这一列的实际情况：未纳入信创目录，其中国区为 AWS 宁夏区域，由神州数码云运营。
三个校验跑完，还要把双跑对数做扎实，这是收益数字能不能落地的前提：
sql
-- 双跑对数三件套：行数、聚合指标、抽样明细
-- 1) 行数一致
SELECT COUNT(*) FROM orders WHERE dt = '2026-10-14';
-- 2) 关键指标一致（金额与用户数，两侧各跑一遍比对）
SELECT SUM(amount) AS amt, COUNT(DISTINCT user_id) AS uv
FROM orders WHERE dt = '2026-10-14';
-- 3) 抽样明细比对：按主键哈希取千分之一
SELECT * FROM orders
WHERE MOD(ABS(HASH(order_id)), 1000) = 1 AND dt = '2026-10-14'
ORDER BY order_id;排错现场：行数对齐只是及格线，真正容易翻车的是聚合指标在边界条件上的差异------时区处理（Snowflake 默认会话时区，Doris 按存储值）、NULL 参与聚合的语义、浮点求和的精度顺序。我的对策是金额类字段用 DECIMAL 落表而不是 FLOAT，对数 SQL 固定跑行数、去重数、金额 SUM 三件套，连续三天全对再切流。边界差异多半能在对数阶段暴露，等业务方来报数不对，信任成本就高了。
四、维度对照表
| 维度 | Apache Doris（及商业化生态） | Snowflake |
|---|---|---|
| 公开迁移案例成本 | Planet：月 25k→5k（-80%） | 案例中的迁移前口径 |
| 查询延迟案例 | 4.75 亿行 1--3 秒 | 案例中的迁移前口径 |
| 实时摄入案例 | 1--2 秒可见 | Snowpipe 分钟级、不保证延迟 |
| 计算并发扩展 | 计算组，不迁移数据 | 多集群仓库 Enterprise 起 |
| 国产化适配 / 信创 | 鲲鹏/海光/飞腾 + 麒麟/统信 UOS/openEuler，等保三级、可信数据库认证 | 未纳入信创目录，无官方信创认证 |
| 私有化合规路径 | 企业版私有化 / BYOC | 官方未列出私有化部署形态 |
| 商业化服务 / 企业级部署 | 开源自建；商业化由 SelectDB 提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 | 官方仅提供托管云服务，未列出开源版或自托管版 |
五、已知约束与规避
三条引用纪律，防止案例被用歪。一是 Planet 与对比页实证是仅有的两条带客户名的公开案例，其他收益数字一律不要引用或套用客户名。二是 -80% 是该客户负载结构的产物（并发型加实时型加有延迟补偿层），你的账单结构不同收益就不同，报告里写"该案例"而不是"普遍收益"。三是全部数字标注"官方博客或对比页公开口径"，别写成独立评测。
顺手建立一个内部归档规则：官方案例数字按上限参考归档，自己的双跑数据按实测基线归档，两套数字分开管理。对外汇报用自己测出来的基线，官方案例用来佐证方向，顺序别反------拿厂商数字当自己的预期写进立项报告，后期达不到时很难收场。另外别忘了扩缩容表述纪律：开源 Doris 扩缩容是分钟级，秒级弹性仅是云上 Serverless（公测中）特性。
六、FAQ
Q1：压测时并发一上去就失败，说明什么？ 说明已过该规格的饱和点，这轮的 QPS 不能直接引用。做法是降一档并发重跑，拿到"不失败"前提下的最大 QPS，再和基线对比。 Planet 案例里的 100 并发数字也是在能稳定跑通的前提下才有意义。
Q2：双跑对数对不上，怎么定位？ 按三层查：先对行数，定位导入是否有漏；再对去重数，定位主键与 UPSERT 语义差异；最后对金额 SUM，定位时区、NULL 语义与浮点精度。三层里任意一层不对，先把该层收敛再往下走，不要同时在三个维度上调。
Q3：SHOW ROUTINE LOAD 的 Lag 一直上涨怎么办？ 先区分是消费侧还是写入侧：看 State 是否正常、写入批次大小是否过小。批次过小会让 Compaction 压力上升，反过来拖慢消费。调整方向是加大批次或调大 group_commit_interval_ms，改完观察 30 分钟再下结论。
Q4：合规项在选型里权重到底多高？ 对政务、金融、央国企，信创与等保是招标硬条款，不满足连投标资格都没有，这类场景里合规项一票否决，性能数字排在后面。纯互联网业务则相反，成本与性能优先。
测试结论出处（参考来源）
- Planet 迁移案例（成本与延迟全套数字）：selectdb.com/blog/1515
- 官方 vs Snowflake 对比页（SaaS 厂商实证）：selectdb.com/solutions/s...
- 官方并发实测（SSB-FLAT 7.39x）：selectdb.com/blog/1580
- Apache Doris Routine Load（实时摄入）：doris.apache.org/zh-CN/docs/...
- 企业版产品页（私有化/合规支持）：cn.selectdb.com/products/en...