hive：存储格式和压缩算法

存储格式(hive自带的存储格式)

a	b
a1	b1
a2	b2
a3	b3

什么是按行存储？

a1b1a2b2a3b3

什么是按列存储？

a1a2a3b1b2b3

两者存储的形式不同，造成了不用的应用场景。行存储更费空间，而且如果查询一整行数据的情况多的时候，因为按行存储，整行的元素都在附近，读取效率就更高。反之，如果查询的只是几个字段，按列效率会更高，而且按列存储更容易压缩。

存储格式	存储方式	特点
TextFile	行式存储	压缩的TextFile无法分割和合并, 查询的效率最低,可以直接存储，加载数据的速度最快
SequenceFile	行式存储	压缩的文件可以分割和合并 查询效率高，需要通过text文件转化来加载
ORCFile(RCFile的改良版)	按行分块，按列存储	压缩快、解压缩快，查询效率高(因为有索引)，可分割
Parquet	列式存储	各种指标相对比ORCFile低一些，但是支持Impala查询引擎

实测同一份数据:

存储格式	存储大小（MB）	查询速度(S) SELECT count(*) from table GROUP BY action;
TextFile	109.78	24.172
Parquet	42.76	22.199
ORC(none)	20.78	22.193

这个none后面说压缩的就明白什么意思了

不难看出，在任何方面orc的性能都优于其它两种常用文本格式。

ORC

The *Optimized Row Columnar* ([ORC](https://orc.apache.org/)) file format provides a highly efficient way to store Hive data. It was designed to overcome limitations of the other Hive file formats. Using ORC files improves performance when Hive is reading, writing, and processing data.

翻译:ORC是hive中一种高效的存储数据方式。它被设计去克服其它hive文本格式的局限性。使用ORC可以为Hive的读写提供更好的表现。

如果你自己亲手尝试，创建三个表，分别是text、parquet、orc。假设text的大小和我一样你会发现你和我的数据会存在一定偏差。偏差会在orc这里，你的orc会比我的orc更小。

这是因为orc默认是采取了压缩算法的。

压缩

key	default	notes
orc.compress	ZLIB	high level compression (one of NONE, ZLIB, SNAPPY)
orc.create.index	true	whether to create row indexes

orc默认采取的是zlib的压缩方式(支持的还有snappy压缩或者none不压缩)。而zlib的压缩比很高，所以往往默认的orc文件格式的文件会非常小。但是往往合适的才是最好的，并不是文件最小就最好。

为什么要压缩？

hive中，越大的文件代表着越大的I/O传输和内存开销，而往往很多任务的速度就取决与I/O和内存。而压缩能缓解这个开销，虽然压缩和解压缩会带来CPU的额外开销，但是相对来说带来的能减少I/O和内存压力的好处是更巨大的，能更好的提升hive的性能。当然，如果你当前执行的Job更需要的是CPU资源，那应该放弃压缩。所以怎么取舍还是看实际的业务场景。

压缩形式

我们知道，hive上所有的数据落地，都必须经过MR的过程。如果需要，我们不仅可以对最终落地的文件压缩(最终压缩)，也可以对MR的shuffle阶段的数据进行压缩(中间压缩)。

• 最终压缩常用压缩方式

  # 设置方式
  set hive.exec.compress.output=true;
  set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;
  

  • zlib
  • Gzip(2.7.3的hadoop已经不支持了)
  • bzip2
  • lz4

• 中间压缩常用压缩方式

  # 设置方式
  set hive.exec.compress.intermediate=true
  set hive.intermediate.compression.code= org.apache.hadoop.io.compress.SnappyCodec
  

  • SnappyCodec(hadoop不自带，需要安装)
  • LzoCodec(hadoop不自带，需要安装)

普遍的压缩，要么偏重压缩比，要么偏重压缩时间。
一般落地的文件更考虑压缩比，即压缩后的文件越小越好。
而中间压缩一般考虑的是尽可能短时间的压缩完或者解压完，这也是snappy常用于中间压缩的原因。因为它压缩比很小但是压缩时间很短

由于对压缩的了解很少，各个压缩算法的对比没法给出准确的数据。需要请自行百度。

压缩方式的取舍

• 如果选择ORC，其只支持三种压缩方式none(不压缩) snappy zlib 而这两种压缩方式落地的文件都不能再切分。
  • 所有如果业务中需要用ORC的格式，但是落地的文件就算用高压缩比的Zlib依旧很大时，我们只能选择不做最终压缩，而选择ORC(none)+Snappy的方式
  • 如果非要压缩。可以选择将采集的力度变小，比如一个小时采集一次。是的压缩后的文件能维持到一个block块大小的情况下，效率会提升很多。
  • 如果不是非要使用ORC,这时候就能选择TextFile的格式，然后用高压缩比的压缩算法压缩文件再配合Snappy做中间数据压缩