1. 实时数仓数据一致性概述：为什么一致性是实时数仓的生命线？
大家好，我是老张。做了十几年数据架构，从离线数仓一路干到实时数仓，踩过的坑比写过的代码还多。今天咱们聊聊一个绕不开的话题——数据一致性。
说白了，数据一致性就是「数据对不对得上」。听起来简单，但在实时数仓里，这玩意儿就是命根子。你想想看，离线数仓跑个 T+1，数据对不上还能第二天补跑。实时数仓呢？数据是秒级流动的，出错了可能直接影响到线上业务决策。
核心观点：一致性不是可选项，而是实时数仓的生存底线。没有一致性，实时就是灾难。
1.1 从 Lambda 到 Kappa：一致性问题的放大效应
我记得刚接触实时数仓那会儿，业界主流还是 Lambda 架构。批处理层跑全量，流处理层跑增量，两套代码维护，数据对不上是家常便饭。
Lambda 架构长这样：
批处理层（Batch Layer）—— 全量计算 —— 服务层
↓
流处理层（Speed Layer）—— 增量计算 —— 服务层你看，两条链路最终都要写入服务层。批处理跑的是精确结果，流处理跑的是近似结果。两者一合并，问题就来了——数据对不上。我在项目中遇到过好几次，业务方拿着报表质问：「为什么昨天和今天的数据差了 5%？」
后来 Kappa 架构出现了，统一用流处理搞定一切。听起来很美，对吧？但问题并没有消失，反而被放大了。
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 处理模式 | 批处理 + 流处理 | 纯流处理 |
| 一致性风险 | 两套结果不一致 | 流处理状态一致性 |
| 数据回溯 | 批处理重跑 | 重新消费消息 |
| 复杂度 | 高（两套代码） | 中（一套代码） |
| 一致性保障难度 | 中等 | 高 |
为什么会这样？我给大家拆解一下。
1.2 Kappa 架构下的一致性挑战
Kappa 架构把所有数据都塞进消息队列（比如 Kafka），然后用流处理引擎（比如 Flink）统一处理。数据流是连续的，状态是持久的，但问题也出在这里。
第一个坑：消息乱序。 你发送了 A、B、C 三条消息，结果流处理收到的是 A、C、B。如果业务逻辑依赖顺序，结果就全错了。我曾经在做一个订单实时统计时，就因为消息乱序，导致当天的 GMV 统计差了 200 万。
第二个坑：状态一致性。 流处理引擎需要维护状态，比如窗口聚合结果。如果任务挂了重启，状态恢复不对，数据就全乱了。Flink 的 Checkpoint 机制就是为了解决这个问题，但配置不好照样翻车。
第三个坑：端到端一致性。 数据从源头（比如 MySQL Binlog）到消息队列，再到流处理，最后写入目标存储（比如 HBase、ClickHouse）。任何一个环节出问题，数据就对不上。
避坑指南：我曾经在一个项目中，Kafka 的 producer 配置了 acks=1，结果 broker 挂了，数据丢了。业务方发现数据对不上，排查了三天才找到原因。后来我强制要求所有实时链路必须配置 acks=all，并且开启幂等性。
1.3 一致性问题的本质：从「最终一致」到「强一致」
离线数仓可以接受最终一致性——今天的数据明天对得上就行。但实时数仓不行，尤其是面向在线业务场景时。
我给大家画个图，看看实时数仓的一致性到底涉及哪些层面：
你看，从数据源到最终存储，每一层都可能出问题。我个人的经验是，一致性保障不能只靠某一层，而是需要端到端的方案。
1.4 为什么说一致性是生命线？
说个真实案例。我之前负责一个实时风控系统，数据从用户行为日志采集，经过 Flink 实时计算，最终写入 ClickHouse 供规则引擎查询。有一次 Kafka 集群抖动，导致部分消息被重复消费。结果呢？同一个用户的行为被统计了两次，风控规则误判，把正常用户给封了。
业务方直接炸了。你说，这是不是生命线？
实时数仓的一致性，说白了就是三个层次：
- 数据不丢： 消息队列的持久化、消费位点管理、Checkpoint 机制
- 数据不重： 幂等写入、去重机制、事务支持
- 数据不乱： 事件时间处理、水位线机制、乱序容忍
我的建议：刚开始做实时数仓的同学，别急着上复杂架构。先把「数据不丢」和「数据不重」搞定，再考虑「数据不乱」。这三步走稳了，一致性才有保障。
1.5 本章小结
从 Lambda 到 Kappa，架构在简化，但一致性挑战在升级。Kappa 架构把数据流变成了一个连续管道，任何环节的抖动都会传导到最终结果。这就是为什么我说，一致性是实时数仓的生命线。
接下来的章节，我会带大家深入每个环节，看看具体怎么保障一致性。嗯，咱们一步步来。