1. OLAP 概念与实时场景

大家好，我是这次课程的主讲。做了十几年大数据架构，从 Hadoop 刚兴起那会儿就开始折腾数仓，后来慢慢转到实时 OLAP 这个方向。今天咱们先聊聊最基础的东西——OLAP 到底是什么，实时场景下它长什么样，以及它跟 OLTP 到底有啥区别。

说实话，很多刚入行的同学容易把这两个概念搞混。我记得有一次面试，候选人跟我说他做过 OLAP，结果一问细节，做的全是订单事务处理。嗯，这俩虽然都是数据库相关，但完全是两码事。

什么是 OLAP

OLAP，全称是 On-Line Analytical Processing，中文叫联机分析处理。说白了，它就是一套专门用来做数据分析的技术体系。你想想看，日常业务中我们经常要回答这些问题：

• 上个月哪个品类的销售额增长最快？
• 过去一小时，App 的 UV 是多少？
• 最近 7 天，风控规则命中率最高的地区是哪里？

这些问题都有一个共同点——它们需要对大量历史数据进行多维度的聚合查询。这就是 OLAP 的用武之地。

我在项目中遇到过不少团队，把 OLAP 当成万能存储来用。结果呢？写入压力一大，查询就卡死。所以一开始就要搞清楚：OLAP 是为分析设计的，不是为事务设计的。

实时 OLAP 的典型场景

传统 OLAP 一般是 T+1 的离线分析，跑个 Hive 任务，第二天看报表。但现在的业务要求越来越快，于是就有了实时 OLAP。我把它分成三个最常见的场景：

1. 实时大屏

这个大家应该不陌生。双十一的销售大屏、物流调度大屏、工厂产线监控大屏……数据每隔几秒刷新一次，领导站在大屏前看实时动态。

这种场景的特点是：高吞吐、低延迟、可视化。数据从产生到展示，端到端延迟通常要求在 5 秒以内。我曾经帮一家电商公司搭过双十一大屏，峰值时每秒要处理几十万条事件，ClickHouse 扛住了，但中间 Kafka 和 Flink 的调优花了不少功夫。

2. 实时报表

跟大屏不同，实时报表更多是给运营、产品、分析师看的。他们需要按小时甚至分钟级查看业务指标，比如：

• 今日新增用户数，按渠道维度下钻
• 实时 GMV，按城市、品类、支付方式交叉分析
• 广告投放的实时 ROI

实时报表对查询灵活性要求更高。用户可能随时改变维度组合，系统得能快速响应。我个人的经验是，这种场景用 Apache Druid 或者 StarRocks 会比较顺手，预聚合和实时摄入能力都很成熟。

3. 实时风控

这个场景最刺激。支付欺诈、账号盗用、恶意刷单……每一笔交易都要在毫秒级判断风险。风控系统需要实时计算用户画像、行为序列、规则匹配和模型打分。

我记得有一次帮某金融客户做风控 OLAP 选型，他们原来的方案用 Elasticsearch，结果高峰期查询 P99 延迟飙到 2 秒多，风控规则根本跑不完。后来换成 ClickHouse 加本地缓存，延迟降到了 200 毫秒以内。嗯，选对工具真的很重要。

OLAP 与 OLTP 的区别

这个问题我几乎每次培训都会被问到。咱们直接上表格对比，一目了然：

对比维度	OLTP	OLAP
典型系统	MySQL、PostgreSQL、Oracle	ClickHouse、Druid、StarRocks、Doris
数据模型	实体关系模型，3NF 范式	星型/雪花型模型，宽表，列存
读写特点	频繁小批量写入，随机读	批量写入，大范围扫描读
查询类型	点查、简单条件过滤	聚合、分组、排序、窗口函数
延迟要求	毫秒级（事务响应）	秒级到分钟级（分析响应）
并发能力	高并发（数千 QPS）	中低并发（数十到数百 QPS）
存储结构	行式存储	列式存储（主流）
典型场景	订单录入、用户注册、库存扣减	BI 报表、大屏、多维分析

你可能会问：能不能用 MySQL 做 OLAP？我见过有人这么干，把几亿条数据塞进 MySQL，然后跑 group by。结果呢？一个查询跑几分钟，还把业务库拖垮了。说白了，OLTP 和 OLAP 是两种不同的设计哲学，硬要用一把钥匙开两把锁，迟早要出问题。

本章知识体系

下面这张图帮你梳理了本章的核心脉络，从 OLAP 定义到实时场景再到与 OLTP 的对比，一目了然：

这张图把本章的核心内容串起来了。从 OLAP 的定义出发，延伸到三个实时场景，最后落到与 OLTP 的对比。后面的章节我们会逐一深入每个场景的选型细节和迁移实战。