一、实时OLAP概述：从概念到选型
1.1 OLAP到底是什么？
OLAP，全称是联机分析处理。说白了，就是让你能从多个维度、多个角度，快速地对大量数据进行查询和分析。
我经常跟团队里的新人这么解释：OLTP是“今天卖了多少笔”，OLAP是“过去三个月，华东区哪个品类的复购率在涨”。前者关注事务，后者关注洞察。
一个典型的OLAP查询，往往涉及：
- 多维聚合：按时间、地区、产品线汇总销售额
- 钻取与上卷：从“全国”下钻到“省份”，再上卷回“大区”
- 切片与切块：只看“2024年Q3”且“品类=电子产品”的数据
- 旋转：把行和列互换，换个视角看问题
嗯，这里要注意：OLAP不是一种数据库，而是一种分析模式。你可以用ClickHouse、Doris、甚至用MySQL加上物化视图来实现，只是体验天差地别。
1.2 实时OLAP vs 传统OLAP
传统OLAP，大家最熟悉的就是T+1模式。凌晨跑批，把昨天的数据从ODS清洗到DWD，再聚合到DWS，最后写入Cube。早上9点，老板打开报表，看到的是昨天的数据。
实时OLAP呢？数据从产生到可查询，延迟控制在秒级甚至毫秒级。我参与过的一个电商大促项目，要求活动开始后30秒内，运营就能看到实时GMV和库存水位。这就是典型的实时OLAP场景。
两者的核心差异，我整理了一张表：
| 对比维度 | 传统OLAP | 实时OLAP |
|---|---|---|
| 数据延迟 | T+1，小时级 | 秒级，毫秒级 |
| 数据源 | 离线数仓，批量导入 | 消息队列（Kafka/Pulsar），实时流 |
| 存储模型 | 预聚合Cube，ROLAP | 列存 + 倒排索引 + 实时写入 |
| 查询模式 | 固定报表，预定义维度 | 即席查询，高并发，低延迟 |
| 典型场景 | 财务月报，经营分析 | 实时大屏，风控，推荐 |
| 技术栈 | Hive + Kylin / Druid | ClickHouse / Doris / StarRocks |
核心观点：实时OLAP不是要取代传统OLAP，而是互补。你想想看，财务对账你敢用实时数据吗？肯定不敢。但运营盯大屏，T+1又太慢了。所以，选型的关键是场景。
1.3 实时OLAP的应用场景
我这些年接触过的实时OLAP项目，场景大致可以归为以下几类：
- 实时大屏与监控：双11大屏、服务器监控、业务指标看板。数据延迟超过10秒，运营就会拍桌子。
- 实时风控与反欺诈：交易行为分析、异地登录检测。每一笔支付都要在毫秒级完成风险评分。
- 实时推荐与个性化：用户点击流实时入湖，分钟级更新用户画像，推荐系统才能跟上兴趣变化。
- 实时报表与自助分析：产品经理想查“今天新上线的功能，用户点击率如何”，不能等明天。
- 物联网与日志分析：百万级设备上报数据，实时聚合出设备健康度、异常告警。
我曾经帮一家金融科技公司做过实时风控平台。他们的要求是：交易事件从产生到风控决策，端到端延迟小于500毫秒。我们用了Kafka + Flink + Doris的架构，把规则引擎下推到存储层，才勉强压住延迟。嗯，这里有个坑：实时OLAP的瓶颈往往不在查询，而在写入。数据写入太快，存储层扛不住，查询就会变慢。
1.4 技术选型概览
说到技术选型，我先泼盆冷水：没有银弹。每个系统都有自己的擅长和短板。我按自己的经验，把主流引擎分了几个流派：
| 流派 | 代表产品 | 核心优势 | 典型局限 |
|---|---|---|---|
| MPP列存 | ClickHouse, Doris, StarRocks | 单表聚合极快，高并发 | 多表JOIN较弱，更新成本高 |
| 预聚合Cube | Apache Kylin, Druid | 超大规模预计算，查询稳定 | 灵活性差，维度爆炸 |
| 搜索引擎 | Elasticsearch | 全文检索，日志分析 | 聚合性能一般，存储成本高 |
| 流式OLAP | RisingWave, Materialize | 实时物化视图，SQL化流处理 | 生态较新，大规模场景验证不足 |
个人建议：如果你的场景是大宽表 + 高并发点查 + 简单聚合，ClickHouse或StarRocks是首选。如果多表关联 + 复杂分析，Doris的优化器更成熟。如果数据量极大且查询模式固定，Kylin的预计算方案依然能打。
你可能会问：那Flink和Spark Streaming算什么？它们是流计算引擎，负责数据的实时加工和清洗，最终数据还是要落到OLAP引擎里才能被查询。所以，一个完整的实时OLAP架构，通常是流计算 + OLAP引擎的组合。
1.5 实时OLAP架构全景图
下面这张图，是我自己总结的实时OLAP架构分层。它涵盖了从数据接入到数据服务的完整链路：
这张图我用了很多年。每次给团队做架构评审，我都会先画出这五层。你会发现，实时OLAP的核心不是某一款产品，而是整个链路的协同。哪一层出了问题，端到端延迟都会崩。
避坑提醒：我曾经在一个项目中，只关注了OLAP引擎的查询性能，却忽略了消息队列的积压处理。结果大促流量一上来，Kafka消费 lag 飙到几百万条，实时变成了“半小时级”。所以，实时OLAP的瓶颈往往在链路的前半段——数据接入和流计算。
1.6 小结
这一章我们聊了OLAP的基本概念，对比了实时与传统OLAP的差异，梳理了典型应用场景，也给出了技术选型的参考。你可能会觉得信息量有点大，没关系，后面的章节我们会逐一深入每个环节。
记住一句话：实时OLAP不是技术炫技，而是业务驱动。选型之前，先想清楚你的用户到底需要多快的数据，以及他们愿意为这个“快”付出多少成本。