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

冕临
137 阅读6分钟

Parquet 和 ORC：高性能列式存储

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

1.列存VS行存

1.数据格式及数据形态

image.png

  • 计算层：各种计算引擎
  • 存储层：承载数据持久化存储
  • 数据格式层：定义了存储层内部的组织格式

2.分层视角下的数据形态

image.png

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

3.OLTP VS OLAP

image.png

1.OLTP(行存）

image.png

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

2.OLAP(列存）

image.png

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

4.总结

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

2.Parquet 原理详解

  • 大数据分析邻域使用最广的列式存储格式
  • Spark推荐存储格式

1.Parquet in Action

  • Spark生成的文件会有.parquet后缀，Hive生成的文件没有后缀
  • Parquet 压缩文件性能较好
  • parquet-cli工具查看parquet文件的具体信息

2.Dremel数据模型

  • Protocol Buffer 定义
  • 支持可选和重复字段
  • 支持嵌套类型 image.png
  • 构建出如下的语法树
  • 只有叶子节点的数据会被保存在数据文件里

3.数据文件布局

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

4.编码

  • Plain 直接存储原始数据
  • Run Length Encoding:适合列基数不大，重复值较多的场景
  • 字典编码：适合列基数不大，构造字典，写到Dictionary Page;把数据用字典Index替换，然后RLE编码

5.压缩

  • Page完成Encoding以后，进行压缩
  • 支持多种压缩算法
  • snappy：压缩速度快，压缩比不高，适合热数据
  • gzip：压缩速度慢，压缩比高，适合冷数据
  • zstd:新引入的压缩算法，压缩比跟gzip差不多，压缩速度比肩snappy

6.索引

  • 与传统数据库相比，对索引支持非常简陋
  • Min-Max Index：记录Page内部Column的min_value和max_value
  • Column Index：
    • Footer里面的Column Metadata包含ColoumnChunk的全部Page的Min-Max Value
  • Offset Index:记录Page在文件中的Offset和Page的RowRange

7.排序

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

8.过滤下推 Predicate PushDown

  1. parquet-mr 库实现，实现高效的过滤机制
  2. 引擎侧传入Filter Expression
  3. parquet-mr转换成具体Column的条件匹配
  4. 查询Footer 里的 Column Index，定位到具体的行号
  5. 返回有效的数据给引擎侧

9.Spark 集成：向量化读

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

3.ORC详解

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

1.数据模型

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

2.数据布局

  • 类似 Parquet
  • Rooter + Stripe + Column + Page (Row Group) 结构
  • Encoding / Compression / Index 支持上和 Parquet 几乎一致

3.ACID 特性

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

4.AliORC

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

5.索引增强

  • 支持 Clusterd Index，更快的主键查找
  • 支持 Bitmap Index，更快的过滤
    • Roaring Bitmap
      • 更高效的压缩保存 Bitmap Index
      • 以 16 bit 的 bitmap 空间为一个保存单元，每个单元可以是以下三种形式之一：
        • Array Container：只保存为 1 的 Index
        • Run Container：类似 RLE 编码
        • Bitset container：原始 bitmap 存储

6.Parquet vs ORC 对比

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

7.Parquet vs.ORC的选择

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

4.列存演进

1.数仓中的列存

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

2.存储侧下推

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

3.Column Family支持

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