一、实时数仓概述：从离线到实时的演进之路

做数据这行这么多年，我亲眼看着数仓从「T+1」慢慢变成了「T+0」。说白了，实时数仓就是让数据从产生到可分析的时间窗口，从一天缩短到秒级。这个变化看似简单，背后的架构演进却很有意思。

1.1 实时数仓的演进历程

我记得刚入行那会儿，公司还在用传统的离线数仓。每天凌晨跑批，早上九点出报表。业务方问能不能看实时数据？我只能摇头。后来随着业务发展，这种「隔夜饭」式的数据服务越来越跟不上节奏。

实时数仓的演进大致经历了三个阶段：

• 第一阶段：离线数仓 + 实时补丁 —— 在离线数仓旁边加一套 Flink/Spark Streaming，单独处理实时链路。数据口径经常对不上，我踩过不少坑。
• 第二阶段：Lambda 架构 —— 离线批处理和实时流处理并行，最终合并结果。解决了口径问题，但维护两套代码让人头疼。
• 第三阶段：Kappa 架构 —— 统一用流处理引擎，把批看成流的特例。架构简化了，但对消息队列和状态管理要求更高。

1.2 Lambda 架构与 Kappa 架构对比

这两个架构是实时数仓领域绕不开的话题。我分别说说它们的核心思路和适用场景。

Lambda 架构

Lambda 架构把数据处理分成三条路径：

• 批处理层（Batch Layer）：处理全量历史数据，生成准确的离线视图
• 流处理层（Speed Layer）：处理实时增量数据，提供低延迟的近似结果
• 服务层（Serving Layer）：合并批和流的结果，对外提供服务

我在一家电商公司做实时大屏时用过 Lambda。当时业务要求同时看历史趋势和实时销量，批处理用 Hive，流处理用 Flink，最后在 ClickHouse 里做合并。效果不错，但维护两套逻辑确实累——改一个指标口径，批和流都得改，还容易出偏差。

Kappa 架构

Kappa 架构的思路更简洁：只用一套流处理引擎，所有数据都当流来处理。历史数据通过重放消息队列来重新计算。

• 统一引擎：Flink 或 Kafka Streams 搞定一切
• 数据重放：需要修正时，从 Kafka 的起始 offset 重新消费
• 状态管理：依赖引擎的 checkpoint 和状态后端

Kappa 的优点是架构简单、口径统一。但缺点也很明显：消息队列的存储成本高，历史数据重放耗时，状态后端容易成为瓶颈。我建议在数据量不大、历史回溯需求少的场景优先考虑 Kappa。

对比维度	Lambda 架构	Kappa 架构
处理引擎	批 + 流两套	一套流引擎
代码维护	两套逻辑，口径易偏差	统一逻辑，口径一致
历史回溯	批处理天然支持	需重放消息队列
存储成本	批流各自存储，成本高	统一存储，相对节省
延迟	流处理秒级，批处理小时级	秒级到分钟级
适用场景	历史数据量大、口径复杂	数据量适中、实时性要求高

1.3 实时数仓的应用场景

实时数仓不是万能药，它解决的是特定场景下的数据时效性问题。我梳理了几个典型的应用场景：

实时大屏与监控

电商大促的实时 GMV、直播间的在线人数、服务器的异常指标……这些场景对延迟敏感，数据晚几秒就可能错过决策窗口。实时数仓在这里的价值最直接。

实时风控与反欺诈

支付交易、登录行为、营销活动……风控规则需要在毫秒到秒级做出判断。实时数仓提供特征计算和规则引擎的基础数据支撑。

实时推荐与个性化

用户刚点击了一个商品，下一秒的推荐列表就应该反映这个行为。实时数仓把用户行为实时加工成特征，喂给推荐模型。

实时数据产品

比如实时报表、自助分析工具、数据 API 服务。业务方希望看到「现在」的数据，而不是「昨天」的数据。

嗯，这里要注意一点：不是所有场景都需要实时。我见过有人把月报也做成实时流，结果成本和收益完全不成正比。实时数仓的投入产出比，一定要算清楚。

1.4 本章知识体系总览

下面这张图概括了实时数仓的核心脉络，从演进历程到架构选型，再到应用场景。你可以把它当作后续学习的路线图。

这张图把本章的三个核心模块串起来了。从左到右，你能看到实时数仓「从哪里来、怎么选、用在哪」。后续章节我们会深入每个模块的细节，包括数据采集、实时计算、存储选型，以及最重要的——全链路数据质量监控。