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

用户5236754501065
219 阅读9分钟

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

Lecture13. Parquet 与 ORC：高性能列式存储

大数据存储服务

  • 传统Hadoop大数据生态：HDFS
  • 公有云云原生存储生态：对象存储
  • 元数据管理：Hive
  • 狭义“数据湖”

引言

所有的大数据作业简单来说都可以简化

  • 从存储服务读取数据
  • 计算引擎解析和计算数据
  • 结果呈现

“如何高效从存储读取所需的数据”是决定大数据计算作业性能的关键因素。

01. 列存vs.行存

1.1 数据格式层概述

  • 计算层:各种计算引擎
  • 存储层:承载数据的持久化存储
  • 数据格式层:定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件

1.2 分层视角下的数据形态

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

1.3 两种数据查询分析场景: OLTP vs.OLAP

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

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

  • 每行的数据在文件上是连续存储的

  • 读取整行数据效率高，单次IO顺序读即可

  • 典型系统

    • 关系型数据库: MySQL,Oracle .
    • Key-Value数据库

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

  • 每列的数据在文件上是连续存储的

  • 读取整列的效率较高

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

  • 典型系统

    • 大数据分析系统: SQL-on-Hadoop，数据湖分析
    • 数据仓库:ClickHouse,Greenplum，阿里云MaxCompute

01. 行存vs.列存总结

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

02. Parquet原理详解

2.1 Parquet简介

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

2.1.1 Parquet in Action - DDL

Hive Table using Parquet

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

2.1.2 Parquet in Action - Spark

Load Data using SparkSQL

INSERT INTO lineitem SELECT * from tpch10g.customer;,

2.1.3 Parquet in Action - Spark

  • Spark 生成的文件会有.parquet后缀
  • Hive生成的文件没有后缀

2.1.4 Parquet in Action - Parquet vs. Text Format

列存：优秀的压缩

2.1.5 Parquet in Action - Spark

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

2.2 Dremel数据模型

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

2.2.1 Dremel数据模型- Continued

  • 嵌套类型只保存叶子节点数据
  • 问题:由于列可能是Optional和Repeated，如何把列内的数据对应到逻辑视图里的Record 呢?

2.3 数据布局

  • RowGroup:每一个行组包含一定数量或者固定大小的行的集合

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

  • Page：ColumnChunk内部继续切分成Page，一般建议8KB大小。压缩和编码的基本单元根据保存的数据类型分为：Data Page ,Dictionary Page ,Index Page

  • Footer保存文件的元信息

    • Schema

    • Config

    • Metadata

      • RowGroup Meta
      • Column Meta

2.4 编码 Encoding

  • Plain直接存储原始数据

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

    • Bit-Pack Encoding: 配合RLE 编码使用，让整形数字存储的更加紧凑

  • 字典编码 Dictionary Encoding:适用于列基数不大的场景，构造字典表，写入到Dictionary Page;把数据用字典Index替换，然后用RLE编码

2.4.1 编码 Encoding

  • 默认场景下parquet-mr会自动根据数据特征选择
  • 业务自定义: org.apache.parquet.column.values.factory.ValuesWriterFactory

2.5 压缩Compression

  • Page完成 Encoding以后，进行压缩
  • 支持多种压缩算法
  • snappy:压缩速度快，压缩比不高，适用于热数据
  • gzip:压缩速度慢，压缩比高，适用于冷数据
  • zstd:新引入的压缩算法，压缩比和gzip差不多，而且压缩速度比肩Snappy
  • 建议选择snappy或者zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响
  • 对比：quixdb.github.iolsquash-benchmark/#results-ta…

2.6 索引 Index

  • 和传统的数据库相比，索引支持非常简陋

  • Min-Max Index:记录 Page内部Column的min_value和max_value

  • Column Index:

    • Footer 里的Column Metadata包含ColumnChunk的全部Page的 Min-MaxValue

  • Offset Index:记录 Page在文件中的 Offset和Page的 Row Range

2.6.1索引 Index - Bloom Filter布隆过滤器

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

2.6.2排序 Ordering

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

2.7 过滤下推 Predicate PushDown、算子下推

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

2.8 Spark集成-向量化读

  • ParquetFileFormat类

  • 向量化读开关:

    • spark.sql.parquet.enableVectorizedReader

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

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

2.9 深入Dremel数据模型- Repetition Level

  • Repetition Level:该字段在Field Path 上第几个重复字段上出现

    • 0:标识新的Record
    • Name.Language.Code为例，Name是第1个重复字段，Language是第2 个重复字段

2.9.1 深入Dremel数据模型 - Definition Level

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

2.9.2 深入Dremel数据模型 - Re-Assembly

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

2.10 Parquet小结

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

03. ORC 详解和对比

3.1 ORC简介

  • 大数据分析领域使用最广的列存格式之一
CREATE TABLE tabLe_name (x INT, y STRING)STORED AS ORC;
  • 出自于Hive项目

3.2 数据模型

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

    • 图中会创建8个Column

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

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

3.2.1思考

  • NestedType的不同实现对于IO模型有什么影响?

3.3数据布局

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

3.4 ACID特性简介

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

3.5 AliORC

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

3.5.1 AliORC-索引增强

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

  • 支持 Bitmap Index，更快的过滤

    • Roaring Bitmap

Bitmao Index：

3.5.2 AliORC-小列聚合

  • 小列聚合，减少小lO
  • 重排 Chunk

3.5.3 AliORC-异步预取

  • 异步预取数据
  • 计算逻辑和数据读取并行化

processing比较长：

3.5.4思考

  • 小列聚合什么场景下效果比较好?
  • 异步预取什么场景下效果比较好?
  • 如何基于Parquet 实现同样的优化?

3.6 Parquet vs.ORC 对比

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

3.6.1 Parquet vs. ORC 对比-性能

  • 场景:Full Table Scan 平台:推测 Hive 时间: 2016
  • 左边:简单Schema右边:复杂Schema
  • Parquet在复杂Schema场景下的算法开销影响较大

3.6.2 Parquet vs. ORC 对比-性能

  • 场景:BigBench时间:2020
  • 结论:在Spark 场景下 Parquet 工作的更好;在 Hive场景下，ORC更好

3.6.3 Parquet vs. ORC 对比-选择

  • 最新的版本来看，Parquet和ORC在性能上没有非常明显的差距和短板
  • 性能上很多情况下依赖于数据集和测试环境，不能迷信Benchmark 结果
  • 根据实际业务做充分的测试调优
  • Spark 生态下Parquet 比较普遍
  • Hive生态下 ORC有原生支持

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

3.7 ORC小结

  • 数据模型，和 Parquet差异
  • ACID支持
  • Parquet 对比和选择

04. 列存演进

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+倍的提升

课程总结

  • 列存的适用场景，和行存的区别
  • Parquet和ORC的原理，以及对比和选择
  • 列存的演进
avatar
文章
阅读
粉丝