Parquet与ORC | 青训营笔记

这是我参与「第四届青训营」笔记创作活动的的第14天

前几节课我们学习了各种大数据计算引擎，从传统的批式处理引擎spark、hive到流批一体的Flink再到OLAP的处理场景，也学习了传统的大数据存储生态HDFS,还有hudi、icebreg等狭义数据湖，而从存储到读取，从计算到结果呈现，所有的大数据作业简单来说都可以简化，“如何高效从存储读取所需的数据” 是决定大数据计算作业性能的关键因素

列存和行存

广义的数据查询分析服务一般是分为计算层、存储层、数据格式层，三层的各种功能分别为：

计算层：各种计算引擎
存储层：承载数据的持久化存储
数据格式层：定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件

而在分层视角下，存储层的数据形态为file和Blocks、格式层为File内部的数据布局 （Layout+Schema） ，计算引擎为ROWS和Columns

我们在日常处理数据业务时的两种数据查询分析场景OLTP和OLAP，两者之间的对比如下

OLTP运用的是行式存储格式（行存），每行的数据在文件上是连续存储的，读取整行数据效率高，单次IO顺序读即可，像我们的MySQL和Oracle这样的key-value数据库就是这样的

而OLAP是列式存储格式（列存），即每列的数据在文件上式连续存储的，读取整列的效率较高，同列的数据类型一致，压缩编码的效率更好，一般的大数据分析系统例如SQL-on-Hadoop，数据湖分析等或者ClickHouse等数据仓库就是这种格式

格式层定义了数据的布局，连接计算引擎和存储服务

OLTP和OLAP场景化差异明显

业务场景决定了技术实现，行存适用于OLTP，列存适用于OLAP

Parquet原理详解

Parquet是面向分析型业务的列式存储格式，由Twitter和Cloudera合作开发，是一种与语言无关的列式存储文件类型，可以适配多种计算框架。

parquet的数据布局如下

RowGroup：每一行组包含一定数量或者固定大小的行的集合
ColumnChunk:RowGroup中按照列切分成多个ColumnChunk
Page:ColumnChunk内部继续切分成Page，一般建议8KB大小。压缩和编码的基本单元，根据保存的数据类型分为：Data Page、DictionaryPage，Index Page
Footer：保存文件的元信息

编码中Plain直接存储原始数据，而Run Length Encoding(RLE)适用于列基数不打，重复值较多的场景，例如：Boolean、枚举等，相对的字典编码Dictionary Encoding适用于列基数不打的场景，构造字典表，写入到Dictionary Page，然后把数据用字典Index替换，然后用RLE编码

ORC详解和对比

ORC的全称是(Optimized Record Columnar)，优化后的列式记录，ORC在RCFile的基础上进行了一定的改进,是大数据分析领域使用最广的列存格式之一

ORC会给包括根节点在内的中间节点都创建一个Column，如下图，嵌套类型或者集合类型支持和Parquet差别较大，optional和repeated字段依赖父节点记录额信息来重新Assembly数据

Parquet vs ORC

从原理层面，最大的差别就是对于NestedType和复杂类型处理上，Parquet的算法上要复杂很多，带来的CPU的开销比ORC要略大，ORC的算法上相对简单，但是要读取更多的数据，因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景

从最近的版本来看，Parquet和ORC在性能上没有非常明显的差距和短板，
性能上很多情况下依赖于数据集和测试环境，不能迷信benchmark结果
根据实际业务做充分的测试调优
Spark生态下Parquet比较普遍，Hive生态下ORC有原生支持

整体上SPark比Hive更加有优势，所以大部分情况下，Parquet可能是个更好的选择