hadoop的reduce阶段卡住的问题

allenpony 2013-10-14 06:29:53

2013-10-14 18:02:37,237 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0637_r_000000_0 0.16666667% reduce > copy (1 of 2 at 0.01 MB/s) >
2013-10-14 18:02:38,447 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0622_r_000000_0 0.05263158% reduce > copy (3 of 19 at 0.00 MB/s) >
2013-10-14 18:02:40,981 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0616_r_000000_0 0.17543861% reduce > copy (10 of 19 at 0.00 MB/s) >
2013-10-14 18:02:43,465 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0637_r_000000_0 0.16666667% reduce > copy (1 of 2 at 0.01 MB/s) >
2013-10-14 18:02:44,192 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0616_r_000000_0 0.17543861% reduce > copy (10 of 19 at 0.00 MB/s) >
2013-10-14 18:02:44,652 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0622_r_000000_0 0.05263158% reduce > copy (3 of 19 at 0.00 MB/s) >
2013-10-14 18:02:46,665 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0637_r_000000_0 0.16666667% reduce > copy (1 of 2 at 0.01 MB/s) >
2013-10-14 18:02:47,869 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0622_r_000000_0 0.05263158% reduce > copy (3 of 19 at 0.00 MB/s) >
2013-10-14 18:02:50,411 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201310122012_0616_r_000000_0 0.17543861% reduce > copy (10 of 19 at 0.00 MB/s) >

reduce阶段一直被卡在17%，一个datanode机器上显示上面这些信息，拷贝没有速度，这是什么问题呢？说明一下，不是每一个任务都会出现这个问题，而是有的任务会这样，而另外一些任务是可以正常完成的。因此我任务应该不是防火墙或者/etc/hosts配置的问题

...全文

3395 10 打赏收藏转发到动态举报

写回复

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

Tsuimify 2016-05-10

打赏
举报

回复

引用 9 楼 huangjing0220 的回复:

可能是你的reduce阶段的代码出现死循环，这会导致reduce出现停止不前。

竟然真的是这个原因，太感谢了~

Summer_Hj 2015-08-27

打赏
举报

回复

可能是你的reduce阶段的代码出现死循环，这会导致reduce出现停止不前。

gwgyk 2015-04-13

打赏
举报

回复

如果你设置的map和reduce参数都很大，势必造成map和reduce争抢资源，造成有些进程饥饿，超时出错，最大的可能就是socket.timeout的出错，网络过于繁忙。

sanguomi 2013-12-02

打赏
举报

回复

在Reduce中加输出日志

核动力蜗牛Killua 2013-10-19

打赏
举报

回复

1）在slave上面用jps，看看Datanode进程是否正常。 2）检查Reduce函数编写是否正确。 3）利用50030查看Job状态，检查Job是否在运行，还是已经卡住。如果只单纯运行缓慢建议重启下Cluster的服务。如果是卡住，那估计要检查下集群配置了。

幸运小侯子 2013-10-18

打赏
举报

回复

一个晚上都卡在那个位置肯定有问题，应该是datanode的配置问题，不过偶尔的时候一般会存在卡一会接下来就会出现commit pending 的时候就没问题。会不会是没有空闲的slots了哪？

allenpony 2013-10-16

打赏
举报

回复

引用 3 楼 jxlhc09 的回复:

会不会是数据倾斜问题呢，改改hql语句，减少出现这种现象的概率。

数据倾斜最多也是慢，不会卡住不动啊，一直就这样了，跑一晚上都这样挂住

allenpony 2013-10-15

打赏
举报

回复

引用 1 楼 s060403072 的回复:

如果不是/etc/hosts的问题，可能是datanode节点出了问题

可能会是什么问题呢？这问题让人头痛。它不是一直出现，而是有时候出现。特别是当我把HIVE的SQL放到后台执行的时候，特别容易出现

海兰 2013-10-15

打赏
举报

回复

如果不是/etc/hosts的问题，可能是datanode节点出了问题

randee_luo 2013-10-15

打赏
举报

回复

会不会是数据倾斜问题呢，改改hql语句，减少出现这种现象的概率。

