有三种压缩算法
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版本。