MapReduce中使用字符串拼接导致的问题

最新推荐文章于 2023-07-18 11:41:42 发布

置顶

快乐程序员

最新推荐文章于 2023-07-18 11:41:42 发布

阅读量3.2k

点赞数

分类专栏： hadoop2.0 文章标签： mapreduce 字符串拼接 StringBuilder

本文链接：https://blog.csdn.net/bigdatahappy/article/details/43937919

版权

在优化MapReduce作业时发现，由于artID的长度不固定，大量字符串拼接导致性能下降。尽管JVM将String拼接转化为StringBuilder操作，但效率仍不高。通过对reduce进程的CPU和内存使用情况进行分析，发现字符串拼接是瓶颈。最终通过替换为StringBuffer，作业运行时间从6小时降至10多分钟，显著提高了效率。建议在类似场景下，明确使用StringBuilder或StringBuffer以确保高效运行。

摘要由CSDN通过智能技术生成

今天在帮业务方优化mapreduce作业时遇到一个用字符串拼接的问题。

reduce中字符串拼接代码：

while (it.hasNext()) {
      line = it.next().toString();
      artID+=line+",";
      ct++;
}

采用的是String直接拼接，结果是该作业作业只剩一个reduce一直在运行，而且时间长达6小时，其他已经完成的reduce只用了10多分钟。

咨询了一下业务方，artID有的会很长，这个时候会一直进行字符串拼接。

我又看了一下未完成和已完成的reduce处理的数据量差别不大，未完成的需要处理60M的数据，已完成的处理了50M的数据。

1、查看该reduce的java进程的堆内存使用情况，不存在堆内存不够用，导致一直FGC的情况。

2、查看该reduce的java进程的cpu使用情况：

[mapred@yz5102 ~]$ top -p 39257
top - 14:48:37 up 393 days, 20:34,  2 users,  load average: 8.75, 15.84, 15.53
Tasks:  43 total,   1 running,  42 sleeping,   0 stopped,   0 zombie
Cpu(s): 28.8%us,  7.2%sy,  0.0%ni, 61.7%id,  0.9%wa,  0.0%hi,  1.3%si,  0.0%st
Mem:  49374704k total, 41905644k used,  7469060k free,  2167520k buffer