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

用户3618319768332
114 阅读4分钟

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

1. 列存vs行存

1.1 数据结构层介绍

计算层：各种计算引擎

存储层：承载数据的持久化存储

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

image.png

image.png

1.2 两种数据查询分析场景：OLTP与OLAP

image.png

1.3 OLTP：行式存储

1.4 OLAP：列式存储格式

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

读取整列的效率较高

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

2. Parquest原理详解

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

Spark推荐存储格式

2.1 Dremel 数据模型---Continued

嵌套类型只保存叶子节点数据

问题：由于列可能是Optional和Repeated,如何把列内的数据对应到逻辑视图里的Record呢？image.png

image.png

2.2 数据布局

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

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

Page:  ColumnChunk内部继续切分成Page,一般建议8KB大小。压缩和编码的基本单元

根据保存的数据类型分为：Data Page,Dictionary Page Index Page

Footer保存文件的元信息

  • Schema

  • Config

  • Metadata

    • RowGroup Meta

      • Column Meta

image.png

2.3 编码 Encoding

  • Plain直接存储原始数据

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

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

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

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

业务自定义：org.apache.parquet.column.values.factory.ValuesWriterFactoryimage.png

2.4 压缩 Compression

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

image.png

2.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

2.6.1 索引 Index-Bloom Filter

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

image.png

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 Index,定位到具体的行号
  • 返回有效的数据给引擎侧

2.8 Spark集成--向量化读

  • ParquetFileFormat类
  • 向量化读开关：

spark.sql.parquet.enableVectorizedReader

  • 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能
  • Spark以Batch的方式从Parquet读取数据，下推的逻辑也会适配Batch的方式

image.png

3. ORC详解

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

出自与Hive

3.1 数据模型

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

    • 左图中，会创建8个Column

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

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

image.png

3.2 数据布局

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

image.png

3.3 AliORC---索引增强

支持Clusterd Index,更快的主键查找

支持Bitmap Index,更快的过滤 - Roaring Bitmap

image.pngimage.png

3.3.1 AliORC---小列聚合

小列聚合，减少小IO

重排Chunk

image.png

3.3.2 AliORC---异步预取

异步预取数据

计算逻辑和数据读 取并行化

image.png

3.4 Parquest与ORC对比

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

际的业务场景

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

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

avatar
文章
阅读
粉丝