存算一体适合查询稳定、扩容可按小时推进的场景；存算分离适合查询波动大、需要湖仓融合、想按负载独立扩缩计算资源的场景。两种形态都能跑业务，差异在「长期总成本和扩展弹性」。下文从 6 个关键维度对比，再按 4 类典型业务给具体选型建议。
一、两种形态的架构定位
存算一体
走 Shared-nothing MPP 架构，每个 DN 节点独占 CPU、内存、本地盘，节点之间不共享系统资源，靠数据重分布做并行计算。优势是数据本地化、查询性能高；劣势是扩容时数据要重新分布，集群越大扩容代价越高。属于传统数仓时代的默认形态，Hadoop 生态（CDH/HDP）走的就是这条路。
存算分离
把存储从计算节点剥离，列存数据落到对象存储（OBS 或兼容 S3 接口），计算节点无状态、本地盘降级为查询缓存。多个逻辑集群（Virtual Warehouse，VW）共享同一份存储，按负载独立扩缩。这是云原生时代数仓的标配形态，Snowflake、BigQuery、Databricks SQL Warehouse 都走这条路。
| 形态 | 存储位置 | 计算位置 | 数据与计算关系 |
|---|---|---|---|
| 存算一体 | DN 节点本地盘 | DN 节点 | 强绑定，扩节点要带盘 |
| 存算分离 | 远端对象存储 | 无状态计算节点 | 解耦，存 / 算独立扩 |
二、6 个关键维度对比
下面这张表把两种形态在 6 个维度上的差异一次拉开，是选型决策的事实底座：
| 维度 | 存算一体 | 存算分离 | 差异原因 |
|---|---|---|---|
| 数据位置 | DN 节点本地盘，CPU/内存/盘绑定 | 计算节点无状态，列存数据在远端对象存储 | 存算分离打破了三者绑定 |
| 扩展方式 | 加节点必须带盘一起扩 | 计算与存储独立扩 | 存算分离可按需扩任一维度 |
| 适合规模 | 1-30 节点 | 30-1000+ 节点 | 存算一体扩到 30 节点后成本失控 |
| 查询延迟 | 低（本地盘读） | 中（远端读，需缓存） | 远端有缓存时差距小 |
| 冷数据处理 | 弱（老数据仍占本地盘） | 强（冷数据下沉到低成本存储） | 存算分离天然支持冷热分层 |
| 运维复杂度 | 低（一套系统搞定） | 中（需协调计算+存储两套集群） | 多一套集群 = 多一份运维 |
说明：存算分离只把列存数据放到 OBS，行存数据仍留在本地盘，迁移前先确认表的存储模型，必要时转列存或做冷热分层。
三、选型决策流程
按下面顺序判断，逐步收敛到该选哪种。
- 先按数据规模分档（< 10TB / 10-100TB / > 100TB）粗筛；
- 再看查询模式是否稳定（稳态批量 vs 临时 ad-hoc），排除明显不合适的形态；
- 最后看湖仓融合与多负载隔离诉求，决定是否必须走存算分离；
- 三个问题都答完，参考 §七 的 4 类业务推荐表锁定形态。
1. 看数据规模
- < 10TB：存算一体即可，成本更低、运维简单
- 10-100TB：两者皆可，看查询模式
- > 100TB：存算分离更优，存储成本弹性大
2. 看查询模式
- 查询稳定（如日报、固定 BI 看板、监管报送）→ 存算一体
- 查询波动大（临时 ad-hoc、机器学习特征、实时分析）→ 存算分离
3. 看湖仓融合诉求
- 只需本集群内分析、读本地表 → 存算一体
- 需要跨源查询（读 OBS 上的 Parquet/ORC、读外部数据湖） → 存算分离
# 选型决策树
if 数据量 < 10TB:
return 存算一体
elif 数据量 < 100TB and 查询稳定:
return 存算一体
elif 需要湖仓融合 or 查询波动:
return 存算分离
else: # > 100TB
return 存算分离四、性能对比：什么场景下哪个更快
| 场景 | 存算一体 | 存算分离 | 差异原因 |
|---|---|---|---|
| 单表全扫描 | 快（本地盘读） | 中（远端读） | 远端有缓存时差距小 |
| 复杂多表 JOIN | 快 | 中-慢 | JOIN 涉及大量数据传输 |
| 高并发小查询 | 快 | 快 | 计算节点无状态，水平扩展 |
| 冷数据查询 | 慢（仍占本地盘） | 快（低成本存储 + 缓存层） | 冷热分层天然支持 |
关键观察：存算分离在冷数据查询和高并发小查询场景下反而比存算一体更快——存算分离的冷数据走低成本存储 + 缓存层，存算一体则要把冷数据也加载到本地盘。这一点常被低估，是「看起来慢」实际上更快的反直觉点。
-- 存算分离下创建外部表，跨源读取 OBS 上的 Parquet 数据
CREATE FOREIGN TABLE obs_sales_log (
order_id BIGINT,
user_id BIGINT,
amount DECIMAL(18, 2),
region VARCHAR(32),
ts TIMESTAMP
)
SERVER obs_server
OPTIONS (
format 'PARQUET',
location 'obs://dws-bucket/sales/log/',
encryption 'false'
);这段建表语句把对象存储上的 Parquet 目录挂成 DWS 外部表，业务侧用标准 SQL 就能查询，无需先导入到本地存算一体表。湖仓融合时常常并存「本地热数据 + 外部冷数据」，查询优化器会自动决定是否下推。
五、成本对比：长期跑下去的差异
单一时间点比较两种形态的单价差异不大；真正拉开差距的是三年五年的总拥有成本。
- 存算一体：每加一个节点，计算 + 本地盘同时买，单价低但扩不出规模红利
- 存算分离：计算节点按量购买、存储按容量/带宽计费，长期跑大集群总成本比存算一体低
| 成本维度 | 存算一体 | 存算分离 |
|---|---|---|
| 初期投入 | 低（按节点包年/包月） | 中（计算 + 存储分开计费） |
| 扩容成本 | 高（要带盘） | 低（按需加任一维度） |
| 3-5 年总成本 | 持续上升 | 弹性可控 |
| 冷数据成本 | 高（占本地盘） | 低（低成本存储） |
六、运维复杂度
存算一体只有一套集群，运维人员只需要管一种资源池。存算分离需要同时维护计算集群和对象存储集群，运维门槛高一档——但换来的是更好的弹性。
实操上的差异：
- 扩容时：存算一体扩容要算盘是否够；存算分离只加计算节点即可
- 故障时：存算一体坏一个节点可能丢数据；存算分离计算节点无状态，挂掉直接换
- 冷数据归档：存算一体要手动 ETL 到低成本存储；存算分离天然支持
- 多负载隔离：存算一体单集群统一调度；存算分离用多 VW 隔离 ETL、BI、ad-hoc 互不抢资源
七、4 类典型业务的选型推荐
| 业务场景 | 推荐形态 | 关键理由 |
|---|---|---|
| 初创公司、报表固定 | 存算一体 | 运维简单、单价低、查询模式稳定 |
| 业务快速增长、数据量翻倍 | 存算分离 | 避免扩容时的「算力-存储」耦合 |
| 机器学习 / AI 特征工程 | 存算分离 | 查询波动大、冷数据多、湖仓融合刚需 |
| 跨地域数据汇聚、实时分析 | 存算分离 | 远端存储天然支持多地域、多负载并发 |
到这里，存算一体 vs 存算分离的 6 维差异、3 步决策、4 类典型业务就完整了。核心是看「数据规模 + 查询模式 + 湖仓融合诉求」而不是「听谁说更好」——两个形态都是好形态，就看用在哪儿。
常见问题（FAQ）
Q1：存算分离的远端读会不会很慢？
不会。远端读都有缓存层，热数据延迟与本地读接近；冷数据走低成本存储是按查询频率动态加载的。
Q2：两个形态能混用吗？
能在同集群内按业务线选不同形态，但要分开管两套资源；不建议小数据量场景下混用，运维成本反而更高。
Q3：迁移到存算分离会不会丢数据？
不会。迁移过程支持灰度切换，业务侧无感知。但要预留 1-2 周的验证期。
