Map任务的不均匀性

最近发现Map端数据越来越不均匀，而处理输入的数据，写到本地磁盘的数据量都差不多，我们随便拿出来两个attempt任务（当前map数量为64个），33和45，33的counter：

下面是000045的Counter数据

可以看出Counter中的数据也是差不多，但是CPU时间以及GC时间相差比较大（实际上以ms为单位，也就相差不太大），CPU时间相差5分钟左右，我们对map端执行的每段数据进行标记：

[INFO]  2014-10-19 19:17:19 : current caid(2000716) report generated!

[INFO]  2014-10-19 19:17:47 : current caid(2000717) report generated!

[INFO]  2014-10-19 19:18:35 : current caid(2000687) report generated!

[INFO]  2014-10-19 19:19:02 : current caid(2000713) report generated!

[INFO]  2014-10-19 19:19:33 : current caid(2000706) report generated!

[INFO]  2014-10-19 19:20:01 : current caid(2000707) report generated!

[INFO]  2014-10-19 19:20:29 : current caid(2000704) report generated!

[INFO]  2014-10-19 19:21:30 : current caid(2000697) report generated!

[INFO]  2014-10-19 19:22:01 : current caid(2000699) report generated!

[INFO]  2014-10-19 19:22:42 : current caid(2000701) report generated!

[INFO]  2014-10-19 19:23:23 : current caid(2000700) report generated!

[INFO]  2014-10-19 19:23:53 : current caid(2000702) report generated!

[INFO]  2014-10-19 19:24:21 : current caid(2000689) report generated!

[INFO]  2014-10-19 19:25:00 : current caid(2000688) report generated!

[INFO]  2014-10-19 19:25:41 : current caid(2000690) report generated!

[INFO]  2014-10-19 19:26:22 : current caid(2000693) report generated!

[INFO]  2014-10-19 19:27:29 : current caid(2000692) report generated!

这个执行得非常快，而相反45就比较慢了：

[INFO]  2014-10-19 19:41:17 : current caid(2000716) report generated!

[INFO]  2014-10-19 19:43:32 : current caid(2000717) report generated!

[INFO]  2014-10-19 19:45:59 : current caid(2000687) report generated!

[INFO]  2014-10-19 19:50:57 : current caid(2000713) report generated!

[INFO]  2014-10-19 19:55:20 : current caid(2000706) report generated!

[INFO]  2014-10-19 20:04:22 : current caid(2000707) report generated!

[INFO]  2014-10-19 20:07:23 : current caid(2000704) report generated!

[INFO]  2014-10-19 20:10:33 : current caid(2000697) report generated!

[INFO]  2014-10-19 20:14:14 : current caid(2000699) report generated!

[INFO]  2014-10-19 20:17:28 : current caid(2000701) report generated!

[INFO]  2014-10-19 20:21:11 : current caid(2000700) report generated!

[INFO]  2014-10-19 20:26:34 : current caid(2000702) report generated!

[INFO]  2014-10-19 20:32:27 : current caid(2000689) report generated!

[INFO]  2014-10-19 20:35:46 : current caid(2000688) report generated!

[INFO]  2014-10-19 20:37:53 : current caid(2000690) report generated!

[INFO]  2014-10-19 20:39:42 : current caid(2000693) report generated!

[INFO]  2014-10-19 20:41:25 : current caid(2000692) report generated!

可以看出，明显比33慢出一个数量级，而且是每个步骤都比较慢，不存在单独数据的故障。首先，任务开始时间有差别，这是因为在最慢的任务启动之前，最快的任务都已经完成了，这是因为资源分配不均匀造成的，也是因为我们初始的时候任务启动过多，以至于Map总是一个个启动；但还有一点就是000045处理每个活动的速度其实都是比较慢的，甚至系统还为此启动了一个推测式任务：

[INFO]  2014-10-19 19:45:58 : current caid(2000716) report generated!

[INFO]  2014-10-19 19:47:58 : current caid(2000717) report generated!

[INFO]  2014-10-19 19:50:28 : current caid(2000687) report generated!

[INFO]  2014-10-19 19:52:29 : current caid(2000713) report generated!

[INFO]  2014-10-19 19:59:15 : current caid(2000706) report generated!

[INFO]  2014-10-19 20:02:12 : current caid(2000707) report generated!

[INFO]  2014-10-19 20:04:38 : current caid(2000704) report generated!

[INFO]  2014-10-19 20:08:47 : current caid(2000697) report generated!

[INFO]  2014-10-19 20:16:01 : current caid(2000699) report generated!

这个推测式任务由于主任务的执行完成而被kill，但从任务的进度来看，好像要比原来的任务进度稍微快一点。

本地化balancer策略

我们对数据块都进行了本地化策略，能够确保大部分数据在Map端执行时都使用本地的数据进行，下面我们就查看对应的服务器上是否有该块信息。

首先，在执行任务时，某个Split块信息打印出来，比如00058块，通过查看hadoop命令手册：http://hadoop.apache.org/docs/r1.0.4/cn/commands_manual.html#fsck。

