一篇文章搞懂数据仓库：数据仓库架构-Lambda和Kappa对比(1)

2401_84166567

于 2024-04-28 13:14:59 发布

阅读量522

点赞数 20

分类专栏：程序员文章标签：数据仓库架构

本文链接：https://blog.csdn.net/2401_84166567/article/details/138274879

版权

184 篇文章 0 订阅

订阅专栏

Lambda架构的缺点

Lambda架构解决了大数据量下实时计算的问题，但架构本身也存在一定缺点。

实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。
批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护
服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

Kappa

=================================================================

Kappa架构原理

Kappa架构的核心思想包括以下三点：

在这里插入图片描述在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。

Lambda架构和Kappa架构优缺点对比

=================================================================================

| 项目 | Lambda | Kappa |

| — | — | — |

| 数据处理能力 | 可以处理超大规模的历史数据 | 历史数据处理的能力有限 |

| 机器开销 | 批处理和实时计算需一直运行，机器开销大 | 必要时进行全量计算，机器开销相对较小 |

| 存储开销 | 只需要保存一份查询结果，存储开销较小 | 需要存储新老实例结果，存储开销相对较大 |

| 开发、测试难度 | 实现两套代码，开发、测试难度较大 | 只需面对一个框架，开发、测试难度相对较小 |

| 运维成本 | 维护两套系统，运维成本大 | 只需维护一个框架，运维成本小 |

小结

==============================================================

小编有话

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

战项目、大纲路线、讲解视频，并且后续会持续更新**

关注