1. 实时OLAP系统全景

大家好，我是老张。做运维十几年，从传统数仓一路干到实时OLAP，踩过的坑比吃过的盐还多。今天咱们先聊聊全景——什么是实时OLAP，它用在哪儿，以及市面上主流选型怎么选。

说白了，实时OLAP就是让分析师能秒级查询海量数据，并且数据是实时更新的。你想想看，传统数仓跑个报表要等半天，业务早凉了。实时OLAP要解决的就是这个痛点。

1.1 核心应用场景

我在项目中遇到过不少场景，真正能发挥实时OLAP价值的，主要是这三类：

• 实时大屏：双11大屏、业务监控大屏。数据从产生到展示，延迟控制在秒级以内。我记得有一次给某电商做双11大屏，流量峰值时每秒写入几十万条，ClickHouse扛住了，但查询优化调了好久。
• 即席查询：分析师想怎么查就怎么查，不用提前建模。比如“昨天北京地区购买过母婴用品的用户，今天又买了什么？”这种多维组合查询，传统数仓得提前建宽表，实时OLAP直接跑。
• 用户画像：实时标签计算、人群圈选。比如“最近1小时浏览过A商品但没下单的用户”，这种场景对写入和查询延迟都极其敏感。

1.2 主流技术选型对比

目前市面上最火的三个实时OLAP引擎：ClickHouse、Apache Doris、StarRocks。我三个都用过，各有千秋。下面这张表是我个人的对比总结：

维度	ClickHouse	Apache Doris	StarRocks
架构	MPP + 列存，无中心节点	MPP + 列存，FE/BE 架构	MPP + 列存，FE/BE 架构
写入方式	批量写入为主，LSM-Tree	Stream Load / Broker Load	Stream Load / Routine Load
查询性能	单表聚合极快，多表Join较弱	多表Join优化好，性能均衡	多表Join极强，CBO优化器
实时性	秒级延迟（需外部工具配合）	秒级延迟，原生支持实时	秒级延迟，原生支持实时
运维复杂度	中等，依赖ZooKeeper	较低，组件少	较低，组件少
生态兼容	MySQL协议有限兼容	MySQL协议高度兼容	MySQL协议高度兼容
适用场景	大宽表聚合、日志分析	实时报表、多维分析	高并发即席查询、用户画像

1.3 实时OLAP系统架构全景

下面这张图是我自己画的，展示了实时OLAP系统的整体架构。你仔细看，数据从产生到最终展示，要经过采集、传输、存储、查询四个环节。

嗯，这里要注意。很多人以为实时OLAP就是装个ClickHouse就完事了。其实不然。数据采集和传输环节往往才是瓶颈。我见过太多案例，OLAP引擎本身没问题，但上游数据延迟太大，导致整个系统实时性不达标。

1.4 选型建议

说了这么多，到底怎么选？我个人习惯按以下思路来：

1. 先看查询模式：如果主要是单表聚合、大宽表查询，ClickHouse性价比最高。如果涉及多表Join，优先考虑StarRocks或Doris。
2. 再看实时性要求：如果要求秒级甚至毫秒级实时写入，Doris和StarRocks原生支持更好。ClickHouse需要配合Kafka引擎或外部工具。
3. 最后看运维能力：团队小、运维资源有限，选Doris或StarRocks，组件少、部署简单。团队有经验，ClickHouse也能玩得转。