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

自律的掌门人
402 阅读6分钟

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

这是我参与「第四届青训营 」笔记创作活动的第4天，主要是对上课时的内容进行汇总，通过记笔记对知识的再次学习。

前言

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

列存vs行存

数据格式层概述

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

分层视角下的数据形态

  • 存储层：File，Blocks
  • 格式层：File内部的数据布局（Layout + Schema）
  • 计算引擎：Rows + Columns
OLTPOLAP
典型场景在线业务系统，例如：订单、交易、社交、评论等数据仓库或者大数据分析系统，例如：决策分析、BI系统、推荐系统等
业务特征事务、实时性、低延时、高并发、高可用弱事务性、近实时、离线分析、大吞吐、并发相对不高、可用性可以有一定的妥协
数据模型特征Schema 相对简单、数据维度不多、数据规模较小Schema复杂、数据维度很多，几百个Column很常见、数据规模巨大

OLTP: 行式存储格式（行存）

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

OLAP: 列式存储格式（列存）

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

Parquet原理详解

Parquet简介

  • 大数据分析领域使用最广的列存格式
  • Spark推荐存储格式
  • Parquet 中文直译是镶木地板，意思是结构紧凑，空间占用率高。

Parquet in Action -DDL

CREATE TABLE lineitem (
    I_orderkey int,
    I_partkey int,
    ...
)
STORED AS PARQUET TBLPROPERTIES ("parquet.compression "=" SNAPPY")

Parquet in Action - Spark

Load Data using SparkSQL

INSERT INTO lineitem SELECT * from tpch10g.lineitem;
  • Spark 生成的文件会有.parquet 后缀
  • Hive生成的文件没有后缀
  • parquet-cli 工具查看parquet文件的具体信息

Dremel 数据模型

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

Dremel 数据模型 - Continued

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

数据布局

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

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

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

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

  • Footer 保存文件的元信息

    • Schema
    • Config
    • Metadata
      • RowGoup Meta
        • Column Meta

编码 Encoding

  • Plain 直接存储原始数据

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

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

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

编码 Encoding

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

压缩 Compression

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

索引 Index

  • 和传统非数据库相比，索引支持非常简陋
  • 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

索引 Index - Bloom Filter

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

排序 Ordering

  • 类似于聚集索引的概念

  • 排序帮助更好的过滤掉无关的 RowGroup 或者 Page

    • 对于少量数据 Seek 很多帮助

  • Parquet Format 支持 SortingColumns

  • Parquet Linrary 目前没有支持

  • 依赖业务侧根据查询特征去保证顺序

过滤下推 Predicate PushDown

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

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个重复字段

ORC 详解

ORC 简介

  • 大数据分析领域使用最广德福列存格式之一
  • 出自于 Hive 项目

数据模型

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

    • 左图中，会创建8个Column

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

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

数据布局

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

ACID 特性简介

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

AliORC

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

Parquet vs ORC 对比

  • 从原理层面，最大的差别就是对于 NestedType 和复杂类型处理上

  • Parquet额算法上要复杂很多，带来的CPU的开销比ORC 要略大

  • ORC的算法上相对简单，但是要读取更多的数据

  • 因此，这个差异的对业务效果的影响，很难多一个定性的判定，更多的时候还是要取决于实际的业务场景

avatar
文章
阅读
粉丝