这是我参与「第四届青训营 」笔记创作活动的第18天
资料来源于[这](【大数据专场 学习资料五】第四届字节跳动青训营 - 掘金 (juejin.cn))
03.ORC详解
数据模型
ORC 会给包括根节点在内的中间节点都创建一个 Column
下图中，会创建 8 个 Column
嵌套类型或者集合类型支持和 Parquet 差别较大
数据布局
类似 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 的深度定制版
其他优化
小列聚合，减少小 IO
- 重排 ColumnChunk
异步预取优化
在计算引擎处理已经读到的数据的时候，异步去预取下一批次数据
04. Parquet vs ORC 对比
从原理层面，最大的差别就是对于 NestedType 和复杂类型处理上
Parquet 的算法上要复杂很多，带来的 CPU 的开销比 ORC 要略大
ORC 的算法上相对加单，但是要读取更多的数据
因此，这个差异的对业务效果的影响，很难做一个定性的判定，更多的时候还是要取决于实际的业务场景
性能对比 1
Parquet 在复杂 Schema 场景下的算法开销影响较大
测试平台 Hive，Hive 上 ORC 更有优势
2016年
简单 Schema 复杂 Schema
性能对比 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+ 倍的提升
