这是我参与「第四届青训营 」笔记创作活动的第5天
ORC 详解
- 产生于 Hive 项目
- 大数据分析领域使用最广的列存格式之一
数据模型（支持复杂格式）
- ORC 会给包括根节点在内的中间节点都创建一个 Column
- 嵌套类型或者集合类型支持和 Parquet 差别较大
- optional 和 repeated 字段依赖父节点记录额外信息来重新 Assembly 数据
数据布局
- 类似 Parquet
- Rooter + Stripe + Column + Page (Row Group) 结构
- Encoding / Compression / Index 支持上和 Parquet 几乎一致，都是基于一些常见的压缩算法
ACID 特性
- 支持 Hive Transactions 实现，目前只有 Hive 本身集成
- 类似 Delta Lake / Hudi / Iceberg
- 基于 Base + Delta + Compaction 的设计
AliORC
- ORC 在阿里云计算平台被广泛应用，主流产品 MaxCompute + 交互式分析 Hologres 的最新版本都支持 ORC 格式
- AliORC 是对 ORC 的深度定制版
索引增强
- 支持 Clusterd Index，更快的主键查找
- 支持 Bitmap Index，更快的过滤
- Roaring Bitmap
- 更高效的压缩保存 Bitmap Index
- 以 16 bit 的 bitmap 空间为一个保存单元，每个单元可以是以下三种形式之一：
- Array Container：只保存为 1 的 Index
- Run Container：类似 RLE 编码
- Bitset container：原始 bitmap 存储
- Roaring Bitmap
其他优化
-
小列聚合，减少小 IO
- 重排 ColumnChunk 和具体的query场景有一定依赖
-
异步预取优化
- 计算逻辑和数据读取并行化：在计算引擎处理已经读到的数据的时候，异步去预取下一批次数据
Parquet vs ORC 对比
- 从原理层面，最大的差别就是对于 NestedType 和复杂类型处理上
- Parquet 的算法上要复杂很多，带来的 CPU 的开销比 ORC 要略大
- ORC 的算法上相对加单，但是要读取更多的数据
- 因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
性能对比 1
- Parquet 在复杂 Schema 场景下的算法开销影响较大
- 测试平台 Hive，Hive 上 ORC 更有优势
- 2016年
性能对比 2
- 在 Spark 场景下 Parquet 工作的更好；在 Hive 场景下，ORC 更好
如何选择
- 最新的版本来看，两者在性能上没有非常明显的差距和短板
- 性能上很多情况下依赖于数据集和测试环境，不能迷信 Benchmark 结果
- 根据实际业务做细粒度的调优
- Spark 生态下 Parquet 比较普遍
- Hive 生态下 ORC 有原生支持
- 整体上，Spark 比 Hive 更加有优势，所以大部分情况下，Parquet 可能是个更好的选择
列存演进
数仓中的列存
-
典型的数仓，例如 ClickHouse 的 MergeTree 引擎也是基于列存构建的
- 默认情况下列按照 Column 拆分成单独的文件，也支持单个文件形式
- 支持更加丰富的索引，例如 Bitmap Index、Reverted Index、Data Skipping Index、Secondary Index 等
- 湖仓一体的大趋势下，数仓和大数据数据湖技术和场景下趋于融合，大数据场景下的格式层会借鉴更多的数仓中的技术
存储侧下推
- 更多的下推工作下沉到存储服务侧
- 越接近数据，下推过滤的效率越高
- 例如 AWS S3 Select 功能
- 挑战：
- 存储侧感知 Schema
- 计算生态的兼容和集成
Column Family 支持
- 背景：Hudi 数据湖场景下，支持部分列的快速更新
- 在 Parquet 格式里引入 Column Family 概念，把需要更新的列拆成独立的 Column Family
- 深度改造 Hudi 的 Update 和 Query 逻辑，根据 Column Family 选择覆盖对应的 Column Family
- Update 操作实际效果有 10+ 倍的提升
