parquet

stable_阿甘

已于 2023-10-28 21:58:46 修改

阅读量795

点赞数

分类专栏： Hadoop 文章标签：大数据 parquet

于 2023-01-15 09:08:17 首次发布

本文链接：https://blog.youkuaiyun.com/stable_zl/article/details/128691676

版权

Hadoop 专栏收录该内容

15 篇文章

订阅专栏

一、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，比如country 的d level = 2，代表Name.Language下面没有country，如果d level 是1，代表Name下面没有Language，如果是0，代表没有Name

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就不能是null
    required <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年发表演讲中提到的，现在是什么情况还不能确定，因为每个格式都在发展！