一、实时OLAP概述：从概念到选型
各位同学，咱们今天正式开讲《从零搭建实时OLAP分析平台》的第一章。说实话，每次带新人入门，我都会先问一个问题：你理解的OLAP到底是什么？
很多人会脱口而出——“就是做报表的”。嗯，这话对了一半。OLAP确实常跟报表绑定，但它的本质远不止于此。我习惯把OLAP比作一个“数据魔方”，你从不同角度切一刀，看到的都是不同的业务真相。
1.1 什么是OLAP？
OLAP，全称是On-Line Analytical Processing，联机分析处理。说白了，就是让业务人员能快速、灵活地从多个维度观察数据。比如“昨天华东区手机品类销售额是多少”，这就是一个典型的OLAP查询。
它跟OLTP（联机事务处理）是两码事。OLTP管的是“用户下单了，扣库存”，OLAP管的是“这个月哪个品类卖得最好”。一个面向交易，一个面向分析。
核心特征：
- 多维分析：时间、地区、产品、渠道……想怎么切就怎么切
- 快速响应：秒级甚至毫秒级返回聚合结果
- 数据集成：通常从多个数据源汇总而来
- 历史趋势：关注的是长期变化，而非单笔交易
我记得刚入行那会儿，公司用的还是传统OLAP——比如微软的SSAS。那时候跑一个Cube全量刷新，动辄几个小时。业务方早上问我要数据，我得说“下午才能好”。现在想想，那哪叫“实时”啊，顶多算“日结”。
1.2 实时OLAP的应用场景
为什么现在大家都在谈“实时”？因为业务等不了。你想想看，一个电商大促期间，运营盯着实时大屏，每秒钟的GMV都在跳动。如果数据延迟5分钟，可能就错过了调整策略的最佳时机。
我梳理了几个典型的实时OLAP场景，你在项目中大概率会遇到：
- 实时大屏：双11战报、物流追踪、工厂产线监控。数据延迟控制在秒级。
- 用户行为分析：App埋点数据实时入仓，分析用户点击路径、漏斗转化。
- 风控与异常检测：交易金额突然飙升、登录地点异常，需要秒级预警。
- 实时报表：销售日报、库存看板，业务方希望看到“此时此刻”的数据。
- 指标监控与告警：服务器QPS下降、接口错误率上升，OLAP引擎直接触发告警。
一个小建议：并不是所有场景都需要实时。我曾经见过一个项目，非要把历史月报也做成实时流，结果资源消耗翻了三倍，查询速度反而慢了。实时OLAP要解决的是“新鲜数据”的问题，不是“全量数据”的问题。分清边界，比什么都重要。
1.3 主流实时OLAP引擎对比
好，到了大家最关心的环节。市面上实时OLAP引擎不少，但真正经过大规模生产验证的，我重点推荐三个：ClickHouse、Apache Doris、StarRocks。它们各有千秋，也各有短板。
先看一张对比表，心里有个底：
| 特性 | ClickHouse | Apache Doris | StarRocks |
|---|---|---|---|
| 开源时间 | 2016年 | 2018年 | 2020年（从Doris fork） |
| 核心语言 | C++ | C++ / Java | C++ / Java |
| 数据模型 | 列式存储，扁平表 | 列式存储，支持聚合模型、明细模型 | 列式存储，支持聚合模型、明细模型、主键模型 |
| 实时写入 | 支持，但高频写入需优化 | 支持，Stream Load 性能优秀 | 支持，Stream Load 性能优秀 |
| 查询性能 | 单表聚合极快，多表Join较弱 | 单表与多表Join均衡 | 单表与多表Join均衡，CBO优化器强 |
| SQL兼容性 | MySQL协议有限兼容 | MySQL协议高度兼容 | MySQL协议高度兼容 |
| 运维复杂度 | 中等，依赖ZooKeeper | 较低，内置高可用 | 较低，内置高可用 |
| 典型场景 | 日志分析、监控、用户行为 | 实时报表、多维分析、数据湖加速 | 实时报表、多维分析、数据湖加速、高并发点查 |
我来逐个说说我的实际感受。
ClickHouse
ClickHouse 是我最早接触的实时OLAP引擎。它的单表聚合能力确实强悍，我曾经在几十亿条数据的表上做 group by，秒级出结果。但它的短板也很明显——多表 Join 性能堪忧，而且对高频写入不太友好。我记得有一次，业务方要求每秒写入几万条数据，ClickHouse 的 merge 线程直接打满了，查询延迟飙升。后来我们调整了写入批次和分区策略，才算稳住。
避坑指南：ClickHouse 不适合做“精确去重”和“事务性写入”。如果你需要精确的 UV 计算，或者需要保证数据不丢不重，建议优先考虑 Doris 或 StarRocks。
Apache Doris
Doris 是百度开源的项目，后来捐给了 Apache。它的设计理念更贴近传统 MPP 数据库，支持标准 SQL，多表 Join 能力比 ClickHouse 强不少。我在一个金融项目中用过 Doris，每天处理几十亿条交易流水，实时写入延迟控制在 3 秒以内，查询响应基本在 1 秒内。运维也很省心，不需要额外维护 ZooKeeper。
不过 Doris 的社区迭代速度在 2021 年后有所放缓，一些新特性（比如主键模型、物化视图）支持得不够及时。如果你追求稳定、社区成熟，Doris 是个好选择。
StarRocks
StarRocks 是从 Doris fork 出来的，但发展速度很快。它的 CBO（基于成本的优化器）做得很好，复杂查询的自动调优能力比 Doris 强。我去年帮一家电商公司做实时大屏，底层用的就是 StarRocks。双11当天，每秒写入峰值达到 50 万条，查询 P99 延迟依然控制在 200 毫秒以内。说实话，这个表现让我挺意外的。
StarRocks 的主键模型支持 UPSERT 语义，非常适合需要实时更新数据的场景。比如订单状态变更、用户标签更新，这些在 ClickHouse 里很难优雅处理，但在 StarRocks 里就是一条 SQL 的事。
1.4 如何选择？
我个人的选型建议是这样的：
- 如果你主要做日志分析、监控、用户行为轨迹，对多表 Join 要求不高，选 ClickHouse。它简单、快、社区资源丰富。
- 如果你需要实时报表、多维分析，且数据需要频繁更新，选 StarRocks。它的主键模型和 CBO 优化器是杀手锏。
- 如果你团队 MySQL 生态比较重，希望平滑迁移，选 Apache Doris。它的 SQL 兼容性最好，学习成本最低。
一句话总结：没有最好的引擎，只有最适合你场景的引擎。选型之前，先想清楚你的数据模型、写入频率、查询模式。别盲目跟风。
1.5 本章知识体系总览
下面这张图，是我梳理的本章核心知识结构。你可以把它当作一个“导航图”，后续章节都会围绕这些节点展开。
这张图把本章内容分成了三个核心分支：概念、场景、引擎。你可以看到，概念是基础，场景是驱动，引擎是工具。三者缺一不可。