三种文件格式简单介绍

Parquet 

     Parquet的设计方案，整体来看，基本照搬了Dremel中对嵌套数据结构的打平和重构算法，通过高效的数据打平和重建算法，实现按列存储（列组），进而对列数据引入更具针对性的编码和压缩方案，来降低存储代价，提升计算性能。想要了解这一算法逻辑的，可以看Dremel的论文：Dremel: Interactive Analysis of WebScaleDatasets。

ORC

     ORC文件格式的一些基础思想和Parquet很像，也是先按行水平切割，在按列垂直切割，针对不同的列，采用特定的编码格式，最后再进一步对编码后的数据进行压缩。支持的编码格式（游程，字典，增量，bit），压缩格式（zlib，snappy，LZO等等）也基本一致。

RC File

      RC File的格式，就简单很多了，基本除了先水平切Row，再垂直切Column以外，就剩下每个行组的Metadata里维护了行组的纪录数和每个column及每个Column纪录的长度，除此之外就没有太多别的黑科技了。编码方面Metadata使用RLE编码，Column Data使用Gzip等压缩格式（取决于写入方，比如MR程序）。

性能比较

      需要注意的是，具体性能数据取决于集群各种参数配置，具体数据格式内容等因素影响，所以绝对值大小并没有实际意义，比例大小的绝对值也不见得完全有代表性，比例的正负趋势才是基本可以参考的，另外时间有限，部分测试还有一些存疑问题尚未验证

      首先是压缩率和写性能，从上表可以看到采用不同的压缩格式，不同的压缩级别，对应不同数据类型，其实结论并不是简单一致的

      基本上，当前版本情况下，对于String类型比重大的数据，RC文件的尺寸，最佳表现要优于ORC的默认格式（ZLIB， SPEED），但是差距不大（3-5%左右），而对于存int bigint等类型的数据，ORC文件表现优于RC文件是比较一致的

      再分析理解一下，可以认为，ORC的编码（Encoding）优势，使得在同等条件下，结果文件尺寸大小要优于RC（30%～100%），而对于复杂String类型比重大的数据，RC文件由于LZ4压缩算法比ZLIB 低压缩率设置下的压缩率的优势，最终结果数据RC＋LZ4在CPU耗时略优的情况下，压缩率也略优。 ORC＋Zlib可以通过更高压缩率反转尺寸优势，但是CPU耗时就大大增加了。当前hive 1.2.1版本集成的ORC文件格式（0.12+一些改进）还不支持LZ4压缩格式（独立的ORC 1.2.2版本支持），可以想见，一旦集成了，同等条件下，ORC＋LZ4的表现应该是最优的。

       而Parquet这边，压缩率方面看起来和ORC也没有很明显差距，小幅度的区别的原因应该还是具体Encoding和compress算法的区别。但是CPU耗时方面，明显高出RC和ORC，应该是列打散算法的消耗造成的，也不排除目前Parquet对Dremel算法的应用还有优化的空间。

下面的数据测试读取性能，RC-LZ4 v.s. ORC-ZLIB SPEED

       可以看到第一例case中，ORC格式由于column data统计数据的存在，在数据过滤方面可以更好的使用Filter Push down技术，所以性能要明显由于RC格式（数据量100倍）。 无条件count这种，很明显，ORC大概能做到只需要检索原始数据500-2000分之一的数据量，RC大概是十五分之一左右（当然，这取决于表的字段数，RC文件的加速来源于分列存储，ORC格式的加速来源于meta统计信息里Count信息的存在）

      而第二例有条件过滤计数case中，ORC还是优于RC，不过我们的数据集case中，检索数据量的大小差异大概只有三倍，大致可以认为是meta统计信息中范围信息起到的过滤作用。 不过，很奇怪的是，理论上ORC文件中添加了Bloom Filter以后，应该可以更好的加速过滤检索，但实际效果并没有见到，还需要再验证，是否是我的测试方法或者测试集又问题，还是当前版本还有Bug存在（1.2.1的版本之前BF这块都有bug，并不能发挥作用，但1.2.1 版本以后，jira上已经找不到这方面bug的报告了）

      CPU耗时方面，差异没有那么显著 50%，这也和这个case中，IO是瓶颈，MR任务数量多，平均执行时间短，启动耗时占比不能忽略等因素有关

      再看Parquet，还是同样的问题，CPU的耗时明显要偏高（尽管使用了比RC和ORC更快的Snappy压缩方式）