优化点:从底向上
1)压缩
选型:不同场景(空间、解压速度、splitable)
好处:
2)Storage Format
行式 vs 列式(olap 90%+)
SQL on hadoop:
textfile、sequencefile
rcfile: 行+列
orc、parquet : bigdata
3)分区
4)SQL:数据倾斜
groupby | hive.map.aggr ===>true & hive.groupby.skewindata ===>true(把一个作业分成两个
第一个job:把map输出随机分到reduce,在每个reduce中做部分聚合
第二个job:把上一部的结果按照相同的key分到一个reduce上处理
)
join: 拆。 mapjoin/smbjoin sql改造
count(distinct xx)
window functions: row_num、first
topn domain+url domain top100 url
.... over partition by xxx order by ...
5)复杂+繁琐
6)order/sort/distribute/cluster by
7) hive作业
8)UDF整合到Hive源码 <== 体现修改的能力
9)执行计划
10)stage 美团有一篇文章
11)裁剪:字段裁剪、分区裁剪
12)ppd: predicate push down + 列式存储
参数:hive...ppd = true
13) 共享
14) metastore uml
15)推测执行:
a.code bug
b.数据倾斜
==>90%task跑完了,10%没跑完
如task100慢了,超过一定时间,他会把这个作业在其他节点重新启动一份,此时就有多个相同的作业,此时就有多个相同的作业,谁先跑完就用谁的结果。
好处:尽可能快地跑完task
坏处:资源消耗(用更多的资源换取时间的优化机制,如果集群资源非常匮乏,那么。。。)
hive默认是开启的
16)控制reduce数量(输出文件的数量)
reduce过多:输出文件数过多,很多小文件,开启/销毁jvm
reduce过少:耗时出现数据倾斜
如何设置reduce个数?
mapred.reduce.tasks
hadoop fs -du +路径==>通过文件大小计算出来 除以 每个reduce能够处理数据的大小
什么场景下只有一个reduce:order by
17)jvm重用:mr是进城级别,一个maptask和rtask都对应一个 jvm。想在一个jvm中运行多个task,mapred.job.reuse.jvm.num.tasks默认为1。修改他的值就行了。
18)优化中间结果集
多次查询同一张表同一分区,可以把前几次查询的结果创建成中间表,后面的查询直接查询这个中间表。
sparksql:
1)依赖hive:hql解析,metastore,serde
sql翻译成ast===>sqarksql接管(catalyst)
2)不依赖hive
发布版本:spark1.0
1)压缩
选型:不同场景(空间、解压速度、splitable)
好处:
2)Storage Format
行式 vs 列式(olap 90%+)
SQL on hadoop:
textfile、sequencefile
rcfile: 行+列
orc、parquet : bigdata
3)分区
4)SQL:数据倾斜
groupby | hive.map.aggr ===>true & hive.groupby.skewindata ===>true(把一个作业分成两个
第一个job:把map输出随机分到reduce,在每个reduce中做部分聚合
第二个job:把上一部的结果按照相同的key分到一个reduce上处理
)
join: 拆。 mapjoin/smbjoin sql改造
count(distinct xx)
window functions: row_num、first
topn domain+url domain top100 url
.... over partition by xxx order by ...
5)复杂+繁琐
6)order/sort/distribute/cluster by
7) hive作业
8)UDF整合到Hive源码 <== 体现修改的能力
9)执行计划
10)stage 美团有一篇文章
11)裁剪:字段裁剪、分区裁剪
12)ppd: predicate push down + 列式存储
参数:hive...ppd = true
13) 共享
14) metastore uml
15)推测执行:
a.code bug
b.数据倾斜
==>90%task跑完了,10%没跑完
如task100慢了,超过一定时间,他会把这个作业在其他节点重新启动一份,此时就有多个相同的作业,此时就有多个相同的作业,谁先跑完就用谁的结果。
好处:尽可能快地跑完task
坏处:资源消耗(用更多的资源换取时间的优化机制,如果集群资源非常匮乏,那么。。。)
hive默认是开启的
16)控制reduce数量(输出文件的数量)
reduce过多:输出文件数过多,很多小文件,开启/销毁jvm
reduce过少:耗时出现数据倾斜
如何设置reduce个数?
mapred.reduce.tasks
hadoop fs -du +路径==>通过文件大小计算出来 除以 每个reduce能够处理数据的大小
什么场景下只有一个reduce:order by
17)jvm重用:mr是进城级别,一个maptask和rtask都对应一个 jvm。想在一个jvm中运行多个task,mapred.job.reuse.jvm.num.tasks默认为1。修改他的值就行了。
18)优化中间结果集
多次查询同一张表同一分区,可以把前几次查询的结果创建成中间表,后面的查询直接查询这个中间表。
sparksql:
1)依赖hive:hql解析,metastore,serde
sql翻译成ast===>sqarksql接管(catalyst)
2)不依赖hive
发布版本:spark1.0