在Cloudera QuickStart VM中执行Hive Join操作失败，求故障原因

我之前在Cloudera QuickStart VM里调试Hive查询时也碰到过一模一样的MapredLocalTask执行失败问题，结合你的场景和排查经历，给你梳理几个最可能的原因和对应的解决办法：

1. 本地模式资源不足（最常见原因） #

Cloudera QuickStart VM默认开启了Hive的本地模式（hive.exec.mode.local.auto=true），这个模式会在VM本地运行MapReduce任务，而非提交到YARN集群。但QuickStart VM的内存、CPU配置通常不高，当你的查询涉及Join+Group By这类计算量稍大的操作时，本地资源不够就会直接触发执行错误。

解决办法：
临时关闭本地模式，让任务走YARN集群执行，执行以下命令后再重新运行你的查询：

set hive.exec.mode.local.auto=false;
select order_date, sum(order_item_subtotal) daily_revenue from orders join order_items on order_id = order_item_order_id group by order_date;

如果想永久关闭，你可以修改Hive的配置文件hive-site.xml，把hive.exec.mode.local.auto的值设为false。

2. HDFS临时目录权限问题 #

Hive执行任务时需要在HDFS的临时目录（默认是/tmp/hive）写入中间数据，如果当前用户（cloudera）没有该目录的读写权限，也会导致MapredLocalTask执行失败。

排查&解决：
先检查临时目录权限：

hdfs dfs -ls /tmp/hive

如果权限不足，执行以下命令修复：

hdfs dfs -chmod -R 777 /tmp/hive

或者自定义Hive的临时目录：

set hive.exec.scratchdir=/user/cloudera/hive_temp;

然后在HDFS创建这个目录并赋权：

hdfs dfs -mkdir -p /user/cloudera/hive_temp
hdfs dfs -chmod 777 /user/cloudera/hive_temp

3. 表数据或元数据异常 #

虽然你已经重新加载了表，但还是要确认两个点：

• 数据类型匹配：你的表结构里orders.order_id和order_items.order_item_order_id都是int类型，这点没问题，但要检查数据里是否存在脏数据（比如非数值的ID），可以用以下命令排查：

select order_id from orders where order_id is null or cast(order_id as string) rlike '[^0-9]';
select order_item_order_id from order_items where order_item_order_id is null or cast(order_item_order_id as string) rlike '[^0-9]';

• 表分隔符匹配：检查建表时指定的字段分隔符是否和源数据一致，执行show create table orders;和show create table order_items;查看ROW FORMAT部分，如果分隔符和源文件不匹配，重新建表并加载数据。

4. Hive MapReduce配置参数不合理 #

如果以上方法都不行，可以尝试调整本地模式的资源阈值，让Hive只有在数据量极小时才用本地模式：

set hive.exec.mode.local.auto.inputbytes.max=10000000;  # 设置本地模式处理的最大数据量为10MB
set hive.exec.mode.local.auto.tasks.max=2;  # 设置本地模式处理的最大任务数

然后再执行查询。

内容的提问来源于stack exchange，提问作者Tarique Anwar