- 浏览: 306489 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (165)
- hadoop (47)
- linux (11)
- nutch (7)
- hbase (7)
- solr (4)
- zookeeper (4)
- J2EE (1)
- jquery (3)
- java (17)
- mysql (14)
- perl (2)
- compass (4)
- suse (2)
- memcache (1)
- as (1)
- roller (1)
- web (7)
- MongoDB (8)
- struts2 (3)
- lucene (2)
- 算法 (4)
- 中文分词 (3)
- hive (17)
- noIT (1)
- 中间件 (2)
- maven (2)
- sd (0)
- php (2)
- asdf (0)
- kerberos 安装 (1)
- git (1)
- osgi (1)
- impala (1)
- book (1)
- python 安装 科学计算包 (1)
最新评论
-
dandongsoft:
你写的不好用啊
solr 同义词搜索 -
黎明lm:
meifangzi 写道楼主真厉害 都分析源码了 用了很久. ...
hadoop 源码分析(二) jobClient 通过RPC 代理提交作业到JobTracker -
meifangzi:
楼主真厉害 都分析源码了
hadoop 源码分析(二) jobClient 通过RPC 代理提交作业到JobTracker -
zhdkn:
顶一个,最近也在学习设计模式,发现一个问题,如果老是看别人的博 ...
Java观察者模式(Observer)详解及应用 -
lvwenwen:
木南飘香 写道
高并发网站的架构
Hive 数据倾斜总结
转载:http://www.tbdata.org/archives/2109
几个比较特殊的点都提到了,大家可以作为参考。
在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均值能代表的价值降低。Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后,总结如下。
1数据倾斜的原因
1.1操作:
关键词
情形
后果
Join
其中一个表较小,
但是key集中
分发到某一个或几个Reduce上的数据远高于平均值
大表与大表,但是分桶的判断字段0值或空值过多
这些空值都由一个reduce处理,灰常慢
group by
group by 维度过小,
某值的数量过多
处理某值的reduce灰常耗时
Count Distinct
某特殊值过多
处理此特殊值的reduce耗时
1.2原因:
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
1.3表现:
任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
单一reduce的记录数与平均记录数差异过大,通常可能达到3倍甚至更多。 最长时长远大于平均时长。
2数据倾斜的解决方案
2.1参数调节:
hive.map.aggr = true
Map 端部分聚合,相当于Combiner
hive.groupby.skewindata=true
有数据倾斜的时候进行负载均衡,当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
2.2 SQL语句调节:
如何Join:
关于驱动表的选取,选用join key分布最均匀的表作为驱动表
做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。
大小表Join:
使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.
大表Join大表:
把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
count distinct大量相同特殊值
count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。
group by维度过小:
采用sum() group by的方式来替换count(distinct)完成计算。
特殊情况特殊处理:
在业务逻辑优化效果的不大情况下,有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。
3典型的业务场景
3.1空值产生的数据倾斜
场景:如日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和 用户表中的user_id 关联,会碰到数据倾斜的问题。
解决方法1: user_id为空的不参与关联(红色字体为修改后)
select * from log a
join users b
on a.user_id is not null
and a.user_id = b.user_id
union all
select * from log a
where a.user_id is null;
解决方法2 :赋与空值分新的key值
select *
from log a
left outer join users b
on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;
结论:方法2比方法1效率更好,不但io少了,而且作业数也少了。解决方法1中 log读取两次,jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。
3.2不同数据类型关联产生数据倾斜
场景:用户表中user_id字段为int,log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时,默认的Hash操作会按int型的id来进行分配,这样会导致所有string类型id的记录都分配到一个Reducer中。
解决方法:把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
3.3小表不小不大,怎么用 map join 解决倾斜问题
使用 map join 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。 以下例子:
select * from log a
left outer join users b
on a.user_id = b.user_id;
users 表有 600w+ 的记录,把 users 分发到所有的 map 上也是个不小的开销,而且 map join 不支持这么大的小表。如果用普通的 join,又会碰到数据倾斜的问题。
解决方法:
select /*+mapjoin(x)*/* from log a
left outer join (
select /*+mapjoin(c)*/d.*
from ( select distinct user_id from log ) c
join users d
on c.user_id = d.user_id
) x
on a.user_id = b.user_id;
假如,log里user_id有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。
4总结
使map的输出数据更均匀的分布到reduce中去,是我们的最终目标。由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤:
1、采样log表,哪些user_id比较倾斜,得到一个结果表tmp1。由于对计算框架来说,所有的数据过来,他都是不知道数据分布情况的,所以采样是并不可少的。
2、数据的分布符合社会学统计规则,贫富不均。倾斜的key不会太多,就像一个社会的富人不多,奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。
3、map读入users和log,假如记录来自log,则检查user_id是否在tmp2里,如果是,输出到本地文件a,否则生成<user_id,value>的key,value对,假如记录来自member,生成<user_id,value>的key,value对,进入reduce阶段。
4、最终把a文件,把Stage3 reduce阶段输出的文件合并起写到hdfs。
如果确认业务需要这样倾斜的逻辑,考虑以下的优化方案:
1、对于join,在判断小表不大于1G的情况下,使用map join
2、对于group by或distinct,设定 hive.groupby.skewindata=true
3、尽量使用上述的SQL语句调节进行优化
转载:http://www.tbdata.org/archives/2109
几个比较特殊的点都提到了,大家可以作为参考。
在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均值能代表的价值降低。Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后,总结如下。
1数据倾斜的原因
1.1操作:
关键词
情形
后果
Join
其中一个表较小,
但是key集中
分发到某一个或几个Reduce上的数据远高于平均值
大表与大表,但是分桶的判断字段0值或空值过多
这些空值都由一个reduce处理,灰常慢
group by
group by 维度过小,
某值的数量过多
处理某值的reduce灰常耗时
Count Distinct
某特殊值过多
处理此特殊值的reduce耗时
1.2原因:
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
1.3表现:
任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
单一reduce的记录数与平均记录数差异过大,通常可能达到3倍甚至更多。 最长时长远大于平均时长。
2数据倾斜的解决方案
2.1参数调节:
hive.map.aggr = true
Map 端部分聚合,相当于Combiner
hive.groupby.skewindata=true
有数据倾斜的时候进行负载均衡,当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
2.2 SQL语句调节:
如何Join:
关于驱动表的选取,选用join key分布最均匀的表作为驱动表
做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。
大小表Join:
使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.
大表Join大表:
把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
count distinct大量相同特殊值
count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。
group by维度过小:
采用sum() group by的方式来替换count(distinct)完成计算。
特殊情况特殊处理:
在业务逻辑优化效果的不大情况下,有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。
3典型的业务场景
3.1空值产生的数据倾斜
场景:如日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和 用户表中的user_id 关联,会碰到数据倾斜的问题。
解决方法1: user_id为空的不参与关联(红色字体为修改后)
select * from log a
join users b
on a.user_id is not null
and a.user_id = b.user_id
union all
select * from log a
where a.user_id is null;
解决方法2 :赋与空值分新的key值
select *
from log a
left outer join users b
on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;
结论:方法2比方法1效率更好,不但io少了,而且作业数也少了。解决方法1中 log读取两次,jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。
3.2不同数据类型关联产生数据倾斜
场景:用户表中user_id字段为int,log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时,默认的Hash操作会按int型的id来进行分配,这样会导致所有string类型id的记录都分配到一个Reducer中。
解决方法:把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
3.3小表不小不大,怎么用 map join 解决倾斜问题
使用 map join 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。 以下例子:
select * from log a
left outer join users b
on a.user_id = b.user_id;
users 表有 600w+ 的记录,把 users 分发到所有的 map 上也是个不小的开销,而且 map join 不支持这么大的小表。如果用普通的 join,又会碰到数据倾斜的问题。
解决方法:
select /*+mapjoin(x)*/* from log a
left outer join (
select /*+mapjoin(c)*/d.*
from ( select distinct user_id from log ) c
join users d
on c.user_id = d.user_id
) x
on a.user_id = b.user_id;
假如,log里user_id有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。
4总结
使map的输出数据更均匀的分布到reduce中去,是我们的最终目标。由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤:
1、采样log表,哪些user_id比较倾斜,得到一个结果表tmp1。由于对计算框架来说,所有的数据过来,他都是不知道数据分布情况的,所以采样是并不可少的。
2、数据的分布符合社会学统计规则,贫富不均。倾斜的key不会太多,就像一个社会的富人不多,奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。
3、map读入users和log,假如记录来自log,则检查user_id是否在tmp2里,如果是,输出到本地文件a,否则生成<user_id,value>的key,value对,假如记录来自member,生成<user_id,value>的key,value对,进入reduce阶段。
4、最终把a文件,把Stage3 reduce阶段输出的文件合并起写到hdfs。
如果确认业务需要这样倾斜的逻辑,考虑以下的优化方案:
1、对于join,在判断小表不大于1G的情况下,使用map join
2、对于group by或distinct,设定 hive.groupby.skewindata=true
3、尽量使用上述的SQL语句调节进行优化
发表评论
-
博客地址变更
2013-08-16 10:29 1220all the guys of visiting the bl ... -
hive 复杂数据结构嵌套
2013-03-14 16:03 5051Hive hive 除了支持基本的数据结构 hive 复 ... -
hive topN 实现
2012-12-14 06:51 2008hive的topN实现 hive的topN实现方式有很多种, ... -
Hive与表操作有关的语句
2012-12-03 14:25 1440Hive与表操作有关的语句 1.创建表的语句: Create ... -
hive参数
2012-11-29 10:18 0第一部分:Hive 参数 hive ... -
hive中的LEFT SEMI JOIN
2012-11-28 14:06 2032hive中的LEFT SEMI JOIN LEFT S ... -
hive 自定义udf
2012-10-24 10:42 1378Hive的预定义UDF函数列表如下 abs(x) - ret ... -
hive Sort By/Order By/Cluster By/Distribute By
2012-10-22 16:51 1102hive Sort By/Order By/Cluster B ... -
hive的权限控制
2012-10-09 17:48 1658hive的权限控制 hiveserver 不支持 并发的访 ... -
hive 基本数据类型
2012-08-30 18:53 0同事整理的,大部分原文摘过来,有少量改动。 1. 基本数据类 ... -
hive cli 操作表分区
2012-08-10 14:04 1292hive表分区 必须在表定义时创建partition a、 ... -
hive中 array,map
2012-04-11 23:03 0关于map的操作说明: drop table table2; ... -
hive array数组
2012-04-11 22:58 0hive中的ARRAY类型array是hive中的数组类型 ... -
hive partitions 操作
2012-04-11 11:00 0必须在表定义时创建partition a、单分区建表语句:c ... -
hive 表分区使用
2012-04-09 14:59 0hive表分区 必须在表定义时创建partition ... -
hive执行作业时reduce任务个数设置为多少合适?
2012-04-05 18:05 1369Hive怎样决定reducer个数? Hadoop MapR ... -
JDBC 客户端 连接hive
2012-03-26 16:29 1342Hive的JDBC连接 博客分类: hive JDBCDer ... -
hive 操作语句
2012-02-13 14:13 1011https://cwiki.apache.org/conflu ... -
hive+hbase整合
2012-02-03 16:48 6114用hbase做数据库,但由于hbase没有类sql查询方式, ... -
使用MySQL作为Hive的Metastore
2012-02-01 17:56 2015使用MySQL作为Hive的Metastore 前提是成功 ...
相关推荐
总结了hive中数据处理发生的倾斜问题,不同的原因对应不同的解决方案,比较具体可实操的方法
大数据Hive数据倾斜、Hive-SQL优化 在大数据处理中,Hive是一个非常重要的工具,然而在实际应用中,数据倾斜和性能优化问题经常会出现。为了解决这些问题,我们需要了解Hive的性能调优、数据模型设计、数据倾斜判断...
【Hive原理】 Hive是基于Hadoop平台的数据仓库解决方案,它主要解决了在大数据场景下,业务人员和数据科学...通过理解其原理、掌握SQL语法、优化技巧和解决数据倾斜问题,可以在大数据环境中高效地进行数据分析工作。
Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化,针对MR全局的优化以及针对整个查询的优化。...
数据倾斜是 Hive 中一个非常重要的问题,影响着数据处理的速度和效率。数据倾斜将导致 Job 执行时间过长,容易堵塞集群。解决数据倾斜的方法有:合并小文件、增加 Map 数、增加 Reduce 数等。 三、 Join、MapJoin、...
- **手动分区**:通过对数据进行预处理,例如按照某个键进行分组,然后再加载到Hive表中,从而实现手动分区,减轻数据倾斜的影响。 通过上述方法,不仅可以提高Hive的查询性能,还能确保数据处理流程更加高效稳定。...
Hive性能优化是一个复杂的问题,它涉及到Hadoop的计算框架特性、数据倾斜问题、MapReduce作业初始化时间长、SUM、COUNT、MAX、MIN等UDAF函数的使用、COUNT(DISTINCT)函数的低效、数据分布不均、Job数多、MapReduce...
以下是对"Hive调优总结文档-hive tuning ppt"中可能涉及的多个知识点的详细阐述: 1. **元数据优化**: - **分区策略**:根据业务需求,合理设计分区字段,减少不必要的数据扫描,例如按日期、地区等进行分区。 -...
### 工作总结:Hive优化 在大数据处理领域,Hive作为一种常用的数据仓库工具,其性能优化一直是数据工程师关注的重点。本文将基于提供的“hive优化”文档内容,深入探讨Hive优化的关键策略与实践技巧。 #### 核心...
虚拟列可根据特定列值将数据分配到不同的桶中,而Skewed Join则处理数据倾斜问题,通过预处理将倾斜数据分散到多个分区或桶中。 3. **文件格式与数据压缩** 文件格式的选择(如TextFile、ORC、Parquet)对查询性能...
总结,Hive SQL是大数据分析的重要工具,通过理解其核心概念和特性,可以有效地管理和处理大规模数据,实现高效的数据查询和分析。这篇博客深入解析了Hive SQL的使用,是学习和提升Hive技能的良好参考资料。
2. 数据倾斜处理:数据倾斜会导致部分Reducer负载过高,影响整体性能。通过Skewed Join或者自定义Partitioner来解决数据倾斜问题。 3. 并行执行:利用Hive的并行执行特性,同时启动多个MapReduce任务,加快处理速度...
8. **数据倾斜与优化**:了解数据倾斜问题,这是大数据处理中的常见挑战,以及如何通过调整分区策略或使用动态分区来避免它。 9. **Hive与外部工具集成**:学习如何将Hive与其他大数据工具,如Pig、Spark、Impala等...
6. **数据倾斜**:Hive-0.8.1在处理大数据时可能会遇到数据倾斜问题,即某些分区或键值下的数据量远超其他,导致计算负载不均。用户可以通过自定义分区、分区裁剪或者使用动态分区重写等方法来缓解数据倾斜。 7. **...
良好的设计可以避免数据倾斜问题,平衡集群负载,同时还能提高数据检索的速度。 5. 通过队列更好地管理工作负荷 在Hadoop生态系统中,YARN(Yet Another Resource Negotiator)是资源管理的关键组件,它负责资源...
总结起来,《最强HiveSQL开发指南》全面涵盖了Hive的基本操作、查询语法、性能优化策略及实战经验,是学习和提升Hive技能的宝贵资源。通过深入学习和实践,读者可以更好地驾驭Hive,应对大数据环境下的各种挑战。
总结,Hive QL的高效使用依赖于理解Hadoop框架的特性和限制,以及对Hive数据模型和操作的理解。通过合理的数据分区、优化Job数量、处理数据倾斜、调整数据类型和操作,可以显著提升Hive查询的效率和性能。在实际应用...
- **数据倾斜**:当数据分布不均匀时,某些节点可能处理大量数据,导致作业运行缓慢。可以通过哈希分桶、预处理等方式改善数据分布。 - **缓存与本地化**:启用Hive的Tez或Spark执行引擎,它们有良好的缓存机制,...
3. **数据倾斜优化**: Hive允许用户通过重分区或定制化分区键来缓解数据倾斜问题。 4. **延迟物化视图**: Hive支持物化视图,预先计算好的结果可提高查询性能。 5. **UDF(用户自定义函数)**: 用户可以创建自己的...
总结,Hive和HBase的组合利用了它们各自的优势,Hive的SQL友好性和HBase的实时性,为大数据处理提供了一种有效的方法。在实际应用中,需要根据业务需求和数据特性,合理设计数据模型,优化查询性能,确保系统的稳定...