列存和行存
数据格式层概述
- 计算层:各种计算引擎
- 存储层:承载数据的持久化存储
- 数据格式层:定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件
分层视角下的数据形态
- 存储层: File, Blocks
- 格式层: File 内部的数据布局(Layout + Schema)
- 计算引擎: Rows + Columns
两种数据查询分析场景
OLTP:行式存储格式(行存)
- 每行的数据在文件上是连续存储的
- 读取整行数据效率高，单次10顺序读即可
- 典型系统
- 关系型数据库: MySQL, Oracle...
- Key-Value数据库
OLAP:列式存储格式(列存)
- 每列的数据在文件上是连续存储的
- 读取整列的效率较高
- 典型系统
- 大数据分析系统: SQL-on-Hadoop, 数据湖分析
- 数据仓库: ClickHouse, Greenplum, 阿里云MaxCompute
- 定义
- 列式存储是指一列中的数据在存储介质中是连续存储的；
- 行式存储是指一行中的数据在存储介质中是连续存储的。
- 比较不同
- 格式层定义了数据的布局，连接计算弓|擎和存储服务
- OLTP和OLAP场景话差异明显
- 业务场景决定了技术实现，行存适用于OLTP,列存适用于OLAP
Parquet原理详解
简介
- 大数据分析领域使用最广的列存格式
- Spark推荐存储格式
Dremel数据模型
- Protocol Buffer定义
- 支持可选和重复字段
- 支持嵌套类型
数据布局
- RowGroup:每一个行组包含一定数量或者固定大小的行的集合
- ColumnChunk: RowGroup中按照列切分成多个ColumnChunk
- Page: ColumnChunk内部继续切分成 Page,一般建议8KB大小。压缩和编码的基本单元
- Footer保存文件的元信息
编码Encoding
- Plain直接存储原始数据
- Run Length Encoding (RLE):适用于列基数不大，重复值较多的场景，例如: Boolean、 枚举、固定的选项等
- 字典编码Dictionary Encoding:适用于列基数不大的场景，构造字典表，写入到Dictionary Page;把数据用字典Index替换，然后用RLE编码
压缩 Compression
- Page完成Encoding以后，进行压缩
- 支持多种压缩算法
- snappy:压缩速度快，压缩比不高，适用于热数据
- gzip:压缩速度慢，压缩比高，适用于冷数据
- zstd:新引入的压缩算法，压缩比和gzip差不多，而且压缩速度比肩Snappy
- 建议选择snappy或者zstd,根据业务数据类型充分测试压缩效果，以及对查询性能的影响
索引Index
- 和传统的数据库相比，索3支持非常简陋
- 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‘’
过滤下推Predicate PushDown
- parquet-mr库实现，实现高效的过滤机制
- 引擎侧传入Filter Expression
- parquet-mr转换成具体Column的条件匹配
- 查询Footer里的Column Index,定位到具体的行号
- 返回有效的数据给引擎侧
Spark集成-向量化读
- ParquetFileFormat类
- 向量化读开关:spark.sql.parquet.enableVectorizedReader
- 向量化读是主流大数据分析引|擎的标准实践，可以极大的提升查询性能
- Spark以Batch的方式从Parquet读取数据，下推的逻辑也会适配Batch的方式
Parquet是一种常见的列式存储文件格式，常用于Pig, Spark, Hive等大数据组件中，其后缀是.parquet。
核心特点有：
- 跨平台
- 可被各种文件系统识别的格式
- 按列存储数据
- 存储元数据
Parquet 是语言无关的，而且不与任何一种数据处理框架绑定在一起。所以适配多种计算框架
ORC详解
简介
大数据分析领域使用最广的列存格式之一
数据模型
- ORC会给包括根节点在内的中间节点都创建一个Column
- 嵌套类型或者集合类型支持和Parquet差别较大
- optional和repeated字段依赖父节点记录额信息来重新Assembly数据
数据布局
- 类似Parquet
- Rooter + Stripe + Column + Page (Row Group)结构
- Encoding / Compression / Index支持上和Parquet几乎一致
ACID特性简介
- 支持Hive Transactions实现，目前只有Hive 本身集成
- 类似Delta Lake / Hudi / lceberg
- 基于Base + Delta + Compaction的设计
AliORC
- ORC在阿里云计算平台被广泛应用，主流产品MaxCompute +交互式分析Hologres的最新版本都支持ORC格式
- AliORC是对ORC的深度定制版
自我思考
ORC的全称是(Optimized Record Columnar)，使用ORC文件格式可以提高hive读、写和处理数据的能力。
ORC文件以二进制方式存储，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。
Parquet和ORC对比
- 从原理层面，最大的差别就是对于NestedType和复杂类型处理上
- Parquet的算法.上要复杂很多，带来的CPU的开销比ORC要略大
- ORC的算法上相对简单，但是要读取更多的数据
- 因此，这个差异的对业务效果的影响，很难做一个定性的判定， 更多的时候还是要取决于实际的业务场景
