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

一只兔兔
329 阅读9分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 31 天

本节课程介绍： OLTP 与 OLAP 展开，重点介绍了列式存储和行式存储的基本原理和使用场景，帮助大家对 OLTP 和 OLAP 定位和原理树立更为清晰的认知。介绍了 Parquet 相关知识，重点讲述了什么是 Parquet 、Parquet 的文件的布局、数据存储中的数据是如何组织的、读取时索引支持是如何让完成的等等，通过学习本节课程能够对 Parquet 有一个比较系统的认识。通过对 OLAP 进行基本的解读后，本节课程将带来另一个常见的列存格式 - ORC ，围绕 ORC 的定义讲解展开，将其和 Parquet 在不同层面进行对比，分析了二者的区别，在此基础上衍生了 AliORC 的相关知识，最后介绍了更广义场景下的列存以及更多的列存演进和优化工作。

本质上，ORC和Parquet都是列存的时候，具体的格式选择而已，类似于你在MySQL中，选择InnoDB进行存储一样昂！

列存 vs 行存

数据格式层概述

image-20230218101900225

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

分层视角下的数据形态

image-20230218102133107

  • 存储层 : File , Blocks
  • 格式层: File 内部的数据布局(Layout+Schema)
  • 计算引擎: Rows + Columns

OLTP vs OLAP

image-20230218102257421

行式存储格式（行存）

  • 每行的数据在文件上是连续存储的
  • 读取整行数据效率高,单次IO顺序读即可
  • 典型系统
    • 关系型数据库: MySQL，Oracle...
    • Key-Value数据库

image-20230218102509908

OLTP一般都是整行进行读取，操作，整行的效率很高昂！！！

列式存储格式（列存）

image-20230218102613479

  • 每列的数据在文件. 上是连续存储的
  • 读取整列的效率较高
  • 同列的数据类型一致,压缩编码的效率更好
  • 典型系统
    • 大数据分析系统: SQL-on-Hadoop，数据湖分析
    • 数据仓库: ClickHouse , Greenplum，阿里云MaxCompute

OLAP一般都是整列进行读取，进行计算分析，并且整列数据类型一致（方便压缩等），整行的效率很高昂！！！

总结

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

Parquet原理详解

  • parquet.apache.org
  • 大数据分析领域使用最广的列存格式
  • Spark 推荐存储格式
  • Github
    • parquet-format：格式定义
    • parquet-mr：Java实现

Parquet in Action

DDL

image-20230218103155912

Spark

image-20230218103228558

image-20230218103252628

  • Spark生成的文件会有.parquet后缀
  • Hive生成的文件没有后缀

Parquet vs Text Format

image-20230218103452413

列存！！！高效的压缩和编码格式！！！

Dremel数据模型

image-20230218103638191

Paper: Dremel: Interactive Analysis of Web-Scale Datasets

  • Protocol Buffer定义
  • 支持可选和重复字段
  • 支持嵌套类型

Continued

image-20230218104125750

只保存叶子结点的数据哈！！！

  • 嵌套类型只保存叶子节点数据
  • 问题:由于列可能是Optional和Repeated ,如何把列内的数据对应到逻辑视图里的Record呢?（required反而好办哈！）

数据分布

image-20230218104328436

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

编码Encoding

image-20230218104508577

  • 各种编码方式：

    • Plain直接存储原始数据
    • Run Length Encoding (RLE): 适用于列基数不大，重复值较多的场景，例如: Boolean、枚举、固定的选项等
    • Bit-Pack Encoding: 配合RLE编码使用,让整形数字存储的更加紧凑
    • 字典编码Dictionary Encoding: 适用于列基数不大的场景，构造字典表，写入到Dictionary Page; 把数据用字典Index替换,然后用RLE编码

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

  • 业务自定义: org.apache.parquet.column.values.factory.ValuesWriterFactory

压缩Compression

image-20230218105046875

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

  • 支持多种压缩算法

  • snappy: 压缩速度快，压缩比不高，适用于热数据

  • gzip: 压缩速度慢,压缩比高，适用于冷数据

  • zstd: 新引入的压缩算法,压缩比和gzip差不多,而且压缩速度比肩Snappy

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

  • 对比：

image-20230218105202913

zstd和snappy是推荐使用的哈，对比可以看出来昂！！！

索引Index

image-20230218105335378

  • 和传统的数据库相比, 索引支持非常简陋
  • 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

Reference: blog.cloudera.com/speeding-up…

Bloom Filter

