HIve之ORC与Parquet_hive orc parquet

Orc与parquet的区别

ORC列式存储

但支持的压缩格式有限，Orc表支持None、Zlib、Snappy压缩，默认支持Zlib压缩。但这3种压缩格式不支持切分，所以适合单个文件不是特别大的场景。使用Zlib压缩率高，但效率差一些，使用Snappy效率高，但压缩率低。

Parquet表支持Uncompress、Snappy、Gzip、lzo压缩，默认不压缩Uncompressed。其中Lzo压缩是支持切分的，所以在表的单个文件较大的场景会选择Lzo格式。Gzip方式压缩率高，效率低；而Snappy、Lzo效率高，压缩率低。

全局压缩配置：

除了在建表时手动指定Orc、Parquet表的压缩格式的属性之外，也可以在执行建表语句前，使用set命令指定

--设置parquet表的压缩格式为SNAPPY
set parquet.compression=SNAPPY;
--设置orc表的压缩格式为SNAPPY
set orc.compress=SNAPPY
1
2
3
4

当然了，这也意味着你可以将参数直接全局配置到hive-site.xml文件种，来规定表的的压缩格式。

• 条带（Stripe）：ORC文件存储数据的地方，每个Stripe一般为HDFS的块大小（包含以下三个部分）
  1. index data：保存了所在条带的一些统计信息，以及数据在stripe种的位置索引信息
  2. row data：数据存储的地方，由多个行组构成，每10000行构成一个行组，数据以stream的形式进行存储
  3. stripe footer：保存数据所在的文件目录
• 文件标注（file footer）：包含了文件种stripe的列表，每个stripe的行数，以及每个列的数据类型。它还包括每个列的数据类型。它还包括每个列的最小值、最大值、行计数、求和等聚合信息。
• postscript：含有压缩参数和压缩大小相关的信息。

所以其实发现，ORC提供了3级索引，文件级、条带级、行组级，所以在查询的时候，利用这些索引可以规避大部分不满足查询条件的文件和数据块。

但注意，ORC中所有数据的描述信息都是和存储的数据放在一起的，并没有借助外部的数据库。

• 特别注意，orc格式的表还支持事务ACID,但是支持事务的表必须是分桶表（因为Hive事务的实现主要依赖于表分桶的存储格式，如果表没有分桶，那么表底下的文件就会很散乱，hive的事务机制无法有效的读取），所以适用于更新大批量的数据，不建议用事务频繁的更新小批量的数据。

Parquet列式存储

既然ORC都那么高效了，那为什么还有parquet，那是因为**Parquet为为了使hadoop生态系统中的任何项目都可以使用压缩的，高效的列式数据表示形式，**它支持压缩格式：Snappy、Gzip、Lzo

Parquet文件是以二进制方式存储的，所以不可以直接读取，和ORC一样，文件的元数据和数据一起存储，所以Parquet格式文件自解析的。

1. 行组（row Group）：每一个行组包含一定的行数，在一个HDFS文件中至少存储一个行组，类似于orc的stripe的概念。
2. 列块（Column Chunk）：在一个行组中每一列保存在一个列块中，行组中的所有列连续的存储在这个行组文件中。一个列块中的值都是相同类型的，不同的列块可能使用不同的算法进行压缩。
3. 页（Page）：每一个列块划分为多个页，一个页是最小的编码的单位，在同一个列块的不同页可能使用不同的编码方式。

在hive的性能比较中，同样的数据，进行sql查询，发现使用ORC读取的行远小于Parquet，所以使用ORC作为存储，可以借助元数据过滤掉更多不必要的数据，查询时需要的集群资源比Parquet少，所以ORC在存储方面看起来还是更胜一筹

选择Parquet的生产原因

因为Hive的sql会转化为MR任务，如果该文件使用ORC作为存储，Snappy压缩的，因为Snappy不支持文件分割操作，所以压缩文件只会被一个任务所读取，如果压缩文件很大，那么处理该文件的Map需要花费的时间会多余普通文件Map时间，这就是常说的Map读取文件的数据倾斜。

那么为了避免这种情况的发生，就需要在数据压缩的时候采用bzip2和lzo等支持文件分割的压缩算法。但恰当ORC不支持刚说的压缩方式，所以这也就成为大家在可能遇到大文件的情况下不选择ORC的原因，避免数据倾斜。

的压缩算法。但恰当ORC不支持刚说的压缩方式，所以这也就成为大家在可能遇到大文件的情况下不选择ORC的原因，避免数据倾斜。

所以在实际生产中，使用Parquet存储，lzo压缩的方式更为常见，这种情况下可以避免由于读取不可分割大文件引发的数据倾斜。但是，如果数据量并不大（预测不会有超大文件，若干G以上）的情况下，使用ORC存储，snappy压缩效率还是非常好的。