hive on tez 执行任务报错

最新推荐文章于 2025-10-10 10:10:34 发布
原创 最新推荐文章于 2025-10-10 10:10:34 发布 · 5.4k 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#大数据 #hive #hdfs #ambari

当使用Hive on Tez执行任务时遇到报错，通常是由于资源不足或被抢占。解决方案包括调整Tez的配置参数，如增大AM和Task的最大重试次数，以及设置适当的Container大小。重要参数包括`tez.am.max.app.attempts`、`tez.am.task.max.failed.attempts`和`tez.container.size`。此外，还涉及到AM和Container的JVM内存设置，以及Map Join的相关参数调整。

 

hive on tez，在执行任务的时候报错，这种情况原因是container资源被抢占或者是资源不足。而task最大的失败次数默认是4，am自己失败的最大重试次数默认是2次。

报错日志：

Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:13
Vertex vertex_1588914175897_18178_1_00 [Map 7] killed/failed due to:OTHER_VERTEX_FAILURE, counters=Counters: 35, File System Counters, FILE_BYTES_READ=47800, FILE_BYTES_WRITTEN=1107572220, HDFS_BYTES_READ=745850999, HDFS_READ_OPS=60, HDFS_OP_OPEN=60, org.apache.tez.common.counters.TaskCounter, SPILLED_RECORDS=16203009, GC_TIME_MILLIS=3322, CPU_MILLISECONDS=239810, PHYSICAL_MEMORY_BYTES=17135828992, VIRTUAL_MEMORY_BYTES=32139993088, COMMITTED_HEAP_BYTES=17135828992, INPUT_RECORDS_PROCESSED=16203009, INPUT_SPLIT_LENGTH_BYTES=4733999156, OUTPUT_RECORDS=16203009, OUTPUT_BYTES=2399220587, OUTPUT_BYTES_WITH_OVERHEAD=2442634582, OUTPUT_BYTES_PHYSICAL=1107524420, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILL_COUNT=0, SHUFFLE_CHUNK_COUNT=5, HIVE, DESERIALIZE_ERRORS=0, RECORDS_IN_Map_7=16203009, RECORDS_OUT_INTERMEDIATE_Map_7=16203009, TaskCounter_Map_7_INPUT_company_baseinfo_complex, INPUT_RECORDS_PROCESSED=16203009, INPUT_SPLIT_LENGTH_BYTES=4733999156, TaskCounter_Map_7_OUTPUT_Reducer_8, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILL_COUNT=0, OUTPUT_BYTES=2399220587, OUTPUT_BYTES_PHYSICAL=1107524420, OUTPUT_BYTES_WITH_OVERHEAD=2442634582, OUTPUT_RECORDS=16203009, SHUFFLE_CHUNK_COUNT=5, SPILLED_RECORDS=16203009, vertexStats=firstTaskStartTime=1589836372219, firstTasksToStart=[ task_1588914175897_18178_1_00_000012,task_1588914175897_18178_1_00_000013,task_1588914175897_18178_1_00_000010,task_1588914175897_18178_1_00_000011 ], lastTaskFinishTime=1589836672777, lastTasksToFinish=[ task_1588914175897_18178_1_00_000008,task_1588914175897_18178_1_00_000009,task_1588914175897_18178_1_00_000006,task_1588914175897_18178_1_00_000007 ], minTaskDuration=38304, maxTaskDuration=61170, avgTaskDuration=49326.8, numSuccessfulTasks=5, shortestDurationTasks=[ task_1588914175897_18178_1_00_000001 ], longestDurationTasks=[ task_1588914175897_18178_1_00_000000 ], vertexTaskStats={numFailedTaskAttempts=0, numKilledTaskAttempts=0, numCompletedTasks=18, numSucceededTasks=5, numKilledTasks=13, numFailedTasks=0}
2020-05-19 05:17:52,787 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: vertex_1588914175897_18178_1_00 [Map 7] transitioned from TERMINATING to KILLED due to event V_TASK_COMPLETED
2020-05-19 05:17:52,788 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000007, stoppedTime=1589836672788, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: Vertex vertex_1588914175897_18178_1_04 [Reducer 2] completed., numCompletedVertices=7, numSuccessfulVertices=2, numFailedVertices=1, numKilledVertices=4, numVertices=8
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: Checking vertices for DAG completion, numCompletedVertices=7, numSuccessfulVertices=2, numFailedVertices=1, numKilledVertices=4, numVertices=8, commitInProgress=0, terminationCause=VERTEX_FAILURE
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |node.AMNodeImpl|: Attempt failed on node: storm-node-20:45454 TA: attempt_1588914175897_18178_1_00_000002_0 failed: false container: container_e57_1588914175897_18178_02_000007 numFailedTAs: 0
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000004, stoppedTime=1589836672789, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |node.AMNodeImpl|: Attempt failed on node: storm-node-15:45454 TA: attempt_1588914175897_18178_1_00_000006_0 failed: false container: container_e57_1588914175897_18178_02_000004 numFailedTAs: 0
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000005, stoppedTime=1589836672789, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |node.AMNodeImpl|: Attempt failed on node: storm-node-16:45454 TA: attempt_1588914175897_18178_1_00_000007_0 failed: false container: container_e57_1588914175897_18178_02_000005 numFailedTAs: 0
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000006, stoppedTime=1589836672789, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |node.AMNodeImpl|: Attempt failed on node: storm-node-12:45454 TA: attempt_1588914175897_18178_1_00_000008_0 failed: false container: container_e57_1588914175897_18178_02_000006 numFailedTAs: 0
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000009, stoppedTime=1589836672789, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |node.AMNodeImpl|: Attempt failed on node: storm-node-16:45454 TA: attempt_1588914175897_18178_1_00_000009_0 failed: false container: container_e57_1588914175897_18178_02_000009 numFailedTAs: 0
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:CONTAINER_STOPPED]: containerId=container_e57_1588914175897_18178_02_000008, stoppedTime=1589836672789, exitStatus=-1000
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: Vertex vertex_1588914175897_18178_1_00 [Map 7] completed., numCompletedVertices=8, numSuccessfulVertices=2, numFailedVertices=1, numKilledVertices=5, numVertices=8
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: Checking vertices for DAG completion, numCompletedVertices=8, numSuccessfulVertices=2, numFailedVertices=1, numKilledVertices=5, numVertices=8, commitInProgress=0, terminationCause=VERTEX_FAILURE
2020-05-19 05:17:52,789 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: DAG did not succeed due to VERTEX_FAILURE. failedVertices:1 killedVertices:5
2020-05-19 05:17:52,795 [INFO] [IPC Server handler 2 on 33236] |app.TaskAttemptListenerImpTezDag|: Container with id: container_e57_1588914175897_18178_02_000008 is valid, but no longer registered, and will be killed
2020-05-19 05:17:52,804 [WARN] [IPC Server handler 18 on 33236] |app.TaskAttemptListenerImpTezDag|: Received task heartbeat from unknown container with id: container_e57_1588914175897_18178_02_000006, asking it to die
2020-05-19 05:17:52,854 [WARN] [IPC Server handler 8 on 33236] |app.TaskAttemptListenerImpTezDag|: Received task heartbeat from unknown container with id: container_e57_1588914175897_18178_02_000005, asking it to die
2020-05-19 05:17:52,857 [WARN] [IPC Server handler 4 on 33236] |app.TaskAttemptListenerImpTezDag|: Received task heartbeat from unknown container with id: container_e57_1588914175897_18178_02_000007, asking it to die
2020-05-19 05:17:52,890 [WARN] [IPC Server handler 0 on 33236] |app.TaskAttemptListenerImpTezDag|: Received task heartbeat from unknown container with id: container_e57_1588914175897_18178_02_000004, asking it to die
2020-05-19 05:17:52,954 [WARN] [IPC Server handler 13 on 33236] |app.TaskAttemptListenerImpTezDag|: Received task heartbeat from unknown container with id: container_e57_1588914175897_18178_02_000009, asking it to die
2020-05-19 05:17:53,007 [INFO] [Dispatcher thread {Central}] |recovery.RecoveryService|: DAG completed, dagId=dag_1588914175897_18178_1, queueSize=0
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |history.HistoryEventHandler|: [HISTORY][DAG:dag_1588914175897_18178_1][Event:DAG_FINISHED]: dagId=dag_1588914175897_18178_1, startTime=1589836371531, finishTime=1589836672789, timeTaken=301258, status=FAILED, diagnostics=Vertex failed, vertexName=Reducer 8, vertexId=vertex_1588914175897_18178_1_01, diagnostics=[Exception in VertexManager, vertex:vertex_1588914175897_18178_1_01 [Reducer 8],org.apache.tez.dag.api.TezUncheckedException: setParallelism cannot be called after scheduling tasks. Vertex: vertex_1588914175897_18178_1_01 [Reducer 8]
	at org.apache.tez.dag.app.dag.impl.VertexImpl.setParallelism(VertexImpl.java:1737)
	at org.apache.tez.dag.app.dag.impl.VertexImpl.reconfigureVertex(VertexImpl.java:1653)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerPluginContextImpl.reconfigureVertex(VertexManager.java:186)
	at org.apache.tez.dag.library.vertexmanager.ShuffleVertexManager.determineParallelismAndApply(ShuffleVertexManager.java:654)
	at org.apache.tez.dag.library.vertexmanager.ShuffleVertexManager.schedulePendingTasks(ShuffleVertexManager.java:670)
	at org.apache.tez.dag.library.vertexmanager.ShuffleVertexManager.schedulePendingTasks(ShuffleVertexManager.java:776)
	at org.apache.tez.dag.library.vertexmanager.ShuffleVertexManager.onSourceTaskCompleted(ShuffleVertexManager.java:500)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerEventSourceTaskCompleted.invoke(VertexManager.java:603)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerEvent$1.run(VertexManager.java:658)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerEvent$1.run(VertexManager.java:653)
	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:1869)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerEvent.call(VertexManager.java:653)
	at org.apache.tez.dag.app.dag.impl.VertexManager$VertexManagerEvent.call(VertexManager.java:642)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
