这是我参与「第四届青训营」笔记创作活动的第17天
本节课程目录：
- 列存 vs. 行存
- Parquet 原理详解
- ORC 详解和对比
- 列存演进
1. 列存 vs 行存
1.1 数据格式层概述
- 计算层：各种计算引擎
- 存储层：承载数据的持久化存储
- 数据格式层：定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件（严格意义上，并不是一个独立的层级，而是运行在计算层的一个 Library）
1.2 分层视角下的数据形态
- 存储层：File，Blocks
- 格式层：File 内部的数据布局（Layout + Schema）
- 计算引擎：Rows + Columns
1.3 两种数据查询分析场景：OLTP vs. OLAP
1.4 OLTP：行式存储格式（行存）
- 每一行 (Row) 的数据在文件的数据空间里连续存放的
- 读取整行的效率比较高，单次顺序 IO 即可
- 在典型的 OLTP 型的分析和存储系统中应用广泛
- 关系型数据库：MySQL、Oracle...
- Key - Value 数据库
1.5 OLAP：列式存储格式（列存）
- 每一列 (Column) 的数据在文件的数据空间里连续存放的
- 同列的数据类型一致，压缩编码的效率更好
- 在典型的 OLAP 型分析和存储系统中广泛应用
- 大数据分析系统：Hive、Spark，数据湖分析
- 数据仓库：ClickHouse，Greenplum，阿里云 MaxCompute
2. Parquet 原理详解
2.1 Parquet 简介
- 大数据分析领域使用最广的列存格式
- Spark 推荐存储格式
2.1.1 Parquet in Action - DDL
Hive Table using Parquet
CREATE TABLE lineitem(
I_orderkey int,
I_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.lineitem;
2.1.3 Parquet in Action - Spark
- Spark 生成的文件会有.parquet 后缀
- Hive 生成的文件没有后缀
2.1.4 Parquet in Action - Parquet vs. Text Format
- Parquet
- Text
2.1.5 Parquet in Action - Spark
parquet-cli 工具查看 parquet 文件的具体信息
2.2 Dremel 数据模型
- Protocol Buffer 定义
- 支持可选和重复字段
- 支持嵌套类型
2.2.1 Dremel 数据模型 - Continued
构建出如下的语法树
- 嵌套类型只保存叶子节点数据
2.3 数据布局
- RowGroup: 每一个行组包含一定数量或者固定大小的行的集合，在 HDFS 上，RowGroup 大小建议配置成 HDFS Block 大小
- ColumnChunk: RowGroup 中按照列切分成多个 ColumnChunk
- Page：ColumnChunk内部继续切分成 Page，一般建议 8KB 大小。Page 是压缩和编码的基本单元
- 根据保存的数据类型，Page 可以分为：Data Page，Dictionary Page，Index Page
- Footer 保存文件的元信息
- Schema
- Config
- Metadata
- RowGroup Meta
- Column Meta
- RowGroup Meta
2.4 编码 Encoding
- Plain 直接存储原始数据
- Run Length Encoding（RLE）：适用于列基数不大，重复值较多的场景，如：Boolean、枚举、固定的选项等
- Bit-Pack Encoding：配合 RLE 编码使用，让整形数字存储的更加紧凑
- 字典编码 Dictionary Encoding：适用于列基数不大的场景，构造字典表，写入到 Dictionary Pages；把数据用字典 index 替换，然后用 RLE 编码
- 默认场景下 parquet-mr 会自动根据数据特征选择
- 业务自定义：
org.apache.parquet.column.values.factory.ValuesWriterFactory
2.5 压缩 Compression
- Page 完成 Encoding 以后，进行压缩
- 支持多种压缩算法
- snappy: 压缩速度快，压缩比不高，适用于热数据
- gzip：压缩速度慢，压缩比高，适用于冷数据
- zstd：新引入的压缩算法，压缩比和 gzip 差不多，而且压缩速度略低于 Snappy
- 建议选择 snappy 或者 zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响
2.6 索引 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
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 Index，定位到具体的行号
- 返回有效的数据给引擎侧
- 优点：
- 在格式层过滤掉大多数不相关的数据
- 减少真实的读取数据量
2.8 Spark 集成 - 向量化读
- 作为最通用的 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 是第一个重复字段，Language 是第二个重复字段
2.9.1 深入 Dremel 数据模型 - Definition Level
- Definition Level：用来记录在 field path 中，有多少个字段是可以不存在（optional/repeated）而实际出现的
- Name.Lauguage.Code 为例，Name 和 Language 都是可以不存在的
- 第一个 NULL 字段，D 是 1，说明 Name 是存在的，但是 Language 是不存在的，保留原有的信息
2.9.2 深入 Dremel 数据模型 - Re-Assembly
- 根据全部或者部分列数据，重新构造 Record
- 构造 FSM 状态机
- 根据同一个 Column 下一个记录的 RepetionLevel 决定继续读的列
3. ORC 详解
3.1 ORC 简介
- 大数据分析领域使用最广的列存格式之一
- 产生于 Hive 项目
3.2 数据模型
- ORC 会给包括根节点在内的中间节点都创建一个 Column
- 下图中，会创建 8 个 Column
- 嵌套类型或者集合类型支持和 Parquet 差别较大
- optional 和 repeated 字段依赖父节点记录额外信息来重新 Assembly 数据
3.2 数据布局
- 类似 Parquet
- Rooter + Stripe + Column + Page (Row Group) 结构
- Encoding / Compression / Index 支持上和 Parquet 几乎一致
3.4 ACID 特性简介
- 支持 Hive Transactions 实现，目前只有 Hive 本身集成
- 类似 Delta Lake / Hudi / Iceberg
- 基于 Base + Delta + Compaction 的设计
3.5 AliORC
- ORC 在阿里云计算平台被广泛应用，主流产品 MaxCompute + 交互式分析 Hologres 的最新版本都支持 ORC 格式
- AliORC 是对 ORC 的深度定制版
3.5.1 AliORC - 索引增强
- 支持 Clusterd Index，更快的主键查找
- 支持 Bitmap Index，更快的过滤
- Roaring Bitmap
- 更高效的压缩保存 Bitmap Index
- 以 16 bit 的 bitmap 空间为一个保存单元，每个单元可以是以下三种形式之一：
- Array Container：只保存为 1 的 Index
- Run Container：类似 RLE 编码
- Bitset container：原始 bitmap 存储
- Roaring Bitmap
3.5.2 AliORC - 小列聚合
- 小列聚合，减少小 IO
- 重排 ColumnChunk
3.5.3 AliORC - 异步读取
- 异步预取数据
- 在计算引擎处理已经读到的数据的时候，异步去预取下一批次数据
3.6 Parquet vs ORC 对比
- 从原理层面，最大的差别就是对于 NestedType 和复杂类型处理上
- Parquet 的算法上要复杂很多，带来的 CPU 的开销比 ORC 要略大
- ORC 的算法上相对加单，但是要读取更多的数据
- 因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
3.6.1 Parquet vs. ORC 对比 - 性能
- 场景：Full Table Scan 平台：推测 Hive 时间：2016
- 图1：简单 Schema 图2：复杂 Schema
- Parquet 在复杂 Schema 场景下的算法开销影响较大
3.6.2 Parquet vs. ORC 对比 - 性能
- 场景：BigBench 时间：2020
- 在 Spark 场景下 Parquet 工作的更好，在 Hive 场景下ORC 工作的更好
- Hive
- Spark
3.6.3 Parquet vs. ORC 对比 - 选择
- 最新版本来看，Parquet 和 ORC 在性能上没有非常明显的差距和短板
- 性能上很多情况下依赖于数据集和测试环境，不能迷信 Benchmark 结果
- 根据实际业务做细粒度的调优
- Spark 生态下 Parquet 比较普遍
- Hive 生态下 ORC 有原生支持
- 整体上，Spark 比 Hive 更加有优势，所以大部分情况下，Parquet 可能是个更好的选择
4. 列存演进
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+ 倍的提升
