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个任务执行要比后面启动的任务快很多的原因。
要解决这个问题,可以将并行度减小,也可以提高当前稀缺的资源:内存。当然,一切结论还等实验后才能完成。
相关推荐
Hadoop Map-Reduce数据分析
⼤数据技术 ⼤数据技术——数据处理和分析 数据处理和分析 ⼤数据技术 ⼤数据技术——数据处理和分析 数据处理和分析 场景:数据清洗,数据规范化,统计分析等。 1. 实时处理 实时处理 对于实时数据及时处理,并输出...
map文件分析工具
Map是Java中最天才的设计,使用起来也很灵活,该类总结了Map通过key和value进行升序和降序排序,Map的两种遍历的公共方法以及上面功能的测试方法
Combiners是对Map端的数据进行适当的聚合,其好处是减少了从Map端到Reduce端的数据传输量。 其作用的本质,是将Map计算的结果进行二次聚合,使Key-Value中List的数据量变小,从而达到减少数据量的目的。
主要介绍了c++中map的基本用法和嵌套用法,以实例形式分析了map容器的基本使用技巧,具有一定参考借鉴价值,需要的朋友可以参考下
IAR编译器编译产生的MAP文件分析,后缀为.map 文件即可看到程序代码及数据在内存中的情况
Word文件,包括:电机效率map图的绘制参考文献,可以直接复制到MATLAB里面的代码。参考文献交代了实际测试电机效率的方法。代码只需修改效率数值,注意矩阵的行列对应的是转矩和转速。
echarts map地图数据下载,echarts map地图数据下载,echarts map地图数据下载
十七道海量数据处理面试题与Bit-map详解。
echarts map 地图完整json数据 包含中国json数据,各省数据,各市数据
【原创】R语言中使用多重聚合预测算法(MAPA)进行时间序列分析数据分析报告论文(代码数据).docx
将一个Map中的数据封装到javaBean中
jsmap数据结构 数据结构 Map 对象保存键值对,并且能够记住键的原始插⼊顺序。任何值(对象或者) 都可以作为⼀个键或⼀个值。 map对象常⽤于保存键值对,它的键是任意数据类型,常⽤于建⽴数据的映射关系 和对象的...
Map/Reduce:大规模集群上的简化数据处理中文翻译,但也有一些语句翻译不到位,请谅解。希望能够对大家有帮助。
Java语言将xml格式数据转map格式数据
map工具,分析linux生產的map文件
argoverse HD map 数据集
reduce端变map端,
C-MAPSS/航天发动机/涡轮发动机数据集 包含FD001-FD004