, Vertex did not succeed due to AM_USERCODE_FAILURE, failedTasks:0 killedTasks:398, Vertex vertex_1588914175897_18178_1_01 [Reducer 8] killed/failed due to:AM_USERCODE_FAILURE]
Vertex killed, vertexName=Reducer 3, vertexId=vertex_1588914175897_18178_1_05, diagnostics=[Vertex received Kill while in RUNNING state., Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:172, Vertex vertex_1588914175897_18178_1_05 [Reducer 3] killed/failed due to:OTHER_VERTEX_FAILURE]
Vertex killed, vertexName=Reducer 5, vertexId=vertex_1588914175897_18178_1_07, diagnostics=[Vertex received Kill while in RUNNING state., Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:220, Vertex vertex_1588914175897_18178_1_07 [Reducer 5] killed/failed due to:OTHER_VERTEX_FAILURE]
Vertex killed, vertexName=Reducer 4, vertexId=vertex_1588914175897_18178_1_06, diagnostics=[Vertex received Kill while in RUNNING state., Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:284, Vertex vertex_1588914175897_18178_1_06 [Reducer 4] killed/failed due to:OTHER_VERTEX_FAILURE]
Vertex killed, vertexName=Reducer 2, vertexId=vertex_1588914175897_18178_1_04, diagnostics=[Vertex received Kill while in RUNNING state., Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:20, Vertex vertex_1588914175897_18178_1_04 [Reducer 2] killed/failed due to:OTHER_VERTEX_FAILURE]
Vertex killed, vertexName=Map 7, vertexId=vertex_1588914175897_18178_1_00, diagnostics=[Vertex received Kill while in RUNNING state., Vertex did not succeed due to OTHER_VERTEX_FAILURE, failedTasks:0 killedTasks:13, Vertex vertex_1588914175897_18178_1_00 [Map 7] killed/failed due to:OTHER_VERTEX_FAILURE]
DAG did not succeed due to VERTEX_FAILURE. failedVertices:1 killedVertices:5, counters=Counters: 68, org.apache.tez.common.counters.DAGCounter, NUM_KILLED_TASKS=33, NUM_SUCCEEDED_TASKS=17, TOTAL_LAUNCHED_TASKS=22, DATA_LOCAL_TASKS=3, RACK_LOCAL_TASKS=8, AM_CPU_MILLISECONDS=21690, AM_GC_TIME_MILLIS=29, File System Counters, FILE_BYTES_READ=92824, FILE_BYTES_WRITTEN=1874380129, HDFS_BYTES_READ=1444697496, HDFS_READ_OPS=145, HDFS_OP_OPEN=145, org.apache.tez.common.counters.TaskCounter, SPILLED_RECORDS=57624814, GC_TIME_MILLIS=5403, CPU_MILLISECONDS=521160, PHYSICAL_MEMORY_BYTES=49465524224, VIRTUAL_MEMORY_BYTES=109211656192, COMMITTED_HEAP_BYTES=49465524224, INPUT_RECORDS_PROCESSED=57624814, INPUT_SPLIT_LENGTH_BYTES=11099796036, OUTPUT_RECORDS=57624814, OUTPUT_BYTES=3583907214, OUTPUT_BYTES_WITH_OVERHEAD=3710166893, OUTPUT_BYTES_PHYSICAL=1874287305, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILL_COUNT=0, SHUFFLE_CHUNK_COUNT=17, HIVE, DESERIALIZE_ERRORS=0, RECORDS_IN_Map_1=41418454, RECORDS_IN_Map_6=3351, RECORDS_IN_Map_7=16203009, RECORDS_OUT_INTERMEDIATE_Map_1=41418454, RECORDS_OUT_INTERMEDIATE_Map_6=3351, RECORDS_OUT_INTERMEDIATE_Map_7=16203009, TaskCounter_Map_1_INPUT_domainweb_complex, INPUT_RECORDS_PROCESSED=41418454, INPUT_SPLIT_LENGTH_BYTES=6365505145, TaskCounter_Map_1_OUTPUT_Reducer_2, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILL_COUNT=0, OUTPUT_BYTES=1184494315, OUTPUT_BYTES_PHYSICAL=766708084, OUTPUT_BYTES_WITH_OVERHEAD=1267347103, OUTPUT_RECORDS=41418454, SHUFFLE_CHUNK_COUNT=11, SPILLED_RECORDS=41418454, TaskCounter_Map_6_INPUT_t1, INPUT_RECORDS_PROCESSED=3351, INPUT_SPLIT_LENGTH_BYTES=291735, TaskCounter_Map_6_OUTPUT_Reducer_2, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILL_COUNT=0, OUTPUT_BYTES=192312, OUTPUT_BYTES_PHYSICAL=54801, OUTPUT_BYTES_WITH_OVERHEAD=185208, OUTPUT_RECORDS=3351, SHUFFLE_CHUNK_COUNT=1, SPILLED_RECORDS=3351, TaskCounter_Map_7_INPUT_company_baseinfo_complex, INPUT_RECORDS_PROCESSED=16203009, INPUT_SPLIT_LENGTH_BYTES=4733999156, TaskCounter_Map_7_OUTPUT_Reducer_8, ADDITIONAL_SPILLS_BYTES_READ=0, ADDITIONAL_SPILLS_BYTES_WRITTEN=0, ADDITIONAL_SPILL_COUNT=0, OUTPUT_BYTES=2399220587, OUTPUT_BYTES_PHYSICAL=1107524420, OUTPUT_BYTES_WITH_OVERHEAD=2442634582, OUTPUT_RECORDS=16203009, SHUFFLE_CHUNK_COUNT=5, SPILLED_RECORDS=16203009
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_05 [Reducer 3]
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_04 [Reducer 2]
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_07 [Reducer 5]
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_06 [Reducer 4]
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_01 [Reducer 8]
2020-05-19 05:17:53,096 [INFO] [Dispatcher thread {Central}] |impl.VertexImpl|: Ignoring multiple aborts for vertex: vertex_1588914175897_18178_1_00 [Map 7]
2020-05-19 05:17:53,097 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: DAG: dag_1588914175897_18178_1 finished with state: FAILED
2020-05-19 05:17:53,097 [INFO] [Dispatcher thread {Central}] |impl.DAGImpl|: dag_1588914175897_18178_1 transitioned from TERMINATING to FAILED due to event DAG_VERTEX_COMPLETED

 

