网站开发众包平台,影视广告片拍摄厂家,淘宝客自建手机网站,域名不变 网站改版工作中涉及到优化部分不多#xff0c;下面的一些方案可能会缺少实际项目支撑#xff0c;这里主要是为了完备一下知识体系。 参考的hive参数管理文档地址#xff1a;https://cwiki.apache.org/confluence/display/Hive/ConfigurationProperties 对于Hive优化#xff0c;可以… 工作中涉及到优化部分不多下面的一些方案可能会缺少实际项目支撑这里主要是为了完备一下知识体系。 参考的hive参数管理文档地址https://cwiki.apache.org/confluence/display/Hive/ConfigurationProperties 对于Hive优化可以从下面几个角度出发 一、建表优化二、存储压缩优化1.存储2.压缩 三、Job层面优化1.合理控制mapreduce个数2.JVM重用3.Fetch抓取4.本地模式5.并行执行6.推测执行7.严格模式 四、HQL层面优化1.列裁剪分区裁剪2.谓词下推3.CBO优化4.group by优化5.join优化6.order bylimit7.避免产生笛卡尔积 一、建表优化
根据业务选择合适的分区表或分桶表分区在HDFS上的表现就是分文件夹分桶就是分文件这样在进行数据查询分析时可以避免全表扫描直接读取目标分区或分桶。
二、存储压缩优化
1.存储
存储主要分为列式存储与行式存储hive支持的主要存储方式有 TextFile行式也是hive默认的存储格式数据以纯文本格式存储可直接文本编辑器打开查看。 Sequence File行式序列化为二进制存储可以被MR高效读写但因为行式所以不适合SQL分析因此当某些需要MR处理但不需要进行SQL分析的可以选择。 ORC File列式RCFile的升级版对hadoop生态的原生支持比较好Hive 0.11版本及之后引入。支持ACID事务和行级别的更新。 Parquet File列式兼容性比较好包括hadoop生态和很多非hadoop生态系统。
hive中往往是基于大数据量对某些指标进行分析计算只需要处理某几个特定的字段就行了因此一般选择列式存储可以提升读的效率。
2.压缩
压缩可以从3个角度来说分别是map输出结果的压缩reduce最终输出结果的压缩和同一个job中不同MR之间中间结果数据的压缩。压缩会一定程度的增加CPU开销但是降低了磁盘IO和网络传输IO。
开发中常用的方案ORC/Parquet Snappy
三、Job层面优化
1.合理控制mapreduce个数
MR中一个map或者一个reduce就是一个进程进程的创建启动开销大如对于小文件问题会造成为每个小文件都启动一个map任务浪费资源。可以通过参数设置在map任务执行前对小文件进行合并。或者是input的文件很大处理逻辑又复杂就会导致单个map的负载过重造成整体任务缓慢这种情况可以通过减小每个map可以读取的数据量最大值来增加map数量提高并行计算的能力。
对于reduce的个数可以通过调整每个reduce处理的数据量进而调整reduce的个数或者是通过参数直接强行指定个数。但要注意reduce个数太少可能会导致单个任务处理缓慢过多可能会导致reduce任务启动开销的浪费和输出小文件过多的问题。一般来说让hive自己选择就好。
2.JVM重用
原因同上默认情况下每个map或reduce任务都会启动一个JVM进程通过参数设置JVM重用JVM重用就是为了减少进程的频繁创建启动当通过参数指定每个JVM进程处理的任务数后JVM实例只有在处理完指定的任务数量之后才会销毁。需要注意的是设置JVM重用并不会影响启动的JVM个数区别只是在于执行完任务后是直接执行下一个任务还是销毁进程重新启动一个JVM 去执行下个任务。可以通过在hadoop的mapred-site.xml配置文件中设置 mapreduce.job.jvm.numtasks参数在一些低版本的hadoop中参数可能为mapred.job.reuse.jvm.num.tasks为JVM设置可重复运行的task任务个数。 参考https://hadoop.apache.org/docs/r2.5.2/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml
3.Fetch抓取
hive读取HDFS数据有两种方式 1通过MR读取。 2直接读取。 开启fetch机制后特定条件下的查询不会转换成MR任务而是直接从HDFS中读取数据从而提升效率。 通过参数hive.fetch.task.conversion设置值允许为none, minimal , more。 在Hive 0.14.0及之后默认值为more当涉及到简单的select全局查找或字段查找where过滤或者limit查找时不走MR。这就要求当前的查询不能出现分组、聚合、关联等类似操作很好理解因为涉及到后面的操作时必须启动MR计算而不是简单的将数据原样读取返回即可。
4.本地模式
这点主要是针对小数据量的任务而言的。也就是对于小数据量的任务不提交到集群执行而是在集群的某个单一节点上执行。好处是避免了集群间不必要的资源协调调度和跨节点数据传输。可通过下面参数开启配置
5.并行执行
一个HiveSQL可能会转化为多个stage阶段如果这些阶段之间没有依赖关系是可以并行执行的最大化利用集群资源。类似于(A) union all (B)此时AB是可以并行执行的。可以通过下面参数设置 并行执行受限于集群资源只有当集群资源充足才会并行执行。同时对于小数据量的sql可能反而导致效率变慢原因是增加了资源和任务的调度开销超过了小查询本身执行的时间。
6.推测执行
这主要是针对个别执行过慢的任务的一种优化策略。如果某个任务执行时间明显超过其他同类型任务时可能是因为执行该任务的节点硬件故障网络拥堵或者其他原因。此时hive会重启一个备份任务执行和原任务谁先执行完就以谁的结果为准。设置参数 参考https://hadoop.apache.org/docs/r2.5.2/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml
7.严格模式
严格模式就是不让执行hive认为有“风险”的查询比如分区表必须使用分区过滤order by时必须跟着limit子句限制产生笛卡尔积的查询等。参数设置
四、HQL层面优化
1.列裁剪分区裁剪
就是查询时只select需要的字段对于分区表指定分区查找。
2.谓词下推
就是将where数据过滤尽早的提前到map端过滤而不是在reduce端对处理后的结果进行过滤。类似于下面这两段SQL
-- 没有使用谓词下推的sql执行逻辑
select *
from A join B on A.id B.id
where A.id10;-- 使用谓词下推后的sql执行逻辑
select*
from (select * from A where id10) A join B on A.idB.id;hive中默认开启此配置
3.CBO优化
CBOCost based Optimizer基于代价/成本的优化。比如多个表join的时候如果不考虑CBO优化往往前面的表作为驱动表被加载进内存后面的表作为被驱动表进行磁盘扫描。开启CBO优化后hive会根据统计信息决定最优的表连接顺序连接算法等。可以通过下面4个参数开启设置
set hive.cbo.enabletrue;
set hive.compute.query.using.statstrue;
set hive.stats.fetch.column.statstrue;
set hive.stats.fetch.partition.statstrue;在hive1.1.0之后默认开启 关于hive中CBO优化细节可以查看https://cwiki.apache.org/confluence/display/Hive/Cost-basedoptimizationinHive
4.group by优化
group by是对相同key的数据拉取到同一个reduce中处理如果这个key的数据量很大就可能导致数据倾斜。可以通过开启map端预聚合和当出现数据倾斜时开启负载均衡来优化。 负载均衡指的是将原先的一个MR job转换成两个MR job第一阶段随机打散预聚合第二阶段对预聚合的结果进行最终聚合。 可通过下面参数开启
-- 开启map端预聚合
set hive.map.aggr true;
-- map端预聚合的数据条数
set hive.groupby.mapaggr.checkinterval 100000;
-- 开启负载均衡
set hive.groupby.skewindata true;5.join优化
join优化可分为map join小表join大表和SMB join大表join大表。
map join map join是将小表直接分发到各个map任务的进程中在map进程中完成join省略了shuffle的过程也就避免了数据倾斜的可能。
参数设置
-- 开启map join
set hive.auto.convert.jointrue;
-- 小表阈值单位字节大约25MB
set hive.mapjoin.smalltable.filesize25000000;SMB join SMBSort Merge Bucket Join这种方式要求两个表都根据关联字段分桶并排序。原理是将两个大表分桶且两表桶数成倍数关系那么关联的时候驱动表的每个桶都只会被驱动表中与自己相关的桶进行连接避免了全局shuffle在map阶段就可以完成所以也不会导致数据倾斜单个任务执行缓慢。同时因为桶内有序所以连接时可以采用类似归并排序的方式进行连接提高连接效率。
6.order bylimit
如果排序时不加limit限制那么就会将所有数据拉取到同一个reduce中进行排序非常容易导致任务执行缓慢。而limit限制之后比如说limit 5那么会首先在每个reduce中对局部数据进行排序并从每个reduce中找出局部前5的数据再将所有reduce的结果进行最终排序选出全局前5的数据。
7.避免产生笛卡尔积
这里主要就是说join连接时要指定连接字段一般开发中也不会犯这种错误。
