咳,随着数据量的暴增和数据实时性要求越来越高,以及大数据技术的发展驱动企业不断升级迭代,数据仓库架构方面也在不断演进,分别经历了以下过程:早期经典数仓架构 > 离线大数据架构 > Lambda > Kappa > 混合架构。
| 架构 | 组成 | 特点 |
| — | — | — |
| 经典数仓架构 | 关系型数据库(mysql、oracle)为主 | 数据量小,实时性要求低 |
| 离线大数据架构 | hive,spark为主 | 数据量大,实时性要求低 |
| Lambda | hive,spark负责存量,strom/Flink负责实时计算 | 数据量大,实时性要求高 |
| Kappa | kafka、strom、Flink | 多业务,多数据源,事件型数据源 |
| 混合架构 | | |
ps.表中举例若有不当,欢迎指正
==================================================================
Lambda架构的核心思想是把大数据系统拆分成三层:Batch Layer,Speed Layer和Serving Layer。其中,Batch Layer负责数据集存储以及全量数据集的预查询。Speed Layer主要负责对增量数据进行计算,生成Realtime Views。Serving Layer用于响应用户的查询请求,它将Batch Views和Realtime Views的结果进行合并,得到最后的结果,返回给用户,如下图
Lambda架构解决了大数据量下实时计算的问题,但架构本身也存在一定缺点。
-
实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两个计算框架和计算程序,算出的结果往往不同,经常看到一个数字当天看是一个数据,第二天看昨天的数据反而发生了变化。
-
批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
-
开发和维护的复杂性问题:Lambda 架构需要在两个不同的 API(application programming interface,应用程序编程接口)中对同样的业务逻辑进行两次编程:一次为批量计算的ETL系统,一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库,各有不同的漏洞。这种系统实际上非常难维护
-
服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。
=================================================================
Kappa架构的核心思想包括以下三点:
-
用Kafka或者类似的分布式队列系统保存数据,你需要几天的数据量就保存几天。
-
当需要全量重新计算时,重新起一个流计算实例,从头开始读取数据进行处理,并输出到一个新的结果存储中。
-
当新的实例做完后,停止老的流计算实例,并把老的一些结果删除。
在Kappa架构下,只有在有必要的时候才会对历史数据进行重复计算,并且实时计算和批处理过程使用的是同一份代码。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Python工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Python开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以扫码获取!!!(备注Python)
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以扫码获取!!!(备注Python)
![img](https://img-blog.csdnimg.cn/img_convert/bd0a9a971c3102633ca31459b693065e.jpeg)