这是我参与「第四届青训营 」笔记创作活动的第10天！
一、列存VS行存。
1.数据格式层概述：
- 计算层:各种计算引掌
- 存储层：承载数据的持久化存储
- 数据格式层：定义了存储层文件内部的组织格式计算引摩通过格式层的支持来读写文件
2.分层视角下的数据形态：
- 存储层:File, Blocks
- 格式层:File 内部的数据布局(Layout+Schema )
- 计算引擎:Rows +Columns
3.两种数据查询分析场景：OLTP vs. OLAP
4.OLTP：行式存储格式（行存）
- 每行的数据在文件上是连续存储的
- 读取整行数据效率高，单次10顺序读即可
- 典型系统：
- 关系型数据库:MySQL, Oracle...
- Key-Value 数据库
5.OLAP：列式存储格式（列存）
- 每列的数据在文件上是连续存储的
- 读取整列的效率较高
- 同列的数据类型一致，压缩编码的效率更好
- 典型系统
- 大数据分析系统：SQL-on-Hadoop,数据湖分析
- 数据仓库:ClickHouse Greenplum,阿里云 MaxCompute
二、Parquet原理详解。
1.Parquet 简介：
- parquet.apache.org
- 大数据分折领域使用最广的列存格式
- Spark 推荐存储格式
- Github上的相应仓库
- parquet-format:格式定义
- parquet-mr: Java 实现
1.1 Parquet in Action-DDL
STORED AS PAEQUET 后面跟具体的存储格式
1.2 Parquet in Action-Spark
1.3 Parquet in Action-Spark
1.4 Parquet in Action-Parquet vs.Text Format
Text 的文件大小远大于 Parquet
Parquet虽然对文件做了压缩，但性能上还是有所提升的
1.5 Parquet in Action-Spark
- parquet-cli 工具查看parquet 文件的具体信息
- github.com/apache/parq…
2.Dremel数据模型：
Parquet的数据模型是根据Dremel的数据模型研发出来的。
- Protocol Buffer定义
- 支持可选和重复字段
- 支持嵌套类型
2.1 Dremel数据模型-Continued
- 嵌套类型只保存叶子节点数据
- 间题:由于列可能是Optional 和 Repeated,如何把列内的数据对应到逻辑视图里的 Record 呢?
3.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
4.编码 Encoding：
- Plain 直接存储原始数据
- Run Length Encoding (RLE):适用于列基数不大，重复值较多的场景，例如: Boolean.枚举、 固定的选项等
- Bit-Pack Encoding:配合RLE编码使用,让整形数字存储的更加紧凑
- 字典编码 Dictionary Encoding :适用于列基数不大的场景，构造字典表，写入到 Dictionary Page ;把数据用字典Index替换，然后用 RLE 编码
4.1编码 Encoding：
- 默认场景下parquet-mr会自动根据数据特征选择
- 业务自定义: org.apache.parquet.column.values. factory.Values WriterFactory
5.压缩Compression：
- Page完成 Encoding 以后，进行压缩
- 支持多种压缩算法
- snappy. 压缩谏度快，压缩比不高，适用于热数据
- gzip :压缩速度慢，压缩比高，话用于冷数据
- zstd :新引入的压缩算法，压缩比和 gzip差不多，而且压缩速度比肩 Snappy
- 建议选择snappy 或者zstd,根据业务数据类型充分测试压缩效果，以及对查询性能的影响
5.1 压缩Compression-对比
6.索引 Index：
- 和传统的数据库相比，索引支持非常简陋
- 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
6.1 索引 Index-Bloom Filter：
- parquet.bloom.filter.enabled
- 对于列基数比较大的场景，或者非排序列的过滤,Min-Max Index 很难发挥作用
- 引入Bloom Filter加速过滤匹配判定
- 每个ColumnChunk 的头部保存 Bloom Filter数据
- Footer 记录 Bloom Filter 的 page offset
6.2排序 Ordering
- 类似于聚集索引|的概念
- 排序帮助更好的过滤掉无关的ROWGroup 或者Page
- 对于少量数据Seek 很有帮助
- Parquet Format 支持 SortingColumns
- Parquet Library 目前没有支持
- 依赖业务侧根据查询特征去保证顺序
7.过滤下推 Predicate PushDown：
- parquet-mr 库实现，实现高效的过滤机制
- 引擎侧传入Filter Expression
- parquet-mr转换成具体Column 的条件匹配
- 查询Footer里的 Column Index,定位到具体的行号
- 返回有效的数据给引掌侧
8.Spark集成-向量化读：
- ParquetfileFormat 类
- 向量化读开关：spark.sql.parquet.enableVectorizedReader
- 向量化读是主流大数据分析引擎的标准实践，可以极大的提升查询性能
- Spark以 Batch 的方式从 Parquet读取数据，下推的逻辑也会适配 Batch 的方式
9.深入Dremel数据模型-Repetition Level
- Repetition Level该字段在 Field Path 第几个重复字段上出现
- 0:标识新的Record
- Name.Language.Code 为例，Name 是第1个重复字段,Language 是第2个重复字段
9.1 深入Dremel数据模型-Definition Level
- Definition Level:用来记录在field path中，有多少个字段是可以不存在(optional/repeated)而实际出现的
- Name.Language.Code 为例,Name 和Language 都是可以不存在的
- 第一个 NULL 字段 ，D是1,说明Name 是存在的，但是Language 是不存在的，保留原有的信息
9.2 深入Dremel数据模型-Re-Assembly
- 根据全部或者部分列数扼，重新构造Record
- 构造FSM状态机
- 根据同一个Column下一个记录的RepetionLevel决定继续读的列
三、ORC详解。
1.ORC简介：
- orc.apache.org
- 大数据分析领域使用最广的列存格式之一
- 出自于Hive 项目
- CREATE TABLE table name (X INT, y STRING)STORED AS ORC;
2.数据模型：
- ORC会给包括根节点在内的中间节点都创建一个Column
- 左图中,会创建8个 Column
- 嵌套类型或者集合类型支持和 Parquet 差别较大
- optional 和 repeated 字段依赖父节点记录额信息来重新Assembly数据
2.1思考：
NestedType 的不同实现对于1I0模型有什么影响?
3.数据布局：
- 类似Parquet
- Rooter + Stripe+Column + Page (Row Group)结构
- Encoding/ Compression/Index 支持上和Parquet几乎一致
4.ACID特性简介：
- 支持Hive Transactions 实现，目前只有 Hive 本身集成
- 类似 Delta Lake / Hudi /Iceberg
- 基于Base +Delta + Compaction 的设计
5.AliORC:
- ORC 在阿里云计算平台被广泛应用，主流产品 MaxCompute +交互式分析 Hologres的最新版本都支持ORC 格式
- AliORC 是对 ORC 的深度定制版
5.1 AliORC-索引增强：
- 支持Clusterd Index,更快的主键查找
- 支持 Bitmap Index,更快的过滤Roaring Bitmap
5.2 AliORC-小列聚合：
- 小列聚合，减少IO
- 重拍Chunk
5.3 AliORC-异步预取：
- 异步预取数据
- 计算逻辑和数据读取并行化
6.Parquet vs. ORC对比
- 从原理层面，最大的差别就是对于NestedType 和复杂类型处理上
- Parquet 的算法上要复杂很多 ,带来的CPU 的开销比 ORC要略大
- ORC的算法上相对加单 ，但是要读取更多的数据
- 因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
6.1 Parquet vs.ORC对比-性能
- 场景:Full Table Scan 平台:推测Hive 时间:2016
- 左边:简单Schema 右边：复杂 Schema
- Parquet 在复杂 Schema 场景下的算法开销影响较大
6.2 Parquet vs.ORC对比-性能
- 场景·BigBench 时间:2020
- 结论:在Spark 场景下Parquet 工作的更好；在Hive 场景下,ORC 更好
6.3 Parquet vs.ORC对比-选择
- 最新的版本来看 ,Parquet 和ORC 在性能上没有非常明显的差距和短板
- 性能上很多情况下依赖于数据集和测试环境 不能迷信Benchmark 结果
- 根据实际业务做充分的测试调优
- Spark 生态下Parquet 比较普遍
- Hive 生态下ORC有原生支持
整体上，Spark比 Hive 更加有优势，所以大部分情况下,Parquet 可能是个更好的选择。
四、列存演进。
1.数仓中的列存：
- ClickHouse 的 MergeTree 引学也是基于列存构建的
- 默认情况下列按照 Column拆分的
- 支持更加丰富的索引
- 湖仓一体的大趋势
2.存储侧下推：
- 更多的下推工作下沉到存储服务侧
- 越接近数据，下推过滤的效率越高
- 例如AWS S3 Select 功能
- 挑战:
- 存储侧感知Schema
- 计算生态的兼容和集成
3.Column Family支持
背景:Hudi 数据湖场景下，支持部分列的快速更新
- 在Parquet 格式里引入 Column Family概念，把需要更新的列拆成独立的Column Family
- 深度改造Hudi 的Update 和Query逻辑，根据Column Family'选择覆盖对应的 Column Family
- Update 操作实际效果有 10+倍的提升
总结：
经过这次课的学习，我学会了OLTP和OLAP的区别等知识，例如OLTP和OLAP适配于不同的业务场景，OLTP具有实时性、低延时、高并发、高可用的访问特征，而OLAP是具有弱事务性、近实时、大吞吐、并发相对不高、可用性可以有一定的妥协的访问特征。
