Spark性能测试报告与调优参数
1、代码中尽量避免group by函数，如果需要数据聚合，group形式的为rdd.map(x=>
(x.chatAt(0),x)).groupbyKey().mapValues((x=&Set.size)).collection() 改为 rdd.map(x=>(x.chatAt(0）,x)).countByKey()；或进⾏reduceByKey，效率会提⾼3倍。
2、parquet存储的⽂件格式查询会⽐sequenceFile快两倍以上，当然这是在select * from的情况下，但其实100+列的情况下，我们做数据分析很少⽤到select * ，那么parquet列式存储会更加⾼效，因为读取⼀个Parquet⽂件时，需要完全读取Footer的meatadata，Parquet格式⽂件不需要读取sync markers这样的标记分割查。
3、spark.rddpress 参数，个参数决定了RDD Cache的过程中，RDD数据在序列化之后是否进⼀步进⾏压缩再储存到内存或磁盘上。当然是为了进⼀步减⼩Cache数据的尺⼨，如果在磁盘IO的确成为问题或者GC问题真的没有其它更好的解决办法的时候，可以考虑启⽤RDD压缩。
4、spark.shuffle.manage 我建议使⽤hash，同时与参数solidateFiles true并⽤。因为不需要对中间结果进⾏排序，同时合并中间⽂件的个数，从⽽减少打开⽂件的性能消耗。
5、⾸先，shuffle过程，与result过程都会将数据返回driver端，JVM参数过少会导致driver端⽼年代也塞满，
容易full GC，同时会经常发⽣GC，因为核数少，所以每个核可以承载更多的数据，那么⼀下⼦返回给driver，就塞满新⽣代，发⽣GC。监控页⾯就发现GC time⽐多核的要⾼。
6、这⾥的limit是直接limit全表的，并没有做where分区limit。同时left join⾃关联，即便内存不够的情况下，spark依旧会写⼊磁盘，但任务相当的慢。
7、发现我们的数据基本没有分库，最好分⼀下库，如果以后多个部门使⽤，那么在default中进⾏各部门数据的梳理⽣成，最终⽣成到不同的库中，防⽌数据杂乱⽆章。
8、分表，我们现在的数据是按dt字段分区的，没有分表，如果前台查询没有分区，将会造成OOM。是否可以按照table_name_20161108这种⽅式，按⽇⽣成，那么select * from tablename 也不会造成Spark卡死，其他任务等待。
jvm调优参数9、在⼀个executor实例中，多核会拉起多个task同时并⾏计算，会⽐单核计算要快很多。后续⽤例调整参数，增加与⽣产同等配置的情况下再进⾏测试。
10、注意⼀点，spark监控页⾯与driver端共享监控页⾯，可以去查看各个节点containner的运⾏情况，尽量少的直接点进去看DAG或task运⾏情况，否则⼤的任务task数据展⽰，也是容易导致JVM对内存溢出。
11、CPU瞬时的使⽤率⼤概在100-200%左右，最⾼持续6秒，随后降⾄百分之2%左右
12、并发极端的情况还未完全测试，但以spark的原理，倘若第⼀个任务没有占满spark的总并发数，那么另⼀个任务将会在这些空闲的task 中进⾏轮训执⾏。整个调度由DAG控制。
13、spark.speculation true 推测执⾏，这个参数⽤来⽐如有数据倾斜或者某个task⽐较慢的情况下，会另起⼀个task进⾏计算，哪个先完成就返回哪个结果集。但是在spark1.3版本的时候，有中间tmp⽂件缺失的情况，会报不到hdfs路径下的⽂件。所以，推测执⾏这个参数不知道在spark1.6是否修复，后续进⾏测试。
14、spark.task.maxFailures 10 这个参数的作⽤主要是在task失败的情况之下，重试的次数，超过这个次数将会kill掉整个job 这种情况⽐如⽹络IO fetch数据失败等情况。
15、Fraction 0.5 这个参数考虑稳定性GC与效率问题，决定使⽤0.5这个参数。
16、spark.sql.shuffle.partitions 200 经测试修改到400并没有变得更快，是因为给的内存⾜以进⾏task的计算，在具体情况下代码中set。
17、spark.kryoserializer.buffer.max 数据传输序列化最⼤值，这个通常⽤户各服务器之间的数据传输，这⾥给到最⼤10g
18、spark.default.parallelism 3 可使⼀个core同时执⾏2-3个task，在代码中通过传⼊numPartitions 参数来改变。（还需深⼊测试）
19、ducer.maxSizeInFlight 128M 在Shuffle的时候，Reducer端获取数据会有⼀个指定⼤⼩的缓存空间，如果内存⾜够⼤的情况下，可以适当的增⼤缓存空间，否则会spill到磁盘上影响效率。因为我们的内存⾜够⼤。
20、spark.shuffle.file.buffer 128M ShuffleMapTask端通常也会增⼤Map任务的写磁盘的缓存

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。