1)API层简单地说就是Spark会通过一些API接受SQL语句
2)收到SQL语句后,将其交给Catalyst,Catalyst负责解析SQL,生成执行计划等
3)Catalyst的输出应该是RDD的执行计划
4)最终再交给集群去运行
15.SparkSQL的执行流程
1)提交SparkSQL代码
2)catalyst优化
a.生成原始的AST语法树
b.标记AST元数据
c.进行断言下推和列值裁剪,以及其他方面的优化作用在AST上
d.将最终的AST得到,生成执行计划
e.将执行计划翻译为RDD代码
3)Driver执行环境入口构建(SqlSession)
4)DAG调度规划逻辑任务
5)TASK调度区分配逻辑任务到具体Executor上工作并监控管理任务
6)Worker干活
DataFrame代码再怎么被优化,最终还是被转换为RDD去执行。
15.Spark on Hive
回顾Hive组件:
对于Hive来说,就两样东西:
1)SQL优化翻译器(执行引擎),翻译SQL到MapReduce并提交到YARN执行
2)MetaStore元数据管理中心
那么Spark on Hive是什么呢?请看下面的图:
由上图可知,Spark on Hive不外乎就是SparkSQL借用了Hive的元数据管理中心,也就是说Hive的MetaStore+SparkSQL就构成了Spark on Hive,然后执行的时候走的是SparkRDD代码这条支线,就不再走Hive老旧的MapReduce这条路线。以上就是Spark on Hive的基本原理。
16.ThriftServer服务(就是方便程序员使用,不需要程序员专门会写Spark或者DataFrame的API依然可以操作Spark)
该服务监听10000端口,该服务对外提供功能,使得我们可以用数据库工具或者代码连接上来,直接写SQL便可操作Spark。(底层是翻译成RDD运行的)
17.分布式SQL归纳
分布式SQL执行引擎就是使用Spark提供的ThriftServer服务,以“后台进程”的模式持续运行,对外提供端口。
可以通过客户端工具或者代码,以JDBC协议连接使用。
SQL提交后,底层运行的就是Spark任务。
**分布式SQL大白话总结:相当于构建了一个以MetaStore服务为元数据,Spark为执行引擎的数据库服务,**像操作数据库那样方便的操作SparkSQL进行分布式的SQL计算。
18.Spark层次关系概念图
19.Spark核心概念思维导图
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Kafka在大数据的应用场景
20.MQ消息队列
消息队列-----用于存放消息的组件
程序员可以将消息放入到队列中,也可以从消息队列中获取消息
很多时候消息队列并不是一个永久性存储,而是作为一个临时存在的(设定一个期限:例如消息在MQ中保存10天)
21.消息队列(主要记录Kafka)的应用场景
1)异步处理:
电商网站新用户注册时,需要将用户的信息保存到数据库中,同时还要额外的发送注册的邮件通知,以及短信注册码给用户。但因为发送邮件,发送短信注册码需要连接外部的服务器,需要额外等待一段时间,此时,就可以使用消息队列来进行异步处理,从而实现快速响应。(其实就是不用及时处理的请求,就堆起来等会处理罢了)
{可以将一些比较耗时的操作放在其他系统中,通过消息队列将需要进行处理的消息进行存储,其它系统可以消息队列中的数据,例如发送短信验证码,发送邮件}。
2)系统解耦:
比如如果订单系统和库存系统耦合着。如果库存系统出现问题,会导致订单系统下单失败,而且如果库存系统接口修改了,会导致订单系统也无法工作。
使用消息队列可以实现系统和系统之间的解耦,订单系统不再调用库存系统接口,而是把订单消息写入到消息队列,库存系统从消息队列中拉取消息,然后再减库存,从而实现系统的解耦。
{原来一个微服务是通过接口(HTTP)调用另一个微服务,这时候耦合严重,只要接口发生变化j就会导致系统不可用。使用消息队列可以将系统进行解耦,现在一个微服务可以将消息放入到消息队列中,另一个微服务可以从消息队列中取出来进行处理。进行系统解耦}。
3)流量削峰:
有大规模用户请求过来,在某个瞬间流量达到顶峰,如果在顶峰没有打下巨大的请求流量,可能会瞬间压垮数据库(而且响应越慢用户越疯狂,用户会疯狂的刷新,不断地发送请求过来)。这个时候可以利用消息队列的大吞吐量先存储大量的用户请求,并可以快速地响应用户:你先等着,然后业务处理程序再去从消息队列中拉去请求来处理。
{因为消息队列是低延迟,高可靠,高吞吐的,可以应对大量并发}。
4)日志处理(大数据领域常见):
大型的电商网站(淘宝京东抖音拼多多),APP(滴滴,抖音,饿了么等)需要分析用户的行为,这要根据用户的访问行为来发现用户的喜好以及活跃情况,需要在页面上收集大量的用户访问信息。
然而他们不会将用户的这些访问信息专门存储到数据库中,而是当用户点击网页的时候,直接将用户的这个访问信息发送到一台服务器中,然后再存储到服务器上的文件当中。(可以在扔给服务器的过程当中,先扔给消息队列暂存,因为消息队列的吞吐量大嘛)
{可以使用消息队列作为临时存储,或者一种管道通信}。
22.消息队列的两种模型
生产者,消费者模型
23.消息队列的两种模式
1)点对点模式
每个消息只有一个消费者(消费了消息就不在了)
生产者和消费者没有依赖性,生产者发送消息之后,不管有没有消费者在运行,都不会影响生产者下次发送消息。
消费者成功消费消息之后需要向队列应答成功,以便消息队列删除已经被消费的消息。
2)发布订阅模式
每个消息可以有多个订阅者。
发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
为了消费消息,订阅者需要提前订阅该角色主题,并保持在线运行。
24.Kafka概念
Apache Kafka是一个分布式流平台。一个分布式流平台应该包含三个部分的能力:
1)发布订阅流数据流,类似于消息队列或者是企业消息传递系统。
2)以容错的持久化方式存储数据流。
3)处理数据流。
25.Kafka的应用场景
1)建立实时的数据管道,以可靠的在系统或者应用程序之间获取数据。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数大数据工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年大数据全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上大数据开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注大数据获取)
712509360647)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上大数据开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注大数据获取)
[外链图片转存中…(img-7uir3V74-1712509360648)]