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

林路
203 阅读7分钟

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

一.列存 vs 行存

1.数据格式层概述

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

image.png

2.分层视角下的数据形态

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

image.png

3.两种数据查询分析场景：OLTP VS OLAP

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

4.行式存储格式：OLTP

  • 每行的数据在文件上的连续存储的
  • 读取整行数据效率高，单次IO顺序读即可
  • 典型系统：关系型数据库：MySQL、Oracle、Key-Value数据库
image.png

5.列式存储格式：OLAP

  • 每列的数据在文件上是连续存储的
  • 读取整列的效率较高
  • 同列的数据类型一致，压缩编码的效率更好
  • 典型系统：大数据分析系统：SQL-on-Hadoop，数据湖分析，数据仓库：ClickHouse,Greenplum,阿里云MacCompute
image.png

二.Parquet原理详解

1.简介：

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

2.Dremel数据模型

  • Protocol Buffer定义
  • 支持可选和重复字段
  • 支持嵌套类型
  • 提供高效压缩和编码格式 （1）Continued
  • 嵌套类型只保存叶子节点
image.png

3.数据布局

  • RowGroup：每一行组包含一定数量或者固定大小的行的集合
  • ColumnChunk：RowGroup中按照切分成多个ColumnCheck
  • Page：ColumnChunk内部继续切分成Page，一般建议8KB大小。压缩和编码的主要单元
  • 根据保存的数据类型分为：Data、Page、Dictionary Page、Index Page
  • Footer保存文件的元信息：Schema、Config、Metadata、RowGroup Meta、Column Meta

image.png 4.编码Encoding

  • Plain直接存储原始数据
  • Run Length Encoding(RLE)：适用于列基数不大，重复值较多的场景，例如：Boolean、枚举、固定的选项等
  • Bit-Pack Encoding：配合RLE编码使用，让整型数字存储的更加紧凑
  • 字典编码Dictionary Encoding：适用于列基数不大的场景，构建字典表，写入到Dictionary Page；把数据用字典Index替换，然后用RLE编码
image.png

第一个是值，第二个是该值出现的次数

5.压缩Compression(一般选择snappy和zstd)

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

6.索引

  • Min-Max Index：记录Page内部Column的min-value和max-value
  • Column Index：Footer里的Column Metadata包含ColumnChunk的全部Page的Min-Max Value
  • Offset Index：记录Page在文件中的Offset和Page的Row Range

image.png

7.Boolm Filter

通过k个hash函数将这个元素映射到位数组的k个点，将他们设置为1。查询时如果k个点中有一个点不为1，那么其一定不在Bloom Filter里面。

  • 对于列基数比较大的场景或者非排序列的过滤，Min-Max Index很难发挥作用
  • 每个ColumnChunk的头部保存Bloom Filter数据
  • Footer记录Bloom Filter的page offset

8.排序Ordering

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

9.过滤下推Predicate PushDown

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

10.Spark集成--向量化读

  • ParquetFileFormat类
  • 向量化读开关：spark.sql.parquet.enableVectorizedReader
  • 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能
  • spark以Batch的方式从Parquet读取数据，下推的逻辑也会适配Batch的方式。
image.png

10.Repetition Level

中间节点不保存，只保存叶子节点

  • r:Repetition Level：该字段在Field Path上第几个重复字段上出现
  • 0：标识新的Record
  • 以图为例，"en-gb"的Name是第一个重复字段，"en"的Language是第2个重复字段

image.png

11.Definition Level

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

image.png

12.Re-Assembly

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

image.png

image.png

三.ORC详解

1.简介：

大数据分析领域使用最广的列式存储格式之一，出自hive项目

2.数据模型

  • ORC会给包括根节点在内的中间节点都创建一个Column（左图中会创建8个column）与parquet不同
  • 嵌套类型或者集合类型支持和Parquet差别较大
  • optional和repeated字段依赖父节点记录额信息来重新Assembly数据

image.png

3.数据布局

  • Rooter+Stripe+Column+page（Row Group）结构
  • Encoding/Compression/Index支持上和Parquet几乎一致 image.png

4.AliORC-索引增强

  • 支持Clusterd Index，更快的主键查找
  • 支持Bitmap Index，更快的过滤
  • Roaring Bitmap

image.png

image.png 第一种：记录行号 第二种：run container 第三种：原始bitmap

5.AliORC-小列聚合

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

image.png

6.AliORC-异步预取

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

image.png

7.Parquet vs ORC

  • 从原理层面，最大的差别就是对于NestedType和复杂类型处理上
  • Parquet的算法上要复杂很多，带来的CPU开销比ORC略大
  • ORC算法上相对简单，但要读取的数据更多
  • 性能对比：
  • Parquet在复杂的Schema场景下的算法开销影响较大
  • 在Spark场景下Parquet工作的更好，在Hive场景下，ORC更好
  • 选择：
  • 最新的版本来看，Parquet和ORC在性能上没有非常明显的差距和短板
  • 很多情况依赖于数据集和测试环境，不能迷信Benchmark结果，据实际业务调优测试
  • Spark生态下Parquet比较普遍
  • Hive生态下ORC有原生支持
  • 整体上，Spark比Hive更加有优势，大部分情况下Parquet更好

四.列存演进

1.数仓中的列存

  • ClickHouse的MergeTree引擎也是基于列存构建的
  • 默认情况下按照Column拆分的
  • 支持更加丰富的引擎
  • 湖仓一体的大趋势

image.png

2.存储侧下推

  • 更多的下推工作下沉到存储服务侧
  • 越接近数据，下推过滤的效率越高
  • 例如AWS S3 Select功能，在s3读数据时可以把filter带进去
  • 挑战：存储侧感知Sechema，计算生态的兼容和集成

image.png

3.Column Family支持（支持部分列的快速更新：如更新c2，就直接更新该列即可不用全部更新）

  • 在Parquet格式里引入Column Family概念，把需要更新的列拆分成独立的Column Family
  • 深度改造Hudi的Update和Query逻辑，根据Column Family选择覆盖对应的Column Family
  • Update操作实际效果有10+倍的提升
image.png
avatar
文章
阅读
粉丝