高性能列式存储 | 青训营笔记

孤独的红心
314 阅读4分钟

这是我参与「第四届青训营 」笔记创作活动的第7天
所有的大数据作业简单来说都可以简化

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

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

列存 vs 行存

1. 数据格式层概述

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

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

  • 存储层:File，Blocks
  • 格式层:File内部的数据布局(Layout + Schema)
  • 计算引擎:Rows + Columns
    Snipaste_2022-08-06_21-29-51.jpg

3. OLTP vs OLAP

Snipaste_2022-08-06_21-32-48.jpg

4.OLTP：行式存储

  • 每行的数据在文件上是连续存储的
  • 读取整行数据效率高，单次IO顺序读即可
  • 典型系统
    • 关系型数据库:MySQL,Oracle
    • Key-Value数据库 Snipaste_2022-08-06_21-34-29.jpg

5.OLAP:列式存储

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

总结

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

Parquet原理详解

1.简介

parquet.apache.org Parquet是大数据分析领域使用最广的列存格式，Spark推荐存储格式 Github

  • parquet-format :格式定义
  • parquet-mr : Java实现

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

2.Dremel数据模型

Snipaste_2022-08-06_21-52-52.jpg

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

Snipaste_2022-08-06_21-54-07.jpg

Snipaste_2022-08-06_21-53-53.jpg

3.数据布局

Snipaste_2022-08-06_21-55-00.jpg

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

4.编码Encodeing

Snipaste_2022-08-06_21-57-56.jpg

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

5.压缩Compression

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

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 Snipaste_2022-08-06_22-05-24.jpg

Bloom Filter

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

排序

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

7.过滤下推 Predicate PushDown

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

8.Spark集成-向量化读

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