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

小阿磊
513 阅读6分钟

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

大数据生态

Hive 元数据管理

Hudi Iceberg 等 狭义‘数据湖’

所有的数据集作业可以简化为

  • 从存储服务读取数据
  • 计算引擎解析和计算数据
  • 结果呈现

“如何高效从存储读取所需的数据” 是决定大数据计算作业性能的关键

学习目标

  • 理解列存的应用场景
  • 理解Parquet 和ORC的原理和区别
  • 了解列存格式中常见编码和压缩算法
  • 学会在大数据中选择合适的列存格式，直到具体的调优方向

本节课程主要分为四个方面：

  1. 列式存储和行式存储的区别

  2. Parquet 列存格式的原理详解

  3. ORC 列存格式的原理详解，以及和Parquet 的对比

  4. 列存格式的演进

列存 vs 行存

数据格式层概述

image.png

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

严格意义上，并不是一个独立的层级，而是运行在计算层的一个Library

分层视角下的数据形态

image.png

  • 存储层：File Blocks
  • 格式层： File内部的数据布局（Layout + Schema）
  • 计算引擎：Rows + Columns

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

image.png

OLTP : 行式存储格式

image.png

  • 每行的数据在文件上是连续存储的

  • 读取证行数据效率高，单词IO顺序读即可

  • 典型系统

    • 关系型数据库： Mysql，Oracle
    • Key-Value数据库

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

image.png

  • 每列的数据在文件上是连续存储的

  • 同列的数据类型一致，压缩编码的效率更好

  • 在典型的 OLAP 型分析和存储系统中广泛应用，例如：

    • 大数据分析系统：Hive、Spark，数据湖分析
    • 数据仓库：ClickHouse，Greenplum，阿里云 MaxCompute

行存 vs 列存

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

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

Parquet原理详解

    1. Parquet简介
    1. Parquet的布局，数据的组织方式，索引支持，如何与计算引擎集成
    1. Parquet背后的数据编码原理

Parqueti简介

image.png

Parquet in Action -DDL

元数据的组织依赖于 Hive store

创建table时，都会在Hive中创建table

image.png

image.png

spark中显示

image.png

接下来介绍一下Parquet的数据模型

Dremel数据模型

image.png

  • Protocol Buffer 定义

  • 支持可选和重复字段

  • 支持嵌套类型

Dremel数据模型- Continued

image.png

image.png

嵌套类型只保存叶子结点数据

问题：由于列可能是Optional和Repeated，如何将列内的数据对用到逻辑视图中的Record中呢？

Parquet的数据布局

image.png

image.png

编码

常见编码码格式：

Plain直接存储原始数据

字典编码：将数据用index联系起来

image.png

image.png

默认场景下Parquet-mr 会自动根据数据特征选择

业务自定义

压缩 Compression

image.png

  • Page 完成 Encoding 以后，进行压缩

  • 支持多种压缩算法

    • snappy: 压缩速度快，压缩比不高，适用于热数据
    • gzip：压缩速度慢，压缩比高，适用于冷数据
    • zstd：新引入的压缩算法，压缩比和 gzip 差不多，而且压缩速度略低于 Snappy

压缩对比：

image.png

索引 Index

image.png

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

  • 主要依赖 Min-Max Index 和 排序 来加速查找

  • Page：记录 Column 的 min_value 和 max_value

  • Footer 里的 Column Metadata 包含 ColumnChunk 的全部 Page 的 Min-Max Value

  • 一般建议和排序配合使用效果最佳

  • 一个 Parquet 文件只能定义一组 Sort Column，类似聚集索引概念

索引 - Bloom Filter

image.png 通过三个哈希算法算出3个位置，将这些位置的值设为1，要判断一个数据是否存在，就用这三个哈希算法计算，看看算出来的3个位置的值是否都是1，是的话就认为该数据已经存在。

  • 适用场景

    • 对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index 很难发挥作用

  • 引入 Bloom Filter 加速过滤匹配判定

  • 每个 ColumnChunk 的头部保存 Bloom Filter 数据

  • Footer 记录 Bloom Filter 的 page offset

