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

Iekr
372 阅读9分钟

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

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

行存 vs 列存

行存列存
按行写入数据，读取数据时需要读取不必要的列可以只读取请求的列
适用于OLTP系统适用于OLAP系统
适用于按记录读取数据适用于按列读取数据
不利于大数据集聚合统计操作利于大数据集聚合统计操作
不利于数据压缩利于数据压缩

数据格式层概述

  • 计算层: 各种计算引擎
  • 存储层: 承载数据的持久化存储
  • 数据格式层:定义了存储层文件内部的组织格式,计算引擎通过格式层的支持来读写文件。严格意义上，并不是一个独立的层级，而是运行在计算层的一个Library。

image-20220815015053491.png

分层视角下的数据形态

  • 存储层：File，Blocks

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

  • 计算引擎：Rows + Columns

image-20220815015240875.png

OLTP vs OLAP

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

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

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

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

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

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

  • 在典型的 OLTP 型的分析和存储系统中应用广泛

    • 例如：MySQL、Oracle、RocksDB 等
    • Key-Value 数据库

image-20220815015815526.png

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

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

  • 读取整列的效率较高

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

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

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

image-20220815015938080.png

总结

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

Parquet 原理详解

Parquet官方

Parquet 使用

DDL

Hive Table using Parquet

CREATE TABLE lineitem (
    l_orderkey int,
    l_partkey int,
    ...
)
STORED AS PARQUET TBLPROPERTIES ("parquet.compression"="SNAPPY");

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")
  • Spark 生成的文件会有 .parquet 后缀
  • Hive 生成的文件没有后缀

image-20220815021058658.png

Parquet 与 Text 格式文件大小对比

image-20220815021157289.png

Tex t格式存储的容量是 Parquet 格式存储的两倍之多

parquet-cli 工具查看 parquet 文件的具体信息

parquet-mr 包含 CLI 工具: parquet-cli

image-20220815021302113.png

Dremel 数据模型

image-20220815021414073.png

  • Protocol Buffer 定义

  • 支持可选和重复字段

  • 支持嵌套类型

Continued

  • 只有叶子节点的数据会被保存在数据文件里

image-20220815021505467.png

image-20220815021539170.png

数据文件布局

image-20220815021715088.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

编码 Encoding

  • Plain直接存储原始数据

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

    • Bit-Pack Encoding：配合RLE编码使用，让整形数字存储的更加紧凑，对于 32位或者64位的整型数而言，并不需要完整的 4B 或者 8B 去存储，高位的零在存储时可以省略掉。适用于最大值非常明确的情况下。

    • RLE编码过程如下图所示：

      2fb9ced3-c466-43f8-b5e3-55012a7fc8a0.png

  • 字典编码Dictionary Encoding: 适用于列基数不大的场景，构造字典表，写入到Dictionary Page；把数据用字典Index 替换，替换后的数据可以使用 RLE + Bit-Pack 编码存储

    • Dictionary Encoding 过程

    image-20220815022631796.png

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

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

压缩 Compression

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

  • 支持多种压缩算法 image-20220815023116579.png

    • snappy: 压缩速度快，压缩比不高，适用于热数据
    • gzip：压缩速度慢，压缩比高，适用于冷数据
    • zstd：新引入的压缩算法，压缩比和 gzip 差不多，而且压缩速度略低于 Snappy
    • 建议选择 snappy 或者 zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响

image-20220815023236207.png

索引 Index

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

image-20220815023615179.png

布隆过滤器 Bloom Filter

  • parquet.bloom.filter.enabled

  • 对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index 很难发挥作用

  • 引入 Bloom Filter 加速过滤匹配判定

  • 每个 ColumnChunk 的头部保存 Bloom Filter 数据

  • Footer 记录 Bloom Filter 的 page offset

布隆过滤器

c19a9cef-de5e-4187-b6de-c29d2b45799f.png

排序 Ordering

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

过滤下推 Predicate PushDown

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

  • 引擎侧传入 Filter Expression

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

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

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

image-20220815024526919.png

Spark 集成 - 向量化读

  • 作为最通用的 Spark 数据格式

  • 主要实现在：ParquetFileFormat

  • 支持向量化读：spark.sql.parquet.enableVectorizedReader

  • 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能

  • Spark 以 Batch 的方式从 Parquet 读取数据，下推的逻辑也会适配 Batch 的方式

深入Dremel 数据模型

Repetition Level

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

image-20220815025352101.png

Definition Level

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

image-20220815025352101.png

Re-Assembly

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

image-20220815030128330.png

image-20220815030137805.png

总结

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

ORC

orc官网

  • 产生于 Hive 项目

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

数据模型

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

    • 下图中，会创建 8 个 Column

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

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

image-20220815030435088.png

image-20220815030444197.png

数据布局

  • 类似 Parquet

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

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

image-20220815030614939.png

ACID 特性

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

  • 类似 Delta Lake / Hudi / Iceberg

  • 基于 Base + Delta + Compaction 的设计

image-20220815030648119.png

AliORC

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

  • AliORC 是对 ORC 的深度定制版

索引增强

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

  • 支持 Bitmap Index，更快的过滤

    image-20220815032410471.png

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

image-20220815032429454.png

小列聚合

  • 小列聚合，减少小 IO
    • 重排 ColumnChunk

image-20220815032745100.png

异步预取

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

image-20220815032817464.png

Parquet vs ORC 对比

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

性能

  • Parquet 在复杂 Schema 场景下的算法开销影响较大

  • 测试平台 Hive，Hive 上 ORC 更有优势 时间:2016

image-20220815033120343.png

  • 在 Spark 场景下 Parquet 工作的更好；在 Hive 场景下，ORC 更好 时间:2020

image-20220815033218187.png

如何选择

  • 当前项目使用的？？

  • 性能上很多情况下依赖于数据集和测试环境，不能迷信 Benchmark 结果

  • 根据实际业务做细粒度的调优

  • Spark 生态下 Parquet 比较普遍

  • Hive 生态下 ORC 有原生支持

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

列存演进

数仓中的列存

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

存储侧下推

  • 更多的下推工作下沉到存储服务侧

  • 越接近数据，下推过滤的效率越高

  • 例如 AWS S3 Select 功能

image-20220815033726384.png

  • 挑战：
    • 存储侧感知 Schema
    • 计算生态的兼容和集成

Column Family 支持

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

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

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

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

image-20220815033852686.png

avatar
文章
阅读
粉丝