一、parquet结构
Row Group
--Column Chunk：一列对应一个Column Chunk
– Page：压缩和编码的单元，parquet的 min/max 索引是针对于page的，存在了文件的页脚。以前的版本是存储Column Chunk和Page的索引，导致在决定是否跳过的时候，都必须读取Page的头文件来决定。
对比orc索引，感觉更优秀
数据编码和orc很像，就不细说了
二、parquet对于嵌套数据类型的处理
2.1 数据模型（数据定义时候用的）
parquet处理嵌套数据的思路来源于Google的Dremel系统（Dremel是Google研发的一个即席查询系统，因为Google处理的数据一般都是网页数据，会有很多嵌套类型，下文把这种数据存储方式简称为Dremel）。
parquet不需要复杂类型，如Map、List或Set，因为它们可以映射到repeated fields 和 groups的组合。
Dremel支持的数据类型：group 和 原子数据类型 (int, float, boolean, string)
Dremel根据数据的出现次数把数据分成了三种类型：
- required：出现且仅出现一次
- optional：出现0次或1次
- repeated：出现0次或多次
例：
2.2 存储（数据存储时候用的）
为了把数据可以组装到一起，定义两个存储级别：Repetition levels 和 Definition levels，如 Fig3
Repetition levels：表示值在字段路径中有几个重复。作用是为了解析非null字段。
如上述示例，Name.Language.Code路径中有两个重复字段，Name和Language，因此Code的重复级别范围是0～2（Name：1，Language：2），0表示新的记录开始。
如果从上往下扫描r1和r2的数据，'en-us’是一个新的Code，所以它的r level是0，'en’是在Language中重复，所以它的 r level是2，
'en-gb’是在Name中重复的，在这个Name中没有重复的Language，所以它的 r level是1。
Definition levels：表示有多少个字段可能未定义（因为它们是可选的或重复的）。作用是为了处理null。
如上述示例，DocId是required，所以它的d level是0；conntry的d level范围是1～3，如果有d level < 3，表示该country是null。
2.3 实现List和Map
2.3.1 List
//optional or required
<list-repetition> group <name> (LIST) {//必须是repeated，我认为是为了识别到下一个list，当很多行的list都存在了一列，怎么识别出来哪个元素是哪个列的repeated group list {//optional or required<element-repetition> <element-type> element;}
}
如上图，只有根节点才会存储数据，通过r的级别就可以组装出list
2.3.2 Map
//optional or required
<map-repetition> group <name> (MAP) {repeated group key_value {//只要map里有值，key就不能是nullrequired <key-type> key;//optional or required<value-repetition> <value-type> value;}
}
三、parquet VS orc
3.1 嵌套数据
parquet在存储嵌套数据上更有优势，orc适用于存储扁平化的数据。我理解orc存储的struct或者map都是一条记录只出现一次的，如果想是上述案例中的一条记录可能有多个Code，这种orc不太适合。
3.2 2013年的对比（参考自Orc作者的演讲PPT）
上图中，Parquet里写 “N” 的地方，在新版本都有实现了！
目前，Orc比Parquet多的一个特性是acid。
3.3 2016年的对比（分数据集对比）
3.3.1 NYC Taxi Data
**数据特点：**18列，22.7million行，类型有double，integer，dicimal，string，没有null
存储对比：
第一次存储对比结论：
-
不能用json！
-
parquet要比orc优秀。
orc作者不服，所以又按照列的类型进行了对比
按照存储类型对比：
按存储类型对比结论：
- 在double上parquet远优于orc，在timestamp上orc远优于parquet，因为parquet没有支持timestamp类型，而是用Logical type支持的。在其他字段的存储上都一样。
扫描全表对比：
扫描全表结论：
- 有时候压缩也不一定会导致变慢
3.3.2 Github Logs
**数据特点：**704列，10.5 million 行，有大量的 structure 和 null
存储对比：
存储对比结论：
- zlib最优秀
- Avro最优秀，因为行string被压缩了
扫描全表对比：
扫描全表对比结论：
- Parquet表现的很差，有一部分原因是用在了垃圾回收上
3.3.3 对于只取少数列
3.4 spark sql的对比
数据集介绍：
case class PageImpression(userId: Long,date: Timestamp,refererUrl: String
)
21.2 G avro
15.1 G orc
30.2 G parquet
注意date是timestamp类型的
case class Order(userId: Long,orderNo: String,date: Timestamp,productId: Int,productCode: String,productTitle: String,productPrice: Float,boughtPrice: Float,discountPercentageApplied: Byte
)
124.2 G avro
93.4 G orc
103.3 G parquet
3.4 结论
- 存储格式的对比还是要真正的在实践中检测，在使用的时候，不仅要考虑到它本身设计的优越性，还要考虑到垃圾回收、真实数据在存储格式上的性能这些意想不到的事情。
- hive适合orc，spark适合parquet，这个结论现在看来不一定所有情况都适用，还需要具体实验。从网上看到说这个原因是因为spark在parquet上只吃了Vectorization机制，hive在orc上支持了Vectorization机制，要讲一下这个。
- 在2016年，orc要优于parquet，orc作者建议除了在少数情况下用Avro结合snappy，其余情况用orc结合zlib就行了！
- 以上的结论都是orc作者在2016年发表演讲中提到的，现在是什么情况还不能确定，因为每个格式都在发展！
参考文献
Performance of Avro, Parquet, ORC with Spark Sql：https://www.linkedin.com/pulse/performance-avro-parquet-orc-spark-sql-konstantine-kougios
dremel-made-simple-with-parquet：https://blog.twitter.com/engineering/en_us/a/2013/dremel-made-simple-with-parquet
Difference Between ORC and Parquet：http://www.differencebetween.net/technology/difference-between-orc-and-parquet/
why parquet is best for spark, and hive best for hive：https://stackoverflow.com/questions/32373460/parquet-vs-orc-vs-orc-with-snappy
File Format Benchmark - Avro, JSON, ORC & Parquet：https://www.slideshare.net/HadoopSummit/file-format-benchmark-avro-json-orc-parquet
