一、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里面也有该机制