image-20230218110121968

  • parquet.bloom.filter.enabled
  • 对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index很难发挥作用
  • 引入Bloom Filter 加速过滤匹配判定
  • 每个ColumnChunk的头部保存Bloom Filter 数据{x,y,z}
  • 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 ,定位到具体的行号
  • 返回有效的数据给引擎侧

image-20230218110604387

Spark集成-向量化读

image-20230218110812877

  • ParquetFileFormat类
  • 向量化读开关:
    • spark.sql.parquet.enableVectorizedReader
  • 向量化读是主流大数据分析引擎的标准实践,可以极大的提升查询性能
  • Spark以Batch的方式从Parquet读取数据下推的逻辑也会适配Batch的方式

SIMD，一批一批处理能够加速昂！！！

Reference: databricks.com/session/vec…

深入Dremel数据模型

Repetition Level

image-20230218111508179

  • Repetition Level: 该字段在Field Path上第几个重复字段上出现
    • 0: 标识新的Record
    • Name.Language.Code为例，Name是第1个重复字段，Language是第2个重复字段

Definition Level

  • Definition Level: 用来记录在field path中有多少个字段是可以不存在(optional/repeated)而实际出现的。
  • Name.Language.Code为例，Name和Language都是可以不存在的。
  • 第一个NULL字段，D是1，说明Name是存在的，但是Language是不存在的，保留原有的信息。

Re-Assembly

  • 根据全部或者部分列数据，重新构造Record
  • 构造FSM状态机
  • 根据同一个Column下一个记录的RepetionLevel决定继续读的列

image-20230218112134249

image-20230218112202577

小结

  • 数据模型:基于Dremel
  • 文件布局: Footer + RowGroup + ColumnChunk + Page
  • Encoding : Page粒度 , Plain / RLE / Dictionary
  • Compression : Snappy / Gzip / Zstd
  • Index : Column Index ( Min-Max Index )
  • Predicate PushDown

ORC详解与对比

ORC简介

  • orc.apache.org
  • 大数据分析领域使用最广的列存格式之一
  • 出自于Hive项目
  • CREATE TABLE table_ name (х INT, y STRING) STORED AS ORC;

数据模型

image-20230218112955045

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

中间节点都会创建Column昂，和Parquet不一样

  • 思考：NestedType的不同实现对于IO模型有什么影响？

数据布局

image-20230218113146789

  • 类似Parquet
  • Rooter + Stripe + Column + Page (Row Group) 结构
  • Еnсоdіng / Соmрrеѕѕіоn / Іndех 支持上和Parquet几乎一致

ACID特性简介

image-20230218113337219

  • 支持Hive Transactions实现,目前只有Hive本身集成
  • 类似Delta Lake / Hudi / Iceberg
  • 基于Base + Delta + Compaction的设计

AliORC

  • ORC在阿里云计算平台被广泛应用，主流产品MaxCompute +交互式分析Hologres的最新版本都支持ORC格式
  • AliORC 是对ORC的深度定制版

索引增强

image-20230218113548058

image-20230218113607188

  • Clusterd Index , 更快的主键查找
  • Bitmap Index , 更快的过滤
    • Roaring Bitmap

小列聚合

image-20230218113823218

  • 小列聚合，减少小IO：重排Chunk

异步预取

image-20230218113914150

  • 异步预取数据
  • 计算逻辑和数据读取并行化

思考

  • 小列聚合什么场景下效果比较好?
  • 异步预取什么场景下效果比较好?
  • 如何基于Parquet实现同样的优化?

Parquet vs ORC

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

性能

image-20230218114240266

image-20230218114319395

选择

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

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

小结

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

列存演进

数仓中的列存

image-20230218114528728

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

存储侧下推

image-20230218114703469

  • 更多的下推工作下沉到存储服务侧
  • 越接近数据,下推过滤的效率越高
  • 例如AWS S3 Select功能
  • 挑战:
    • 存储侧感知Schema
    • 计算生态的兼容和集成

Column Family支持

image-20230218114816898

  • 背景: Hudi数据湖场景下,支持部分列的快速更新
  • 在Parquet格式里引入Column Family概念，把需要更新的列拆成独立的Column Family
  • 深度改造Hudi的Update和Query逻辑，根据Column Family选择覆盖对应的Column Family
  • Update操作实际效果有10+倍的提升

Summary

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

References

  1. Apache Parquet
  2. Dremel 数据格式的社区实现
  3. Paper: Dremel: Interactive Analysis of Web-Scale Datasets
  4. blog.cloudera.com/speeding-up…
  5. databricks.com/session/vec…
avatar
文章
阅读
粉丝