hadoop平台存储文件格式的概念及对比

最近在书写大数据基础组件的时候对hadoop平台的文件格式感觉到有些困惑，不知道各自的优缺点及如何使用。现特意总结一下：

hdfs支持哪些文件格式：

TEXTFILE：
textfile为默认格式，存储方式为行式存储，在检索时磁盘开销大 数据解析开销大，而对压缩的text文件 hive无法进行合并和拆分

SEQUENCEFILE：
二进制文件,以<key,value>的形式序列化到文件中,存储方式为行式存储，可以对文件进行分割和压缩，一般使用block压缩，使用Hadoop 的标准的Writable 接口实现序列化和反序列化,和hadoop api中的mapfile是相互兼容的。

RCFILE：
存储方式为数据按行分块，每块按照列存储的行列混合模式，具有压缩快，列存取快的特点。
在使用时，读记录尽量涉及到的block最少，这样读取需要的列只需要读取每个row group 的头部定义，具有明显速度优势。
读取全量数据的操作 性能可能比sequencefile没有明显的优势。

Orc：

Orc是从HIVE的原生格式RCFILE优化改进而来。

Parquet：

Parquet是Cloudera公司研发并开源的格式。

这两者都属于列存储格式，但Orc严格上应该算是行列混合存储，首先根据行组分割整个表，在每一个行组内进行按列存储。
Parquet文件和Orc文件都是是自解析的，文件中包括该文件的数据和元数据，Orc的元数据使用Protocol Buffers序列化。
两者都支持嵌套数据格式（struct\map\list），但策略不同：

• Parquet支持嵌套的数据模型，类似于Protocol Buffers，每一个数据模型的schema包含多个字段，每一个字段有三个属性：重复次数、数据类型和字段名。
• ORC原生是不支持嵌套数据格式的，而是通过对复杂数据类型特殊处理的方式实现嵌套格式的支持。

压缩：
两者都相比txt格式进行了数据压缩，相比而言，Orc的压缩比例更大，效果更好。

计算引擎支持：都支持spark、MR计算引擎。

查询引擎支持：Parquet被Spark SQL、Hive、Impala、Drill等支持，而Orc被Spark SQL、Presto、Hive支持，Orc不被Impala支持。

功能及性能对比：
使用TPC-DS数据集并且对它进行改造以生成宽表、嵌套和多层嵌套的数据。使用最常用的Hive作为SQL引擎进行测试
最终表现：
功能：

• ORC的压缩比更大，对存储空间的利用更好
• ORC可以一定程度上支持ACID操作，Parquet不可以
  性能：
• 数据导入 orc更快
• 聚合查询 orc更快
• 单表查询 orc快一点点点
• 带有复杂数据构成的表查询 （1层） orc更快
• 带有复杂数据构成的表查询 （3层） orc更快

结果分析
从上述测试结果来看，星状模型对于数据分析场景并不是很合适，多个表的join会大大拖慢查询速度，并且不能很好的利用列式存储带来的性能提升，在使用宽表的情况下，列式存储的性能提升明显，ORC文件格式在存储空间上要远优于Text格式，较之于PARQUET格式有一倍的存储空间提升，在导数据（insert into table select 这样的方式）方面ORC格式也要优于PARQUET，在最终的查询性能上可以看到，无论是无嵌套的扁平式宽表，或是一层嵌套表，还是多层嵌套的宽表，两者的查询性能相差不多，较之于Text格式有2到3倍左右的提升。
另外，扁平式的表结构要比嵌套式结构的查询性能有所提升，所以如果选择使用大宽表，则设计宽表的时候尽可能的将表设计的扁平化，减少嵌套数据。
通过测试对比，ORC文件存储格式无论是在空间存储、导数据速度还是查询速度上表现的都较好一些，并且ORC可以一定程度上支持ACID操作，社区的发展目前也是Hive中比较提倡使用的一种列式存储格式，另外，本次测试主要针对的是Hive引擎，所以不排除存在Hive与ORC的敏感度比PARQUET要高的可能性。Parquet更多的是在Impala环境下使用