hive降io之压缩和分布式缓存

有三种压缩算法

gzip

lzo

snappy

第一种压缩后文件是最小的，snappy是最大的，但是压缩效率也就是压缩速度和解压速度，snappy是最好的

企业中一般用后两种方式

曾经用过lzo压缩，常导致个别老机器down机

cdh4集成了snappy

snappy的前身是zippy。虽然只是一个数据压缩库，它却被coogle用于许多内部项目，其中就包括Bigtable，map reduce，roc。google宣称它在这个库本身及其算法做了数据处理速度上的优化，作为代价，并没有考虑输出大小以及和其他类型工具兼容性问题，snappy特地为64位x86处理器做了优化，在单个intel core i7处理器内核上能够达到至少每秒250mb的压缩速度和每秒500mb的解压速度

如果允许损失一些压缩率的话，那么可以达到更高的压缩速度，虽然生成压缩文件可能会比其他库的要大些，但是相比其他压缩库，snappy能够在特定压缩率下拥有惊人的压缩速度。“压缩普通文本文件的sudu是其他库的1.5-1.7倍，html能达到2-4倍，但对于jpeg，png以及其他的已压缩的数据，压缩速率不会有明显改善。

分布式缓存：

共用20多个jar文件

jar文件被上传上万次，分发达上万次（百g级）

hadoop jar 引用：

hadoop jar -libjars aa.jar bb.jar ...

jar包会上传到hfs，然后分发到每个datanode

如何使这些jar包在hdfs上进行缓存，只需上传和分发一次，所有作业共享，从而减少不必要的上传和分发？

mr作业的分布式缓存（hadoop distributed cache的使用）

Configuration conf = new Configuration()

DistributedCache.createSymlink(conf)

DistributedCache.addCacheFile(new URI("/user/bi/input/testFile#testFile"),conf);

//可以用testfile替代前面的文件

Job job = new Job(conf)

//DistributedCache的操作一定要放在job的初始化之前，否则会报出文件找不到的异常

在map端打开：

FileReader fr = new FileReader("testFile");

hive实现分布式缓存：

hive作业的cli里面有个命令：add jar...

add jar /opt/software/lib/UDF.jar //这个动作已经是上传到hdfs上的缓存里边了，同时已经分发到每个节点上了

create temporary function getDate as 'com.test.GetDate';

天天写add jar很烦，所以用下面方式：

通过设置hive的配置文件hive-site.xml加入，就是自动把jar包加载进去，用的时候就自动找到com.test.GetDate这个类

<property>

<name>hive.aux.jars.path</name>

<value>file:///opt/software/lib/UDF.jar</value>

</property>

snappy压缩的优势：可以压缩pb级别数据量，有c++版本，java版本。