这是我参与「第四届青训营 」笔记创作活动的第10天
数据格式层概述
- 计算层：各种计算引擎
- 存储层：承载数据的持久化存储
- 数据格式层：定义了存储层文件内部的组织格式 计算引擎通过格式层的支持来读写文件
行存 VS 列存
- 格式层定义了数据的布局，连接计算引擎和存储服务
- OLTP和OLAP场景话差异明显
- 业务场景决定了技术实现，行存适用于OLTP,列存适用于OLAP
Parquet原理
数据布局
- RowGroup:每一个行组包含一定数量或者固定大小的行的集合
- ColumnChunk:RowGroup中按照列切分成多个 ColumnChunk
- Page:ColumnChunk内部续切分成Page,般建 议8KB大小。压缩和编码的基本单元
- 根据保存的据类型分为：Data Page,Dictionary Page,Index Page
- Footer保存文件的元信息 Schema
- Config
- Metadata
- RowGroup Meta
- Column Meta
- RowGroup Meta
编码Encoding
- Plain直接存储原始数据
- Run Length Encoding(RLE:适用于列基数不大, 重复值较多的场景，例收如：Boolean、枚举、固定的选项等
- Bit-Pack Encoding:配合RLE编码使用，让整形数字存储的更劻加紧凑
- 字典编码Dictionary Encoding:适用于列基数不大的场景，构造字典表写入到Dictionary Page;把据用字典Index替换，然后用RLE编码
压缩Compression
- Page完成Encoding以后，进行压缩
- 支持多种压缩算法
- snappy:压缩速度快，压缩比不高， 适用于热据
- gzip:压缩速度慢，压缩比高，适用于冷数据
- Zstd:新引入的压缩算法，压缩比和gzip差不多，而且 压缩速度比肩Snappy
- 建议选择snappy或者zstd,根据业务据类型充分测 试压缩效果，以及对查询性能的影响
ORC
大数据分析领域使用最广的列存格式之一 ,出自于Hive项目
Parquet VS ORC对比
- 从原理层面，最大的差别就是对于NestedType和复杂类型处理上
- Parquet的算法上要复杂很多，带来的CPU的开销比ORC要略大
- ORC的算法上相对简单，但是要读取更多的数据
- 因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实 际的务场景
Parquet和ORC的选择
- 最新的版本来看，Parquet和ORC在性能上没有非常明显的差距和短板
- 性能上很多情况下依赖于数据集和环境，不能迷信Benchmark结果
- 根据实际业务做充分的测试调优
- Spark生态下Parquet比较普遍
- Hive生态下ORC有原生支持
- 整体上，Spark比Hive更加有优势，所以大部分情况下，Parquet可能是个更好的选择