排序 Ordering

image.png

过滤下推 Predicate PushDown

image.png

  • parquet-mr 库实现，实现高效的过滤机制

  • 引擎侧传入 Filter Expression

  • parquet-mr 转换成具体 Column 的条件匹配

  • 查询 Footer 里的 Column Index，定位到具体的行号

  • 返回有效的数据给引擎侧

  • 优点：

    • 在格式层过滤掉大多数不相关的数据
    • 减少真实的读取数据量

Spark 集成 - 向量化读

image.png

  • 作为最通用的 Spark 数据格式

  • 主要实现在：ParquetFileFormat

  • 支持向量化读：spark.sql.parquet.enableVectorizedReader

  • 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能

  • Spark 以 Batch 的方式从 Parquet 读取数据，下推的逻辑也会适配 Batch 的方式

深入Dremel 数据模型 - Repetition Level

image.png

r：repetion level，该字段在Filed path上第几个重复字段出现

0标识新的Record

d：Definition Level，用来记录在fielis path中，有多少个字段是可以不存在（optional/repeated）而实际出现的

根据表中格式进行编码

深入Dremel 数据模型 - Re-Assebly

  • 根据全部或者部分列数据，重新构造Record

  • 构造FSM状态机

  • 根据同一个Column下一个记录的Reprtion Level决定继续的列

image.png

image.png

小结：

  • 数据模型：基于Dremel
  • 文件布局：Footer+ RowGroup + ColumnChunk + Page
  • Encodeing： Page粒度，Plain/RLE/Dictary
  • Compression: Snappy/Gzip/Zstd
  • Index:Cloumn Index
  • Predicate PushDown

ORC详解

ORC整体文件布局类似Praquet

image.png

image.png

思考NestedType的不同实现对IO有怎么样的影响？

image.png

ACID特征

image.png

ALIORC

ORC在阿里云计算平台广泛使用，主流产品MaxCompute+交互式

ALIORC-索引增强

image.png

ALIORC-小列聚合

image.png

ALIORC-异步预取

image.png

思考：

image.png

Parquet vs ORC 对比

  • 从原理层面，最大的差别就是对于 NestedType 和复杂类型处理上

  • Parquet 的算法上要复杂很多，带来的 CPU 的开销比 ORC 要略大

  • ORC 的算法上相对加单，但是要读取更多的数据

  • 因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景

性能对比 1

  • Parquet 在复杂 Schema 场景下的算法开销影响较大

  • 测试平台 Hive，Hive 上 ORC 更有优势

  • 2016年 image.png

image.png

性能对比 2

  • 在 Spark 场景下 Parquet 工作的更好；在 Hive 场景下，ORC 更好

image.png

image.png

ORC 小结

  • 数据模型，和Parquet的差异
  • ACID支持
  • Parquet对比和选择

列存发展

数仓中的列存

  • 典型的数仓，例如 ClickHouse 的 MergeTree 引擎也是基于列存构建的

    • 默认情况下列按照 Column 拆分成单独的文件，也支持单个文件形式

    • 支持更加丰富的索引，例如 Bitmap Index、Reverted Index、Data Skipping Index、Secondary Index 等

    • 湖仓一体的大趋势下，数仓和大数据数据湖技术和场景下趋于融合，大数据场景下的格式层会借鉴更多的数仓中的技术

image.png

存储侧下推

  • 更多的下推工作下沉到存储服务侧

  • 越接近数据，下推过滤的效率越高

  • 例如 AWS S3 Select 功能

image.png

Column Family 支持

image.png

总结

  • 列存的适用场景，和行存的区别
  • Parquet和ORC原理，以及对比和选择
  • 列存的演变

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

网址：juejin.cn/

avatar
文章
阅读
粉丝