对 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)离线、实时数据的边界可能有模糊的地方。

相关推荐
java叶新东老师1 小时前
PowerDesigner 画ER图并生成sql 教程
数据库·sql
Jonariguez1 小时前
Mysql InnoDB存储引擎
数据库·mysql
nbsaas-boot2 小时前
SQL Server 窗口函数全指南(函数用法与场景)
开发语言·数据库·python·sql·sql server
Y.ppm2 小时前
数分思维12:SQL技巧与分析方法
数据库·sql
森叶2 小时前
Claude Code 安装向量数据库MCP服务
数据库
bestsun9992 小时前
Time drifts can result in unexpected behavior such as time-outs.
数据库·oracle
SoFlu软件机器人3 小时前
秒级构建消息驱动架构:描述事件流程,生成 Spring Cloud Stream+RabbitMQ 代码
分布式·架构·rabbitmq
waveee1234 小时前
学习嵌入式的第三十四天-数据结构-(2025.7.29)数据库
数据结构·数据库·学习
何传令4 小时前
SQL优化系统解析
数据库·sql·mysql
智海观潮4 小时前
Unity Catalog与Apache Iceberg如何重塑Data+AI时代的企业数据架构
大数据·人工智能·ai·iceberg·catalog