• 阅读: 56 回复: 0
    数据123

    Hive提高查询效率的八条军规

    楼主 发表于 2021-09-13 14:06:35

    大家好,我是一哥,今天分享一下Hive如何提升查询效率。Hive作为最常用的数仓计算引擎,是我们必备的技能,但是很多人只是会写Hql,并不会优化,也不知道如何提升查询效率,今天分享8条军规: 

    1、开启FetchTask

    一个简单的查询语句,是指一个没有函数、排序等功能的语句,当开启一个Fetch Task功能,就执行一个简单的查询语句不会生成MapRreduce作业,而是直接使用FetchTask,从hdfs文件系统中进行查询输出数据,从而提高效率。

    设置的方式: 

    2、合并中间表

    一个日志文件中,每一行记录,会有很多很多字段,四五十个字段很正常。实际分析中,常常使用少数几个字段将原始的表中数据,依据业务需求提取出要分析的字段,数据放入到对应的业务表(子表)中,实际的业务针对业务表进行分析。

    在实际中,我们会发现,有些业务处理,会有共同数据集用户表、订单表、商品表,三个表需要进行join的操作,join 会产生一个结果集,会有很多的业务是针对此jion结果集进行分析。

    优化:将众多的业务中相同的中间结果集,抽取到一个Hive中的表中去。

     

    3、合理使用分区表

    外部表、分区表,结合使用,采用多级分区。数据采用存储格式(textfile、orcfile、parquet)或者数据压缩(snappy)。

    明细数据我们一般采用按天分区,对于特别大的表,可以采用子分区,每个分区其实对应到HDFS上就是一个目录。数据存储方式我们可以采用parquet列式存储,同时具有很好的压缩性能;同时可以减少大量的表扫描和反序列化的时间。在OLAP查询场景下,我们选择需要的列信息进行查询,而不是直接select * 查询所有字段。

     

    4、jvm重用

    JVM重用是hadoop调优参数的内容,对hive的性能具有非常大的影响,特别是对于很难避免小文件的场景或者task特别多的场景,这类场景大多数执行时间都很短。hadoop默认配置是使用派生JVM来执行map和reduce任务的,这是jvm的启动过程可能会造成相当大的开销,尤其是执行的job包含有成千上万个task任务的情况。JVM重用可以使得JVM实例在同一个JOB中重新使用N次,N的值可以在Hadoop的mapre-site.xml文件中进行设置

    JVM的一个缺点是,开启JVM重用将会一直占用使用到的task插槽,以便进行重用,直到任务完成后才能释放。如果某个“不平衡“的job中有几个reduce task 执行的时间要比其他reduce task消耗的时间多得多的话,那么保留的插槽就会一直空闲着却无法被其他的job使用,直到所有的task都结束了才会释放。

     

    5、speculative execution(推测执行)

    所谓的推测执行,就是当所有task都开始运行之后,Job Tracker会统计所有任务的平均进度,如果某个task所在的task node机器配置比较低或者CPU load很高(原因很多),导致任务执行比总体任务的平均执行要慢,此时Job Tracker会启动一个新的任务(duplicate task),原有任务和新任务哪个先执行完就把另外一个kill掉。

    推测执行需要设置Job的两个参数:

    6、合理设置reduce个数

    reduce个数

    计算公式:reducer个数=min(参数2,总输入数据量/参数1)

    set mapred.reduce.tasks =N:

    每个任务默认的reduce数目。典型为0.99* reduce槽数,hive默认为-1,即自动确定reduce数目。

    reduce个数并不是越多越好

    同map一样,启动和初始化reduce也会消耗时间和资源;另外,有多少个reduce,就会有多少个输出文件,如果生成了很多个小文件,那么如果这些小文件作为下一个任务的输入,则也会出现小文件过多的问题。小文件过多会非常影响查询效率,文件越多造成的IO就越多,同时还会增加元数据(namenode)的压力。在生产环境中,一定要避免小文件问题,如果核查发现,及时合并文件!!

     

    7、开启并行执行

    并行执行,意思是同步执行hive的多个阶段,hive在执行过程,将一个查询转化成一个或者多个阶段。某个特定的job可能包含众多的阶段,而这些阶段可能并非完全相互依赖的,也就是说可以并行执行的,这样可能使得整个job的执行时间缩短

    8、优化sql

    • where条件优化

    优化前(关系数据库不用考虑会自动优化):

    in 要比join 快

    • 消灭子查询内的 group by 、 COUNT(DISTINCT),MAX,MIN。可以减少job的数量。

    • join 优化:

    Common/shuffle/Reduce JOIN:连接发生的阶段,发生在reduce 阶段,适用于大表连接大表(默认的方式)

    Map join :连接发生在map阶段,适用于小表连接大表 大表的数据从文件中读取;小表的数据存放在内存中(hive中已经自动进行了优化,自动判断小表,然后进行缓存)。

    本文内容转载自“数据社”(ID:DataClub),作者数据社

热门文章

数据中台系列(一):你的企业真的需要「数据中台」吗?

数据中台案例 | 一呼百应:激活 670 万企业用户数据,赋能智慧供应链

辨析BI、数据仓库、数据湖和数据中台内涵及差异点(建议收藏)

数据中台案例 | 数字化为零售行业创造新可能

最新文章

「央视新闻」快三彩平台邀请码「手机搜狐网」

数据仓库研发规范

元数据管理在数据仓库的实践应用

Gartner发布2022年重要战略技术趋势

  • 未登录

    回复楼主

    登录后可回复
    /1000