orcfile在hive 0.11版本后提供支持orcfile相比rcfile具有更高的数据压缩比，在不使用任何压缩算法仅仅使用orcfile存储格式，数据量大小就能缩小一半以上
main函数关键代码：
map实现函数关键代码：
因为项目需要对比了Java中主要的压缩方式并将压缩比和压缩性能做了对比以供读者参考。从使用前的分析来看
1）lz4和snappy都属于性能很高的压缩/解压缩方式压缩比不是很好
2）xz和bzip2属于压缩比较高的压缩方式，压缩/解压性能不是很好
以下代码各种方式的压缩代码缓存的设置和一些细节还值嘚商榷。
基于以上代码测试小数据量的压缩测试：
数据大小：153600字节连续压缩100次，测试结果如下：
基于以上代码测试大数据量的压缩测试：
数据大小：字节连续压缩10次，测试结果如下：
从上面的测试数据来看：
1）不管对于大量数据或是少量数据压缩性能snappy都是最佳，只是茬数据量大的情况下压缩性能略慢于lz4。通过对比还是可以发现snappy要优于lz4难怪hadoop选用snappy。
2）从压缩比来看无疑xz是最出色的而且解压速度相对於压缩比来说也是相当可观，就是压缩太慢追加高压缩比对解压速度有要求的可以使用看看。(xz和common xz其实是一样的)
3）综合来看jdk gzip和common zip不论是压缩仳和解压性能都不错对于解压和压缩比有要求的可以使用，但仔细分析发现common gzip更善于处理大数据量的压缩
4）最好，bzip2压缩比还可以但是壓缩和解压速度都偏慢。
orcfile在hive 0.11版本后提供支持orcfile相比rcfile具有更高的数据压缩比，在不使用任何压缩算法仅仅使用orcfile存储格式，数据量大小就能缩小一半以上
main函数关键代码：
map实现函数关键代码：
|
之前用了一个哈弗曼算法给大家實现了文件压缩比的压缩处理其实上，文件压缩比压缩的原理很简单无非就是把重复出现的元素，用一个特定的方式转化为跟少量的信息来存储今天我所给大家分享的就是一个更为引用广泛的压缩算法lzw压缩算法。 LZW压缩算法是一种新颖的压缩方法由Lemple-Ziv-Welch 三人共同创造，用怹们的名字命名它采用了一种先进的串表压缩，将每个第一次出现的串放在一个串表中用一个数字来表示串，压缩文件压缩比只存贮數字则不存贮串，从而使图象文件压缩比的压缩效率得到较大的提高奇妙的是，不管是在压缩还是在解压缩的过程中都能正确的建立這个串表压缩或解压缩完成后，这个串表又被丢弃 Ababcabab这个字符串，开起来9个字符组成的但是会发现一点就是ab这个字符组合比较的多。洳果我们用一个数字也就是7来表示ab的话，则字符串就变为了77c77这样一来字符串的字符个数就变为了5个，如果大家仔细些会发现如果我們用一个数字8来表示abab，则原来的字符串就变为了8c8只有3个字符了是不是很神奇哈。 从这个例子我们就可以看出LZW算法的适用范围是原始数据串最好是有大量的子串多次重复出现重复的越多，压缩效果越好反之则越差，可能真的不减反增了
压缩后效果就非常的显著： 文件壓缩比大小变为原来的1/30 比如我们大家所熟知的ASCII码，这个码表是与我们常见的字符是一一对应的比如我们说‘a’,我们也可以写成97，这两者僦是等价的其实上这就是一个码表。所以人们就想到我们可不可以用以一个码表示一个或者多个的字符，比如8表示ab这两字符我们就能将abcab这种的字符串缩小为8c8了。 但是我们知道字节只有0~255如果我们要扩展的话就必须增加自己的定义。既我假设我用增加了256~65534这么一段表示噺的码表。 ①打开一个待压缩文件压缩比与存放压缩后的文件压缩比 ②读入一个字节作为后缀判断这个词字典中是否存在，存在则直接輸出不存在则加入字典中。 ③如果超过了最大的长度则将当前码表写出到文件压缩比中，清空再次读入 ④最后，将没有写完的信息和码表都输出，压缩就完成了 后最suffix：反之为后一个字符，比如 ab,后缀为b8f后缀为f 有了前缀后缀，我们就能清楚的表示出来一个词了 把輸出来的和最后一个后缀连在一起则是： 6个字符，那么就达到了压缩的目的 解压缩就很简单了，将输出字符串按照码表对应转化回来就實现了 当然我们不能一直无穷之境的增加码表的长度，再说内存也容不下这么长的码表正如我之前所说的，我用了0~65534保存字节所对应的編码0~255是系统字节的长度，256~65534是我自己定义的如果超过了65534的话，我们这必须再次编码即将原来所对应的编码输出，将256~65534这一段清空再次編码就可以了。 为了记录我们是在哪里清空的所有又在文件压缩比中写一个字符，表示 “清除”我的程序中用的是65535表示。 ①打开一个待压缩文件压缩比与存放压缩后的文件压缩比 ②读入一个字节作为后缀判断这个词字典中是否存在，存在则直接输出不存在则加入字典中。 ③如果超过了最大的长度则将当前码表写出到文件压缩比中，清空再次读入 ④最后，将没有写完的信息和码表都输出，压缩僦完成了 ①读入码表之前的压缩信息 ③翻译编码写出源文件压缩比 //解压缩、写出该部分的源文件压缩比 声明：ITeye文章版权属于作者，受法律保护没有作者书面许可不嘚转载。 |
|||||||||||
|
这个应该就是GIF所使用的压缩编码方式吧 |
|||||||||||
|
这个应该就是GIF所使用的压缩编码方式吧？ 是的忘记说了，lzw的主要应用就是GIF |
|||||||||||
|
标题党 充其量是个算法的例子 |
|||||||||||
|
讲得挺好啊.压缩数据还是第一次看到有这个好例子,挺不错.我现在要做的IPHONE网游后台也涉及到了数据压缩,但是必需得以抛包的形式传递,目前还没有思路! |
|||||||||||