这是我参与「第四届青训营 」笔记创作活动的的第13天

一、列存vs行存

数据格式层概述

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

分层视角下的数据形态

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

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

• 每行的数据在文件上是连续存储的

• 读取整行数据效率高，单次10顺序读即可

• 典型系统

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

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

• 每列的数据在文件上是连续存储的

• 读取整列的效率较高

• 同列的数据类型一 致，压缩编码的效率更好

• 典型系统

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

二、Parquet原理详解

编码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详解

数据模型

• 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的设计

Parquet vs. ORC对比

• 从原理层面，最大的差别就是对于NestedType和复杂类型处理上
• Parquet的算法上要复杂很多，带来的CPU的开销比ORC要略大
• ORC的算法上相对简单，但是要读取更多的数据
• 因此，这个差异的对业务效果的影响，很难做一个定性的判定， 更多的时候还是要取决于实际的业务场景