2072人阅读
Hadoop（8）
当一个HDFS系统同时处理许多个并行的put操作，往HDFS上传时，有时候会出现dfsclient 端发生socket 链接超时的报错，有的时候甚至会由于这种原因导致最终的put操作失败，造成数据上传不完整。
log类似如下：
All datanodes& *** are bad. Aborting...
类似这样的错误，常常会在并行的put操作比较多，比如60-80个，每个put的数据量约100G的时候，产生类似的错误，错误出现以后，比较好一点的情况是DFSClient端会报出一些列的错误log，如：
error Recovery for block& block_-405 bad datanode ** &
Bad response& for block block_-254u& from datanode& ***
10/01/18 18:48:00 WARN hdfs.DFSClient: Error Recovery for block blk_296138 bad datanode[0] 172.23.115.79:50010
10/01/18 18:48:00 WARN hdfs.DFSClient: Error Recovery for block blk_296138 in pipeline 172.23.115.79:5.115.68:50010: bad datanode 172.23.115.79:50010
10/01/18 18:48:27 WARN hdfs.DFSClient: DFSOutputStream ResponseProcessor exception& for block blk_-296769java.net.SocketTimeoutException: 63000 millis timeout while waiting for channel to be ready for read. ch :
.nio.channels.SocketChannel[connected local=/172.23.113.2:50391 remote=/172.23.114.41:50010]
&&& at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:162)
&&& at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:150)
&&& at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:123)
&&& at java.io.DataInputStream.readFully(DataInputStream.java:178)
&&& at java.io.DataInputStream.readLong(DataInputStream.java:399)
&&& at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$ResponseProcessor.run(DFSClient.java:2318)
10/01/18 18:48:27 WARN hdfs.DFSClient: Error Recovery for block blk_-296769 bad datanode[0] 172.23.114.41:50010
10/01/18 18:49:04 WARN hdfs.DFSClient: DFSOutputStream ResponseProcessor exception& for block blk_297704java.net.SocketTimeoutException: 63000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected
local=/172.23.113.2:44177 remote=/172.23.115.68:50010]
&&& at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:162)
&&& at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:150)
&&& at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:123)
&&& at java.io.DataInputStream.readFully(DataInputStream.java:178)
&&& at java.io.DataInputStream.readLong(DataInputStream.java:399)
&&& at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$ResponseProcessor.run(DFSClient.java:2318)
10/01/18 18:49:04 WARN hdfs.DFSClient: Error Recovery for block blk_297704 bad datanode[0] 172.23.115.68:50010
put: All datanodes 172.23.115.190:50010 are bad. Aborting...
put: All datanodes 172.23.115.101:50010 are bad. Aborting...
产生这样的报错后，put操作仍然能够进行，并最终数据上传是完整的，只是效率会收到影响。
但是如果碰到不好的情况，就会报出：
All datanodes& *** are bad. Aborting...
这样的错误，这样就会导致put操作中断，导致数据上传不完整。
后来检查发现，所有的datanode虽然负载都比较搞，都在正常，而DFS的操作都是客户端直接跟datanode进行通信和数据传输，那么到底是什么原因导致了这样的问题呢？
根据log查看hadoop的代码发现，出错的地方在 DFSClient 的 processDatanodeError()方法中，进入这个方法就表示DFSClient的操作发生了错误。而进入这个报错的代码逻辑是因为DFSClient中发现errorIndex & 0，继续跟踪，发现修改了errorIndex变量的方法调用中，只有 createBlockOutputStream，DFSOutputStream的构造方法，以及ResponseProcessor.run()方法中对该变量进行了修改，而由于DFSOutputStream的构造方法对该变量进行的修改是在append的时候，ResponseProcessor.run()会直接抛出另外的异常，因此调用定位到createBlockOutputStream()
方法中，最后发现修改errorIndex的原因是由于 某个datanode的link跟dfsclient短发生了失败，根据log中发现失败是由于socket链接超时导致，这说明，put发生异常的时候，是DFSClient 链接从namenode得来的datanode列表中的datanode时，由于该datanode当时的负载非常的高，导致当时无法服务造成。
& 找到原因以后就好办了，由于DFSClient跟datanode的链接超时控制参数是一个客户端参数，因此，在数据上传的客户端hadoop-site.xml里修改配置参数 dfs.socket.timeout（默认十分钟），之后重新运行大批量的数据上传操作，问题不再重现：）
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：307518次
积分：3200
积分：3200
排名：第8072名
原创：49篇
转载：71篇
评论：16条
(1)(7)(7)(23)(10)(1)(2)(21)(12)(7)(3)(1)(4)(3)(5)(5)(8)推荐这篇日记的豆列
······中国领先的IT技术网站
51CTO旗下网站
大数据“流言”：剖析Hadoop和大数据的七误解
如今，Hadoop成为解决大数据需求的主要投资领域之一，而类似Facebook等互联网巨头在都公开的吹捧Hadoop上取得的成功，同样初入大数据领域的公司也必先着眼于Hadoop。但对于Hadoop技术而言，是一个多维的解决方案，可以通过不同的方式进行部署和使用。下面就了解一些关于Hadoop和大数据的七大错误理念。
作者：王迪来源：| 10:22
　对于Hadoop技术而言，可以说是开源领域的传奇，然而如今业界还伴随着一些流言，这些流言可能会导致IT高管们带着&有色&的观点去制定策略。
如今，数据量在以惊人的速度增长，从IDC分析师报告中2013年数据存储上的增长速度将达到53.4%，AT&T更是声称无线数据的流量在过去的5年内增长200倍，从互联网内容、电子邮件、应用通知、社交消息以及每天接收的消息都在显著的增长，这也是众多大企业都聚焦大数据的原因所在。
毫无疑问，Hadoop成为解决大数据需求的主要投资领域之一，而类似Facebook等互联网巨头在都公开的吹捧Hadoop上取得的成功，同样初入大数据领域的公司也必先着眼于Hadoop。但对于Hadoop技术而言，是一个多维的解决方案，可以通过不同的方式进行部署和使用。下面就了解一些关于Hadoop和大数据的七大错误理念：
1.大数据仅仅是容量
对大数据来说，除了指体积之外，还经常提到Variety（多样）、Variability（可变）、Velocity（速度）和Value（价值）。关键点在于大数据并不是体积上的增长，更多是未来的实时分析、结构化和非结构化数据的发展，并被企业CIO用于更好的决策。
综上所述，并不是只有分析大数据才会获得价值。举个例子，存储和分析1PB的超时限数据的价值可能比不上实时分析1GB的数据，而从&新鲜&的数据上获得价值比解剖过时的数据更具价值。
2.传统SQL不能在Hadoop上使用
众多厂商在Hadoop上投入精力，布局市场战略时，十分清楚HDFS和MapReduce受限于处理类似SQL语言的能力，这也是Hive、Pig和Sqoop最终得以推广的原因。更多企业通过Hadoop和SQL兼容来管理大量的数据，Pivotal HD是结合SQL并行处理资料库与Hadoop 2.0，针对企业资料分析需求而优化的Hadoop强化版本。　
3.Hadoop是唯一的新IT数据平台
谈到数据平台，大型机在IT投资组合里有是一个长期投资，与ERP、CRM和SCM这些系统一样演变至今。而面对大数据时代，大型机不想被架构遗弃，必须展示在现有IT投资环境中的价值，而许多客户遇到速度、规模和成本的问题，通过vFabric SQLFire这样的内存大数据网络去解决高速数据存取，促进大型机批处理或实时分析报告这些问题。
4.虚拟化会导致性能下降
Hadoop最初的设计只是运行实体服务器上，然而随着云计算发展，许多企业都希望能作为云数据中心提供服务。之所以虚拟化Hadoop，企业首先要考虑管理基础设施的扩展性，认识到扩展计算资源，比如虚拟Hadoop节点在数据和计算分开时会对性能有所帮助，否则如果你关闭某个Hadoop节点将丢失上面的所有数据或者添加一个没有数据的空节点。
5.Hadoop只可以在数据中心运行
对于在SaaS云服务解决方案，许多云服务允许云端运行Hadoop、SQL，这无疑可以帮助企业省下数据中心建造投资的时间和金钱。特别是对于公有云情况下，Java开发者可以从Spring Data for Hadoop以及一些其它的GitHub用例中获益。
大数据复杂性
6.Hadoop对虚拟化无经济价值
Hadoop被很多人认为，尽管在商用服务器上运行，添加一个虚拟层在带来额外支出的同时并不会有额外的价值收益，但其实这个说法并没有考虑到数据和数据分析事实上都是动态的。虚拟化基础设施同样可以减少物理硬件数量，让CAPEX（资本支出）直接等于商用硬件成本，而通过自动以及高效利用共享基础设施同样可以减少OPEX（运营成本）。
7.Hadoop不能运行在SAN或NAS上
尽管Hadoop在本地磁盘上运行，对于中小型集群一样可以在一个共享的SAN环境下体现良好的性能表现，而高带宽比如10GB以太网、PoE以及iSCSI对性能同样有很好的支持。
由此，大数据成为行业追逐的热点，以上七大有关大数据&误解&问题的客观看待。如同不同项目需求不同，Hadoop是一个工具来帮助企业更好的应对大数据问题。无论是面对数据网格的GemFire​或SQLFire，还是面向消息的RabbitMQ中间件，一个完整的SaaS解决方案如今比在Hadoop环境更容易实现。
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条外电头条外电
24H热文一周话题本月最赞
讲师：0人学习过
讲师：0人学习过
讲师：11人学习过
精选博文论坛热帖下载排行
本书深入浅出地说明了如何利用.NET、Flash及XML来辅助Flash富媒体应用程序的开发。
本书首先介绍了Flash影片应用程序与.NET应用程序结合的...
订阅51CTO邮刊现在的位置:
hadoop socket超时导致put失败解决方案
当一个系统同时处理许多个并行的put操作，往HDFS上传数据时，有时候会出现dfsclient 端发生socket 链接超时的报错，有的时候甚至会由于这种原因导致最终的put操作失败，造成数据上传不完整。
log类似如下：
All datanodes *** are bad. Aborting...
类似这样的错误，常常会在并行的put操作比较多，比如60-80个，每个put的数据量约100G的时候，产生类似的错误，错误出现以后，比较好一点的情况是DFSClient端会报出一些列的错误log，如：
error Recovery for block block_-405 bad datanode ** "
Bad response for block block_-254u from datanode ***
10/01/18 18:48:00 WARN hdfs.DFSClient: Error Recovery for block blk_296138 bad datanode[0] 172.23.115.79:50010
10/01/18 18:48:00 WARN hdfs.DFSClient: Error Recovery for block blk_296138 in pipeline 172.23.115.79:5.115.68:50010: bad datanode 172.23.115.79:50010
10/01/18 18:48:27 WARN hdfs.DFSClient: DFSOutputStream ResponseProcessor exception for block blk_-296769java.net.SocketTimeoutException: 63000 millis timeout while waiting for channel to be ready for read. ch :java.nio.channels.SocketChannel[connected local=/172.23.113.2:50391 remote=/172.23.114.41:50010]
at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:162)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:150)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:123)
at java.io.DataInputStream.readFully(DataInputStream.java:178)
at java.io.DataInputStream.readLong(DataInputStream.java:399)
at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$ResponseProcessor.run(DFSClient.java:2318)
10/01/18 18:48:27 WARN hdfs.DFSClient: Error Recovery for block blk_-296769 bad datanode[0] 172.23.114.41:50010
10/01/18 18:49:04 WARN hdfs.DFSClient: DFSOutputStream ResponseProcessor exception for block blk_297704java.net.SocketTimeoutException: 63000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/172.23.113.2:44177 remote=/172.23.115.68:50010]
at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:162)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:150)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:123)
at java.io.DataInputStream.readFully(DataInputStream.java:178)
at java.io.DataInputStream.readLong(DataInputStream.java:399)
at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$ResponseProcessor.run(DFSClient.java:2318)
10/01/18 18:49:04 WARN hdfs.DFSClient: Error Recovery for block blk_297704 bad datanode[0] 172.23.115.68:50010
put: All datanodes 172.23.115.190:50010 are bad. Aborting...
put: All datanodes 172.23.115.101:50010 are bad. Aborting...
产生这样的报错后，put操作仍然能够进行，并最终数据上传是完整的，只是效率会收到影响。
但是如果碰到不好的情况，就会报出：
All datanodes *** are bad. Aborting...
这样的错误，这样就会导致put操作中断，导致数据上传不完整。
后来检查发现，所有的datanode虽然负载都比较搞，都在正常服务，而DFS的操作都是客户端直接跟datanode进行通信和数据传输，那么到底是什么原因导致了这样的问题呢？
根据log查看hadoop的代码发现，出错的地方在 DFSClient 的 processDatanodeError()方法中，进入这个方法就表示DFSClient的操作发生了错误。而进入这个报错的代码逻辑是因为DFSClient中发现errorIndex & 0，继续跟踪，发现修改了errorIndex变量的方法调用中，只有 createBlockOutputStream，DFSOutputStream的构造方法，以及ResponseProcessor.run()方法中对该变量进行了修改，而由于DFSOutputStream的构造方法对该变量进行的修改是在append的时候，ResponseProcessor.run()会直接抛出另外的异常，因此调用定位到createBlockOutputStream() 方法中，最后发现修改errorIndex的原因是由于 某个datanode的link跟dfsclient短发生了失败，根据log中发现失败是由于socket链接超时导致，这说明，put发生异常的时候，是DFSClient 链接从namenode得来的datanode列表中的datanode时，由于该datanode当时的负载非常的高，导致当时无法服务造成。
找到原因以后就好办了，由于DFSClient跟datanode的链接超时控制参数是一个客户端参数，因此，在数据上传的客户端hadoop-site.xml里修改配置参数 dfs.socket.timeout（默认十分钟），之后重新运行大批量的数据上传操作，问题不再重现：）
ps：最好是在程序中通过 conf.set 设置，否则如果程序有死循环岂不是要经过n久才会发现~~
conf.set("mapred.task.timeout", "3600000");
conf.set("dfs.socket.timeout", "3600000");
conf.set("dfs.datanode.socket.write.timeout", "3600000");
EasyQuery的目标是不需要写一行java代码就可以实现非常非常复杂的查询，省时省力，提高效率。
【上篇】【下篇】
您可能还会对这些文章感兴趣！
籍贯山东，落户北京，IT行业。
工作经历：
2014年至今&，自主创业
，传智播客
，超人学院
，亚信科技
教育经历：
，中科院研究生院
，河北大学