- 1芋道源码 / yudao-cloud：前端技术架构探索与实践
- 2RabbitMQ源码解析前奏--集群_[{nodes,[{disc,[rabbit@proxy2]},{ram,[rabbit@proxy
- 3最新人工智能源码搭建部署教程/ChatGPT程序源码/AI系统/H5端+微信公众号版本源码_ai网站搭建
- 4大型语言模型 (LLM) 的系统消息框架和模板建议_llm下的智能客服的系统架构
- 530节AMOS教程从入门到论文分析：验证性因子分析的求解_amos验证性因子分析
- 6【mysql】—— 数据类型详解_mysql 数值类型
- 7AGI｜一文识别LangChain中ChatOpenAI 和OpenAI的区别_langchain chatopenai
- 804-PMP学习笔记-第四章《项目整合管理》_项目目标属于项目整合吗
- 9GOPS现场 | 对话龙智董事长何明，探讨DevOps安全新概念
- 10网络安全协议之IPsec
hive 处理小文件_hive 小文件分钟
赞
踩
原文地址：http://blog.csdn.net/yfkiss/article/details/8590486
http://blog.csdn.net/column/details/hive.html
当Hive输入由很多个小文件组成，由于每个小文件都会启动一个map任务，如果文件过小，以至于map任务启动和初始化的时间大于逻辑处理的时间，会造成资源浪费，甚至OOM。
为此，当我们启动一个任务，发现输入数据量小但任务数量多时，需要注意在Map前端进行输入合并
当然，在我们向一个表写数据时，也需要注意输出文件大小
1. Map输入合并小文件
对应参数：
set mapred.max.split.size=256000000; #每个Map最大输入大小
set mapred.min.split.size.per.node=100000000; #一个节点上split的至少的大小
set mapred.min.split.size.per.rack=100000000; #一个交换机下split的至少的大小
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; #执行Map前进行小文件合并
在开启了org.apache.hadoop.hive.ql.io.CombineHiveInputFormat后，一个data node节点上多个小文件会进行合并，合并文件数由mapred.max.split.size限制的大小决定。
mapred.min.split.size.per.node决定了多个data node上的文件是否需要合并~
mapred.min.split.size.per.rack决定了多个交换机上的文件是否需要合并~
2.输出合并
set hive.merge.mapfiles = true #在Map-only的任务结束时合并小文件
set hive.merge.mapredfiles = true #在Map-Reduce的任务结束时合并小文件
set hive.merge.size.per.task = 256*1000*1000 #合并文件的大小
set hive.merge.smallfiles.avgsize=16000000 #当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge
源地址:http://www.myexception.cn/database/1620535.html
hive 处理小文件，减少map数
1、hive.merge.mapfiles，True时会合并map输出。
2、hive.merge.mapredfiles，True时会合并reduce输出。
3、hive.merge.size.per.task，合并操作后的单个文件大小。
4、hive.merge.size.smallfiles.avgsize，当输出文件平均大小小于设定值时，启动合并操作。这一设定只有当hive.merge.mapfiles或hive.merge.mapredfiles设定为true时，才会对相应的操作有效。
5、mapred.reduce.tasks=30; 设置Reduce Task个数
6、hive.exec.compress.output=’false’; 设置数据不作压缩，要是压缩了我们拿出来的文件就只能通过HIVE-JDBC来解析
7、mapred.map.tasks=1200;
8、hive.optimize.skewjoin=true;这个是给join优化的 0.6官方版本好像有个bug悲哀啊
9、hive.groupby.skewindata=true;这个是给groupby优化的
优化案例一：
使用的生产Hive环境的几个参数配置如下：
dfs.block.size=268435456hive.merge.mapredfiles=truehive.merge.mapfiles=truehive.merge.size.per.task=256000000mapred.map.tasks=2
因为合并小文件默认为true，而dfs.block.size与hive.merge.size.per.task的搭配使得合并后的绝大部分文件都在300MB左右。
CASE 1：
现在我们假设有3个300MB大小的文件，那么goalsize = min(900MB/2,256MB) = 256MB (具体如何计算map数请参见http://blog.sina.com.cn/s/blog_6ff05a2c010178qd.html)
所以整个JOB会有6个map，其中3个map分别处理256MB的数据，还有3个map分别处理44MB的数据。
这时候木桶效应就来了，整个JOB的map阶段的执行时间不是看最短的1个map的执行时间，而是看最长的1个map的执行时间。所以，虽然有3个map分别只处理44MB的数据，可以很快跑完，但它们还是要等待另外3个处理256MB的map。显然，处理256MB的3个map拖了整个JOB的后腿。
CASE 2：
如果我们把mapred.map.tasks设置成6，再来看一下有什么变化：
goalsize = min(900MB/6,256MB) = 150MB
整个JOB同样会分配6个map来处理，每个map处理150MB的数据，非常均匀，谁都不会拖后腿，最合理地分配了资源，执行时间大约为CASE 1的59%(150/256)
案例分析：
虽然mapred.map.tasks从2调整到了6，但是CASE 2并没有比CASE 1多用map资源，同样都是使用6个map。而CASE 2的执行时间约为CASE 1执行时间的59%。
从这个案例可以看出，对mapred.map.tasks进行自动化的优化设置其实是可以很明显地提高作业执行效率的。
案例二(处理小文件)：
最近仓库里面新建了一张分区表，数据量大约是12亿行，分区比较多，从2008年7月开始 一天一个分区。
配置了一个任务
对这个表进行group by 的时候 发现启动了2800多个maps .
执行的时间也高大10分钟。
然后我在hdfs文件里面看到 这个表的每个分区里面都有20多个小文件，每个文件都不大 300KB--1MB
之前的hive的参数：
hive.merge.mapfiles=true
hive.merge.mapredfiles=false
hive.merge.rcfile.block.level=true
hive.merge.size.per.task=256000000
hive.merge.smallfiles.avgsize=16000000
hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
mapred.max.split.size=256000000
mapred.min.split.size=1
mapred.min.split.size.per.node=1
mapred.min.split.size.per.rack=1
hive.merge.mapredfiles 这个指的是 在Map-Reduce的任务结束时合并小文件
解决办法：
1.修改参数hive.merge.mapredfiles=true
2.通过map_reduece的办法生成一张新的表 此时生成的文件变成了每个分区一个文件
再次执行group by 发现效率得到了大大的提升。
小结：
正确处理hive小文件 是 控制map数的一个重要环节
处理的不好 会大大影响任务的执行效率