大数据常见问题之数据倾斜全文共5页，当前为第1页。大数据常见问题之数据倾斜全文共5页，当前为第1页。大数据常见问题之数据倾斜大数据常见问题之数据倾斜全文共5页，当前为第1页。大数据常见问题之数据倾斜全文共5页，当前为第1页。什么是数据倾斜简单的讲，数据倾斜就是我们在计算数据的时候，数据的分散度不够，导致大量的数据集中到了一台或者几台机器上计算，这些数据的计算速度远远低于平均计算速度，导致整个计算过程过慢。相信大部分做数据的童鞋们都会遇到数据倾斜，数据倾斜会发生在数据开发的各个环节中，比如：用Hive算数据的时候reduce阶段卡在99.99% 用SparkStreaming做实时算法时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低。数据倾斜有一个关键因素是数据量大，可以达到千亿级。数据倾斜长的表现以Hadoop和Spark是最常见的两个计算平台，下面就以这两个平台说明： 1、Hadoop中的数据倾斜 Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序，虽说Hive最后也是用MR来执行（至少目前Hive内存计算并不普及），但是毕竟写的内容逻辑区别很大，一个是程序，一个是Sql，因此这里稍作区分。 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%，一直99.99%不能结束。这里如果详细的看日志或者和监控界面的话会发现：有一个多几个reduce卡住各种container报错OOM 读写的数据量极大，至少远远超过其它正常的reduce 伴随着数据倾斜，会出现任务被kill等各种诡异的表现。经验： Hive的数据倾斜，一般都发生在Sql中Group和On上，而且和数据逻辑绑定比较深。 2、Spark中的数据倾斜大数据常见问题之数据倾斜全文共5页，当前为第2页。大数据常见问题之数据倾斜全文共5页，当前为第2页。Spark中的数据倾斜也很常见，这里包括Spark Streaming和Spark Sql，表现主要有下面几种：大数据常见问题之数据倾斜全文共5页，当前为第2页。大数据常见问题之数据倾斜全文共5页，当前为第2页。 Executor lost，OOM，Shuffle过程出错 Driver OOM 单个Executor执行时间特别久，整体任务卡在某个阶段不能结束正常运行的任务突然失败补充一下，在Spark streaming程序中，数据倾斜更容易出现，特别是在程序中包含一些类似sql的join、group这种操作的时候。因为Spark Streaming程序在运行的时候，我们一般不会分配特别多的内存，因此一旦在这个过程中出现一些数据倾斜，就十分容易造成OOM。数据倾斜的原理 1、数据倾斜产生的原因我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到，countdistinct、group by、join等操作，这些都会触发Shuffle动作，一旦触发，所有相同key的值就会拉到一个或几个节点上，就容易发生单点问题。 2、万恶的shuffle Shuffle是一个能产生奇迹的地方，不管是在Spark还是Hadoop中，它们的作用都是至关重要的。那么在Shuffle如何产生了数据倾斜？ Hadoop和Spark在Shuffle过程中产生数据倾斜的原理基本类似。如下图。大数据常见问题之数据倾斜全文共5页，当前为第3页。大数据常见问题之数据倾斜全文共5页，当前为第3页。大数据常见问题之数据倾斜全文共5页，当前为第3页。大数据常见问题之数据倾斜全文共5页，当前为第3页。大部分数据倾斜的原理就类似于下图，很明了，因为数据分布不均匀，导致大量的数据分配到了一个节点。 3、从业务计角度来理解数据倾斜数据往往和业务是强相关的，业务的场景直接影响到了数据的分布。再举一个例子，比如就说订单场景吧，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。然后我们要统计不同城市的订单情况，这样，一做group操作，可能直接就数据倾斜了。如何解决数据倾斜的产生是有一些讨论的，解决它们也是有一些讨论的，本章会先给出几个解决数据倾斜的思路，然后对Hadoop和Spark分别给出一些解决数据倾斜的方案。一、几个思路解决数据倾斜有这几个思路： 1.业务逻辑，我们从业务逻辑的层面上来优化数据倾斜，比如上面的例子，我们单独对这两个城市来做count，最后和其它城市做整合。大数据常见问题之数据倾斜全文共5页，当前为第4页。大数据常见问题之数据倾斜全文共5页，当前为第4页。2.程序层面，比如说在Hive中，经常遇到count（distinct）操作，这样会