hadoop fsck  /xxxx/xxx_part-r-00058 -files -locations -blocks

Connecting to namenode via http://x1202.xxxx.cn:50070

FSCK started by tong (auth:SIMPLE) from /192.168.7.11 for path //xxxx/xxx_part-r-00058 at Mon Oct 20 14:16:40 CST 2014

/xxxx/xxx_part-r-00058 864740440 bytes, 7 block(s):  OK

0. BP-714842383-192.168.7.11-1393991369860:blk_1088800687_1099546661897 len=134217728 repl=3 [192.168.7.75:50010, 192.168.7.14:50010, 192.168.7.21:50010]

1. BP-714842383-192.168.7.11-1393991369860:blk_1088801074_1099546662284 len=134217728 repl=3 [192.168.7.14:50010, 192.168.7.75:50010, 192.168.7.34:50010]

2. BP-714842383-192.168.7.11-1393991369860:blk_1088801189_1099546662399 len=134217728 repl=3 [192.168.7.75:50010, 192.168.7.14:50010, 192.168.7.24:50010]

3. BP-714842383-192.168.7.11-1393991369860:blk_1088801280_1099546662490 len=134217728 repl=3 [192.168.7.14:50010, 192.168.7.75:50010, 192.168.7.20:50010]

4. BP-714842383-192.168.7.11-1393991369860:blk_1088801390_1099546662600 len=134217728 repl=3 [192.168.7.75:50010, 192.168.7.14:50010, 192.168.7.26:50010]

5. BP-714842383-192.168.7.11-1393991369860:blk_1088801661_1099546662871 len=134217728 repl=3 [192.168.7.14:50010, 192.168.7.75:50010, 192.168.7.16:50010]

6. BP-714842383-192.168.7.11-1393991369860:blk_1088801774_1099546662992 len=59434072 repl=3 [192.168.7.75:50010, 192.168.7.14:50010, 192.168.7.13:50010]

Status: HEALTHY

 Total size:864740440 B

 Total dirs:0

 Total files:1

 Total symlinks:0

 Total blocks (validated):7 (avg. block size 123534348 B)

 Minimally replicated blocks:7 (100.0 %)

 Over-replicated blocks:0 (0.0 %)

 Under-replicated blocks:0 (0.0 %)

 Mis-replicated blocks:0 (0.0 %)

 Default replication factor:3

 Average block replication:3.0

 Corrupt blocks:0

 Missing replicas:0 (0.0 %)

 Number of data-nodes:31

 Number of racks:1

FSCK ended at Mon Oct 20 14:16:40 CST 2014 in 1 milliseconds

块本身的数据并没有任何问题，而且从块的数据分布可以看出，当前集群中HDFS块的大小设置为128M，策略大概设置为3到4个块来进行保存该block的数据。

根据某个HDFS数据块的分布情况，我们使用ping机器主机名称的方式查到具体的ip地址

下面就简要说明一下我们如何分片的，每日的日志都会根据一定的字段分成固定的数量（64个），Map端处理的InputSplit扩展自CombineInputSplit，即多个不同日期日志文件的集合，每个集合对应的不同日期相同下标的日志文件。

InputSplit会根据getLocations方法来确定最优分配的机器名称，于是元数据文件就是下标对应机器名的一个文件。后台会启动一个自己写的balancer程序，会在集群不工作的情况下偷偷地移动数据，以满足元数据文件的本地化策略。

虽然我们已经设置了本地化策略，但是根据运行的结果，Map最慢的任务却并不是在那台推荐的机器上运行的，具体原因已经分析出来了，原因就在于某些资源的不足，确切来说当前是Map端的内存，造成我们虽然同时启动了多个任务，但是病不是所有的任务都已经正常运行，看下面的趋势图：

蓝色条表示执行开始时间，绿色表示执行结束时间。可以看出虽然任务初始时会启动9个任务，但是只有前4个拿到了充分的资源，后面的Map任务都处于Pending状态，等待资源，此时集群已经占满。

我们知道Map占用的资源随着Map任务的执行结束会马上被释放掉，此时后面的Map任务就可以拿到资源并运行，但此时，已经没有其他的选择，也就是说，不一定会选择推荐的本地化机器！这也是为什么前面启动的4个任务执行要比后面启动的任务快很多的原因。

要解决这个问题，可以将并行度减小，也可以提高当前稀缺的资源：内存。当然，一切结论还等实验后才能完成。

