"这篇文档详细解释了HIVE中的一些常用设置参数,涵盖了动态分区、文件合并策略以及本地模式的启用,这些都是Hadoop大数据处理中优化Hive性能的关键配置。" 在Hive中,动态分区是一种非常有用的功能,它允许用户在插入数据时只指定部分分区键,而其余部分可以在运行时根据数据自动确定。动态分区的两个关键参数是`hive.exec.dynamic.partition`和`hive.exec.dynamic.partition.mode`。将`hive.exec.dynamic.partition`设置为`true`开启动态分区功能,而`hive.exec.dynamic.partition.mode`设置为`nonstrict`则允许所有分区字段都为动态,但在严格模式下,至少需要有一个分区字段被显式指定。 此外,为了控制动态分区的使用,还有几个参数需要调整。`hive.exec.max.dynamic.partitions.pernode`定义每个mapper或reducer可以创建的最大动态分区数,默认为100。`hive.exec.max.dynamic.partitions`限制了一个DML操作可以创建的总动态分区数,其默认值为1000。`hive.exec.max.created.files`规定了一个DML操作可以创建的文件数上限,默认为100000。这些参数的合理设置能避免系统因创建过多分区或文件而过载。 文件合并策略对优化Hive性能也至关重要。`hive.merge.mapfiles`和`hive.merge.mapredfiles`分别控制是否合并Map和Reduce阶段的输出文件,以减少小文件的数量。通常,合并可以提高HDFS的效率,但过度合并可能会增加单个文件的大小,反而影响性能。`sethive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;`这个命令可以开启小文件合并,通过调整文件块大小来优化文件布局。 Hive从0.7版本开始支持本地模式执行,这对于处理小规模数据时可以显著提升效率。通过设置`hive.exec.mode.local.auto=true`,Hive可以自动决定是否使用本地模式。`setmapred.reduce.tasks`则用于设置当前会话的map和reduce任务数量,这在优化任务分配和资源利用时十分关键。 理解并正确配置这些Hive参数对于优化大数据处理性能至关重要,尤其是在Hadoop集群上运行大规模查询时。通过精细调整,可以有效地平衡资源消耗与处理速度,从而提升整体的Hive作业执行效率。
hive.exec.dynamic.partition=true
默认值:false
描述:是否允许动态分区
hive.exec.dynamic.partition.mode=nonstrict
默认值:strict
描述:strict是避免全分区字段是动态的,必须有至少一个分区字段是指定有值的。
读取表的时候可以不指定分区。
设置如下参数配置动态分区的使用环境:
hive.exec.max.dynamic.partitions.pernode=100
默认值:100
描述:each mapper or reducer可以创建的最大动态分区数
hive.exec.max.dynamic.partitions=1000
默认值:1000
描述:一个DML操作可以创建的最大动态分区数
hive.exec.max.created.files=100000
默认值:100000
描述:一个DML操作可以创建的文件数
设置如下参数取消一些限制(HIVE 0.7后没有此限制):
hive.merge.mapfiles=false
默认值:true
描述:是否合并Map的输出文件,也就是把小文件合并成一个map
hive.merge.mapredfiles=false
默认值:false
描述:是否合并Reduce的输出文件,也就是在Map输出阶段做一次reduce操作,再输出
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
这个参数表示执行前进行小文件合并,
前面三个参数确定合并文件块的大小,大于文件块大小128m的,
按照128m来分隔,小于128m,大于100m的,按照100m来分隔,把那些小于100m的(包括小文件和分隔大文件剩下的),
进行合并,最终生成了74个块。
配置如下参数,可以开启Hive的本地模式:
hive> set hive.exec.mode.local.auto=true;(默认为false)
set mapred.reduce.tasks;
设置当前Session的map,reduce 的个数,默认值是-1,为系统自动匹配。
匹配原则是按照block的个数来启动map。
但并非map的数量越多越好,当有大量的小文件的时候,反而适合一个map负责读取多个文件对象。
因为每启动一个map都是一个开销。
一、控制hive任务中的map数:
1.通常情况下,作业会通过input的目录产生一个或者多个map任务。
主要的决定因素有: input的文件总个数,input的文件大小,集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到,该参数不能自定义修改);
2.举例:
a)假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和1个12m的块),从而产生7个map数
b)假设input目录下有3个文件a,b,c,大小分别为10m,20m,130m,那么hadoop会分隔成4个块(10m,20m,128m,2m),从而产生4个map数
即,如果文件大于块大小(128m),那么会拆分,如果小于块大小,则把该文件当成一个块。
3.是不是map数越多越好?
答案是否定的。如果一个任务有很多小文件(远远小于块大小128m),则每个小文件也会被当做一个块,用一个map任务来完成,
而一个map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。
而且,同时可执行的map数是受限的。
4.是不是保证每个map处理接近128m的文件块,就高枕无忧了?
答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,
但这个文件只有一个或者两个小字段,却有几千万的记录,
如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。
针对上面的问题3和4,我们需要采取两种方式来解决:即减少map数和增加map数;
如何合并小文件,减少map数?
假设一个SQL任务:
Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;
该任务的inputdir /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
共有194个文件,其中很多是远远小于128m的小文件,总大小9G,正常执行会用194个map任务。
Map总共消耗的计算资源: SLOTS_MILLIS_MAPS= 623,020
剩余5页未读,继续阅读
- 粉丝: 0
- 资源: 5
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- C++标准程序库:权威指南
- Java解惑:奇数判断误区与改进方法
- C++编程必读:20种设计模式详解与实战
- LM3S8962微控制器数据手册
- 51单片机C语言实战教程:从入门到精通
- Spring3.0权威指南:JavaEE6实战
- Win32多线程程序设计详解
- Lucene2.9.1开发全攻略:从环境配置到索引创建
- 内存虚拟硬盘技术:提升电脑速度的秘密武器
- Java操作数据库:保存与显示图片到数据库及页面
- ISO14001:2004环境管理体系要求详解
- ShopExV4.8二次开发详解
- 企业形象与产品推广一站式网站建设技术方案揭秘
- Shopex二次开发:触发器与控制器重定向技术详解
- FPGA开发实战指南:创新设计与进阶技巧
- ShopExV4.8二次开发入门:解决升级问题与功能扩展