Parquet 和 ORC:高性能列式存储笔记(二)| 青训营笔记

218 阅读3分钟

Parquet 和 ORC:高性能列式存储笔记(二)| 青训营笔记

这是我参与「第四届青训营 -大数据场」笔记创作活动的第18天

三、ORC 详解

1. ORC 简介

  • orc.apache.org/
  • 产生于 Hive 项目
  • 大数据分析领域使用最广的列存格式之一

2. 数据模型

  • ORC 会给包括根节点在内的中间节点都创建一个 Column
  • 下图中,会创建 8 个 Column
  • 嵌套类型或者集合类型支持和 Parquet 差别较大
  • optional 和 repeated 字段依赖父节点记录额外信息来重新 Assembly 数据

image.png

3. 数据布局

  • 类似 Parquet
  • Rooter + Stripe + Column + Page (Row Group) 结构
  • Encoding / Compression / Index 支持上和 Parquet 几乎一致

image.png

4. ACID 特性

  • 支持 Hive Transactions 实现,目前只有 Hive 本身集成
  • 类似 Delta Lake / Hudi / Iceberg
  • 基于 Base + Delta + Compaction 的设计

image.png

5. AliORC

  • ORC 在阿里云计算平台被广泛应用,主流产品 MaxCompute + 交互式分析 Hologres 的最新版本都支持 ORC 格式
  • AliORC 是对 ORC 的深度定制版
5.1 索引增强
  • 支持 Clusterd Index,更快的主键查找

  • 支持 Bitmap Index,更快的过滤

    • Roaring Bitmap

      • 更高效的压缩保存 Bitmap Index

      • 以 16 bit 的 bitmap 空间为一个保存单元,每个单元可以是以下三种形式之一:

        • Array Container:只保存为 1 的 Index
        • Run Container:类似 RLE 编码
        • Bitset container:原始 bitmap 存储

image.png

5.2 小列聚合
  • 小列聚合,减少小 IO

    • 重排 ColumnChunk

image.png

5.3 异步预取
  • 在计算引擎处理已经读到的数据的时候,异步去预取下一批次数据

image.png

6. Parquet vs.ORC 对比

  • 从原理层面,最大的差别就是对于 NestedType 和复杂类型处理上
  • Parquet 的算法上要复杂很多,带来的 CPU 的开销比 ORC 要略大
  • ORC 的算法上相对加单,但是要读取更多的数据
  • 因此,这个差异的对业务效果的影响,很难做一个定性的判定,更多的时候还是要取决于实际的业务场景
6.1 性能对比 1
  • Parquet 在复杂 Schema 场景下的算法开销影响较大
  • 测试平台 Hive,Hive 上 ORC 更有优势
  • 2016年

image.png

image.png

6.2 性能对比 2
  • 在 Spark 场景下 Parquet 工作的更好;在 Hive 场景下,ORC 更好

image.png

image.png

6.3 选择
  • 最新的版本来看,Parquet和ORC在性能上没有非常明显的差距和短板
  • 性能上很多情况下依赖于数据集和测试环境,不能迷信Benchmark结果
  • 根据实际业务做充分的测试调优
  • Spark生态下Parquet比较普遍
  • Hive生态下ORC有原生支持
  • 整体上,Spark比Hive更加有优势,所以大部分情况下,Parquet可能是个更好的选择。

7. ORC 小结

  • 数据模型,和 Parquet 差异
  • ACID 支持
  • Parquet 对比和选择

四、列存演进

1. 数仓中的列存

  • 典型的数仓,例如 ClickHouse 的 MergeTree 引擎也是基于列存构建的

    • 默认情况下列按照 Column 拆分成单独的文件,也支持单个文件形式
  • 支持更加丰富的索引,例如 Bitmap Index、Reverted Index、Data Skipping Index、Secondary Index 等

  • 湖仓一体的大趋势下,数仓和大数据数据湖技术和场景下趋于融合,大数据场景下的格式层会借鉴更多的数仓中的技术

image.png

2. 存储侧下推

  • 更多的下推工作下沉到存储服务侧
  • 越接近数据,下推过滤的效率越高
  • 例如 AWS S3 Select 功能

image.png

  • 挑战:

    • 存储侧感知 Schema
    • 计算生态的兼容和集成

3. Column Family 支持

  • 背景:Hudi 数据湖场景下,支持部分列的快速更新
  • 在 Parquet 格式里引入 Column Family 概念,把需要更新的列拆成独立的 Column Family
  • 深度改造 Hudi 的 Update 和 Query 逻辑,根据 Column Family 选择覆盖对应的 Column Family
  • Update 操作实际效果有 10+ 倍的提升

image.png

五、课程总结

  • 列存的适用场景,和行存的区别
  • Parquet 和 ORC 的原理,以及对比和选择
  • 列存的演进