对 Lambda 架构问题的深入理解

感谢 GPT，对很多问题的理解有机会更深。

大家攻击 Lambda 架构，常说的一个点就是 “实时离线指标存在差异”。“实时离线指标存在差异”，是一个真实困扰运营方的问题吗？

答案：是的，这是一个真实生活中的痛点。

原因如下，特别是第一条，会让业务运营存在不确定性，为了应对这种不确定性，可能需要预留出业务余量，造成浪费。

1. 实时数据偏差引发错误判断
   • 运营团队可能在实时看板上看到用户注册数为 900，以为目标还没达成，于是推送通知、加大预算。
   • 结果第二天离线数据跑完，真实注册是 1100，实际早就达成了。
   • 这会造成 资源浪费、判断误差。

2. 数据不一致影响信任
   • 运营问：“实时看板显示新增 900，日报却说新增 1100，这是哪个错了？”
   • 数据团队解释：“实时数据有水位延迟、数据乱序、去重不完整……”
   • 非技术同学听不懂，久而久之就对系统失去信任。

3. 多方依赖相同指标，版本不一致
   • 实时系统和离线系统往往使用不同代码、不同计算链路：
   • 实时：Kafka → Flink → Redis/ClickHouse
   • 离线：Hive/Spark → HDFS → 数据仓库
   • 一点小的业务逻辑差异、时间处理方式不同、清洗策略不同，就会让指标产生偏差。

附1：实时指标为什么可能不对？

答：因为 Flink 的计算有时间窗口的概念，比如：每个整点，计算上一个小时的销售额。因为队列延迟、网络出错、重试导致数据重复等原因，会让 Kafka 等队列中的数据不能完全被信任，上一个小时的数据不一定真的全了，可能有一些数据要等几分钟才到，也有可能永远不到。
为了解决这个问题，一般会延迟几分钟，等等跑慢了的数据。但也不能无限等下去。理论上总是可能有数据来晚了。

附2：批处理系统（离线） + 流处理系统（实时） + Serving 层合并结果为什么不准？

简而言之：因为实时数据不准确，那么 Serving 的到的数据肯定也不准确。

Lambda 架构：批处理系统（离线） + 流处理系统（实时） + Serving 层合并结果

我之前的疑问：Serving 层如何合并？如何保证离线+实时，得到准确的全量数据？
一般大家说得不到，原因就在于
（1）流处理系统拿到的数据可能是不准确的
（2）离线、实时数据的边界可能有模糊的地方。