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

FlemingFan
190 阅读5分钟

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


0x00 列存vs.行存

0.1 数据格式层概述

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

13_数据格式层概述.jpg

0.2 分层视角下的数据形态

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

13_分层视角下的数据形态.png

0.3 OLTP vs OLAP

13_OLTP&OLAP.png

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

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

13_行式存储格式.jpg

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

  • 每一列 (Column) 的数据在文件的数据空间里连续存放的
  • 同列的数据类型一致，压缩编码的效率更好
  • 在典型的 OLAP 型分析和存储系统中广泛应用，例如：
    • 大数据分析系统：Hive、Spark，数据湖分析
    • 数据仓库：ClickHouse，Greenplum，阿里云 MaxCompute

13_列式存储.awebp

0x01 Parquet原理

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

1.1 Dremel数据模型

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

13_数据模型.png

1.1.1 Dremel数据模型 - Continued

13_数据模型.jpg

13_数据模型.jpg 13_数据模型-Continued.png

1.2 数据布局

  • 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

13_数据文件布局.gif

1.3 数据编码

  • 在 Parquet 的 ColumnChunk 里，同一个 ColumnChunk 内部的数据都是同一个类型的，可以通过编码的方式更高效的存储

  • Parquet 支持的编码方式有如下：

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

    13_Encoding.png

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

    13_字典编码.jpeg

      * 构造字典表，用字典中的 Index 替换真实数
  * 替换后的数据可以使用 RLE + Bit-Pack 编码存储
    • Bit-Pack Encoding: 对于 32位或者64位的整型数而言，并不需要完整的 4B 或者 8B 去存储，高位的零在存储时可以省略掉。适用于最大值非常明确的情况下。

1.4 数据压缩

  • Page 完成 Encoding 以后，进行压缩
  • 支持多种压缩算法
    • snappy: 压缩速度快，压缩比不高，适用于热数据
    • gzip：压缩速度慢，压缩比高，适用于冷数据
    • zstd：新引入的压缩算法，压缩比和 gzip 差不多，而且压缩速度略低于 Snappy

1.5 索引和排序

1.5.1 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 读取剩下的数据

13_索引.png

1.5.2 Ordering

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

0x02 ORC详解和对比

  • 产生于 Hive 项目
  • 大数据分析领域使用最广的列存格式之一

2.1 数据模型

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

13_数据模型0.png

13_数据模型1.png

2.2 数据布局

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

13_数据布局.png

2.3 ACID 特性

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

2.4 AliORC

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

2.5 Parquet vs ORC 对比

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

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

0x03 列存演进

3.1 数仓中的列存

  • 典型的数仓，例如 ClickHouse 的 MergeTree 引擎也是基于列存构建的
    • 默认情况下列按照 Column 拆分成单独的文件，也支持单个文件形式
  • 支持更加丰富的索引，例如 Bitmap Index、Reverted Index、Data Skipping Index、Secondary Index 等
  • 湖仓一体的大趋势下，数仓和大数据数据湖技术和场景下趋于融合，大数据场景下的格式层会借鉴更多的数仓中的技术

3.2 存储侧下推

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

13_存储测下推.png

3.3 Column Family 支持

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

13_ColumnFamily支持.jpg

avatar
文章
阅读
粉丝