一、OLAP 系统概述：从定义到选型
大家好，我是这次课程的主讲。做了这么多年 OLAP 系统，我见过太多团队在压测和优化上走弯路。所以第一章节，我们先打好基础。
OLAP，全称是 联机分析处理（Online Analytical Processing）。说白了，它就是用来做复杂查询和数据聚合分析的。你想想看，一个电商平台每天产生几亿条订单，老板想看看“上个月华东区哪个品类的毛利率最高”——这种问题，OLAP 系统就是专门干这个的。
核心定义：OLAP 是一种软件技术，它使分析人员能够从多角度对大量数据进行快速、一致、交互式的访问，从而获得对数据的洞察。
1.1 OLAP 与 OLTP 的区别：两个世界的碰撞
很多刚入行的朋友容易把 OLAP 和 OLTP 搞混。我刚开始带项目时，就见过有人用 MySQL 跑几十亿数据的聚合查询，跑了半小时还没出结果。嗯，这就是典型的“用错工具”。
OLTP（联机事务处理）和 OLAP，虽然只差一个字母，但设计哲学完全不同。我整理了一个对比表，你一看就明白：
| 维度 | OLTP（事务型） | OLAP（分析型） |
|---|---|---|
| 典型场景 | 订单录入、用户注册、支付扣款 | 报表分析、趋势洞察、多维钻取 |
| 数据模型 | 实体关系模型（3NF） | 星型/雪花型模型、列式存储 |
| 读写特点 | 高并发、短查询、写多读少 | 低并发、长查询、读多写少 |
| 响应时间 | 毫秒级（< 100ms） | 秒级到分钟级（可接受） |
| 数据量级 | GB ~ TB | TB ~ PB |
| 典型引擎 | MySQL、PostgreSQL、Oracle | ClickHouse、Doris、StarRocks |
我的经验：有一次在项目评审会上，业务方坚持要用 MySQL 做实时大屏分析。我直接拿这个表给他们看，告诉他们“OLTP 的索引结构是为点查设计的，你让它做全表聚合，等于让短跑运动员去跑马拉松”。后来换了 ClickHouse，查询从 40 秒降到了 0.8 秒。
1.2 为什么需要专门的 OLAP 引擎？
你可能会问：MySQL 也能存数据，为什么不能直接用它做分析？
原因很简单——存储结构不同。OLTP 引擎用的是行式存储，一条记录的所有字段连续存放。而 OLAP 引擎几乎都采用列式存储，同一列的数据连续存放。
举个例子：假设一张表有 100 列，你要计算所有订单的总金额。行式存储需要把每一行的 100 个字段都读出来，再扔掉 99 个。列式存储只需要读取“金额”那一列的数据块。这个差距，在几十亿行数据面前，就是天壤之别。
避坑指南：我曾经见过一个团队，用列式引擎去跑高频的“点查”（比如查某个用户的单条订单详情），结果性能还不如 MySQL。记住：列式存储擅长的是“读少数列、扫大量行”，不是“读所有列、查单一行”。选型前一定要搞清楚你的查询模式。
1.3 常见 OLAP 引擎介绍：三足鼎立
目前市面上主流的 OLAP 引擎，我个人接触最多的就是 ClickHouse、Apache Doris 和 StarRocks。这三者各有千秋，我分别说说我的使用感受。
1.3.1 ClickHouse：极致的单表查询性能
ClickHouse 是俄罗斯 Yandex 开源的。它的特点就一个字——快。在单表聚合查询上，它几乎是目前最快的引擎之一。
- 存储结构：纯列式存储，支持向量化执行
- 数据压缩：压缩比极高，通常能到 5:1 ~ 10:1
- 适用场景：日志分析、监控指标、用户行为分析
- 短板：多表 JOIN 性能一般，不支持完整的事务
我的经验：之前帮一家游戏公司做埋点分析，每天 200 亿条事件数据。用 ClickHouse 做“按游戏版本聚合 DAU”的查询，响应时间基本都在 1 秒以内。但有一次业务方要求做 5 张表的复杂 JOIN，ClickHouse 就有点吃力了。后来我们通过物化视图和预聚合解决了这个问题。
1.3.2 Apache Doris：国产开源的全能选手
Doris 是百度开源的分析型数据库。它的设计理念是“统一”——既能做高并发的点查，也能跑复杂的分析查询。
- 存储结构：列式存储 + 智能分区/分桶
- 查询优化：支持 CBO（基于成本的优化器），多表 JOIN 能力强
- 适用场景：报表系统、实时数仓、Ad-hoc 查询
- 短板：单表扫描速度略逊于 ClickHouse
小技巧：Doris 的 Rollup 表（物化索引）非常实用。我习惯在创建表时，根据业务常用的聚合维度，提前建好几个 Rollup。这样查询时可以直接命中预聚合数据，速度能提升 5-10 倍。
1.3.3 StarRocks：Doris 的进化版
StarRocks 是从 Doris 分叉出来的，由原团队核心成员打造。它在 Doris 的基础上做了大量优化，尤其是查询性能和并发能力。
- 存储结构：列式存储 + 自适应索引
- 查询优化：全面向量化执行，CBO 更成熟
- 适用场景：实时大屏、高并发报表、数据湖分析
- 短板：社区生态相对年轻，部分高级功能需商业版
避坑指南：StarRocks 的“主键模型”和“明细模型”选择要谨慎。我曾经有个项目，业务方要求实时更新订单状态，我选了主键模型。结果因为写入频率太高，导致合并（Compaction）压力过大，查询延迟飙升。后来改成“明细模型 + 定期合并”，问题就解决了。
1.4 三大引擎核心对比
为了让你更直观地理解它们的差异，我画了一张对比图：
1.5 如何选择适合你的引擎？
我经常被问到：“到底该选哪个？”说实话，没有银弹。我个人的选型思路是这样的：
- 先看查询模式：如果 80% 的查询是单表聚合，优先考虑 ClickHouse。如果 JOIN 很多，Doris 或 StarRocks 更合适。
- 再看并发要求：如果 QPS 超过 1000，StarRocks 的高并发能力更有优势。
- 最后看团队能力：ClickHouse 的运维相对简单，Doris/StarRocks 需要一定的分布式系统知识。
总结一下：OLAP 系统的核心就是“用列式存储 + 向量化执行 + 预聚合”来加速分析查询。后面的章节，我们会深入每个引擎的压测方法和优化技巧。到时候你会发现，很多性能问题，其实在选型阶段就已经埋下了伏笔。