Parquet与ORC:高性能列式存储 | 青训营笔记

Parquet与ORC:高性能列式存储

列存 、 行存

数据格式层概述

计算层：各种计算引擎

存储层：承载数据的持久化存储

数据格式层：定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件；从分层视角下的数据形态来看

从分层视角下的数据形态来看，计算引擎表现为Rows+Columns，存储层的数据形态为file和Blocks、格式层为File内部的数据布局 （Layout+Schema）

数据查询分析场景：OLTP vs. OLAP

OLTP：行式存储格式（行存）

每行的数据在文件上是连续存储的，读取整行数据效率高，单次IO顺序读即可。典型系统有关系型数据库、key-value数据库

OLAP：列式存储格式（列存）

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

总结：格式层定义了数据的布局，连接计算引擎和存储服务。OLTP和OLAP场景差异明显。业务场景决定了技术实现，行存适用于OLTP，列存适用于OLAP

Parquet

Parquet是大数据分析领域使用最广的列存格式；Spark推荐存储格式

Dremel数据模型

Protocol Buffer定义、支持可选和重复字段、支持嵌套类型（嵌套类型只保存叶子节点数据）

数据布局

RowGroup：每一个行组包含一定数量或者固定大小的行的集合

ColumnChunk：RowGroup中按照列切分成多个ColumnChunk

Page：ColumnChunk内部继续切分为Page，一般建议8KB大小。压缩和编码的基本单元。根据保存的数据类型分为Data Page、Dictionary Page、Index Page

Footer保存文件元信息：Schema、Config、Metadata（Rowgroup Meta、Column Meta）

编码Encoding

Plain直接存储原始数据

Run Length Encoding(RLE)适用于列基数不大，重复值较多的场景，例如：枚举、Boolean、固定的选项等。

Bit-Pack Encoding：配合RLE编码使用，让整形数字存储的更加紧凑

字典编码Dictionary Encoding多用于编码字符串，适用于列基数不大的场景，构建字典表，写入到Dictionary Page；把数据用字典index替换，然后用RLE编码

默认场景下parquet-mr会自动根据数据特征选择。在业务自定义场景下，可以使用org.apache.parquet.column.values.factory.ValuesWriteFactory

压缩compression

page完成encoding以后，进行压缩

支持多种压缩算法

snappy：压缩速度块，压缩比不高，适用于热数据

gzip：压缩速度慢，压缩比高，适用于冷数据

zstd：新引入的压缩算法，压缩比和gzip差不多，而且压缩速度比肩snappy

建议选择snappy或zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响

索引Index

和传统给的数据库相比，索引支持非常简陋

Min-Max Index：记录page内部column的min_value和max_value

Column Index：footer里的column metadata包含columnChunk的全部page的Min-Max value

Offset Index：记录page在文件中的offset和page的row range

bloom filter

• parquet.bloom.filter.enabled
• 对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index很难发挥作用
• 引入bloom filter加速过滤匹配判定
• 每个ColumnChunk的头部保存的bloom filter数据
• footer记录bloom filter的page offset

排序Ordering

• 类似于聚集索引的概念
• 排序帮助更好的过滤掉无关的RowGroup或者Page，对于少量数据seek很有帮助
• parquet Format支持sortingColumns
• parquet Library目前没有支持
• 依赖业务侧根据查询特征去保证顺序

过滤下推Predicate PushDown

• parquet mr库实现，实现高效的过滤机制
• 引擎侧传入filter expression
• parquet mr转换为具体column的条件匹配
• 查询footer里的column index，定位到具体的行号
• 返回有效的数据给引擎侧

spark集成-向量化读

• 向量化读是基于parquetFileFormat类实现的
• 向量化读开关spark.sql.parquet.ebableVectorizeReader
• 向量化读是主流大数据分析引擎的标准实践，可以极大的提高查询性能
• spark以batch的方式从parquet读取数据，下推的逻辑也会适配batch的方式

ORC详解

ORC 是大数据分析领域使用最广的列存格式之一，出自于hive项目

数据模型

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

数据布局

• 类似parquet
• rooter+stripe+column+page(row group) 结构
• encoding/compression/index支持上和parquet几乎一致

ACID特性简介

• 支持Hive Transactions实现，目前只有hive本身集成
• 类似delta lake/hudi/iceberg
• 基于Base+Delta+Compaction的设计

parquet 对比 ORC

• 从原理层面，最大的差别就是对于nestedType和复杂类型的处理上
• parquet的算法上要复杂很多，带来的cpu的开销比orc略大
• orc的算法相对简单，但是要读取更多数据
• 因此，这个差异对业务效果的影响，取决于实际的业务场景

列存演进

数仓中的列存

• clickhouse的mergeTree引擎也是基于列存构建的
• 默认情况下列按照column拆分
• 支持更加丰富的索引
• 湖仓一体的大趋势

存储侧下推

• 更多的下推工作下沉到存储服务侧
• 越接近数据，下推过滤的效率越高
• 例如AWS S3 Select功能

挑战：存储侧感知schema、计算生态的兼容和集成、column family