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: select count(distinct user) from some_table;
R:由于必须去重,因此hive会将Map阶段的输出全部分不到一个Reduce Task上,因此很容引起性能问题
S:
select count(*)
from
(
select user
from some_table
group by user
) tmp

利用gourp by 去重,再统计group by 的行数目

大表join小表优化
join相关的优化主要分为mapjoin 可以解决的优化(即大表join小表)和mapjoin无法解决的优化(即大表join大表)

eg:以销售明细事实表与供应商维度关联。
R:二八法则会导致订单集中在部分供应商上,因此在处理数据时容易加剧数据倾斜
S:直接使用mapjoin

大表join大表优化

1、转换为mapjoin: 通过限制行和列的方式看看能否将大表转换为小表,从而进行mapjoin。

2、join时用case when语句
前提:倾斜的值时明确的而且数量很少,比如null值引起的倾斜。其核心是将这些引起倾斜的值随机分发到Reduce,其主要核心逻辑在于join时对这些特殊值concat随机数,从而达到分发的目的。

3、倍数B表,再取模join
1)通用方案:
建立一个numbers表,其值只有一列int行,比如从1到10(具体值可根据倾斜成都确定)。然后让其中一个表join number,放大该表10倍。因为group by一个字段会发生倾斜,那么在人公司增加一列进行group by, 再分发数据的时候就会变成之前的1/10

2)专用方案:
通用方案把B 表的每条数据都放大了相同的倍数,实际上这是不需要的,只需要把大卖家放大倍数即可。

步骤:
a)需要知道大卖家的名单,先建立一个临时表动态存放每日最新的大卖家,同时此表的大卖家要膨胀到预先设定的倍数(比如1000倍)
b)在A表和B表分别新建一个join列,其逻辑为:如果是大卖家,那么concat一个随机分配正整数(0到预定的倍数之间,本列是0-1000);如果不是,保持不变。

4、动态一分为二
终极解决方案就是动态一份为二,即对倾斜的键值和不倾斜的键值分开处理,不倾斜的正常join即可,倾斜的把他们找出来然后做mapjoin,最后做union all其他结果即可。

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

时间: 2024-10-01 13:10:13

hive sql 优化 - 2.0的相关文章

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

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

hive sql 优化

sql优化: ---------------------------------------------------------------- 数据倾斜的处理方式: -- Q: 活动数据 和 对应的维表进行关联,其中某个活动特别的大. A: 1) 给关联健加入一个随机的 1-10的值 2)将维度表 的关联健, 每个加上 1-10的值,将维度表扩充十倍. 3)然后将2个表进行join,从而来消除数据倾斜. -- 尽量不使用count distinct 1) 通过select子查询优化 2) 通过建

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 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,最后任务由原先

一次非常有意思的SQL优化经历:从30248.271s到0.001s

场景 我用的数据库是mysql5.6,下面简单的介绍下场景 课程表 create table Course( c_id int PRIMARY KEY, name varchar(10) ) 数据100条 学生表: create table Student( id int PRIMARY KEY, name varchar(10) ) 数据70000条 学生成绩表SC CREATE table SC( sc_id int PRIMARY KEY, s_id int, c_id int, scor

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 SQL的编译过程

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