orc parquet区别 spark_Scala+Spark教程：RC ORC Parquet 格式比较和性能测试

作者：刘旭晖 Raymond 转载请注明出处

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

为什么要比较这三者

为什么要比较，起因是为了提高Hadoop集群的存储和计算效率，尤其是离线Hive作业的效率，为什么比较的是这三者，是因为三者是目前Hive离线作业中正在大规模使用或可能大规模使用的三种主流的相对成熟的文件格式

这篇文章在ORC改进原理等方面说的比较客观，但是实际的benchmark比较数据，即使不说是有故意偏颇的嫌疑，至少也是不科学不客观的，特别是下面这张文件尺寸比较，带有很大的误导性。

这个测试的数据集，看起来用了TPC－DS的数据，貌似很专业的样子

但是首先，这里的测试方法明显的就不科学，压缩算法并不相同有什么好比的(Snappy侧重性能，Zlib侧重压缩率)？不知道作者对RCFile采用了什么压缩算法，但是Parquet＋Snappy，ORC＋Zlib，这种比较的基调就不公正(当然，这个问题，作者说是因为这是它们默认的压缩格式，但是科学严谨的来说，benchmark应该用统一的标准来衡量)

其次，套多数hive作业任务的的场景，TPC－DS的数据特性和典型的Hive应用场景(至少我们这边的场景)里的数据看起来并不一致。RC File的压缩还不到15%，这压缩率明显不是Hive离线处理数据场景和压缩算法下RCFile的典型表现

三种文件格式简单介绍

Parquet

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

从文件结构上来看，如下图所示：

基本上就是一个文件由多个列组组成，数据先按列组(rowgroup)分段(也就是先做行切割)，然后在列组内部对每个列的数据分列连续存储(columnchunk)(也就第二步做列切割)&#