1、OLAP引擎全景概览
聊OLAP引擎选型之前，咱们得先搞清楚一个根本问题：OLAP到底是什么？
我见过不少团队，一上来就对比ClickHouse和Doris，比了半天才发现业务需求其实用MySQL就能搞定。嗯，这就是典型的「选型前置条件没对齐」。
1.1 什么是OLAP
OLAP，全称是Online Analytical Processing，联机分析处理。说白了，它就是用来做复杂查询、多维分析、数据聚合的那类系统。
你想想看，一个电商平台每天产生几亿条订单数据。运营想看「过去30天华北地区女性用户的客单价趋势」，这种查询如果扔给MySQL，大概率会超时或者把库打挂。这就是OLAP的典型场景——海量数据、复杂聚合、响应时间容忍度相对较高。
核心特征：
- 数据量大：单表百亿级起步
- 查询复杂：多维度Group By、窗口函数、关联分析
- 写入批量：通常是T+1或准实时导入
- 响应要求：秒级到分钟级，视场景而定
1.2 OLAP与OLTP的区别
很多新手容易把OLAP和OLTP搞混。我刚开始接触大数据时也犯过这个错——拿OLAP引擎去做高并发点查，结果被DBA骂了一顿。
咱们直接看对比表，一目了然：
| 维度 | OLTP | OLAP |
|---|---|---|
| 典型系统 | MySQL、PostgreSQL | ClickHouse、Doris、StarRocks |
| 数据模型 | 行存，3NF范式 | 列存，星型/雪花模型 |
| 查询特征 | 短小精悍，索引命中 | 全表扫描，大规模聚合 |
| 并发要求 | 高并发（数千TPS） | 中低并发（数十QPS） |
| 事务支持 | 强ACID | 弱事务或最终一致 |
| 典型延迟 | 毫秒级 | 秒级到分钟级 |
避坑提醒：我曾经见过一个团队用ClickHouse做订单实时写入，每秒几千笔，结果ClickHouse的MergeTree引擎频繁合并，查询延迟飙升到几十秒。OLAP引擎不是万能药，选型前一定要分清场景。
1.3 OLAP引擎的三大流派
现在的OLAP引擎市场，说白了就是三大流派在打架。我这些年接触过的项目，基本都逃不出这个框架。
流派一：MPP数据库
MPP（Massively Parallel Processing）数据库，是最正统的OLAP路线。代表产品有Greenplum、Vertica、Doris、StarRocks。
它们的核心思路是：把数据分片到多个节点，每个节点独立计算，最后汇总结果。就像你让10个人同时算10堆数据，比一个人算快10倍。
我个人习惯把MPP数据库比作「数据库界的正规军」——SQL支持最完整，事务一致性最好，适合对数据准确性要求极高的场景。
流派二：SQL-on-Hadoop
这个流派诞生于Hadoop生态，代表产品有Hive、Spark SQL、Presto/Trino。
它们的思路是：用SQL引擎去调度底层分布式存储（HDFS、对象存储）上的数据。说白了，就是把Hadoop的MapReduce包装成SQL接口。
我记得2016年做第一个大数据项目时，用的就是Hive。那时候跑一个简单的Group By要等几分钟，现在想想真是「石器时代」。不过SQL-on-Hadoop的优势在于数据湖生态兼容性极强，适合做ETL和Ad-hoc查询。
流派三：搜索引擎类
这个流派比较特殊，代表产品是Elasticsearch。它原本是做全文搜索的，但因为倒排索引和聚合能力很强，被很多人拿来当OLAP用。
你想想看，日志分析、APM监控、安全事件分析——这些场景天然适合搜索引擎。ES的即席查询能力极强，秒级响应，但缺点是JOIN能力弱，数据一致性也一般。
我的建议：如果业务场景是「日志检索+轻量聚合」，ES是首选。如果是「复杂SQL分析+高一致性」，MPP数据库更靠谱。SQL-on-Hadoop则适合「数据湖上的探索性分析」。
1.4 选型前的核心思考框架
选OLAP引擎，最忌讳的就是「听说ClickHouse快就用ClickHouse」。我见过太多这样的翻车案例了。
下面这个框架，是我这些年总结出来的，每次选型前我都会过一遍：
具体来说，我建议你按这五个维度来思考：
- 数据规模：日增数据量级是多少？总数据量是百亿还是千亿？这直接决定了你需要MPP还是SQL-on-Hadoop。
- 查询模式：是固定报表还是即席分析？复杂JOIN多不多？这决定了你是选MPP还是搜索引擎。
- 实时性要求：需要秒级响应还是分钟级？实时写入还是T+1？ClickHouse和Doris在实时场景表现不错，Hive就不太行了。
- 运维能力：团队有多少DBA？有没有Hadoop运维经验？ES和ClickHouse相对好运维，Greenplum就比较重。
- 生态兼容：现有技术栈是什么？数据源有哪些？如果已经用了Kafka和HDFS，选SQL-on-Hadoop会更顺滑。
一个小技巧：我每次做选型前，都会先画一个「需求-能力矩阵」，把业务需求列在左边，候选引擎的能力列在右边，逐项打分。这样选出来的结果，至少不会出现「用ES做复杂JOIN」这种尴尬情况。
好了，这一章我们先把OLAP的「全景地图」铺开了。后面的章节，我会逐个深入每个流派的代表引擎，带你看看它们各自的「杀手锏」和「坑」。选型这件事，急不得，先把框架搭好，后面填细节就顺了。