parquet文件格式——本质上是将多个rows作为一个chunk，同一个chunk里每一个单独的column使用列存储格式，这样获取某一row数据时候不需要跨机器获取

Parquet是Twitter贡献给开源社区的一个列数据存储格式，采用和Dremel相同的文件存储算法，支持树形结构存储和基于列的访问。Cloudera Impala也将使用Parquet作为底层的存储格式。在很多大数据的应用场景下面，比如电信行业，具有一定规则的数据，字段很多，但是每次查询仅仅针对其中少数的几个字段，这个时候列式存储是极佳的选择。
优势：
使用列式存储，一列的值都是同质的，从而带来了更高的压缩比；对于在hadoop集群上的大数据量来说，使用parquet可以节省大量空间；
可以提高IO性能；在查询的时候，只需要读取关心的列，而不需要将整条记录都读出来进行条件过滤；
由于列数据都是同类型的，从而可以对不同的列采用不同的编码方式来组织存储，提升读写效率，节省空间。
劣势：
不支持update操作（数据写成后不可删除和修改），不支持ACID等

Parquet文件将数据分为N列，M个RowGroup，每个RowGroup中按照Column进行文件存储。
每个Column中对列的数据话划分为多个Page，每个Page对数据内容进行压缩，默认推荐snappy算法。
Parquet文件写入完毕后会写入File MetaData，File MetaData包含了所有列元数据的起始位置，因此读取列数据时先从中找到感兴趣的列，然后再顺序读取。

4-byte magic number "PAR1"
<Column 1 Chunk 1 + Column Metadata>
<Column 2 Chunk 1 + Column Metadata>
...
<Column N Chunk 1 + Column Metadata>
<Column 1 Chunk 2 + Column Metadata>
<Column 2 Chunk 2 + Column Metadata>
...
<Column N Chunk 2 + Column Metadata>
...
<Column 1 Chunk M + Column Metadata>
<Column 2 Chunk M + Column Metadata>
...
<Column N Chunk M + Column Metadata>
File Metadata
4-byte length in bytes of file metadata
4-byte magic number "PAR1"

综合来看，ORCfiel和parquet本质上都是列上存储，大同小异。parquet主要特点是支持嵌套格式，ORCfile主要特点是strips中有轻量级的index data。所以这两种数据存储格式完全是可以相互借鉴融合的。