1. 课程导入与成本认知
OLAP平台的成本问题，往往不是“花了多少钱”这么简单。很多团队在扩容时只盯着集群账单，却发现账单上涨的速度远快于查询量的增长；也有团队为了压成本大幅缩减资源，结果SLA频繁告警，业务方投诉不断。要真正做好容量与成本优化，第一步是建立一套清晰的成本认知框架：钱花在了哪里、容量和成本是什么关系、优化到底该朝哪个方向走、用什么指标衡量成败。
一、OLAP平台的成本构成
一个典型OLAP平台（以ClickHouse、Doris、StarRocks、Druid等为代表）的成本可以拆成四层，理解这四层是后续所有优化的基础。
- 计算成本：查询执行所消耗的CPU与内存。它通常体现在计算节点规格、节点数量、弹性扩缩容策略上，是成本中波动最大、也最容易被优化的一部分。
- 存储成本：原始数据、副本、物化视图、索引、冷热分层数据所占用的磁盘或对象存储费用。存储成本相对稳定，但会随数据保留周期和副本数线性增长。
- 网络与I/O成本：节点间Shuffle、数据导入、跨可用区传输、对象存储读取产生的流量费用。在存算分离架构中，这部分成本占比会明显上升。
- 运维与人力成本：集群维护、故障处理、调优、监控告警所投入的工程人力。它不直接出现在云账单里，但往往是隐性的大头。
这四类成本并非孤立。例如把热数据下沉到对象存储，存储成本下降，但查询时远程读取会推高I/O和网络成本，同时可能拉长查询延迟。因此成本优化必须放在整体视角下权衡，而不是单点压缩某一项。
二、容量与成本的关系
容量是成本的主要驱动因素，但两者不是简单的线性关系。容量通常由三个维度共同决定：数据量（需要存多少）、查询负载（需要多快算完多少查询）、并发压力（同一时刻有多少请求）。
在资源充足区间，增加容量能显著提升吞吐、降低延迟；但当资源利用率超过某个阈值（经验上CPU长期高于70%~80%、内存接近上限）后，排队、Spill、缓存失效会让单位算力产出急剧下降，此时继续加机器带来的收益递减，成本却线性上升。反过来，容量长期低于30%利用率，则意味着为闲置资源付费。优化的核心，就是让容量曲线尽量贴近真实负载曲线，而不是按峰值长期预留。
三、优化目标与核心指标
成本优化不能只追求“更便宜”，否则很容易牺牲业务体验。本课程把优化目标定义为：在满足SLA的前提下，持续降低单位查询成本，并保持合理的资源利用率。围绕这个目标，需要盯住三个核心指标。
| 指标 | 含义 | 计算方式（示例） | 健康参考 |
|---|---|---|---|
| 单位查询成本 | 每完成一次查询平均花费多少资源成本 | 周期总成本 ÷ 周期查询总数 | 逐月下降或持平 |
| 资源利用率 | 计算与存储资源的实际使用程度 | CPU/内存平均使用率、存储有效数据占比 | CPU 40%~70% |
| SLA达成率 | 查询在约定时间内返回的比例 | 达标查询数 ÷ 总查询数 | ≥ 99%（按业务定） |
三个指标要一起看。单位查询成本下降但SLA达成率跌破阈值，说明是“省错了地方”；利用率很高但单位查询成本不降，说明瓶颈可能在低效SQL或数据模型，而非容量本身。实际工作中建议按周或按天采集这三个指标，形成趋势线，再定位异常。
四、全课学习路径与实战项目
本课程共30章，整体按“认知—度量—优化—治理”推进。前几章建立成本模型与度量体系；中段分别深入计算、存储、查询、数据模型、弹性调度等具体优化手段；后段进入成本治理、预算告警、容量规划与复盘。每一章都会给出可落地的参数、配置或判断依据。
贯穿全课的实战项目是：为一个中等规模OLAP集群（示例设定：3个计算节点、数据量约20TB、日均查询约5万次）做一轮完整的成本优化。你将依次完成成本基线盘点、指标采集、瓶颈定位、优化实施与效果验证。下面这张图给出了本课程的核心逻辑与实战主线。
需要强调的是，图中所有数值均为教学示例设定，用于说明方法，不代表任何真实集群的实测结果。你在自己的环境中应替换为实际采集到的账单、监控与查询日志数据。
成本优化不是一次性的项目，而是一种持续运营能力。它要求你既懂平台架构，又能读懂指标，还要能和业务方就SLA达成共识。接下来的章节，我们会把这套认知逐步落到具体的参数、配置和操作上。