1. 实时数仓概述

大家好，我是这次课程的主讲。做了这么多年大数据架构，我见过太多团队在「数仓该不该实时」这个问题上反复纠结。今天咱们就从最基础的问题聊起——实时数仓到底是什么？它跟传统数仓差在哪？

1.1 实时数仓与传统数仓的区别

传统数仓，说白了就是「今天看昨天的数据」。凌晨跑批，T+1 出报表，这是过去十几年的标准玩法。但到了现在这个时代，业务方等不了那么久——用户下了单，运营想立刻看到转化；系统出了故障，运维想秒级定位问题。

实时数仓的核心区别就一句话：数据从产生到可查询的时间窗口，从小时级、天级压缩到分钟级、秒级。

对比维度	传统数仓	实时数仓
数据延迟	T+1 或小时级	秒级到分钟级
计算模式	批量调度（离线ETL）	流式计算 + 微批
存储介质	HDFS / 关系型数据库	消息队列 + 对象存储 + OLAP引擎
数据一致性	强一致（事务保证）	最终一致（Exactly-Once语义）
典型场景	财务月报、年度分析	实时大屏、风控、推荐

我刚开始做实时数仓的时候，犯过一个低级错误——直接把离线ETL的逻辑搬到流上，结果数据对不上。后来才明白，实时和离线不是简单的「加速版」，而是两种完全不同的思维方式。

1.2 Lambda 架构与 Kappa 架构

聊实时数仓，绕不开这两个架构。我见过不少团队在这上面踩坑，包括我自己。

Lambda 架构

Lambda 架构把数据处理分成两条路：一条是实时流（Speed Layer），处理秒级数据；另一条是离线批（Batch Layer），处理全量历史数据。最后通过 Serving Layer 把两边的结果合并。

听起来很完美对吧？但实际用起来，问题不少。

Lambda 架构的优点很明显：历史数据可以重算，容错性好。但代价就是维护成本高，代码冗余严重。

Kappa 架构

Kappa 架构就干脆多了——只用一套流处理引擎，所有数据都走实时流。历史数据重算？把数据重新从消息队列里拉一遍就行。

你想想看，如果只用 Flink 或 Spark Streaming 搞定所有事，是不是省心很多？

但 Kappa 也不是银弹。我遇到过的问题是：消息队列的保留时间有限，比如 Kafka 默认只保留 7 天。真要重算三个月前的数据，还得靠离线存储兜底。

下面这张图可以帮你快速理解两者的区别：

1.3 实时数仓的应用场景

说了这么多理论，咱们看看实际中哪些场景非用实时数仓不可。

• 实时大屏与监控——双11大屏、服务器监控面板，数据晚一秒都影响决策。我记得有个电商客户，大促期间大屏数据延迟超过30秒，运营总监直接打电话过来骂人。
• 实时风控——支付欺诈、刷单检测，必须在毫秒级完成。离线分析？等跑完批，钱早被转走了。
• 实时推荐——用户刚点了一个商品，推荐系统立刻更新候选集。我做过一个案例，实时推荐比离线推荐点击率提升了40%。
• 实时数据湖——把流式数据直接写入 Iceberg / Hudi 等湖格式，既支持实时查询，又保留历史版本。这也是咱们这门课的核心内容。
• 实时 ETL 与数据同步——从业务库 CDC 同步到数仓，替代传统的 Sqoop 定时抽取。