这是我参与「第四届青训营 」笔记创作活动的第13天
1. Parquet简介
数据的接入、处理、存储与查询，是大数据系统不可或缺的四个环节。随着数据量的增加，大家开始寻找一种高效的数据格式，来解决存储与查询环节的痛点。
- 高效的压缩编码，用于降低存储成本
- 高效的读取能力，用于支撑快速查询
Parquet便是在这样的背景下诞生，它有三个核心特征，为解决上述的痛点问题提供了基础。
- 列式存储
- 自带Schema
- 具备Predicate Filter特性
在行式存储中，一行的多列是连续的写在一起的，而在列式存储中，数据按列分开存储。由于同一列的数据类型是一样的，可以使用更高效的压缩编码进一步节约存储空间。
目前主要有三种手段，核心目的是尽可能只加载有符合数据的文件，而这些手段都能基于Parquet实现。
- Partition Pruning。类似于将文件分文件夹存放的思路，根据某些字段将数据进行分区，在查询时指定相应的分区条件。
- Column Projection。在查询中指定需要返回的字段，跳过不必要的字段，减少需要加载的数据量。
- Predicate Filter。先判断一个文件中是否存在符合条件的数据，有则加载相应的数据，否则跳过。
2. ORC详解
2.1 数据模型
ORC会给包括根节点在内的中间节点都创建一个Column，嵌套类型或者集合类型支持，和Parquet差别较大，optional和repeated字段依赖父节点记录额信息来重新Assembly数据
2.2 数据布局
- 类似Parquet
- Rooter + Stripe + Column + Page (Row Group)结构
- Encoding / Compression / Index支持上和Parquet几乎一致
2.3 ACID特性简介
- 支持Hive Transactions实现，目前只有Hive本身集成
- 类似Delta Lake / Hudi / lceberg
- 基于Base + Delta + Compaction的设计
2.4 Parquet vs ORC
从原理层面，最大的差别就是对于NestedType和复杂类型处理上Parquet的算法上要复杂很多，带来的CPU的开销比ORC要略大ORC的算法上相对简单，但是要读取更多的数据因此，这个差异的对业务效果的影响，很难做一个定性的判定， 更多的时候还是要取决于实际的业务场景
3 列存演进
3.1 数仓中的列存
- ClickHouse的MergeTree引擎基于列存构建
- 默认情况下按照Column拆分
- 支持更加丰富的索引
- 湖仓一体是大趋势
3.2 存储侧下推
- 更多的下推工作下沉到存储服务侧
- 越接近数据，下推过滤的效率越高
- 例如:AWS S3 的 select共呢个
3.3 Column Family支持
Hudi数据湖场景下，支持部分列的快速更新
- 在parquet中引入column family概念，把需要更新的列拆成独立的Column Family
总结
- 列式存储和行式存储的区别；
- Parquet 列存格式的原理详解；
- ORC 列存格式的原理详解，以及和 Parquet 的对比；
- 列存格式的演进；
