Parquet 与 ORC：高性能列式存储

太宰先生
437 阅读5分钟

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

列存 vs 行存

数据格式层：

  • 计算层：各种计算引擎。

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

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

  • 数据形态：

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

image.png

OLTP vs OLAP

image.png

行式存储格式 (行存) 与 OLTP

  • 每一行 (Row) 的数据在文件的数据空间里连续存放的
  • 读取整行的效率比较高，一次顺序 IO 即可
  • 在典型的 OLTP 型的分析和存储系统中应用广泛，例如：MySQL、Oracle、RocksDB 等

列式存储格式 (列存) 与 OLAP

  • 每一列 (Column) 的数据在文件的数据空间里连续存放的

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

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

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

Parquet原理详解

数据模型

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

image.png 构造出的语法树：只有叶子节点的数据会被保存在数据文件里

image.png

数据文件布局

  • RowGroup: 每一个行组包含一定数量或者固定大小的行的集合，在 HDFS 上，RowGroup 大小建议配置成 HDFS Block 大小

  • ColumnChunk: RowGroup 中按照列切分成多个 ColumnChunk

  • Page：ColumnChunk内部继续切分成 Page，一般建议 8KB 大小。Page 是压缩和编码的基本单元

    • 根据保存的数据类型，Page 可以分为：Data Page，Dictionary Page，Index Page

  • Footer 保存文件的元信息

    • Schema

  • Config

  • Metadata

    • RowGroup Meta

      • Column Meta

image.png

编码Encoding：

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

压缩

  • Page完成Encoding以后,进行压缩。

  • 支持多种压缩算法：

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

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

image.png

索引Index：

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，定位到具体的行号
  • 返回有效的数据给引擎侧

ORC详解

  • 大数据分析领域使用最广的列存格式之一

数据模型

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

数据布局

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

AliORC索引增强

  • 支持 Clusterd Index，更快的主键查找

  • 支持 Bitmap Index，更快的过滤

    • Roaring Bitmap

      • 更高效的压缩保存 Bitmap Index

      • 以 16 bit 的 bitmap 空间为一个保存单元，每个单元可以是以下三种形式之一：

        • Array Container：只保存为 1 的 Index
        • Run Container：类似 RLE 编码
        • Bitset container：原始 bitmap 存储

  • 小列聚合，减少小 IO

    • 重排 ColumnChunk

  • 异步预取优化

    • 在计算引擎处理已经读到的数据的时候，异步去预取下一批次数据

Parquet vs ORC 对比

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

存储侧下推

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

image.png

Column Family 支持

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