这是我参与「第四届青训营」笔记创作活动的第14天。
ORC 详解
Apache ORC(optimizedRC File) 存储源自于RC这种存储格式，产生于 Hive 项目，是一种列式存储引擎，对schema的变更(修改schema需要重新生成数据)支持较差，主要是在压缩编码、查询性能方面做了优化。是大数据分析领域使用最广的列存格式之一。
数据模型
ORC 会给包括根节点在内的中间节点都创建一个 Column。下图中创建 8 个 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 的设计。
Parquet vs ORC 对比
原理层面上最大的差别就是对于 NestedType 和复杂类型处理上，Parquet 的算法上要复杂很多，带来的 CPU 的开销比 ORC 要略大。 ORC 的算法上相对简单，但是要读取更多的数据。因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
选择
两者在性能上没有非常明显的差距与优势。
-
根据实际业务做充分的测试调优
-
Spark 生态下 Parquet 比较普遍
-
Hive 生态下 ORC 有原生支持
-
整体上，Spark 比 Hive 更加有优势，所以大部分情况下，Parquet 可能是个更好的选择
列存演进
数仓列存
- 典型的数仓，例如 ClickHouse 的引擎也是基于列存构建的。支
- 持更加丰富的索引，例如 Bitmap Index、Reverted Index、Data Skipping Index等
- 湖仓一体的大趋势下，数仓和大数据数据湖技术和场景下趋于融合，大数据场景下的格式层会借鉴更多的数仓中的技术
存储侧下推
- 更多的下推工作下沉到存储服务侧
- 越接近数据，下推过滤的效率越高
- 例如 AWS S3 Select 功能
- 挑战：
- 存储侧感知 Schema
- 计算生态的兼容和集成
Column Family 支持
背景： Hudi 数据湖场景下，支持部分列的快速更新
- Parquet引入 Column Family 概念，把需要更新的列拆成独立的 Column Family
- 深度改造 Hudi 的 Update 和 Query 逻辑，根据 Column Family 选择覆盖对应的 Column Family
- Update 操作实际效果有 10+ 倍的提升
总结
ORC是大数据分析领域使用最广的列存格式之一。总体而言Spark 比 Hive 更加有优势，大部分情况下Parquet 也许是更好的选择。