⼤数据常见问题之数据倾斜什么是数据倾斜简单的讲，数据倾斜就是我们在计算数据的时候，数据的分散度不够，导致⼤量的数据集中到了⼀台或者⼏台机器上计算，这些数据的计算速度远远低于平均计算速度，导致整个计算过程过慢。相信⼤部分做数据的童鞋们都会遇到数据倾斜，数据倾斜会发⽣在数据开发的各个环节中，⽐如：⽤Hive算数据的时候reduce阶段卡在99.99% ⽤SparkStreaming做实时算法时候，⼀直会有executor出现OOM的错误，但是其余的executor内存使⽤率却很低。数据倾斜有⼀个关键因素是数据量⼤，可以达到千亿级。数据倾斜长的表现以Hadoop和Spark是最常见的两个计算平台，下⾯就以这两个平台说明： 1、Hadoop中的数据倾斜 Hadoop中直接贴近⽤户使⽤使⽤的时Mapreduce程序和Hive程序，虽说Hive最后也是⽤MR来执⾏（⾄少⽬前Hive内存计算并不普及），但是毕竟写的内容逻辑区别很⼤，⼀个是程序，⼀个是Sql，因此这⾥稍作区分。 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%，⼀直99.99%不能结束。这⾥如果详细的看⽇志或者和监控界⾯的话会发现：有⼀个多⼏个reduce卡住各种container报错OOM 读写的数据量极⼤，⾄少远远超过其它正常的reduce 伴随着数据倾斜，会出现任务被kill等各种诡异的表现。经验： Hive的数据倾斜，⼀般都发⽣在Sql中Group和On上，⽽且和数据逻辑绑定⽐较深。 2、Spark中的数据倾斜 Spark中的数据倾斜也很常见，这⾥包括Spark Streaming和Spark Sql，表现主要有下⾯⼏种： Executor lost，OOM，Shuffle过程出错 Driver OOM 单个Executor执⾏时间特别久，整体任务卡在某个阶段不能结束正常运⾏的任务突然失败补充⼀下，在Spark streaming程序中，数据倾斜更容易出现，特别是在程序中包含⼀些类似sql的join、group这种操作的时候。因为 Spark Streaming程序在运⾏的时候，我们⼀般不会分配特别多的内存，因此⼀旦在这个过程中出现⼀些数据倾斜，就⼗分容易造成 OOM。数据倾斜的原理 1、数据倾斜产⽣的原因我们以Spark和Hive的使⽤场景为例。他们在做数据运算的时候会设计到，countdistinct、group by、join等操作，这些都会触发 Shuffle动作，⼀旦触发，所有相同key的值就会拉到⼀个或⼏个节点上，就容易发⽣单点问题。 2、万恶的shuffle Shuffle是⼀个能产⽣奇迹的地⽅，不管是在Spark还是Hadoop中，它们的作⽤都是⾄关重要的。那么在Shuffle如何产⽣了数据倾斜？ Hadoop和Spark在Shuffle过程中产⽣数据倾斜的原理基本类似。如下图。⼤部分数据倾斜的原理就类似于下图，很明了，因为数据分布不均匀，导致⼤量的数据分配到了⼀个节点。 3、从业务计⾓度来理解数据倾斜数据往往和业务是强相关的，业务的场景直接影响到了数据的分布。再举⼀个例⼦，⽐如就说订单场景吧，我们在某⼀天在北京和上海两个城市多了强⼒的推⼴，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。然后我们要统计不同城市的订单情况，这样，⼀做group操作，可能直接就数据倾斜了。如何解决数据倾斜的产⽣是有⼀些讨论的，解决它们也是有⼀些讨论的，本章会先给出⼏个解决数据倾斜的思路，然后对Hadoop和Spark分别给出⼀些解决数据倾斜的⽅案。⼀、⼏个思路解决数据倾斜有这⼏个思路： 1.业务逻辑，我们从业务逻辑的层⾯上来优化数据倾斜，⽐如上⾯的例⼦，我们单独对这两个城市来做count，最后和其它城市做整合。 2.程序层⾯，⽐如说在Hive中，经常遇到count（distinct）操作，这样会导致最终只有⼀个reduce，我们可以先group 再在外⾯包⼀层count，就可以了。 3.调参⽅⾯，Hadoop和Spark都⾃带了很多的参数和机制来调节数据倾斜，合理利⽤它们就能解决⼤部分问题。⼆、从业务和数据上解决数据倾斜很多数据倾斜都是在数据的使⽤上造成的。我们举⼏个场景，并分别给出它们的解决⽅案。数据分布不均匀：前⾯提到的"从数据⾓度来理解数据倾斜"和"从业务计⾓度来理解数据倾斜"中的例⼦，其实都是数据分布不均匀的类型，这种情况和计算平台⽆关，我们能通过设计的⾓度尝试解决它。有损的⽅法：找到异常数据，⽐如ip为0的数据，过滤掉⽆损的⽅法：对分布不均匀的数据，单独计算先对key做⼀层hash，先将数据打散让它的并⾏度变⼤，再汇集 ·数据预处理三、Had

课程简介：本门课程总体分为初始Hadoop、Hadoop深入及Hadoop高级三大阶段。由浅入深地讲解了Hadoop三大模块：HDFS、YARN及 MapReduce。课程内容：

今天写好hadoop 程序之后，进行线上测试，驶入数据为一个hive表的文件，location到了一个hdfs目录下，然后跑hadoop的过程中，map阶段没有出现问题，但是每次到了reduce阶段，进度都卡在33%不动了，刚开始以为是集群问题，后来重新启动了几次任务，都是这种情况。可能的情况1：后来在stackoverflow上找到了答案，这是hadoop上数据倾斜造成的问题（我的hiv

阅读本文可以带着下面问题： 1.map /reduce程序卡住的原因是什么？ 2.根据原因，你是否能够想到更好的方法来解决？（企业很看重个人创作力） map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节

Hadoop生态社区

20,808

社区成员

4,690

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章