1. 实时数仓概述：从离线到实时的演进、Lambda与Kappa架构对比、状态一致性的重要性

1.1 从离线数仓到实时数仓：我们为什么要变？

说实话，我刚入行那会儿，做的全是离线数仓。每天凌晨跑批，早上看报表，数据延迟24小时是常态。那时候大家觉得这很正常——业务决策嘛，看昨天的数据就够了。

但后来不行了。用户点了个广告，你得立刻知道转化率；双十一大促，GMV要秒级刷新；风控场景里，一笔交易延迟几分钟可能就出大事。离线数仓的「T+1」模式，越来越扛不住。

我经历过一个典型的案例：某电商平台做实时大屏，离线数仓凌晨3点才产出昨天的销售数据，运营团队白天开会用的永远是「过期」信息。后来我们上了实时数仓，数据延迟压到10秒以内，运营终于能盯着大屏做决策了。

离线数仓和实时数仓的核心差异，我列个表你就明白了：

对比维度	离线数仓	实时数仓
数据延迟	小时级~天级（T+1）	秒级~分钟级
计算引擎	Hive、Spark SQL（批处理）	Flink、Spark Streaming（流处理）
存储选型	HDFS、Hive表	Kafka、消息队列、OLAP引擎
数据一致性	强一致（事务保证）	最终一致（状态一致性挑战）
典型场景	月度报表、财务对账	实时大屏、风控、推荐

说白了，离线数仓追求的是「准」，实时数仓追求的是「快」。但问题来了——又快又准，能做到吗？这就是我们这门课要聊的核心。

1.2 Lambda与Kappa架构：两条不同的路

实时数仓刚兴起的时候，大家最先想到的是Lambda架构。我2018年参与过一个项目，就是典型的Lambda架构——批处理层跑全量数据保证准确性，流处理层跑增量数据保证低延迟，最后在服务层做合并。

听起来很完美对吧？但实际落地的时候，坑不少。

后来Kappa架构出现了。它的思路很简单：只用一套流处理引擎，所有数据都走流式处理。如果需要重算历史数据，就重新消费Kafka里的数据，从头跑一遍。

我个人的习惯是：如果业务场景允许数据最终一致，且Kafka能保留足够长的历史数据，我会优先选Kappa架构。少维护一套代码，少操一份心。

但Kappa架构也不是银弹。举个例子，你想想看——如果Kafka的Topic数据量巨大，重算一次要跑好几个小时，中间还可能出现状态不一致的问题，这时候你怎么办？

两种架构的对比，我整理了一下：

对比维度	Lambda架构	Kappa架构
核心思想	批处理+流处理并行，结果合并	统一用流处理，数据重放
代码维护	两套代码，维护成本高	一套代码，维护成本低
数据一致性	批处理保证强一致，流处理保证低延迟	依赖流处理引擎的状态一致性机制
历史重算	批处理层直接重算	重新消费Kafka数据
适用场景	对准确性要求极高，且能接受较高维护成本	数据量大、延迟敏感、能接受最终一致

下面这张图，是我自己画的一个Lambda与Kappa架构的对比流程图，帮你直观理解两者的差异：

1.3 状态一致性：实时数仓的「阿喀琉斯之踵」

聊完架构，咱们得聊聊这门课最核心的问题——状态一致性。

什么是状态？说白了，就是流处理过程中需要记住的「中间结果」。比如你算过去5分钟的UV，每个用户的访问记录就是状态；你算订单的累计金额，每一笔订单的金额就是状态。

状态一致性，就是保证这些中间结果在故障恢复后，依然准确无误。

状态一致性为什么这么重要？我总结了三个原因：

1. 数据准确性——实时数仓的输出直接驱动业务决策，数据错了，决策就偏了。
2. 故障恢复——流处理任务跑几个月是常态，中间任何一次故障，都要保证恢复后数据不丢不重。
3. 端到端一致性——从数据源到Kafka，再到Flink，最后到结果存储，每个环节都要保证一致，一个环节出问题，全链路的可信度就没了。

你想想看，一个实时大屏上显示「今日成交额1.2亿」，结果因为状态不一致，实际只有1.1亿。运营团队按1.2亿做了促销预算，最后对不上账——这种事故，谁扛得住？

1.4 本章小结

这一章我们聊了三件事：

• 离线数仓到实时数仓的演进，本质是业务对数据时效性的要求越来越高
• Lambda和Kappa两种架构各有优劣，选型要看团队和业务场景
• 状态一致性是实时数仓的基石，搞不定它，实时数仓就是空中楼阁

接下来的课程，我会带你一步步深入状态一致性的技术细节。从Flink的状态管理，到Checkpoint机制，再到端到端一致性保障——每一章都会有我踩过的坑和实战经验。准备好了吗？咱们开始吧。