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

serendipity__
249 阅读6分钟

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

Parquet 和 ORC：高性能列式存储

一、行存 vs 列存

1.1 数据格式层

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

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

1.2 分层视角下的数据形态

  • 存储层：File，Blocks

  • 格式层：File 内部的数据布局 （Layout + Schema）

  • 计算引擎：Rows + Columns

1.3 OLTP vs OLAP

  • OLTP 和 OLAP 作为数据查询和分析领域两个典型的系统类型，具有不同的业务特征，适配不同的业务场景

  • 理解两者的区别可以帮助更好的理解行存和列存的设计背景

OLTPOLAP
典型场景在线业务系统，例如：订单、交易、社交、评论等数据仓库或者大数据分析系统，例如：决策分析、BI系统、推荐系统等
访问特征- 事务- 实时性- 低延时- 高并发- 高可用- 弱事务性- 近实时、离线分析- 大吞吐- 并发相对不高- 可用性可以有一定的妥协
数据模型特征- Schema 相对简单- 数据维度不多- 数据规模较小- Schema 复杂- 数据维度很多，几百个Column 很常见- 数据规模巨大

1.4 OLTP：行式存储格式 (行存)

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

  • 读取整行的效率比较高，一次顺序 IO 即可

  • 在典型的 OLTP 型的分析和存储系统中应用广泛，例如：MySQL、Oracle、RocksDB 等

1.5 OLAP: 列式存储格式 (列存)

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

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

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

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

二、Parquet 详解

image.png

2.1使用 Parquet

# Spark
df.write.parquet("/path/to/file.parquet")
df.write
  .partitionBy(”col1")
  .format("parquet")
  .saveAsTable(”sometable")
val df = spark.read.parquet(”/path/to/file.parquet")

# Hive DDL
CREATE TABLE table_name (x INT, y STRING) STORED AS PARQUET;

2.2数据模型

  • Protocol Buffer 定义

  • 支持可选和重复字段

  • 支持嵌套类型

image.png

2.2.1 Dremel数据模型 —— Continued

image.png

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

2.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
      • RowGroup Meta
        • Column Meta

image.png

2.4 编码Encoding

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

image.png

  • Bit-Pack Encoding: 对于 32位或者64位的整型数而言，并不需要完整的 4B 或者 8B 去存储，高位的零在存储时可以省略掉。适用于最大值非常明确的情况下。

    • 一般配合 RLE 一起使用

  • Dictionary Encoding：适用于列基数 (Column Cardinality) 不大的字符串类型数据存储；

    • 构造字典表，用字典中的 Index 替换真实数据
    • 替换后的数据可以使用 RLE + Bit-Pack 编码存储

image.png

2.5 压缩 Compression

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

  • 支持多种压缩算法

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

image.png

2.6 索引 Index

  • 和传统的数据库相比，索引支持非常简陋
  • 主要依赖 Min-Max Index 和 排序 来加速查找
  • Page：记录 Column 的 min_value 和 max_value
  • Footer 里的 Column Metadata 包含 ColumnChunk 的全部 Page 的 Min-Max Value
  • 一般建议和排序配合使用效果最佳
  • 一个 Parquet 文件只能定义一组 Sort Column，类似聚集索引概念

典型的查找过程：

  • 读取 Footer
  • 根据 Column 过滤条件，查找 Min-Max Index 定位到 Page
  • 根据 Page 的 Offset Index 定位具体的位置
  • 读取 Page，获取行号
  • 从其他 Column 读取剩下的数据

2.7过滤下推 Predicate PushDown

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

  • 引擎侧传入 Filter Expression

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

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

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

  • 优点：

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

image.png

三、ORC详解

3.1 ORC简介

image.png

  • 产生于 Hive 项目

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

3.2数据模型

  • ORC 会给包括根节点在内的中间节点都创建一个 Column

  • 下图中，会创建 8 个 Column

  • 嵌套类型或者集合类型支持和 Parquet 差别较大

  • optional 和 repeated 字段依赖父节点记录额外信息来重新 Assembly 数据

image.png

3.3 数据布局

  • 类似 Parquet

  • Rooter + Stripe + Column + Page (Row Group) 结构

  • Encoding / Compression / Index 支持上和 Parquet 几乎一致

3.4 ACID特性简介

  • 支持 Hive Transactions 实现，目前只有 Hive 本身集成

  • 类似 Delta Lake / Hudi / Iceberg

  • 基于 Base + Delta + Compaction 的设计

3.5 AliORC

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

  • AliORC 是对 ORC 的深度定制版

3.5.1索引增强

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

  • 支持 Bitmap Index，更快的过滤

    • Roaring Bitmap

      • 更高效的压缩保存 Bitmap Index

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

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

image.png

3.6 Parquet vs ORC 对比

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

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

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

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

四、列存演进

4.1 数仓中的列存

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

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

4.2 存储侧下推

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

4.3 Column Family 支持

  • 背景：Hudi 数据湖场景下，支持部分列的快速更新

  • 在 Parquet 格式里引入 Column Family 概念，把需要更新的列拆成独立的 Column Family

  • 深度改造 Hudi 的 Update 和 Query 逻辑，根据 Column Family 选择覆盖对应的 Column Family

  • Update 操作实际效果有 10+ 倍的提升

avatar
文章
阅读
粉丝