分析：

[Reducer 2] transitioned from TERMINATING to KILLED due to event V_TASK_COMPLETED  reduce和map被Kill了好几次。
失败的原因是container被高优先级的任务抢占了。而task最大的失败次数默认是4。当集群上的任务比较多时，比较容易出现这个问题。

解决方案：

命令行修改默认值

set tez.am.task.max.failed.attempts=10;
set tez.am.max.app.attempts=5;

1. 参数：set tez.am.max.app.attempts=5;   表达含义：am自己失败的最大重试次数，默认是2次。这里并不是am自己挂了，只是因为一些系统原因导致失联了，所以这里用到这个设置；

2. 参数：set tez.am.task.max.failed.attempts=10;  表达含义：任务中attempts失败的最大重试次数，默认跟yarn一样是4次 ，在不稳定集群可以设置大一点，这里设置为10；

3. 参数：Tez Container Size  表达含义：还有一个原因可能是container设置的内存太小，默认本来是1G，改为4G以上基本没啥问题了 (目前生产集群为 5120MB)。在Hive配置文件修改 ；    （本次任务报错非此参数原因，故未做改动）

 

 

 

一些TEZ的比较重要参数：

part1:

一、AM、Container大小设置
1、tez.am.resource.memory.mb　　#设置 tez AM容器内存
　　默认值：1024　　
　　配置文件：tez-site.xml
　　建议：不小于或者等于yarn.scheduler.minimum-allocation-mb值。
　　

