1. 实时OLAP分析全景与课程定位

实时OLAP（Online Analytical Processing）指的是在数据产生后秒级到分钟级内即可被查询、聚合与下钻分析的一类分析型数据库能力。它要解决的核心问题不是“能不能存下数据”，而是“数据到达后多快能被业务看到、看到后能不能立刻按任意维度切片”。在风控、营销、监控等场景中，这个“多快”往往直接决定业务动作是否还有意义：一笔支付是否拦截、一次促销是否追加预算、一条告警是否触发扩容，都要求在极短时间内完成对海量明细的聚合判断。

理解实时OLAP，关键是把它与两个容易混淆的概念划清边界：离线OLAP和流处理。离线OLAP（如Hive/Spark SQL、传统数仓）以T+1或小时级批处理为主，数据先落存储再统一计算，优势是吞吐大、成本低、口径稳定，但延迟以小时计，无法支撑即时决策。流处理（如Flink、Kafka Streams）擅长对事件流做逐条或窗口计算，延迟可到毫秒级，但它通常面向“预定义的计算逻辑”，输出的是指标结果或告警，而不是让分析师随时发起任意维度的即席查询。实时OLAP处在两者之间：它既要有接近流处理的写入时效，又要保留OLAP的灵活多维分析能力。

从图中可以看到，实时OLAP并不是替代流处理或离线OLAP，而是在数据链路中承担“可交互分析层”的角色。流处理负责把原始事件加工成有业务含义的中间结果，实时OLAP负责把这些结果以可查询、可聚合、可下钻的形式暴露给分析师和业务系统，离线OLAP则负责历史沉淀与最终对账。三者是互补关系，而不是互斥关系。

典型生产场景

实时风控。以支付风控为例，一笔交易发生后，系统需要在几百毫秒内判断是否命中规则。风控引擎通常先查实时OLAP中的用户近1分钟交易笔数、近1小时累计金额、近24小时设备更换次数等聚合指标，再结合规则引擎做决策。这里的实时OLAP查询特点是：高并发点查、按用户ID精确过滤、时间窗口聚合。示例参数：单集群QPS约5万，P99查询延迟要求小于50ms，单表日增明细约20亿行。

实时营销。运营人员需要在大促期间实时观察各渠道的曝光、点击、转化、GMV，并按城市、商品类目、用户分层下钻。这类场景的查询特点是：维度组合多、聚合量大、看板刷新频繁。示例参数：看板每10秒刷新一次，单次查询扫描近1小时数据约3亿行，要求返回时间小于2秒。实时OLAP需要支持物化视图或预聚合来降低重复计算。

实时监控。运维和SRE团队需要实时查看服务调用量、错误率、P99延迟、机器负载等指标，并在异常时快速定位到具体实例或接口。这类场景的查询特点是：时间序列特征明显、按时间范围过滤、按标签分组聚合。示例参数：每秒写入约200万条指标点，查询通常覆盖最近5分钟到1小时，要求亚秒级返回。

课程整体学习路径与实战目标

本课程共30章，围绕“建得起来、查得快、稳得住、算得准”四条主线展开。前段先建立全景认知与选型判断，中段深入表模型、写入链路、查询执行、索引与预聚合等核心机制，后段聚焦性能调优、资源隔离、监控排障与生产运维。每一章都会尽量落到可操作的对象、参数和判断依据上，而不是停留在概念介绍。

学习路径可以概括为四个阶段：

• 认知与选型（第1~5章）：理解实时OLAP边界，掌握Doris、StarRocks、ClickHouse等主流引擎的适用场景与选型依据。
• 建模与写入（第6~12章）：掌握明细模型、聚合模型、主键模型、物化视图的设计方法，以及Flink/CDC写入链路的稳定性保障。
• 查询与优化（第13~22章）：深入执行计划、索引、分区裁剪、Join优化、内存与并发控制，学会用Profile定位慢查询。
• 生产与运维（第23~30章）：覆盖监控告警、扩缩容、数据一致性、故障恢复与成本治理，形成完整的生产闭环。