列存和行存

数据格式层概述

• 计算层:各种计算引擎
• 存储层:承载数据的持久化存储
• 数据格式层:定义了存储层文件内部的组织格式，计算引擎通过格式层的支持来读写文件

分层视角下的数据形态

• 存储层: File, Blocks
• 格式层: File 内部的数据布局(Layout + Schema)
• 计算引擎: Rows + Columns

两种数据查询分析场景

OLTP:行式存储格式(行存)

1. 每行的数据在文件上是连续存储的
2. 读取整行数据效率高，单次10顺序读即可
3. 典型系统

• 关系型数据库: MySQL, Oracle...
• Key-Value数据库

OLAP:列式存储格式(列存)

1. 每列的数据在文件上是连续存储的
2. 读取整列的效率较高
3. 典型系统

• 大数据分析系统: SQL-on-Hadoop, 数据湖分析
• 数据仓库: ClickHouse, Greenplum, 阿里云MaxCompute

1. 定义

• 列式存储是指一列中的数据在存储介质中是连续存储的；
• 行式存储是指一行中的数据在存储介质中是连续存储的。

1. 比较不同

• 格式层定义了数据的布局，连接计算弓|擎和存储服务
• 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的算法上相对简单，但是要读取更多的数据
• 因此，这个差异的对业务效果的影响，很难做一个定性的判定， 更多的时候还是要取决于实际的业务场景