Chiriri's blog
Iekr
2022-08-15
目录

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

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

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

# 行存 vs 列存

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

# 数据格式层概述

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

image-20220815015053491

# 分层视角下的数据形态

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

image-20220815015240875

# OLTP vs OLAP

  • OLTP 和 OLAP 作为数据查询和分析领域两个典型的系统类型，具有不同的业务特征，适配不同的业务场景
  • 理解两者的区别可以帮助更好的理解行存和列存的设计背景
OLTP OLAP
典型场景 在线业务系统，例如：订单、交易、社交、评论等 数据仓库或者大数据分析系统，例如：决策分析、BI 系统、推荐系统等
访问特征 事务
实时性
低延时
高并发
高可用		 弱事务性
近实时、离线分析
大吞吐 - 并发相对不高
可用性可以有一定的妥协
数据模型特征 Schema 相对简单
数据维度不多 - 数据规模较小		 Schema 复杂
数据维度很多，几百个 Column 很常见
数据规模巨大

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

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

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

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

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

image-20220815015815526

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

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

  • 读取整列的效率较高

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

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

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

image-20220815015938080

# 总结

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

# Parquet 原理详解

Parquet 官方 (opens new window)

# Parquet 使用

# DDL

Hive Table using Parquet

CREATE TABLE lineitem (
    l_orderkey int,
    l_partkey int,
    ...
)
STORED AS PARQUET TBLPROPERTIES ("parquet.compression"="SNAPPY");
1
2
3
4
5
6

# 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")
1
2
3
4
5
6
  • Spark 生成的文件会有 .parquet 后缀
  • Hive 生成的文件没有后缀

image-20220815021058658

Parquet 与 Text 格式文件大小对比

image-20220815021157289

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

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

parquet-mr 包含 CLI 工具: parquet-cli (opens new window)

image-20220815021302113

# Dremel 数据模型

image-20220815021414073

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

# Continued

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

image-20220815021505467

image-20220815021539170

# 数据文件布局

image-20220815021715088

  • 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

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

    • Dictionary Encoding 过程

      image-20220815022631796

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

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

# 压缩 Compression

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

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

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

image-20220815023236207

# 索引 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

# 布隆过滤器 Bloom Filter

  • parquet.bloom.filter.enabled
  • 对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index 很难发挥作用
  • 引入 Bloom Filter 加速过滤匹配判定
  • 每个 ColumnChunk 的头部保存 Bloom Filter 数据
  • Footer 记录 Bloom Filter 的 page offset

布隆过滤器 (opens new window)

c19a9cef-de5e-4187-b6de-c29d2b45799f

# 排序 Ordering

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

# 过滤下推 Predicate PushDown

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

image-20220815024526919

# 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

# Definition Level

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

image-20220815025352101

# Re-Assembly

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

image-20220815030128330

image-20220815030137805

# 总结

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

# ORC

orc 官网 (opens new window)

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

# 数据模型

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

    • 下图中，会创建 8 个 Column

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

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

image-20220815030435088

image-20220815030444197

# 数据布局

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

image-20220815030614939

# ACID 特性

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

image-20220815030648119

# AliORC

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

# 索引增强

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

  • 支持 Bitmap Index，更快的过滤

    image-20220815032410471

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

image-20220815032429454

# 小列聚合

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

image-20220815032745100

# 异步预取

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

image-20220815032817464

# Parquet vs ORC 对比

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

# 性能

  • Parquet 在复杂 Schema 场景下的算法开销影响较大
  • 测试平台 Hive，Hive 上 ORC 更有优势 时间：2016

image-20220815033120343

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

image-20220815033218187

# 如何选择

  • 当前项目使用的？？
  • 性能上很多情况下依赖于数据集和测试环境，不能迷信 Benchmark 结果
  • 根据实际业务做细粒度的调优
  • Spark 生态下 Parquet 比较普遍
  • Hive 生态下 ORC 有原生支持
  • 整体上，Spark 比 Hive 更加有优势，所以大部分情况下，Parquet 可能是个更好的选择

# 列存演进

# 数仓中的列存

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

# 存储侧下推

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

image-20220815033726384

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

# Column Family 支持

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

image-20220815033852686

编辑 (opens new window)
上次更新: 2023/12/06, 01:31:48
从 Kafka 到 Pulsar 的数据流演进之路｜ 青训营笔记
LSMT 存储引擎浅析｜ 青训营笔记

← LSMT 存储引擎浅析｜ 青训营笔记→

最近更新
01
k8s
06-06
02
进程与线程
03-04
03
计算机操作系统概述
02-26
更多文章>
Theme by Vdoing | Copyright © 2022-2025 Iekr | Blog