这是我参与「第四届青训营」笔记创作活动的的第18天
1、 列存 Vs 行存
概述数据格式层的作用和定位，对比列式存储和行式存储的基本原理和使用场景
1.1 数据格式层概述
- 计算层:各种计算引擎
- 存储层:承载数据的持久化存储
- 数据格式层:定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件
数据查询分析服务
1.2 分层视角下的数据形态
● 存储层: File, Blocks
● 格式层: File 内部的数据布局(Layout + Schema)
● 计算引擎: Rows + Columns
1.3 两种数据查询分析场景: OLTP Vs. OLAP
1.4 OLTP:行式存储格式(行存)
● 每行的数据在文件上是连续存储的
● 读取整行数据效率高，单次IO顺序读即可
● 典型系统
1）关系型数据库: MySQL, Oracle ....
2）Key-Value数据库
1.5 OLAP:列式存储格式(列存)
● 每列的数据在文件. 上是连续存储的
● 读取整列的效率较高
● 同列的数据类型一致，压缩编码的效率更好
● 典型系统
1）大数据分析系统: SQL -on-Hadoop,数据湖分析
2）数据仓库: ClickHouse, Greenplum, 阿里云MaxCompute
1.6 行存vs.列存总结
1）格式层定义了数据的布局，连接计算引擎和存储服务
2）OLTP和OLAP场景话差异明显
3）业务场景决定了技术实现，行存适用于OLTP，列存适用于OLAP
2、 Parquet原理详解
2.1 Parquet 简介
2）大数据分析领域使用最广的列存格式
3）Spark 推荐存储格式
4）Github paretvormat :格式定义 parquet-mr: Java实现
2.1.1 Parquet in Action - DDL
CREATE TABLE lineitem (
I_ orderkey int,
l_ partkey int,
STORED AS PARQUET TBLPROPERTIES ("parquet.compression"-
"SNAPPY");
Hive Table using Parquet
2.1.2 Parquet in Action - Spark
INSERT INTO lineitem SEL ECT * from tpch10g. lineitem;
Load Data using SparkSQL
2.1.3 Parquet in Action - Spark
- Spark 生成的文件会有.parquet后缀
- Hive 生成的文件没有后缀
2.1.4 Parquet in Action - Parquet VS. Text Format
Parquest
Text
2.1.5 Parquet in Action - Spark
▪️ parquet-cli工具查看parquet文件的具体信息
▪️ github.com/apache/parq… cli/README.md
2.2 Dremel数据模型
▪️ Protocol Buffer定义
▪️ 支持可选和重复字段
▪️ 支持嵌套类型
2.2.1 Dremel数据模型一Continued
▪️ 嵌套类型只保存叶子节点数据
▪️ 问题:由于列可能是Optional和Repeated,如何把列内的数据对应到逻辑视图里的Record呢?
2.3 数据布局
▪️ RowGroup:每-个行组包含一定数 量或者固定大小的行的集合
▪️ ColumnChunk: RowGroup中按照列切分成多个ColumnChunk
▪️ Page: ColumnChunk内部继续切分成Page,一般建议8KB大小。压缩和编码的基本单元
- 根据保存的数据类型分为: Data Page, Dictionary Page, Index Page
▪️ Footer保存文件的元信息
1）Schema
2）Config
3）Metadata
- RowGroup Meta
[i] Column Meta
2.4 编码Encoding
▪️ Plain直接存储原始数据
▪️ Run Length Encoding (RLE):适用于列基数不大，重复值较多的场景，例如: Boolean、 枚举、固定的选项等
- Bit- Pack Encoding:配合RLE编码使用，让整形数字存储的更加紧凑
▪️ 字典编码Dictionary Encoding:适用于列基数不大的场景，构造字典表，写入到Dictionary Page;把数据用字典Index替换，然后用RLE编码
2.4.1 编码 Encoding
1）默认场景下parquet-mr会自动根据数据特征选择
2）业务自定义:
org.apache.parquet.column.values.factory.ValuesWriterFactory
2.5 压缩Compression
● Page完成Encoding以后，进行压缩
● 支持多种压缩算法
● snappy:压缩速度快，压缩比不高，适用于热数据
● gzip:压缩速度慢，压缩比高，适用于冷数据
● zstd:新引入的压缩算法，压缩比和gzip差不多，而且压缩速度比肩Snappy
● 建议选择snappy或者zstd,根据业务数据类型充分测试压缩效果，以及对查询性能的影响
2.5.1 压缩 Compression - 对比
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
1）parquet.bloom.filter. enabled
2）对于列基数比较大的场景，或者非排序列的过滤，Min-Max Index很难发挥作用
3）引入Bloom Filter 加速过滤匹配判定
4）每个ColumnChunk的头部保存Bloom Filter 数据
5）Footer记录Bloom Filter的page offset
2.6.2 排序Ordering
1）类似于聚集索引的概念
2）排序帮助更好的过滤掉无关的RowGroup或者Page
- 对于少量数据Seek很有帮助
3）Parquet Format支持SortingColumns
4）Parquet Library目前没有支持
5）依赖业务侧根据查询特征去保证顺序
2.7 过滤下推Predicate PushDown
1）parquet-mr库实现，实现高效的过滤机制
2）引擎侧传入 Filter Expression
3）parquet-mr转换成具体Column的条件匹配
4）查询Footer里的Column Index,定位到具体的行号
5）返回有效的数据给引擎侧
Spark 3.2.0 x1
issues.apache.org/jira/browse… 26345
https://issues apache.org/jira/browse/PARQUET-1201
2.8 Spark集成 - 向量化读
▪️ ParquetFileFormat类
▪️ 向量化读开关:spark.sql.parquet.enableVectorizedReader
▪️ 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能
▪️ Spark以Batch的方式从Parquet读取数据，下推的逻辑也会适配Batch的方式
2.9 深入Dremel数据模型- Repetition Level
▪️ Repetition L evel:该字段在Field Path上第几个重复字段上出现
1）0:标识新的Record
2）Name.L .anguage.Code为例，Name是第1个重复字段，Language是第2 个重复字段
2.9.1 深入Dremel数据模型一Definition Level
● Definition L evel:用来记录在field path中，有多少个字段是可以不存在 (optional/repeated)而实际出现的
● Name.Language.Code为例，Name和Language都是可以不存在的
● 第一个NULL字段，D是1说明Name是存在的，但是Language是不存在的，保留原有的信息
2.9.2 深入Dremel数据模型- Re-Assembly
● 根据全部或者部分列数据，重新构造Record
● 构造FSM状态机
● 根据同一个Column下一个记录的RepetionLevel决定继续读的列
2.10 Parquet小结
1）数据模型:基于Dremel
2）文件布局: Footer + RowGroup + ColumnChunk + Page
3）Encoding: Page粒度，Plain / RLE / Dictionary
4）Compression: Snappy / Gzip / Zstd
5）Index: Column Index ( Min-Max Index )
6）Predicate PushDown
3、 ORC详解
3.1 ORC 简介
● 大数据分析领域使用最广的列存格式之一
● 出自于Hive项目
● CREATE TABLE table_ name ( X INT, y STRING) STORED AS ORC;
3.2 数据模型
● ORC会给包括根节点在内的中间节点都创建一个Column
1）下图中，会创建8个Column
● 嵌套类型或者集合类型支持和Parquet差别较大
● optional和repeated字段依赖父节点记录额信息来重新Assembly数据
3.3 数据布局
▪️ 类似 Parquet
▪️ Rooter + Stripe + Column + Page (Row Group) TA
▪️ Еnсоdіn/Соmрrеѕѕіоn Іndех 支持上和 Раrquеt 几乎一致
3.4 ACID 特性简介
1）支持Hive Transactions实现，目前只有Hive本身集成
2）类似 Delta Lake / Hudi / Iceberg
3）基于 Base + Delta + Compaction 的设计
3.5 AliORC
1）ORC在阿里云计算平台被广泛应用，主流产品MaxCompute +交互式分析Hologres的最新版本都支持ORC格式
2）AliORC是对ORC的深度定制版
3.5.1 AliORC - 索引增强
1）支持Clusterd Index,更快的主键查找
2）支持 Bitmap Index, 更快的过滤
▪️ Roaring Bitmap
Bitmap Index示例
3.5.2 AliORC - 小列聚合
▪️ 小列聚合，减少小I0
1）重排 Chunk
3.5.3 AliORC - 异步预取
● 异步预取数据
● 计算逻辑和数据读取并行化
3.6 Parquet vs. ORC对比
1）从原理层面，最大的差别就是对于NestedType和复杂类型处理上
2）Parquet的算法.上要复杂很多，带来的CPU的开销比ORC要略大
3）ORC的算法.上相对简单，但是要读取更多的数据
4）因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
3.6.1 Parquet vs. ORC对比 - 性能
1）场景: Full Table Scan 平台: 推测Hive 时间: 2016
2）左边:简单Schema 右边:复杂Schema
3）Parquet在复杂Schema场景下的算法开销影响较大
3.6.2 Parquet vs. ORC对比 - 性能
1）场景: BigBench 时间: 2020
2）结论:在Spark场景下Parquet工作的更好;在Hive场景下，ORC更好
Spark
Hive
3.6.3 Parquet vs. ORC对比 - 选择
- 最新的版本来看，Parquet 和ORC在性能.上没有非常明显的差距和短板
- 性能上很多情况下依赖于数据集和测试环境，不能迷信Benchmark结果
- 根据实际业务做充分的测试调优
- Spark 生态下Parquet比较普遍
- Hive生态下ORC有原生支持
整体上，Spark 比Hive更加有优势，所以大部分情况下，Parquet 可能是个更好的选择。
3.7 ORC小结
- 数据模型，和Parquet差异 2) ACID支持 3) Parquet对比和选择
4、 列存演进
4.1 数仓中的列存
▪️ ClickHouse的MergeTree引擎也是基于列存构建的
▪️ 默认情况下列按照Column拆分的
▪️ 支持更加丰富的索引
▪️ 湖仓一体的大趋势
4.2 存储侧下推
▪️ 更多的下推工作下沉到存储服务侧
▪️ 越接近数据，下推过滤的效率越高
▪️ 例如AWS S3 Select功能
▪️ 挑战: 1）存储侧感知Schema 2）计算生态的兼容和集成
4.3 Column Family支持
▪️ 背景: Hudi数据湖场景下，支 持部分列的快速更新
▪️ 在Parquet格式里引入Column Family概念，把需要更新的列拆成独立的Column Family
▪️ 深度改造Hudi的Update和Query逻辑，根据Column Family选择覆盖对应的Column Family
▪️ Update操作实际效果有10+倍的提升
