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

0 引言

思维导图.png

1 列存vs行存

数据格式层概述：

计算层（Compute Layer）：各种计算引擎（Rows + Columns），比如Spark、Flink、ClickHouse、Mysql
数据格式层（Format Layer）：定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件（Layout + Schema）
存储层（Storage Layer）：承载数据的持久化存储（File，Blocks），比如HDFS、ObjectStorage、NAS、Disk

OLTP比较OLAP.png
两种数据查询分析场景:OLTP vs. OLAP：

OLTP用于行式存储格式(行存)，每行的数据在文件上是连续存储的，读取整行数据效率高，单次IO顺序读即可。
OLAP用于列式存储格式(列存)，每列的数据在文件上是连续存储的，读取整列的效率较高，同列的数据类型一致，压缩编码的效率更好。

行存vs.列存总结：

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

2 Parquet原理详解

Dremel数据模型.png
Dremel数据模型讲解：
Dremel数据模型可以使用Protocol Buffer定义，支持可选和重复字段，支持嵌套类型。Continued 的嵌套类型只保存叶子节点数据。

Repetition Level：该字段在Field Path上第几个重复字段上出现
Definition Level：用来记录在fieldpath中，有多少个字段是可以不存在(optional/repeated)而实际出现的
Re-Assembly：根据全部或者部分列数据，重新构造Record，构造FSM状态机，根据同一个Column下一个记录的RepetionLevel决定继续读的列

数据布局.gif
数据布局：

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

编码Encoding：

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

压缩Compression：
Page完成Encoding以后，进行压缩支持多种压缩算法。建议选择snappy或者zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响。

snappy：压缩速度快，压缩比不高，适用于热数据
gzip：压缩速度慢，压缩比高，适用于冷数据
zstd：新引入的压缩算法，压缩比和gzip差不多，而且压缩速度比肩Snappy

索引Index：
和传统的数据库相比，索引支持不好。在Min-Max Index引入引入Bloom Filter加速过滤匹配判定，每个ColumnChunk的头部保存Bloom Filter数据，Footer记录Bloom Filter的page offset。

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

过滤下推Predicate PushDown：
parquet-mr库实现，实现高效的过滤机制，引擎侧传入Filter Expression。

parquet-mr转换成具体Column的条件匹配
查询Footer里的Column Index，定位到具体的行号
返回有效的数据给引擎侧

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

向量化读开关:
spark.sql.parquet.enableVectorizedReader

3 ORC详解和对比

数据模型ORC.png 数据模型：

create table Foobar (
myInt int,
myMap map<string,struct<myString:string,myDouble:double>>,
myTime timestamp
);

ORC会给包括根节点在内的中间节点都创建一个Column（上面例子会创建8个Column）
嵌套类型或者集合类型支持和Parquet差别较大
optional和repeated 字段依赖父节点记录额信息来重新Assembly数据

数据布局ORC.png 数据布局：

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

ACID特性简介：
支持Hive Transactions实现，目前只有Hive本身集成；类似数据湖；基于Base+Delta+Compaction的设计。

AliORC讲解：

索引增强：支持Clusterd lndex，更快的主键查找支持Bitmap Index，更快的过滤Roaring Bitmap
小列聚合：小列聚合，减少小IO，重排Chunk
异步预取：异步预取数据，计算逻辑和数据读取并行化

Parquet vs.ORC 对比：

从原理层面，最大的差别就是对于NestedType和复杂类型处理上。Parquet的算法上要复杂很多，带来的CPU的开销比ORC要略大。ORC的算法上相对简单，但是要读取更多的数据。
Spark生态下Parquet比较普遍，Hive生态下ORC有原生支持。

4 列存演进

数仓中的列存：
ClickHouse的MergeTree引擎也是基于列存构建的，默认情况下列按照Column拆分的，支持更加丰富的索引，湖仓一体的大趋势。

存储侧下推：
更多的下推工作下沉到存储服务侧。越接近数据，下推过滤的效率越高（例如AWS S3 Select功能）。挑战（存储侧感知Schema、计算生态的兼容和集成）

Column Family支持：

Hudi数据湖场景下，支持部分列的快速更新。深度改造Hudi的Update和Query逻辑，根据Column Family选择覆盖对应的Column Family。
在Parquet格式里引入Column Family概念，把需要更新的列拆成独立的Column Family。

5 实操课-简易列式存储

Github地址：github.com/theMYang/da…
代码结构.png 理解列存数据排布，以列存格式写入数据并正确读出。

写入流程.png
写入流程：

将各行数据拆分，分别存储在对应的ChunkWriter中；
写入达到块长度或者数据写入完毕，持久化数据（输出流）并生成块元数据（数据+信息）；
完成写入，将文件元信息到输出流，在文件最后记录元数据字节数。

读取流程：

读取元数据，获取各block各个列信息；
根据请求读取列数据；
读取的数据拼成Record返回。

引用参考

【大数据专场学习资料五】第四届字节跳动青训营

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