内存溢出
Client端内存溢出
ApplicationMaster端内存溢出
为了演示，先将am的内存调小到 512M。 之后客户端输入如下的报错信息：
set yarn.app.mapreduce.am.resource.mb=512;
select count(1) from (select num, count(1) from default.test_tb_1_1 where part>180 and part<190 group by num) a;
Map端 和 Reduce端内存溢出
数据倾斜
现象
常见容易出现数据倾斜的操作
join
参数：
- mapjoin
- Skew Join
解决方法：把空置变成一个字符串加上随机数，把倾斜的数据分布到不同的reduce上
可以考虑把数据类型转化为同一数据类型
groupby
group by 维度过小，某值的数量过多
set hive.map.aggr=true；
set hive.groupby.skewindata=true;
count distinct
调整map/reduce个数
控制hive任务中的map数
- 通常情况下，作业会通过input的目录产生一个或者多个map任务。
主要的决定因素有： input的文件总个数，input的文件大小，集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到，该参数不能自定义修改)；
- 举例：
- 是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m）,则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。
- 是不是保证每个map处理接近128m的文件块，就高枕无忧了？
如何合并小文件，减少map数？
假设一个SQL任务：
如何适当的增加map数？
控制hive任务的reduce数
1. Hive自己如何确定reduce数：
2. 调整reduce个数：
3. 什么情况下只有一个reduce；
自动合并输出的小文件
hive tez insert union all问题
查看对应的sql，发现存在insert union操作，查看往上信息，发现tez对于insert union操作会进行优化，通过并行加快速度，为防止有相同文件输出，所以对并行的输出各自生成成了一个子目录，在子目录中存放结果。如果此时全部hive客户端引擎及相关都设定为tez，则无问题。如果有客户端还在使用mr引擎，则会出现读取不到数据的情况。而在hive中，对于表目录存放信息有如下策略：
同时为了查看tez的此种情况对其他引擎的兼容性，又对sparktThriftServer的sql访问进行了测试：
到此这篇查询yarn上运行的任务（yarn 查看 任务计划）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/28614.html