Hive 大量数据动态分区导入出现异常:“如何修复”文件只能复制到0个节点而不是minreplication(=1)。“?

最新推荐文章于 2025-03-11 11:28:52 发布

@DANGE

最新推荐文章于 2025-03-11 11:28:52 发布

阅读量1.2k

点赞数

分类专栏： hive 文章标签：大数据 hive

本文链接：https://blog.youkuaiyun.com/qq_45831607/article/details/116299758

版权

hive 专栏收录该内容

3 篇文章

订阅专栏

本文档详细介绍了在Hadoop HDFS中遇到的文件复制到节点失败的问题，原因可能是由于数据节点空间预留机制导致。解决方案包括调整Hadoop配置参数，如减小块大小、设置动态分区优化等，以及优化YARN和MapReduce的相关配置，以提高系统资源利用率和处理大量并行文件写入的能力。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如何修复”文件只能复制到0个节点而不是minreplication(=1)

异常:Vertex failed, vertexName=Map 1, vertexId=vertex_1619776126790_0001_1_00, diagnostics=[Task failed, taskId=task_1619776126790_0001_1_00_000002, diagnostics=[TaskAttempt 0 failed, info=[Error: Failure while running task:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators

Caused by: org.apache.hadoop.ipc.RemoteException(java.io.IOException): File /snbap/ods/ods_user_pc_click_log/.hive-staging_hive_2021-04-30_09-52-11_138_4541347196075063109-1/_task_tmp.-ext-10000/dt=2019-12-12/_tmp.000002_3 could only be replicated to 0 nodes instead of minReplication (=1).  There are 1 datanode(s) running and no node(s) are excluded in this operation.
	at org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget4NewBlock(BlockManager.java:1549)
	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:3200)
	at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:641)
	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.addBlock(ClientNamenodeProtocolServerSideTranslatorPB.java:482)
	at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
	at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:619)
	at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:962)
	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2039)
	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2035)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2033)

	at org.apache.hadoop.ipc.Client.call(Client.java:1468)
	at org.apache.hadoop.ipc.Client.call(Client.java:1399)
	at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
	at com.sun.proxy.$Proxy10.addBlock(Unknown Source)
	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.addBlock(ClientNamenodeProtocolTranslatorPB.java:399)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
	at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
	at com.sun.proxy.$Proxy11.addBlock(Unknown Source)
	at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.locateFollowingBlock(DFSOutputStream.java:1532)
	at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1349)
	at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:588)
]], Vertex did not succeed due to OWN_TASK_FAILURE, failedTasks:1 killedTasks:2, Vertex vertex_1619776126790_0001_1_00 [Map 1] killed/failed due to:OWN_TASK_FAILURE]DAG did not succeed due to VERTEX_FAILURE. failedVertices:1 killedVertices:0

我最终接触到了Cloudera论坛,他们在几分钟内回答了我的问题: http://community.cloudera.com/t5/Storage-Random-Access-HDFS/Why-can-t-I-partition-a-1-gigabyte-dataset-into-300/m-p/86554#M3981 我试过J的建议,但效果很好!

他是这样说的:

如果要处理来自数据源的无序分区,则需要最终可能会像分区那样并行创建大量文件未遂的

在hdfs中,当一个文件(或者更具体地说,它的块)打开时, datanode执行其目标块大小的逻辑保留。所以如果配置的块大小为128 mib,则每次同时打开块将从可用的剩余值中(逻辑上)扣除该值数据节点发布到名称节点的空间。

此预订是为了帮助管理空间并确保阻止写入客户端,以便开始写入其文件不会在中途遇到空间不足异常。

注意:关闭文件时,只保留实际长度, 并对预留量计算进行调整,以反映可用空间。但是,当文件块保持打开状态时, 它总是被认为是持有一个完整的块大小。

如果可以的话,namenode进一步将只为写入选择一个datanode。确保完全目标块大小。它将忽略任何数据节点认为(基于其报告的价值和指标)不适合请求的写入参数。您的错误表明namenode 在尝试分配新块请求。

例如,如果同时打开的文件将超过560个(共70个gib) 128 mib块大小)。因此,数据节点将在大约560个打开文件的点,将不再作为有效目标进一步的文件请求。

根据您对插入的描述,这可能是数据集的300个块中的每一块可能仍然包含不同的ID, 导致每个并行任务请求大量打开的文件, 插入到几个不同的分区中。

你可以通过减少请求块来“破解”你的方法。查询中的大小(例如,将fs.blocksize设置为8 mib), 影响预约计算。但是,这可能不是随着规模的扩大,对于更大的数据集是个好主意,因为它将推动文件:块计数并增加名称节点的内存成本。

更好的方法是执行预分区插入(先按分区排序,然后插入分区态度)例如,hive提供了一个选项: hive.optimize.sort.dynamic.partition 如果你用普通的火花或者mapreduce,那么它们的默认分区策略这个。

解决问题:

set hive.exec.dynamic.partition.mode=nonstrict;  开启动态分区

set hive.optimize.sort.dynamic.partition=true

set hive.exec.max.dynamic.partitions.pernode=100000;
set hive.exec.max.dynamic.partitions=100000;

此外我还设置了以下配置:

#在hadoop/etc/hadoop/mapred-site.xml添加如果配置 
  <property>
    <name>mapred.child.java.opts</name>
    <value>-Xmx1000m</value>
  </property>

#在hadoop/etc/hadoop/yarn-site.xml添加如果配置 
<property>
   <name>yarn.scheduler.minimum-allocation-mb</name>
   <value>2048</value>
   <description>default value is 1024</description>
</property>
<property>
    <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4.0</value>
    <description>default value is 4.0</description>
</property>

#在hadoop yarn-site.xml设置 关闭虚以内存
<property>
        <name>yarn.nodemanager.vmem-check-enabled</name>
        <value>false</value>
</property>

推荐博客地址:http://ask.sov5.cn/q/BIXe47sxh5