spark实时计算性能优化

1、  计算提供两种模式,一种是jar包本地计算、一种是JSF服务。

2、  第一步是引入spark,因与netty、JDQ均有冲突,解决netty冲突后,隔离计算为单独服务。已在线上,因storm也与spark存

在运行时冲突,storm也在用服务。

3、  第二步是召回集扩量,发现当召回集由200扩到500后性能下降过快到70ms,利用多线程多核计算,性能到6ms。已在线上

4、  第三步在此扩量到1000,采用增加线程方式,性能达到25ms左右。已在预发

5、  第四步召回集在扩量,如性能瓶颈是io,则使用jar包本地计算,但与JDQ冲突。需要将线上上报迁移到统一上报服务,服务已有

待联调上线。

6、  第五步在扩召回集,取素材特征与提供接口服务拆分、接口服务通过并发分布式方式进行请求,此时召回集量应为几种方式最大。

需要调整接口服务与素材、特征以及计算服务,通过测试得到IO、线程计算结果合并、多核计算的平衡,需排期配合。

第五步已基本和开源分布式搜索引擎计算方式类似,后续会持续调研新的优化方式,并引入到线上。

时间: 2024-10-20 09:04:33

spark实时计算性能优化的相关文章

[转] - Spark排错与优化

Spark排错与优化 http://blog.csdn.net/lsshlsw/article/details/49155087 一. 运维 1. Master挂掉,standby重启也失效 Master默认使用512M内存,当集群中运行的任务特别多时,就会挂掉,原因是master会读取每个task的event log日志去生成Sparkui,内存不足自然会OOM,可以在master的运行日志中看到,通过HA启动的master自然也会因为这个原因失败. 解决 增加Master的内存占用,在Mas

Spark 读取 Hbase 优化 --手动划分 region 提高并行数

一. Hbase 的 region 我们先简单介绍下 Hbase 的 架构和 region : 从物理集群的角度看,Hbase 集群中,由一个 Hmaster 管理多个 HRegionServer,其中每个 HRegionServer 都对应一台物理机器,一台 HRegionServer 服务器上又可以有多个 Hregion(以下简称 region).要读取一个数据的时候,首先要先找到存放这个数据的 region.而 Spark 在读取 Hbase 的时候,读取的 Rdd 会根据 Hbase 的

Spark SQL性能优化

1.设置Shuffle过程中的并行度:spark.sql.shuffle.partitions(SQLContext.setConf()) 2.在Hive数据仓库建设过程中,合理设置数据类型,比如能设置为INT的,就不要设置为BIGINT.减少数据类型导致的不必要的内存开销. 3.编写SQL时,尽量给出明确的列名,比如select name from students.不要写select *的方式. 4.并行处理查询结果:对于Spark SQL查询的结果,如果数据量比较大,比如超过1000条,那

基于Lucene的近实时搜索引擎优化总结

一.搜索优化: 在工程领域,越是看起来“简单.确定”的问题,越是难以解决.近实时搜索引擎需要解决的问题只有一个:性能!它包含快速索引,快速搜索,以及索引到搜索的快速生效. 以下为百万条数据级(适用于千万级)快速滚动数据近实时搜索引擎实践经验总结:  1. 针对技术优化 1.1 数值搜索优化: 将数值的范围缩小,能用 int值 的不要用 long值,能用 float值 的不用要 double值:能用string 替换的,就不要用范围查询(特别是大范围查询),这些都基于Lucene搜索引擎对数值建索

Spark实时流计算Java案例

现在,网上基于spark的代码基本上都是Scala,很多书上也都是基于Scala,没办法,谁叫spark是Scala写出来的了,但是我现在还没系统的学习Scala,所以只能用java写spark程序了,spark支持java,而且Scala也基于JVM,不说了,直接上代码 这是官网上给出的例子,大数据学习中经典案例单词计数 在linux下一个终端 输入 $ nc -lk 9999 然后运行下面的代码 package com.tg.spark.stream; import java.util.Ar

Spark 实时计算整合案例

1.概述 最近有同学问道,除了使用 Storm 充当实时计算的模型外,还有木有其他的方式来实现实时计算的业务.了解到,在使用 Storm 时,需要编写基于编程语言的代码.比如,要实现一个流水指标的统计,需要去编写相应的业务代码,能不能有一种简便的方式来实现这一需求.在解答了该同学的疑惑后,整理了该实现方案的一个案例,供后面的同学学习参考. 2.内容 实现该方案,整体的流程是不变的,我这里只是替换了其计算模型,将 Storm 替换为 Spark,原先的数据收集,存储依然可以保留. 2.1 Spar

spark新能优化之多次使用RDD的持久化或checkPoint

如果程序中,对某一个RDD,基于它进行了多次transformation或者action操作.那么就非常有必要对其进行持久化操作,以避免对一个RDD反复进行计算. 此外,如果要保证在RDD的持久化数据可能丢失的情况下,还要保证高性能,那么可以对RDD进行Checkpoint操作.(也就是多次用到中间RDD的生成值时可以持久化再checkPoint(当持久化数据没的时候会去checkPoint中寻找,详细见spark源码.))

Spark Streaming性能优化: 如何在生产环境下应对流数据峰值巨变

1.为什么引入Backpressure 默认情况下,Spark Streaming通过Receiver以生产者生产数据的速率接收数据,计算过程中会出现batch processing time > batch interval的情况,其中batch processing time 为实际计算一个批次花费时间, batch interval为Streaming应用设置的批处理间隔.这意味着Spark Streaming的数据接收速率高于Spark从队列中移除数据的速率,也就是数据处理能力低,在设置

spark新能优化之shuffle新能调优

shuffle调优参数 new SparkConf().set("spark.shuffle.consolidateFiles", "true") spark.shuffle.consolidateFiles:是否开启shuffle block file的合并,默认为false//设置从maPartitionRDD上面到到下个stage的resultTask时数据的传输快可以聚合(具体原理可以看下shuffle的原理设置和没设置的区别)spark.reducer.m