《OD学hive》第六周20160731

一、hive的压缩

1. hadoop的压缩

1）为什么需要压缩

MapReduce的性能瓶颈：网络IO、磁盘IO

数据量：对于MapReduce的优化，最主要、根本就是要能够减少数据量

Combiner：减少跨网络传输的数据量

压缩：将数据量减少，但是需要消耗CPU计算功能

2）哪些地方可以压缩

（1）输入文件进行压缩

（2）map的输出进行压缩

（3）reduce的输出进行压缩

3）压缩方式

gzip，lzo，snappy，bzip2

10G -->128M

10G -->压缩gizp -->6G -->128M（无法切分）

map的输入文件如果是压缩的，最好选择一种支持split的压缩方式；如果选择不支持split的压缩方式，那么大文件将会由一个map进程进行处理。

如果要选择不支持split的压缩方式，那么解决办法：先将大文件分割成大小接近128M的小文件，然后对这些小文件进行单独压缩。

4）压缩方式选择原则

（1）压缩比率

（2）压缩解压速度

（3）是否支持split切分

综合压缩比率和压缩解压速度，更注重压缩解压速度。

常用压缩方式： SNAPPY，LZO

reduce端的输出：

（1）reduce端的输出结果，后面很少使用；使用压缩比率较高的方式

（2）迭代计算，使用压缩提升性能；

5）如何配置

配置map端输出压缩  mapreduce.map.output.compress=true

配置map端压缩算法  mapreduce.map.output.compress.codec=默认zlib，通常改为snappy

配置reduce端输出压缩    mapreduce.output.fileoutputforamt.compress=true

mapreduce.output.fileoutputforamt.compress.type=NONE,RECORD or BLOCK

配置reduce端压缩算法 mapreduce.output.fileoutputforamt.compress.codec=默认zlib

6）hdoop参数配置查找：

（1）官网

（2）*-default.xml

（3）hive

启动hive，启用hadoop历史服务器进程，运行一个mapreduce的sql查询，到8088页面，点击job的【history】--->左边栏位的

7）压缩配置临时生效

bin/hadoop jara abc.jar wordcount -Dmapreduce.map.output.compress=true -D mapreduce.output.fileoutputforamt.compress=压缩算法类

2. hive的压缩

hive.exec.compress.intermediate设为true

SQL翻译成多个mapreduce的话，hive.exec.compress.intermediate不仅仅控制MapReduce中map的输出结果压缩，也控制着job之间的输出输入压缩

set hive.exec.compress.intermediate=true

二、hive的文件格式

1. 存储格式

create table

stored as textfile;

hive一般以文本格式来加载源数据，因为源数据本身就是文本格式。

统计分析过程，采用其他优化的文件格式。

1）以行格式存储文件

textfile

sequenceFile 二进制序列化文件

2）以列式格式存储文件

rcfile

orfile

parquet: hive/spark/impala

2. 案例实战

淘宝日志

在企业中（优化手段）

orc + snappy

parquete + snappy : spark天生支持parquet

UDF

压缩和文件格式相结合

对于MapReduce、Hive优化，可以将压力从磁盘IO、网络IO转移到CPU上。

三、日志数据的处理

某培训机构日志分析案例：

大数据，H5，PHP

Nginx服务器 --> web服务器

(nginx服务器安装)

淘宝 nginx -> 升级成tengine版本

正则表达式： http://wpjam.qiniudn.com/tool/regexpal/

在分析过程中，根据业务需求所需要的字段，拆解出小表。

大表拆分成小表

hive jdbc ： mvnrepository.com

UDF/UDTF/UDAF

四、hive的优化方案

1. hive的性能下降

1）本质：MapReduce

map个数 reduce个数

map输出结果数据传输到reduce：数据量、数据倾斜

2）sql层面

group by：

order by：全局排序，只会有一个reduce

join

3）整体架构

服务器资源

4G->8G

2. 优化措施

1）不转成mapreduce任务

（1）minimal：

select * from where （分区表）

fetch task：抓取任务，直接hdfs相关目录下读取文件内容

（2）more：

select clolumnname from tablename where xxx limit xx;

2）mapreduce的运行模式

本地模式、伪分布式模式、分布式模式

少数据量，如果直接启动本地模式进行，对性能会有一定的提高。

3）并发执行

某些sql会转成多个MapReduce job

（1）集群资源匮乏，这时候就不要并发执行

（2）集群空闲，可以通过并发执行提供性能

4）join优化

能先进行过滤则先过滤再join

启动mapjoin优化：使用mapjoin是不需要再执行reduce

select /*+MAPJOIN(samlltablename)*/

5）group by优化

数据倾斜：

map或者reduce中，某个map或者reduce的执行时间比较长；

不可split的压缩方式来压缩输入文件 -->map端的数据倾斜。

reduce端的数据倾斜：

数据倾斜：自然的普遍现象。 2/8原理，80%的访问量/订单量，由20%的用户产生。

不可避免，无法规避。

group by：

（1）随机分配，key值打散到每个reduce进行一次group by，再进行另外一次group by，

hive.groupby.skewindata=true

（2）相同的key分配到同一个reduce再进行另外一次group by（汇总）

写sql进行减缓，日志分析里面null值往往是造成数据清洗额的原因。

user_id很多是null值，这时使用user_id作为join的on key字段，就很容易造成数据倾斜。

解决方案：

user_id为Null，使用case when then else end函数，将null先转成一个随机值（不可重复）

6）分区表、大表拆小表、桶表

7）压缩、文件格式

8）JVM重用

前提条件：job数量多，每个job处理的数据量少

hive sql 转成mapreduce job是多个，

启动、停止mapreduce的进程（map进程和reduce进程）也是需要消耗时间的，

当每个job处理的数据量并不是很大，这时候，就可以启用jvm重用措施。

默认是不重用

mapred.job.reuse.jvm.num.tasks=1

可以先使用explain sql查看一下sql执行计划，再去调整

mapreduce任务是进程级别的任务

spark任务是线程级别

9）multi insert

from tablename

insert overwrite table newtable1

select *

from tablename

insert overwrite table newtable2

select * where clause1

from tablename

insert overwrite table newtable2

select * where clause2

10）推测执行

对于某个map/reduce，当map/reduce出现延迟现象，推测执行机制会从集群中另外找台比较空闲的服务器，重新执行该map/reduce，

此时会有两个相同的map/reduce(处理的数据相同)运行，

最终的结果以最先执行结束的map/reduce为准，另一个没有执行完的map/reduce会被杀掉。

spark里面也有该机制