hive sql 优化

sql优化:

----------------------------------------------------------------

数据倾斜的处理方式:

--

Q: 活动数据 和 对应的维表进行关联,其中某个活动特别的大。

A:

1) 给关联健加入一个随机的 1-10的值

2)将维度表 的关联健, 每个加上 1-10的值,将维度表扩充十倍。

3)然后将2个表进行join,从而来消除数据倾斜。

--

尽量不使用count distinct

1) 通过select子查询优化

2) 通过建立临时表

--

用in 来代替join

select id,name from tb1 where id in(select id from tb2); in 要比join 快

--

Map join :

连接发生在map阶段 , 适用于小表 连接 大表

大表的数据从文件中读取

小表的数据存放在内存中(hive中已经自动进行了优化,自动判断小表,然后进行缓存)

--

1.  将大表放后头

3. 尽量尽早地过滤数据

4.尽量避免一个SQL包含复杂逻辑,可以使用中间表来完成复杂的逻辑

5.避免使用select * , 不用列不要放进去

6.过滤不使用的数据分区

2. 使用相同的连接键

--

配置 优化----------------------------------------------------------------------

设置map 和reduce 为合理的数量

合并小文件

原文地址:https://www.cnblogs.com/lt1548748657/p/11609268.html

时间: 2024-10-29 08:05:48

hive sql 优化的相关文章

深入浅出Hive企业级架构优化、Hive Sql优化、压缩和分布式缓存(企业Hadoop应用核心产品)

一.本课程是怎么样的一门课程(全面介绍)    1.1.课程的背景       作为企业Hadoop应用的核心产品,Hive承载着FaceBook.淘宝等大佬 95%以上的离线统计,很多企业里的离线统计甚至全由Hive完成,如我所在的电商.       Hive在企业云计算平台发挥的作用和影响愈来愈大,如何优化提速已经显得至关重要.       Hive作业的规模决定着优化层级,一个Hive作业的优化和一万的Hive作业的优化截然不同.       拥有1万多个Hive作业的大电商如何进行Hiv

hive SQL优化之distribute by和sort by

最近在优化hiveSQL, 下面是一段排序,分组后取每组第一行记录的SQL INSERT OVERWRITE TABLE t_wa_funnel_distinct_temp PARTITION (pt='${SRCTIME}') SELECT bussiness_id, cookie_id, session_id, funnel_id, group_first(funnel_name) funnel_name, step_id, group_first(step_name) step_name,

hive sql 优化 数据倾斜

此脚本运行速度慢,主要是reduce端数据倾斜导致的,了解到dw.fct_traffic_navpage_path_detl表是用来收集用户点击数据的,那么最终 购物车和下单的点击肯定极少,所以此表ordr_code字段为空和cart_prod_id字段为NULL的数据量极大,如下所示: select ordr_code,count(*) as a from dw.fct_traffic_navpage_path_detl  where ds = '2015-05-10'  group by o

hive sql 优化 - 2.0

hive 优化 1.需要计算的指标真的需要从数据仓库的公共明细自行汇总吗?2.真的需要扫描那么多的分区么?3.尽量不要使用 select * from table这样的方式4.输入文件不要是大量的小文件 group by引起的倾斜优化: R:group by引起的倾斜主要是输入数据行按照group by列分布不均匀引起的. S:优化方案: set hive.map.aggr = true set hive.groupby.skewindata=true count distinct优化 eg:

hive job sql 优化 之CPU占有过高

最近有个SQL运行时长超过两个小时,所以准备优化下 首先查看hive sql 产生job的counter数据发现 总的CPU time spent 过高估计100.4319973小时 每个map的CPU time spent 排第一的耗了2.0540889小时 建议设置如下参数: 1.mapreduce.input.fileinputformat.split.maxsize现在是256000000   往下调增加map数(此招立竿见影,我设为32000000产生了500+的map,最后任务由原先

Hive SQL的编译过程

Hive是基于Hadoop的一个数据仓库系统,在各大公司都有广泛的应用.美团数据仓库也是基于Hive搭建,每天执行近万次的Hive ETL计算流程,负责每天数百GB的数据存储和分析.Hive的稳定性和性能对我们的数据分析非常关键. 在几次升级Hive的过程中,我们遇到了一些大大小小的问题.通过向社区的咨询和自己的努力,在解决这些问题的同时我们对Hive将SQL编译为MapReduce的过程有了比较深入的理解.对这一过程的理解不仅帮助我们解决了一些Hive的bug,也有利于我们优化Hive SQL

Hive SQL 编译过程

转自:http://www.open-open.com/lib/view/open1400644430159.html Hive跟Impala貌似都是公司或者研究所常用的系统,前者更稳定点,实现方式是MapReduce,因为用Hue的时候,在groupby中文的时候,出现了点问题,并且看到写很长的SQL语句,经常会看到起很多个Job,因此想了解下Hive怎么将SQL转化成MapReduce的Job.以后写SQL的时候,大概就了解怎么去做优化了.下面是看到的一片优秀的文章(美团的技术博客),我粘过

Hive ive优化 (important)

Hive ive优化 要点:优化时,把hive sql当做map reduce程序来读,会有意想不到的惊喜. 理解hadoop的核心能力,是hive优化的根本. 长期观察hadoop处理数据的过程,有几个显著的特征: 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.map reduce作业初始化的时间是比较长的. 3.对sum,count来说,不存在数据倾斜问题. 4.对count

(转)Hive SQL的编译过程

本文来着美团 :http://tech.meituan.com/hive-sql-to-mapreduce.html Hive是基于Hadoop的一个数据仓库系统,在各大公司都有广泛的应用.美团数据仓库也是基于Hive搭建,每天执行近万次的Hive ETL计算流程,负责每天数百GB的数据存储和分析.Hive的稳定性和性能对我们的数据分析非常关键. 在几次升级Hive的过程中,我们遇到了一些大大小小的问题.通过向社区的咨询和自己的努力,在解决这些问题的同时我们对Hive将SQL编译为MapRedu