2. OLAP平台架构与资源模型

要谈容量与成本优化，必须先看清OLAP平台“钱花在哪里”。一个查询从提交到返回结果，会依次消耗计算、存储、网络三类资源，而这三类资源的配比、耦合方式，又由底层架构决定。本节围绕MPP架构、存算分离与存算一体两条主线，把资源模型拆开讲清楚，为后续的容量规划与成本核算打基础。

一、MPP架构：把一个大查询切成很多小查询

MPP（Massively Parallel Processing，大规模并行处理）是绝大多数OLAP引擎的底座。它的核心思想是：数据按某种分布键（distribution key）水平切分到多个节点，每个节点只处理自己那一份数据，最后把各节点的局部结果汇总。以一张10亿行的订单表为例，若按order_id哈希分布到16个节点，每个节点大约持有6250万行；执行SELECT city, SUM(amount) FROM orders GROUP BY city时，各节点先做本地聚合，再把“城市→局部和”这一小批中间结果发到协调节点做最终合并。数据扫描量被16个节点分摊，理论上扫描阶段耗时接近单机的1/16。

MPP的代价在于“协调”和“数据移动”。当查询涉及多表关联且关联键与分布键不一致时，引擎必须做重分布（Redistribution）或广播（Broadcast）：把其中一张表按新键重新哈希到各节点，或把小表复制到所有节点。这一步会占用大量网络带宽，也是MPP查询变慢的常见原因。因此，分布键的选择直接决定了后续网络开销——选得好，关联本地化；选得差，每次关联都要跨节点搬数据。

二、存算一体与存算分离：两种资源耦合方式

存算一体（Shared-Nothing）把CPU、内存和本地盘绑定在同一批节点上，数据落在本地磁盘，计算就近读取。它的优势是延迟低、带宽高，本地盘顺序读吞吐可达数GB/s，适合对扫描性能要求极高的场景。但它的弹性很差：存储和计算必须同比例扩容，业务低谷时计算资源闲置，存储却仍占着机器；一旦某节点故障，其上的数据分片需要从副本恢复，恢复期间该分片不可用。

存算分离（Shared-Storage）把数据放到对象存储（如S3、OSS），计算节点变成无状态或弱状态的“算力池”，按需拉起、用完释放。它的优势是弹性极强：计算可以独立扩缩容，存储按实际用量付费，多套计算集群还能共享同一份数据。代价是对象存储的访问延迟远高于本地盘（毫秒级 vs 微秒级），且每次读取都要走网络，因此引擎必须依赖本地缓存（Cache）和列式格式（Parquet/ORC）来减少实际IO量。实践中，热数据缓存在本地SSD，冷数据回源对象存储，是存算分离的常见折中。

三、三类资源的成本特征

计算资源（CPU/内存）。CPU决定扫描与聚合的吞吐，内存决定能缓存多少中间数据、能承载多大的Hash Join。内存不足时，引擎会把数据溢写到磁盘（Spill），性能断崖式下跌。成本上，计算资源通常按实例规格×时长计费，是弹性最强、也最容易浪费的部分——很多集群CPU平均利用率长期低于20%。

存储资源（本地盘/对象存储）。本地盘按机器容量计费，单价高但吞吐好；对象存储按存储量+请求次数+流量计费，单价低但每次读取都有成本。一个容易被忽视的点是：存算分离下，如果缓存命中率低，每次查询都回源对象存储，请求费用和流量费用会迅速累积，反而可能比本地盘更贵。因此“存算分离一定更省钱”是伪命题，关键看访问模式。

网络资源。MPP的Shuffle、存算分离的回源读取、跨可用区的数据传输，都会消耗网络带宽。网络成本往往不体现在账单的显眼位置，却会以“查询变慢→需要更多计算资源→成本上升”的间接方式体现。分布键设计、数据本地化、缓存策略，本质上都是在优化网络开销。

四、架构选择对容量与成本的影响

把上面的关系落到决策上，可以归纳为几条判断依据：

• 负载稳定、延迟敏感：优先存算一体。本地盘的高吞吐能压低查询延迟，资源利用率高时单位查询成本更低。
• 负载波动大、有明显波峰波谷：优先存算分离。计算按需扩缩，避免低谷期为闲置算力付费。
• 多团队共享数据、需要数据隔离：存算分离更合适，一份数据可挂载多套计算集群，避免数据反复拷贝。
• 冷热分层明显：存算分离+本地缓存，热数据缓存命中率若能达到80%以上，回源成本可控。