2、hive.tez.container.size　　#设置 tez container内存
　　默认值：-1
　　默认情况下，Tez将生成一个mapper大小的容器。这可以用来覆盖默认值。
　　配置文件：hive-site-xml
　　建议：不小于或者是yarn.scheduler.minimum-allocation-mb的倍数
　　
二、AM、Container JVM参数设置
1、tez.am.launch.cmd-opts　　#设置 AM jvm，启动TEZ任务进程期间提供的命令行选项。
　　默认值：-XX:+PrintGCDetails -verbose:gc -XX:+PrintGCTimeStamps -XX:+UseNUMA -XX:+UseParallelGC(用于GC)，默认的大小：80%*tez.am.resource.memory.mb
　　配置文件：tez-site.xml
　　建议：不要在这些启动选项中设置任何xmx或xms，以便tez可以自动确定它们。
　　

2、hive.tez.java.ops　　#设置 container jvm
　　默认值：Hortonworks建议“–server –Djava.net.preferIPv4Stack=true–XX:NewRatio=8 –XX:+UseNUMA –XX:UseG1G”，默认大小：80%*hive.tez.container.size
　　说明：在hive 2.x的官方文档中没有找到这个参数。看有些博客里面有这个值。
　　配置文件：hive-site.xml

3、tez.container.max.java.heap.fraction　　#设置task/AM占用jvm内存大小的比例。
　　默认值：0.8
　　配置文件：tez-site.xml
　　说明：这个值按具体需要调整，当内存不足时，一般都要调小。

