![](https://img-blog.csdnimg.cn/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Spark
文章平均质量分 67
离线处理Spark
程序员面试笔记
这个作者很懒,什么都没留下…
展开
-
spark 性能调优 JVM调优原理概述
full gc由于这个算法的设计,是针对的是,老年代中的对象数量很少,经验:在spark作业的运行过程中,只要一牵扯到有shuffle的操作,基本上shuffle操作的性能消耗,2、老年代囤积大量活跃对象(短生命周期的对象),导致频繁full gc,full gc时间很长,短则数十秒,默认情况下,给RDD cache操作的内存占比,是0.6,60%的内存都给了cache操作了。可能马上就要被回收掉的对象。2、JVM调优(Java虚拟机):JVM相关的参数,通常情况下,如果你的硬件配置、基础的JVM的配置,原创 2024-04-13 09:30:48 · 258 阅读 · 0 评论 -
spark troubleshooting 错误的持久化方式以及checkpoint的使用
发现有标记为待checkpoint的rdd,就会进行二次标记,inProgressCheckpoint,正在接受checkpoint操作。6、将checkpoint过的rdd之前的依赖rdd,改成一个CheckpointRDD*,强制改变你的rdd的lineage。5、job执行完之后,就会启动一个内部的新job,去将标记为inProgressCheckpoint的rdd的数据,后面如果rdd的cache数据获取失败,直接会通过它的上游CheckpointRDD,去容错的文件系统,都写入hdfs文件中。原创 2024-04-13 09:18:28 · 429 阅读 · 0 评论 -
spark 性能调优 RDD持久化
如果正常将数据持久化在内存中,那么可能会导致内存的占用过大,这样的话,也许,会导致OOM内存溢出。尽量去复用RDD,差不多的RDD,可以抽取称为一个共同的RDD,供后面的RDD计算时,反复使用。馅料+饺子皮+水->包好的饺子,对包好的饺子去煮,这种情况,是绝对绝对,一定要避免的,一旦出现一个RDD重复计算的情况,就会导致性能急剧降低。持久化的双副本机制,持久化后的一个副本,因为机器宕机了,副本丢了,就还是得重新计算一次;持久化,也就是说,将RDD的数据缓存到内存中/磁盘中,(BlockManager),原创 2024-04-07 22:49:13 · 358 阅读 · 0 评论 -
spark shuffle调优
2、第二个stage,原本要拉取第一个stage的task数量份文件,1000个task,第二个stage的每个task,shuffle操作的后半部分,以及后面的,每一个shuffle的前半部分stage的task,每个task都会创建下一个stage的task数量相同的文件,shuffle的后半部分stage的task,每个task都会从各个节点上的task写的属于自己的那一份文件中,划分的依据,就是,如果发现有会触发shuffle操作的算子,比如reduceByKey,就将这个操作的前半部分,原创 2024-04-07 22:47:32 · 665 阅读 · 0 评论 -
spark 性能优化 shuffle参数优化
有哪些executor,有哪些task,每个task的shuffle write和shuffle read的量,shuffle的磁盘和内存,会显示一个Spark UI的地址,4040的端口,进去看,依次点击进去,可以看到,你的每个stage的详情,reduce task,在进行汇聚、聚合等操作的时候,实际上,使用的就是自己对应的executor的内存,如果数据量比较大,reduce task拉取过来的数据很多,在map task处理的数据量比较大的情况下,而你的task的内存缓冲默认是比较小的,32kb。原创 2024-04-07 22:45:23 · 406 阅读 · 0 评论 -
spark 性能调优,给spark作业分配更多的资源!
SparkContext,DAGScheduler,TaskScheduler,会将我们的算子,切割成大量的task,比如有3个executor,每个executor有2个cpu core,那么同时能够并行执行的task,就是6个。增加了executor数量以后,那么,就意味着,能够并行执行的task数量,也就变多了。如果说你的spark作业,能够分配的资源达到了你的能力范围的顶端之后,无法再分配更多的资源了,分配更多资源:性能调优的王道,就是增加和分配更多的资源,性能和速度上的提升,是显而易见的;原创 2024-04-07 22:44:16 · 400 阅读 · 0 评论 -
spark 性能优化-调节堆外内存!!!
spark.core.connection.ack.wait.timeout(spark core,connection,连接,ack,wait timeout,不是在你的spark作业代码中,用new SparkConf().set()这种方式去设置,不要这样去设置,是没有用的!这个executor跑着跑着,突然内存不足了,堆外内存不足了,可能会OOM,挂掉。然后spark作业一运行,时不时的报错,通常这个参数调节上去以后,就会避免掉某些JVM OOM的异常问题,同时呢,会让整体spark作业的性能,原创 2024-04-07 22:42:33 · 416 阅读 · 0 评论 -
saprk 性能调优,并行度调节
reduceByKey,stage0的task,在最后,执行到reduceByKey的时候,会为每个stage1的task,因为,比如150个task,10个先运行完了,剩余140个还在运行,但是这个时候,有10个cpu core就空闲出来了,task没有设置,或者设置的很少,比如就设置了,100个task。但是你现在,只有100个task,平均分配一下,每个executor分配到2个task,ok,实际情况,与理想情况不同的,有些task会运行的快一点,比如50s就完了,有些task,可能会慢一点,原创 2024-04-07 22:40:49 · 303 阅读 · 0 评论 -
spark 数据倾斜解决方案 提高shuffle操作reduce并行度
将reduce task的数量,变多,就可以让每个reduce task分配到更少的数据量,这样的话,就至少可以避免OOM的情况,程序至少是可以跑的。1、如果最理想的情况下,提升并行度以后,减轻了数据倾斜的问题,或者甚至可以让数据倾斜的现象。比如说,原本某个task分配数据特别多,直接OOM,内存溢出了,程序没法运行,直接挂掉。2、不太理想的情况下,就是比如之前某个task运行特别慢,要5个小时,现在稍微快了一点,按照log,找到发生数据倾斜的shuffle操作,给它传入一个并行度数字,这样的话,原创 2024-04-07 22:39:18 · 256 阅读 · 0 评论 -
spark 数据倾斜解决方案 使用随机key实现双重聚合
用我们讲的这种高级的reduce join转map join的技术,不要用普通的join,去通过shuffle,第一轮聚合的时候,对key进行打散,将原先一样的key,变成不一样的key,相当于是将每个key分为多组;可以执行map操作,去将之前打上的随机数,给去掉,然后再和另外一个普通RDD join以后的结果,1、选择一个RDD,要用flatMap,进行扩容,将每条数据,映射为多条数据,每个映射出来的数据,join,咱们通常不会这样来做,后面会讲三种,针对不同的join造成的数据倾斜的问题的解决方案。原创 2024-04-07 22:35:23 · 316 阅读 · 0 评论 -
spark 算子优化 filter + coalecse
主要就是用于在filter操作之后,针对每个partition的数据量各不相同的情况,来压缩partition的数量。1、每个partition数据量变少了,但是在后面进行处理的时候,还是要跟partition数量一样数量的task,那么这样的话,后面的task分配到的partition的数据量。2、每个partition的数据量不一样,会导致后面的每个task处理每个partition的时候,避免了数据倾斜的问题。那么在后面的task处理逻辑一样的情况下,不同的task要处理的数据量可能差别达到了9倍,原创 2024-04-07 22:33:47 · 417 阅读 · 0 评论 -
spark 算子优化 foreachPartition
首先,对于每条数据,都要单独去调用一次function,task为每个数据,都要去执行一次function函数。foreachPartition,在生产环境中,通常来说,都使用foreachPartition来写数据库的。1、对于我们写的function函数,就调用一次,一次传入一个partition所有的数据。但是要注意的是,数据库连接的创建和销毁,都是非常非常消耗性能的。如果100万条数据,(一个partition),调用100万次。以上两点(数据库连接,多次发送SQL语句),都是非常消耗性能的。原创 2024-04-07 22:32:04 · 339 阅读 · 0 评论 -
spark 算子优化 reduceByKey
reduceByKey,相较于普通的shuffle操作(比如groupByKey),它的一个特点,就是说,对map端给下个stage每个task创建的输出文件中,写数据之前,就会进行本地的combiner操作,2、对于一些类似于要对每个key进行一些字符串拼接的这种较为复杂的操作,可以自己衡量一下,1、非常普通的,比如说,就是要实现类似于统计分析的程序一样的,对每个key对应的值,也就是说对每一个key,对应的values,都会执行你的算子函数(_ + _)2、下一个stage,拉取数据的量,也就变少了。原创 2024-04-07 22:31:08 · 402 阅读 · 0 评论 -
spark 算子优化 reduceByKey
reduceByKey,相较于普通的shuffle操作(比如groupByKey),它的一个特点,就是说,对map端给下个stage每个task创建的输出文件中,写数据之前,就会进行本地的combiner操作,2、对于一些类似于要对每个key进行一些字符串拼接的这种较为复杂的操作,可以自己衡量一下,1、非常普通的,比如说,就是要实现类似于统计分析的程序一样的,对每个key对应的值,也就是说对每一个key,对应的values,都会执行你的算子函数(_ + _)2、下一个stage,拉取数据的量,也就变少了。原创 2024-04-07 22:29:51 · 324 阅读 · 0 评论 -
spark 算子优化 MapPartitions
在项目中,自己先去估算一下RDD的数据量,以及每个partition的量,还有自己分配给每个executor。但是MapPartitions操作,对于大量数据来说,比如甚至一个partition,100万数据,都可以用这种MapPartitions系列操作,性能还是非常不错的,是有提升的。但是也有过出问题的经验,MapPartitions只要一用,直接OOM,内存溢出,崩溃。spark中,最基本的原则,就是每个task处理一个RDD的partition。但是试了一下以后,发现,不行,OOM了,那就放弃吧。原创 2024-04-07 22:25:45 · 369 阅读 · 0 评论 -
spark 算子优化 repartiton
官网有推荐的设置方式,你的spark-submit脚本中,会指定你的application总共要启动多少个executor,比如你第一个stage,用了Spark SQL从hive表中查询出了一些数据,然后做了一些transformation操作,官方推荐,根据你的application的总cpu core数量(在spark-submit中可以指定,200个),问题来了,Spark SQL,用了。然后呢,从repartition以后的RDD,再往后,并行度和task数量,就会按照你预期的来了。原创 2024-04-07 21:30:35 · 478 阅读 · 0 评论