一、实时数仓概述：从离线到实时的进化之路
大家好，我是这次课程的主讲。今天咱们聊聊实时数仓的来龙去脉。说实话，我做了快十年的大数据架构，亲眼看着数仓从「T+1」一步步走到「秒级响应」。这个过程，踩过的坑比吃过的盐还多。
你可能会问：离线数仓用得好好的，为什么非要搞实时？嗯，这个问题我当年也问过自己。直到有一次，业务方凌晨三点打电话说「双十一大屏数据延迟了半小时」——从那以后，我再也不敢轻视实时能力。
1.1 实时数仓与传统数仓的区别
传统数仓，说白了就是「今天算昨天的账」。数据从业务系统抽过来，经过ETL清洗，落进Hive或者Greenplum，第二天早上出报表。这套模式跑了好多年，稳定是稳定，但有个硬伤——慢。
实时数仓不一样。它的核心是「数据产生即可用」。用户点个按钮，后台几秒钟就能看到效果。这不是炫技，是业务倒逼出来的。
核心差异对照表
| 对比维度 | 传统数仓 | 实时数仓 |
|---|---|---|
| 数据延迟 | T+1（天级） | 秒级～分钟级 |
| 计算模式 | 批量调度（离线ETL） | 流式计算 + 微批 |
| 存储选型 | HDFS、Hive、MPP | 消息队列 + OLAP引擎 |
| 数据一致性 | 强一致（事务保证） | 最终一致（允许短暂偏差） |
| 典型场景 | 财务月报、经营分析 | 实时大屏、风控、推荐 |
我个人的习惯是：能用离线解决的，绝不硬上实时。实时是有成本的——集群资源、运维复杂度、数据一致性保障，每一项都不轻松。但有些场景，比如金融风控、电商大促、物联网监控，你不实时就等于没做。
1.2 实时数仓的架构演进
实时数仓不是一天建成的。我把它分成三个阶段，你对照一下自己团队在哪个位置。
阶段一：Lambda架构（批流分离）
这是最经典的方案。一条批处理链路跑全量数据，一条流处理链路跑增量数据，最后在服务层做合并。听起来合理，对吧？但我在项目里吃过它的苦头——维护两套代码，逻辑稍微不一致，结果就对不上。业务方天天问「为什么离线报表和实时大屏数字不一样？」
阶段二：Kappa架构（纯流式）
后来大家想了个办法：既然批流合并这么痛苦，干脆全走流。Kafka存全量数据，Flink从Kafka消费，需要重算时直接回放。这个思路很漂亮，但有个前提——你的消息队列得扛得住全量数据的存储和回溯。
我记得有个项目，每天几百亿条日志，Kafka集群的磁盘直接被打满。后来加了层级存储才稳住。所以说，Kappa虽好，基础设施得跟上。
阶段三：实时湖仓一体（流批融合）
这是目前的主流方向。底层用Iceberg或Hudi这样的湖格式，上层用Flink做流式写入，Kafka做实时管道。数据既可以实时查询，也能跑离线分析。说白了，就是「既要又要还要」——但这次真的做到了。
我的建议：新项目直接上实时湖仓一体。如果团队还在Lambda上挣扎，优先考虑迁移到Kappa，别在批流分离的路上越走越远。
1.3 Kafka在实时数仓中的定位
聊了这么多架构，Kafka到底扮演什么角色？我用一句话总结：实时数仓的「中枢神经」。
没有Kafka，实时数仓也能跑——用Pulsar、用RocketMQ，甚至直接用TCP直连。但Kafka之所以成为事实标准，靠的是三个硬实力：
- 高吞吐：单机每秒百万条消息，这个量级在业界是独一档的
- 持久化：消息落盘，支持回溯重放，这是Kappa架构的基石
- 生态：Flink、Spark、ClickHouse、Doris……几乎所有主流引擎都原生支持Kafka
我在设计实时数仓时，通常把Kafka放在这个位置：
你看这张图，Kafka处在中间位置。上面接各种数据源，下面连计算引擎和存储系统。它不负责计算，也不负责存储最终结果，但它保证数据「流得动、不丢、不乱序」。
避坑提醒：我曾经见过一个团队，把Kafka当数据库用——在Topic里存了几个月的数据，还不设过期策略。结果磁盘爆了，整个集群重建。记住，Kafka是管道，不是仓库。数据该过期就过期，该归档就归档。
小结
这一章我们聊了三件事：实时数仓为什么和传统数仓不一样，架构是怎么一步步演进的，以及Kafka在其中扮演的角色。说白了，实时数仓的核心就一句话——让数据更快地产生价值。而Kafka，就是那条让数据跑起来的「高速公路」。