三、Hive内存Map Join参数设置
1、tez.runtime.io.sort.mb　　#设置输出排序内存大小
　　默认值：100
　　配置文件：tez-site.xml
　　建议：40%*hive.tez.container.size，一般不超过2G
2、hive.auto.convert.join.noconditionaltask　　#是否将多个mapjoin合并为一个
　　默认值：true
　　建议使用默认值。
　　配置文件：hive-site.xml
3、hive.auto.convert.join.noconditionaltask.size  
　　默认值：10000000　　(10M)
　　说明：这个参数使用的前提是hive.auto.convert.join.noconditionaltask值为true，多个mapjoin转换为1个时，所有小表的文件大小总和小于这个值，这个值只是限制输入的表文件的大小，并不代表实际mapjoin时hashtable的大小。 建议值：1/3* hive.tez.container.size
　　配置文件：hive-site.xml
4、tez.runtime.unordered.output.buffer.size-mb　　#如果不直接写入磁盘，使用的缓冲区大小
　　默认值：100M
 　建议：10%* hive.tez.container.size
　　配置文件：tez-site.xml

5、tez.am.container.reuse.enabled　　#容器重用
　　默认值：true
　　配置文件：tez-ste.xml

 

 

part2:

timeline server 配置 ，默认是org.apache.tez.dag.history.logging.ats.ATSHistoryLoggingService

tez.history.logging.service.class

jobhistory搭建的地址，需要独立的ui-war部署

tez.tez-ui.history-url.base

是否开启推测执行，默认是false，在出现最后一个任务很慢的情况下，建议把这个参数设置为true

tez.am.speculation.enabled

分配的内存，默认1024 ,出现内存不够时候，设置更大点

tez.task.resource.memory.mb

分配的vcores 默认是1  ，一般不需要改

tez.task.resource.cpu.vcores

日志级别，默认info

tez.task.log.level

启动的JVM参数 ，默认-XX:+PrintGCDetails -verbose:gc -XX:+PrintGCTimeStamps -XX:+UseNUMA -XX:+UseParallelGC

tez.task.launch.cmd-opts

在yarn中的默认执行队列

tez.queue.name

依赖的hadoop相关包

tez.lib.uris.classpath

运行依赖的自身包，这个参数设置比较麻烦，很容易出错

tez.lib.uris

自己定义的UDF 相关包

tez.aux.uris

基于yarn提供的内存，分配给java进程的百分比，默认是0.8，具体大小取决于mapreduce.reduce.memory.mb和mapreduce.map.memory.mb。一般不用变即可

tez.container.max.java.heap.fraction

任务中attempts失败的最大重试次数，默认跟yarn一样是4次 ，在不稳定集群可以设置大一点

tez.am.task.max.failed.attempts

am自己失败的最大重试次数，默认是2次。这里并不是说am自己挂了，只是因为一些系统原因导致失联了

tez.am.max.app.attempts

am分配的cpu个数，默认1

tez.am.resource.cpu.vcores

