1. 实时OLAP概述

大家好，我是老张。做OLAP这行快十年了，从传统数仓一路干到实时。今天咱们聊聊实时OLAP——说白了，就是让数据从产生到能分析，延迟控制在秒级甚至毫秒级。嗯，这跟传统OLAP完全是两码事。

1.1 实时OLAP的定义

实时OLAP，全称是Online Analytical Processing，但加了个"实时"前缀。它允许用户在数据产生后极短时间内进行多维查询和分析。我习惯这么定义：数据写入到可查询的延迟在1分钟以内，且支持高并发、低延迟的即席查询。

你想想看，传统OLAP跑个ETL要等T+1，第二天才能看昨天的报表。实时OLAP呢？用户刚下的单，10秒后就能在GMV大屏上看到。我在项目中遇到过，电商大促期间，运营盯着实时大屏调策略，晚一分钟可能就错过几百万的生意。

1.2 与传统OLAP的区别

很多人问我，实时OLAP不就是把批处理改成流处理吗？没那么简单。我整理了一张对比表，你看完就明白了。

维度	传统OLAP	实时OLAP
数据延迟	T+1，甚至更久	秒级到分钟级
数据源	离线数仓、批量导入	消息队列、实时流
计算引擎	MapReduce、Spark Batch	Flink、Spark Streaming
存储选型	Hive、传统MPP	ClickHouse、Doris、Druid
查询模式	预计算、预聚合	预聚合+实时计算混合
数据一致性	强一致（事务保证）	最终一致（允许短暂不一致）
典型场景	财务月报、年度分析	实时大屏、风控监控

这里有个关键点：实时OLAP不是要取代传统OLAP。我见过不少团队一上来就想全量实时化，结果搞到一半发现历史数据回溯、复杂关联查询根本跑不动。我的建议是：实时OLAP解决的是"快"的问题，传统OLAP解决的是"全"和"准"的问题，两者互补。

1.3 实时数仓架构演进

说到实时数仓架构，绕不开Lambda和Kappa。这两个架构之争，我当年也纠结了很久。先看一张架构对比图。

1.4 Lambda 架构

Lambda架构是2011年由Nathan Marz提出的。它的核心思想是：用批处理保证数据准确性，用流处理保证数据实时性。两条链路并行，最终在查询层合并。

我在2017年参与过一个金融风控项目，用的就是Lambda。当时的需求很明确：实时监控交易异常，同时每天跑全量对账。批处理层用Spark SQL做T+1的精确计算，流处理层用Flink做秒级预警。嗯，听起来很完美对吧？但实际踩了不少坑。

Lambda架构的优缺点很明显：

• 优点：容错性好，批处理可以重跑修复历史数据；实时性有保障，流处理覆盖近实时场景。
• 缺点：代码维护成本高，两套逻辑容易不一致；资源消耗大，存储和计算都有冗余。

1.5 Kappa 架构

Kappa架构是Jay Kreps在2014年提出的。说白了，就是抛弃批处理，所有数据都走流处理。核心思想是：既然流处理引擎（如Flink）已经支持Exactly-Once语义和状态管理，为什么还要保留批处理这条线？

我后来在2019年做一个电商实时大屏项目时，果断选了Kappa。架构简单太多了：所有数据进Kafka，Flink消费后直接写入ClickHouse，前端大屏实时刷新。运维只需要盯一套链路。

但Kappa也不是银弹。我遇到过一个问题：当需要重跑历史数据时，Kappa需要从Kafka的起始offset开始消费，如果数据量很大，重放时间会非常长。这时候Lambda的批处理优势就体现出来了——直接跑个Spark任务，几小时搞定。

1.6 如何选择？

很多新人问我：到底选Lambda还是Kappa？我的回答是：看场景，别跟风。

我个人的经验是：

• 金融、医疗等强一致性场景：Lambda更稳妥。批处理可以保证最终数据的准确，实时层只做辅助决策。
• 互联网、电商等追求时效性场景：Kappa更合适。架构简洁，迭代快，偶尔的数据不一致可以通过业务补偿。
• 混合场景：可以取中间态。比如核心指标走Lambda，非核心指标走Kappa。我在一个物流项目中就这么干的——运单轨迹实时展示用Kappa，财务结算用Lambda。