一、OLAP 选型概述：为什么需要实时 OLAP？
大家好，我是这次课程的主讲。做了十几年大数据架构，我见过太多团队在 OLAP 选型上栽跟头。有的选了个查询飞快的引擎，结果数据写不进去；有的吞吐量上去了，查个东西要等半天。说白了，选型就是个权衡的艺术。
今天咱们先聊聊最核心的问题：为什么实时 OLAP 突然成了刚需？
1.1 从 T+1 到实时：数据价值的窗口在缩短
我记得 2015 年那会儿，大部分公司的数据分析还是 T+1 模式。凌晨跑批，早上看报表。那时候大家觉得「今天看昨天的数据」很正常。
但现在不一样了。你想想看，电商大促期间，每延迟一分钟看到销售数据，可能就错过一次调价机会；金融风控场景里，数据晚到 10 秒，一笔欺诈交易就过去了。数据价值的窗口期，已经从「天」缩短到了「秒」。
核心观点：实时 OLAP 不是炫技，而是业务对数据时效性的硬性要求。当你的业务决策需要依赖「当前时刻」的数据时，传统离线数仓就撑不住了。
1.2 实时 OLAP 到底解决了什么问题？
我习惯把实时 OLAP 的能力拆成三个层面来看：
- 秒级写入：数据产生后，几秒内就能进入分析系统。不是分钟级，更不是小时级。
- 秒级查询：在实时写入的同时，还能对海量数据做交互式查询。不能因为数据在写，查询就卡住。
- 实时与历史统一：既能查刚刚产生的数据，也能查几个月甚至几年前的历史数据。不需要在两个系统之间来回切换。
嗯，这里要注意：很多号称「实时」的系统，其实只是做到了写入实时，查询性能一塌糊涂。或者查询快了，写入就慢了。真正好的实时 OLAP，这两者必须同时在线。
1.3 OLAP 选型的核心维度
做了这么多年的选型，我总结出四个必须考察的维度。少一个，后面都可能踩坑。
| 维度 | 说明 | 我踩过的坑 |
|---|---|---|
| 查询性能 | 对海量数据的聚合查询、明细查询、点查的响应速度 | 曾经选了个引擎，单表查询很快，但一 Join 就慢到无法接受 |
| 写入吞吐 | 系统能承受的每秒写入行数或数据量 | 有次压测发现写入一上去，查询延迟直接飙升 10 倍 |
| 数据一致性 | 写入后多久能被读到？会不会读到中间状态？ | 金融场景里，读到不一致的数据差点引发生产事故 |
| 生态兼容性 | 能否对接现有的 Kafka、Flink、Spark、BI 工具 | 选了个冷门引擎，最后发现连 JDBC 驱动都不完善 |
避坑指南：我曾经在一个项目中，只盯着查询性能看，忽略了写入吞吐。结果上线后，数据源一爆发，写入队列直接打满，查询也挂了。选型一定要做全链路压测，别只看单点指标。
1.4 实时 OLAP 的技术演进脉络
为了让大家有个全局视角，我画了一张图，梳理了实时 OLAP 的技术演进路径和当前的主流方案。
1.5 四个维度的权衡之道
你可能会问：这四个维度能不能全都要？我的答案是：理论上可以，但现实中必须取舍。
举个例子：
- 如果你追求极致的查询性能，可能会牺牲一部分写入吞吐。ClickHouse 就是典型，查询快得离谱，但写入需要攒批，不适合单条实时写入。
- 如果你追求强一致性，那写入延迟可能会增加。Doris 的两阶段提交保证了数据一致性，但写入链路比最终一致性的系统要重一些。
- 如果你追求生态兼容性，那可能得选一个「中庸」的方案。StarRocks 在查询、写入、一致性上做得比较均衡，生态也丰富。
我的建议：选型前先列清楚你的业务场景优先级。是电商大促看实时 GMV？还是金融风控做实时预警？场景不同，维度的权重完全不同。我习惯画一个四维雷达图，把每个候选引擎的得分标上去，一眼就能看出谁最匹配。
1.6 本章小结
好了，这一章我们聊了实时 OLAP 为什么重要，以及选型时必须关注的四个核心维度。说白了，没有最好的引擎，只有最合适的引擎。后面的章节，我会逐一深入每个维度，带大家看看主流引擎在这些维度上的真实表现。
嗯，记住一句话：选型不是比参数，而是比匹配度。