SparkStreaming程序优化小记

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhou_shaowei/article/details/80695704

最近公司部署了一个sparkstreaming程序,主要逻辑是处理flume采集到kafka的数据,集群环境3个nodemanager,5核20G内存,刚开始测试阶段并没设置资源配置,直接丢在yarn上运行,每天的数据量大概2500万records。测试几天后发现数据处理时间延迟稍微长了一点,怀疑是程序处理数据的数据低于数据产生的数据,随着时间和数据的增加,这个时间延迟越来越大,遂决定对程序进行相关的优化,整个过程主要从下面几个方面进行了优化:

1、程序占用资源

    3个节点,每个节点配置5cores,20G内存。

spark submit提交的时候,executor-memory设置为2G,每个节点启2个executor,3台节点一共启了5个executor,还有一个供 ApplicationMaster使用。

spark-submit 
 --master yarn 
 --conf spark.streaming.concurrentJobs=4  
 --class com.jiadun.handler.CP_GetWA_Source_1001FromKafka 
 --executor-memory 2G 
 --executor-cores 2 
 --num-executors 5  
 /data/test/GetDataFromKafka-1.0-SNAPSHOT.jar >/dev/null 2>/data/test/log/wa.log

2、设置程序拉取数据的大小

    我启用的是spark的反应机制,动态的控制拉取数据的rate。

conf.set("spark.streaming.backpressure.enabled","true") 

当然还可以从下面两种方式中进行控制,如果三种都设置的话,程序会比较它们的大小取最小值

conf.set("spark.streaming.receiver.maxRate","") 
conf.set("spark.streaming.kafka.maxRatePerPartition","") 

3、配置JVM GC的频率和时间

conf.set("spark.executor.extraJavaOptions","-XX:+UseConcMarkSweepGC")

4、batch interval

这个参数很重要,如果一个interval时间段内你拉取的batch没有处理结束,那么就会出现数据堆积,长此以往,数据会堆积的越来越多,这样的处理逻辑肯定有问题,所以适当的调节interval大小对于程序能不能稳定运行有很大的影响。一般设置在1-10s内,视具体情况而定

5、spark.streaming.concurrentJobs

这是决定你程序同时启动几个active job的参数,如果你的资源足够多,你可以在提交的任务的时候指定这个参数,此参数默认为1,我暂时设置项目的这个参数为4。

观察程序的运行状况 :

可以从sparkUI来观察,


上图中红框内记录了每个batch的执行耗时的折线图和柱状图,其中有个虚线stable,这是你的batch interval时间,如果大量的batch都在这条线以下的话,说明程序的处理速度是足够的,少量的超过是没有问题的。

当然对sparkstreaming程序的优化远不止于此,后期还需要学习更深层次的知识,这样才能更好的去适配各种运行环境,完成健壮性,稳定的项目

.NET程序优化小记(欢迎拍砖)

08-31

今早胡乱写了一篇博客,拿出来供大家讨论一下,欢迎拍砖。rn[url=http://blog.csdn.net/durongjian/archive/2010/08/31/5851801.aspx].NET程序优化小记[/url]rnrn不说废话了,直接写吧:rnrn1、对长度不固定的字符串(如根据条件拼接Sql语句)推荐用StringBuilder类型而不要直接用String,原因如下:rnrn String数据类型代表的是一种不可变的字符串, 对这个字符串的插入删除或是更改时要建立一个新的字符串,会引发对内存的配置操作以及对内存的反配置操作,加重CLR管理内存和内存回收的工作,在操作大字符串时,更为明显,但StringBuilder会保留自己的字符串缓冲区,在针对StringBuilder执行字符串操作时,会先检查缓冲区的大小是否能否容纳新的字符串,不够时再去增加需要的内存数量,因此大幅降低内存配置的操作次数,提高了效能,当然大多数的情况下,多估算一些缓冲区空间比后来又不断加大要好。rnrn2、什么时候用静态方法(static方法):rnrn 静态方法可以使程序显得简洁,调用更加方便(如.NET自带的MessageBox.Show()方法),但什么时候改用静态方法呢?如果方法与对象实例相关,从属于某个对像,就不用静态方法,如果某个方法并不需要从属于对象或者根本无法从对象上调用,就可以采取静态方法。rnrn3、如果用了代码生成器,可以用局部类(partial类)或继承类来增强代码的可维护性:rnrn 现在有很多程序员在项目中用了代码生成器,但代码生成器中生成的代码是固定的,有时我们需要增加一些自己的方法,这时最好不要在生成的代码中加(再次生成后替换很不方便),这时我们可以把自己写的方法放在一个局部类(partial类)中,或是放在一个继承于生成的类的新类中,重新生成代码时直接替换生成器生成的类就好了。rnrn4、如何防止用户禁用JS来输入非法数据:rnrn 可用双重检测,客户端用JS,服务器端判断用户有没有禁用JS,如果禁用再次验证数据合法性,否则进行其他处理。服务器端判断JS是否禁用可以用以下方法,在页面加载事件中写一个JS函数,改变页面某个标签的值,服务器端对此标签进行检测,如果值已更改则JS没有禁用,否则已禁用。rnrn5、如果不涉及到对集合数据进行处理(如筛选或者排序)推荐使用IList而非List,ArrayList,原因如下:rnrn 对于ArrayList要装箱拆箱,就不说了。对于IList和List,从面向对象设计来讲,使用接口(IList)而非具体类型(List),是OOP中比较普遍的原则,其核心价值在于解除对特定类的依赖,通过接口将对象的行为与具体实现隔离开来,接口实现松耦合,有利于系统的维护与重构,从效率上讲当你只想使用接口的方法时,他不获取实现这个接口的类的其他方法和字段,可以有效的节省空间。rnrn6、为了维护的方便,推荐使用IDataReader和IDataAdapter,原因如下:rnrn IDataReader和IDataAdapter是接口,更改数据库时可以不改代码。rnrn7、试着用Dictionary应用取代某些Switch,原因如下:rnrn 对我们已经明确知道对应结果而通常不会更改的(如北京区号010,上海区号021),我们可以把Switch改为Dictionary,减少了查找次数,可以提高率效。rnrn[color=#FF0000]以上是本人自学.NET近两年的一点心得,算是抛砖引玉,供有兴趣的朋友讨论参考,因为本人也是新人,可能说的有不准确和错误的地方,欢迎大家指正,也希望大家能够补充。[/color]rn

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