标签:form 千万 url apache com 启动 原则 剪裁 生成
如果不指定 MapJoin 或者不符合 MapJoin 的条件,那么 Hive 解析器会将 Join 操作转换成 Common Join,即:在 Reduce 阶段完成 join。容易发生数据倾斜。可以用 MapJoin 把小表全部加载到内存在 map 端进行 join,避免 reducer 处理。
列处理:在 SELECT 中,只拿需要的列,如果有,尽量使用分区过滤,少用 SELECT *。
行处理:在分区剪裁中,当使用外关联时,如果将副表的过滤条件写在 Where 后面,那么就会先全表关联,之后再过滤。
SELECT a.id FROM lxw1234_a a left outer join t_lxw1234_partitioned b ON (a.id = b.url); WHERE b.day = ‘2015-05-10′
正确的写法是写在ON后面:
SELECT a.id FROM lxw1234_a a left outer join t_lxw1234_partitioned b ON (a.id = b.url AND b.day = ‘2015-05-10′);
或者直接写成子查询:
SELECT a.id FROM lxw1234_a a left outer join (SELECT url FROM t_lxw1234_partitioned WHERE day = ‘2015-05-10′) b ON (a.id = b.url)
(1)通常情况下,作业会通过 input 的目录产生一个或者多个 map 任务。
主要的决定因素有:input 的文件总个数,input 的文件大小,集群设置的文件块大小。
(2)是不是 map 数越多越好?
答案是否定的。如果一个任务有很多小文件(远远小于块大小 128m),则每个小文件也会被当做一个块,用一个 map 任务来完成,而一个 map 任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的 map 数是受限的。
(3)是不是保证每个 map 处理接近 128m 的文件块,就高枕无忧了?
答案也是不一定。比如有一个 127m 的文件,正常会用一个 map 去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果 map 处理的逻辑比较复杂,用一个 map任务去做,肯定也比较耗时。
针对上面的问题 2 和 3,我们需要采取两种方式来解决:即减少 map 数和增加 map 数;
在 Map 执行前合并小文件,减少 Map 数:CombineHiveInputFormat 具有对小文件进行合并的功能(系统默认的格式)。HiveInputFormat 没有对小文件合并功能。
set hive.input.format=org.apache.hadoop.hive.al.io.CombineHiveInputFormat
Reduce 个数并不是越多越好
(1)过多的启动和初始化 Reduce 也会消耗时间和资源;
(2)另外,有多少个 Reduce,就会有多少个输出文件,如果生成了很多个小文件,那么如果这些小文件作为下一个任务的输入,则也会出现小文件过多的问题;在设置 Reduce 个数的时候也需要考虑这两个原则:处理大数据量利用合适的 Reduce数;使单个 Reduce 任务处理数据量大小要合适;
// 输出合并小文件
SET hive.merge.mapfiles = true; -- 默认 true,在 map-only 任务结束时合并小文件 SET hive.merge.mapredfiles = true; -- 默认 false,在 map-reduce 任务结束时合并小文件 SET hive.merge.size.per.task = 268435456; -- 默认 256M SET hive.merge.smallfiles.avgsize = 16777216; -- 当输出文件的平均大小小于该值时,启动一个独立的 map-reduce 任务进行文件 merge
参考博客:https://www.cnblogs.com/1130136248wlxk/articles/5517666.html
标签:form 千万 url apache com 启动 原则 剪裁 生成
原文地址:https://www.cnblogs.com/guoyu1/p/12347235.html