am分配的内存大小，默认1024

tez.am.resource.memory.mb

任务进程重用是否开启，默认是true

tez.am.container.reuse.enabled

更多详细的配置 （官方文档）：

https://tez.apache.org/releases/0.8.4/tez-api-javadocs/configs/TezConfiguration.html

Hive on Tez 报错: DAG 执行失败，原因是 VERTEX_FAILURE
DevProPlus的博客
09-14 1360
在错误信息中，我们可以看到有关 failedVertices 和 killedVertices 的信息，这些信息可以帮助我们定位到具体出错的顶点和执行过程。通过检查日志、检查资源、优化查询、更新软件版本和调整配置参数，我们可以解决这些错误并提高应用程序的性能和稳定性。更新软件版本：检查所使用的 Hive、Tez 和相关软件的版本，并确保使用的是最新的稳定版本。希望本文所提供的解决方法和示例代码能够帮助您解决 DAG VERTEX_FAILURE 错误，并顺利进行 Hive on Tez 的数据处理任务。
Hive on tez 运行报错集锦
cuichunchi的博客
10-26 2221
执行 hive：直接报java.lang.ClassNotFoundException: org.apache.hadoop.mapred.MRVersion CDH集群安装组件都ok，在Hue界面中使用Hive的HQL是都是ok的 但是直接在liunx中，打开客户端命令： 执行 hive：直接报java.lang.ClassNotFoundException: org.apache.hadoop.mapred.MRVersion 解决方案： 因为CDH的hive-site.xml配置文件中没
OTHER_VERTEX_FAILURE]DAG did not succeed due to VERTEX_FAILURE. failedVertices:1 killedVertices:2
vikings_lau的博客
03-03 2221
后来发现是源表的建表语句有问题,直接select * 查询也不行.原来是中台从SQL server抽数到hive上时,decimal自动识别转成了string类型,导致这张表查询都查不了.跑一个insert 语句时遇到这个报错,一开始以为是数据量过大导致的,但是查询之后发现源表数据量很小,只有1000多,所以不是数据量导致的资源不足.于是手动更改,把string类型改为float类型,重新建表,然后就一切正常了.附报错图。
hive on tez运行及hive ha搭建
最新发布
weixin_62206215的博客
10-10 1267
在Hive2.x版本起，Hive官方不再建议使用MapReduce作为底层默认执行引擎，推荐使用Tez或者Spark作为执行引擎（目前Hive4.0.0版本不支持Spark引擎），这些引擎相比于默认的MapReduce执行引擎执行任务时可以提升查询性能、降低延迟并优化资源利用，Hive4.x版本后可能会彻底弃用MapReduce引擎。Apache Tez是一个开源分布式执行框架，专为处理复杂数据流任务而设计。它允许将多个依赖任务转化为单一的有向无环图（DAG）作业，从而大幅提升性能。
Hive Tez任务失败
wisgood的专栏
09-23 1万+
Hive Tez任务跑失败
hive on tez执行任务报错，did not succeed due to VERTEX_FAILURE
后来X大数据
05-12 1万+
hive on tez，在执行任务的时候报错，这种情况原因是container资源被抢占或者是资源不足。而task最大的失败次数默认是4. Status: Failed Vertex failed, vertexName=Map 1, vertexId=vertex_1589254309642_0001_4_00, diagnostics=[Task failed, taskId=task_1589254309642_0001_4_00_000000, diagnostics=[TaskAttempt 0
Hive Tez报错：errorMessage=Cannot recover from this error:java.lang.OutOfMemoryError: Java heap space
周源的专栏
02-26 1769
ERROR : FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.tez.TezTask. Vertex failed, vertexName=Reducer 2, vertexId=vertex_1582200549031_0142_2_02, diagnostics=[Task failed, ...
踩坑填坑-个人总结持续更新
留歌__36的博客
10-26 2574
===================================== AirFlow 部分======================================== 1.Airflow 任务假死问题 版本：Airflow 1.10.9 现象： 日志出现： dependency ‘Task Instance State’ FAILED: Task is in the ‘running’ state which is not a valid state for execution. The task
hive on tez 常见报错问题收集
01-26
这里我们将深入探讨五个在Hive on Tez中常见的报错问题及其解决方案。 1. 错误一：Failing because I am unlikely to write too。 这个问题是由于Hive中的一个已知bug，具体问题可以在Apache JIRA的HIVE-16398中...
Hive On Tez报错汇总
TomAndersen的博客
06-04 2031
前言 Hive：2.3.0 Hadoop：2.7.7 JDK：1.8.0_221 Tez：0.9.1 报错一 报错内容： 在Hive下使用Tez引擎执行MR Job时报错：Container killed on request. Exit code is 143 问题分析： 从Container killed on request这几个关键字就可以猜测，Container在非正常结束时被kill，很有可能就是Container使用的内存超出Container限制导致的。 查看Hive运行日志： Hiv
记录hive on tez报错
琅天溪的博客
10-23 1386
记录hive on tez报错 我使用的hadoop以及hive还有tez的版本是： hadoop-2.6.0-cdh5.16.2 hive-1.1.0-cdh5.16.2 tez-0.8.5 上测试成功结果 Query ID = root_20201023210303_3bda0a6a-6f65-41fe-9c18-64b582c5d2d8 Total jobs = 1 Launching Job 1 out of 1 Status: Running (Executing on YARN cluste
[Hive]四、Hive On Tez
weixin_44428807的博客
08-26 1380
用Hive直接编写MR程序，假设有四个有依赖关系的MR作业，上图中，绿色是Reduce Task，云状表示写屏蔽，需要将中间结果持久化写到HDFS。2）拷贝apache-tez-0.9.1-bin.tar.gz到hadoop102的/opt/software目录。Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。3）将apache-tez-0.9.1-bin.tar.gz上传到HDFS的/tez目录下。下面创建一个tez-site.xml文件。
hive - ERROR : Vertex failed, vertexName=Map 1
a123147abc的博客
11-29 4857
ERROR : Vertex failed, vertexName=Map 1 解决：在 hive sql 脚本前，加上 set hive.vectorized.execution.enabled=false;
Hive数据倾斜调优(详细版)
wzluestc的博客
07-19 711
一、数据倾斜本质 数据在各Map task或Reduce task上分配不均匀，数据量过大的task会拉长整个任务的执行时间。 二、表现 某个map task运行时间明显长于其他task。并且该task的数据量明显大于其他task。针对Map task，看INPUT_SPLIT_LENGTH_BYTES，该参数表示map task的输入数据量，和OUTPUT_BYTES_PHYSICAL，表示map task的输出数据量；针对Reduce task，看SHUFFLE_BYTES，表示shuffle输出，也就
Vertex did not succeed due to OWN_TASK_FAILURE, failedTasks:1 killedTasks:355, Vertex vertex_1723443
jojo_oulaoula的博客
08-16 927
报错信息：Vertex did not succeed due to OWN_TASK_FAILURE, failedTasks:1 killedTasks:355, Vertex vertex_1723443443009_487387_1_06 [Reducer 7] killed/failed due to:OWN_TASK_FAILURE]DAG d。比如我这次的报错，就是select一个null而报错，视开发平台不同而判断。明明很简单的select语句查询却会报错，这个时候注意一下你的字段类型。
MapReduce中跨InputSplit数据的处理
黑夜舞者的专栏
10-10 1028
LineRecordReader类的分析 InputSplit只是一个逻辑概念，每个InputSplit并没有对文件进行实际的切割，只是记录了要处理的数据的位置，首先说明InputSplit的生成： 一、bytesRemaining = length，length为文件的大小，bytesRemaining初始化的值为文件的大小 二、生成blockIndex，blkIndex =getBloc
MapReduce源码分析之InputSplit分析
热门推荐
chlaws的专栏
04-03 1万+
前言 MapReduce的源码分析是基于Hadoop1.2.1基础上进行的代码分析。 什么是InputSplit        InputSplit是指分片，在MapReduce当中作业中，作为map task最小输入单位。分片是基于文件基础上出来的而来的概念，通俗的理解一个文件可以切分为多少个片段，每个片段包括了等信息。在MapTask拿到这些分片后，会知道从哪开始读取数据。 Job
Tez调优参数总结
cuichunchi的博客
02-17 3828
hive.tez.auto.reducer.parallelism=false hive.tez.bucket.pruning=false hive.tez.bucket.pruning.compat=true hive.tez.container.max.java.heap.fraction=0.8 hive.tez.container.size=768 hive.tez.cpu.vcores=-1 hive.tez.dynamic.partition.pruning=true hive.tez.dyn.
升级到 CDP 后Hive on Tez 性能调整和故障排除指南
未来在这儿的专栏
02-09 2086
此博客介绍了有关 CDP 的 Hive on Tez 查询的一些基本故障排除和调整指南。作为查询性能分析的第一步，您应该验证并验证在 Hive 和 Hive on Tez 服务上设置的所有配置。所做的每一项更改都应进行测试，以确保其做出可衡量且有益的改进。查询调优是一项专门的工作，并非所有查询都可以通过更改 Tez 配置属性来更好地执行。您可能会遇到需要深入研究 SQL 查询以优化和提高执行和性能的场景。如果您需要有关性能调整工作的更多帮助，请联系您的 Cloudera 帐户和专业服务团队以提供指导。
paimon1.0.1,使用hive on tez读取paimon表做sql报错：Vertex failed
07-31
在 Paimon 1.0.1 中使用 Hive on Tez 读取 Paimon 表时遇到 SQL 报错 `Vertex failed`，通常与任务执行过程中某些节点（Vertex）未能成功完成计算任务有关。此类错误可能由多种原因引发，包括但不限于资源不足、数据倾斜、配置问题或兼容性问题。 ### 可能的原因及解决方案 #### 1. **资源不足导致任务失败** 在 Hive on Tez 执行过程中，如果某个 Map 或 Reduce 任务分配的内存或 CPU 资源不足，可能导致 Vertex 执行失败。特别是在读取 Paimon 表时，由于其列式存储结构和复杂的文件合并机制，可能对内存需求较高。 - **解决方案**：适当调整 Tez 和 YARN 的资源配置参数，例如： ```sql -- 增加 Mapper 内存 SET mapreduce.map.memory.mb=4096; -- 设置 YARN 容器最小内存 SET yarn.scheduler.minimum-allocation-mb=4096; -- 调整 JVM 堆内存参数 SET mapreduce.map.java.opts=-Xmx3600m; -- 设置 Tez 的内存分配 SET tez.task.resource.memory-mb=4096; SET tez.runtime.unordered.output.buffer.size-mb=1024; ``` #### 2. **Paimon 表与 Hive Catalog 集成问题** Paimon 表通过 Hive StorageHandler 集成到 Hive 中，若集成配置不正确，可能导致元数据读取失败或文件路径解析异常，从而触发 Vertex 失败。 - **验证方式**：检查 Paimon 表的 Hive 外部表定义是否正确，确保 `LOCATION` 或 `paimon_location` 指向有效的 HDFS 路径，并且 Hive Metastore 和 Hiveserver2 已重启以加载新配置 [^3]。 - **修复方式**：重新确认 Hive Metastore 和 Hiveserver2 的启动状态，确保所有服务正常运行，并检查日志文件中是否有连接或路径异常。 #### 3. **Hive on Tez 与 Paimon 文件格式兼容性问题** Paimon 使用其自定义的列式文件格式（基于 ORC 或 Parquet 的变种），若 Hive on Tez 版本不支持该格式，可能导致读取失败。 - **解决方案**： - 确保 Hive 和 Tez 的版本与 Paimon 1.0.1 兼容。 - 更新 Paimon 的 Hive StorageHandler JAR 包至最新版本，确保其支持当前 Hive 和 Tez 的运行环境。 - 在 Hive 表定义中明确指定文件格式，例如： ```sql CREATE EXTERNAL TABLE test.paimon_ex_ws_t STORED BY 'org.apache.paimon.hive.PaimonStorageHandler' LOCATION 'hdfs://node154:8020/paimon/hive/test.db/ws_t'; ``` #### 4. **任务执行中的 GC 问题或线程异常** 在执行过程中，若 JVM 频繁发生 Full GC 或线程阻塞，也可能导致 Vertex 超时或失败。 - **解决方案**：启用 GC 日志并分析： ```sql SET mapreduce.map.java.opts=-Xmx3600m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/tmp/gc.log; ``` 根据 GC 日志判断是否存在频繁 GC 或内存泄漏问题。 #### 5. **数据倾斜导致部分 Vertex 耗时过长** 若 Paimon 表中某些分区或文件的数据量远大于其他分区，可能导致部分 Vertex 执行时间过长，进而被 YARN 或 Tez 判定为失败。 - **解决方案**： - 对数据进行预分区或采样，避免数据倾斜。 - 使用动态分区并控制每个分区的数据量。 - 启用 Tez 的自动并发调整功能： ```sql SET tez.grouping.split-waves=3.0; SET tez.grouping.min-size=16MB; SET tez.grouping.max-size=1024MB; ``` ### 总结 `Vertex failed` 错误通常由资源不足、配置错误、数据倾斜或兼容性问题引起。解决该问题需结合日志分析、资源配置调整和 Paimon 与 Hive 集成状态的检查。建议优先排查资源限制和 Hive Catalog 配置，其次关注数据分布与执行日志。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值