项目中Map端数据处理不均匀性分析的更多相关文章

  1. 项目中Map端内存占用的分析

      最近在项目中开展重构活动,对Map端内存尽量要省一些,当前的系统中Map端内存最高占用大概3G左右(设置成2G时会导致Java Heap OOM).虽然个人觉得占用不算多,但是显然这样的结果想要试 ...

  2. create-react-app 搭建的项目中，引入 webpack-bundle-analyzer 打包分析

    安装npm intall webpack-bundle-analyzer --save-dev 在 config/webpack.config.prod.js 文件(推荐)或 config/webpa ...

  3. MapReduce在Map端的Combiner和在Reduce端的Partitioner

    1.Map端的Combiner. 通过单词计数WordCountApp.java的例子,如何在Map端设置Combiner... 只附录部分代码: /** * 以文本 * hello you * he ...

  4. 教你如何在React及Redux项目中进行服务端渲染

    服务端渲染(SSR: Server Side Rendering)在React项目中有着广泛的应用场景 基于React虚拟DOM的特性,在浏览器端和服务端我们可以实现同构(可以使用同一份代码来实现多端 ...

  5. 关联分析FPGrowth算法在JavaWeb项目中的应用

    关联分析(关联挖掘)是指在交易数据.关系数据或其他信息载体中,查找存在于项目集合或对象集合之间的频繁模式.关联.相关性或因果结构.关联分析的一个典型例子是购物篮分析.通过发现顾客放入购物篮中不同商品之 ...

  6. 初识quartz 并分析 项目中spring整合quartz的配置【原创+转载】

    初识quartz 并分析 项目中spring整合quartz的配置[原创+转载]2018年01月29日 12:08:07 守望dfdfdf 阅读数:114 标签: quartz 更多个人分类: 工具 ...

  7. mqtt协议实现 java服务端推送功能（三）项目中给多个用户推送功能

    接着上一篇说,上一篇的TOPIC是写死的,然而在实际项目中要给不同用户 也就是不同的topic进行推送 所以要写活 package com.fh.controller.information.push ...

  8. 【DDD/CQRS/微服务架构案例】在Ubuntu 14.04.4 LTS中运行WeText项目的服务端

    在<WeText项目:一个基于.NET实现的DDD.CQRS与微服务架构的演示案例>文章中,我介绍了自己用Visual Studio 2015(C# 6.0 with .NET Frame ...

  9. 动端逐渐出了许多的移动端的框架，比如Sencha Touch、JQTouch、Jquery-moblie、jqMobi等等。这些框架都有优缺点，不同的框架应用在不同的项目中。现简单阐述一下各框架的优缺点：

    移动前端工作的那些事---前端制作之微信小技巧篇   (2013-11-15 15:20) 转载▼ 标签: it css3/javascript html5 webapp 手机网站搭建 分类: 前端制 ...

随机推荐

  1. IOS开发 多线程GCD

    Grand Central Dispatch (GCD)是Apple开发的一个多核编程的解决方法. dispatch queue分成以下三种: 1)运行在主线程的Main queue,通过dispat ...

  2. vuex（二）getters

    getters: 有时候,我们需要对state的数据进行筛选,过滤.这些操作都是在组件的计算属性进行的.如果多个组件需要用到筛选后的数据,那我们就必须到处重复写该计算属性函数:或者将其提取到一个公共的 ...

  3. GitLab+Rancher实践DevOps【转载】

    摘要 本文描述使用自建GitLab和Rancher实践持续集成/持续交付流水线的过程,并用Rancher实现容器编排和蓝绿发布. GitLab持续集成 GitLab持续集成/持续交付流程图:部署Git ...

  4. ubuntu16.04中使用搜狗输入法Qt5无法输入中文解决方式

    1.安装fcitx-frontend-qt5 sudo apt-get install fcitx-frontend-qt5 2.将libfcitxplatforminputcontextplugin ...

  5. silverlight——获取控件相对位置

    事出有因:页面中存在滚动条,然后点击页面按钮时会进行正确性检查,如果出错在控件的位置会出现提示信息,但由于滚动条的出现,有可能在非可视区域内的控件出了问题,但目前是看不见的,因此,考虑获得出问题控件的 ...

  6. wampserver2.5的php.ini位置在wamp\bin\apache\apache2.4.9\bin

    wampserver2.5的php.ini位置在wamp\bin\apache\apache2.4.9\bin php.ini有多个地方,C:\wamp\bin\php\php5.5.12下面有php ...

  7. huawei机试题目

    1/*输入一个字符串,输出这个字符串中单词的字典排序*/ bool cmp(char* a,char* b){ ? true:false; } void sortWord(char* str) { v ...

  8. andriod studio报错 Emulator: emulator: ERROR: x86 emulation currently requires hardware acceleration! Emulator: Process finished with exit code 1

    安装即可,再次运行svd,成功

  9. 用fiddler设置手机代理

    做App测试的朋友可能因为环境的需要,要切换不同的测试环境,这时就需要在自己的电脑上配置好环境,然后在手机上设置代理,用WiFi连自己的电脑,这样一来,手机网络走的就是自己的电脑网络,也就是说,手机的 ...

  10. {Reship}{Sparse Representation}稀疏表示入门

    声明:本人属于绝对的新手,刚刚接触“稀疏表示”这个领域.之所以写下以下的若干个连载,是鼓励自己不要急功近利,而要步步为赢!所以下文肯定有所纰漏,敬请指出,我们共同进步! 踏入“稀疏表达”(Sparse ...