Member since
07-13-2020
5
Posts
0
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1540 | 01-19-2021 07:10 PM | |
6964 | 01-19-2021 07:08 PM |
01-19-2021
07:10 PM
It's the same LDAP uid conflicts issue with this one: https://community.cloudera.com/t5/Support-Questions/Hive-tez-vertex-failed-during-map-phase-HDP-3-1-4/td-p/309973
... View more
01-19-2021
07:08 PM
Finally, I managed to solve this issue. I'd like to add some details for others might be lost in the same trap. The root cause is that the user UIDs in our LDAP clashes with the UIDs of hdp internal user UIDs(e.g. hive, spark, infra-solr, hbase...). To be more specific in the above case, the user test has UID 1002 in our LDAP configuration, while the hdp internal user 'infra-solr' has the same UID. From the log, we can see some INPUT_READ_ERROR, the error is raised by some downstream task complaining that it cannot get data from the upstream task. The reason behind it is that when the downstream task try to get upstream task data from shuffle service (which runs on yarn node manager as an aux-service), a lot of HTTP 500 error raised. Why shuffle service raises 500? It's because it checks the permission (owner) of data file sent out by upstream task and found the user name does not match, so it raised an error. When we look at the logs from node manager, we can see bunch of errors like below: Caused by: java.io.IOException: Owner 'infra-solr' for path /xxx/hadoop/yarn/local/usercache/xxx/appcache/application_1610695610027_0576/output/attempt_1610695610027_0576_2_00_000017_0_10002/file.out.index did not match expected owner 'test' The related source code: - https://github.com/apache/hadoop/blob/master/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle/src/main/java/org/apache/hadoop/mapred/ShuffleHandler.java - https://github.com/apache/tez/blob/master/tez-plugins/tez-aux-services/src/main/java/org/apache/tez/auxservices/ShuffleHandler.java The lesson here is: when we configure uid/gid in LDAP, we should be more careful about the potential conflicts.
... View more