hudi 、iceberg 、paimon 比较

文件布局
●data files（数据文件）:

数据文件是Apache Iceberg表真实存储数据的文件，一般是在表的数据存储目录的data目录下，如果我们的文件格式选择的是parquet,那么文件是以“.parquet”结尾，例如：

00000-0-root_20211212192602_8036d31b-9598-4e30-8e67-ce6c39f034da-job_1639237002345_0025-00001.parquet 就是一个数据文件。

Iceberg每次更新会产生多个数据文件(data files)。
●Snapshot（表快照）：
快照代表一张表在某个时刻的状态。每个快照里面会列出表在某个时刻的所有 data files 列表。data files是存储在不同的manifest files里面，manifest files是存储在一个Manifest list文件里面，而一个Manifest list文件代表一个快照。
●Manifest list（清单列表）：
manifest list是一个元数据文件，它列出构建表快照（Snapshot）的清单（Manifest file）。这个元数据文件中存储的是Manifest file列表，每个Manifest file占据一行。每行中存储了Manifest file的路径、其存储的数据文件（data files）的分区范围，增加了几个数文件、删除了几个数据文件等信息，这些信息可以用来在查询时提供过滤，加快速度。
●Manifest file（清单文件）：
Manifest file也是一个元数据文件，它列出组成快照（snapshot）的数据文件（data files）的列表信息。每行都是每个数据文件的详细描述，包括数据文件的状态、文件路径、分区信息、列级别的统计信息（比如每列的最大最小值、空值数等）、文件的大小以及文件里面数据行数等信息。其中列级别的统计信息可以在扫描表数据时过滤掉不必要的文件。
Manifest file是以avro格式进行存储的，以“.avro”后缀结尾，例如：8138fce4-40f7-41d7-82a5-922274d2abba-m0.avro。

列式存储

Iceberg 支持使用列式存储格式（如 Parquet 和 ORC），这是其高效性的核心之一。列式存储将数据按列而非按行进行组织，每个列单独存储并压缩。这种格式有以下优点：

• 高效查询：只需读取查询涉及的列，显著减少 I/O 操作，尤其适用于仅需访问少量列的分析查询。

• 高效压缩：由于同一列内的数据类型相同，可以采用更高效的压缩算法，降低存储空间占用。

• 向量化执行：与现代查询引擎的向量化执行模式天然契合，能批量处理大量数据，提高CPU利用率。

LSM (Log-Structured Merge Tree)

虽然 Iceberg 并不直接使用 LSM 树作为底层存储结构，但其某些特性（如数据文件合并与 compaction）借鉴了 LSM 的思想。LSM 树是一种高效处理大量写入和更新的数据结构，通过将写入操作先记录在内存中的 memtable，随后定期合并到磁盘上的有序段（SSTable），并通过 compaction 过程合并段并清除无效数据。

Compaction

在 Iceberg 中，compaction 是一种数据管理操作，用于合并小文件、删除无效数据、更新元数据统计信息，并优化数据布局。Compaction 可以是手动触发或根据策略自动进行，有助于减少文件数量、提升查询性能，并保持数据集的整体健康状态。

DataSkipping

Iceberg 支持 DataSkipping 算法，允许查询引擎跳过无关数据块。这通常通过在元数据中存储数据文件的统计信息（如 min/max 值）实现，查询时可以利用这些信息进行谓词下推，避免读取不符合查询条件的数据。

Sorted Tables

Iceberg 支持创建排序表（Sorted Tables），其中数据在某个或某几个列上预排序。排序表对于涉及范围查询、窗口函数或者需要特定顺序的数据处理任务非常有利，可以进一步优化查询性能。

分区与隐藏分区（Hidden Partition）

Iceberg支持分区来加快数据查询。在Iceberg中设置分区后，可以在写入数据时将相似的行分组，在查询时加快查询速度。Iceberg中可以按照年、月、日和小时粒度划分时间戳组织分区。

在Hive中也支持分区，但是要想使分区能加快查询速度，需要在写SQL时指定对应的分区条件过滤数据，在Iceberg中写SQL查询时不需要再SQL中特别指定分区过滤条件，Iceberg会自动分区，过滤掉不需要的数据。

在Iceberg中分区信息可以被隐藏起来，Iceberg的分区字段可以通过一个字段计算出来，在建表或者修改分区策略之后，新的数据会自动计算所属于的分区，在查询的时候同样不用关心表的分区是什么字段，只需要关注业务逻辑，Iceberg会自动过滤不需要的分区数据。

正是由于Iceberg的分区信息和表数据存储目录是独立的，使得Iceberg的表分区可以被修改，而且不会涉及到数据迁移。

表演化（Table Evolution）

在Hive分区表中，如果把一个按照天分区的表改成按小时分区，那么没有办法在原有表上进行修改，需要创建一个按照小时分区的表，然后把数据加载到此表中。

Iceberg支持就地表演化，可以通过SQL的方式进行表级别模式演进，例如：更改表分区布局。Iceberg进行以上操作时，代价极低，不存在读出数据重新写入或者迁移数据这种费时费力的操作。

模式演化（Schema Evolution）

Iceberg支持以下几种Schema的演化：

• ADD:向表或者嵌套结构增加新列。

• Drop:从表或嵌套结构中移除列。

• Rename:重命名表中或者嵌套结构中的列。

• Update:将复杂结构（Struct、Map<Key,Value>,list）中的基本类型扩展类型长度，比如：tinyint修改成int。

• Reorder:改变列的顺序，也可以改变嵌套结构中字段的排序顺序。

注意：

Iceberg Schema的改变只是元数据的操作改变，不会涉及到重写数据文件。Map结构类型不支持Add和Drop字段。

Iceberg保证Schema演化是没有副作用的独立操作，不会涉及到重写数据文件，具体如下：

• 增加列时不会从另一个列中读取已存在的数据

• 删除列或者嵌套结构中的字段时，不会改变任何其他列的值。

• 更新列或者嵌套结构中字段时，不会改变任何其他列的值。

• 改变列或者嵌套结构中字段顺序的时候，不会改变相关联的值。

Iceberg实现以上的原因使用唯一的id来追踪表中的每一列，当添加一个列时，会分配新的ID，因此列对应的数据不会被错误使用。

分区演化（partition Evolution）

Iceberg分区可以在现有表中更新，因为Iceberg查询流程并不和分区信息直接关联。

当我们改变一个表的分区策略时, 对应修改分区之前的数据不会改变, 依然会采用老的分区策略, 新的数据会采用新的分区策略, 也就是说同一个表会有两种分区策略, 旧数据采用旧分区策略, 新数据采用新新分区策略, 在元数据里两个分区策略相互独立,不重合.

因此，在我们写SQL进行数据查询时, 如果存在跨分区策略的情况, 则会解析成两个不同执行计划, 如Iceberg官网提供图所示:

图中booking_table表2008年按月分区, 进入2009年后改为按天分区, 这两中分区策略共存于该表中。得益于Iceberg的隐藏分区(Hidden Partition), 针对上图中的SQL查询, 不需要在SQL中特别指定分区过滤条件（是按照月还是按照天）, Iceberg会自动分区, 过滤掉不需要的数据。

列顺序演化（Sort Order Evolution）

Iceberg可以在一个已经存在的表上修改排序策略。修改了排序策略之后, 旧数据依旧采用老排序策略不变。往Iceberg里写数据的计算引擎总是会选择最新的排序策略， 但是当排序的代价极其高昂的时候, 就不进行排序了。

ZOrder

ZOrder（或 Z-curve Ordering）是一种空间填充曲线（Space-Filling Curve），用于将多维数据映射到一维空间，从而实现高效的多维数据索引和查询。在 Iceberg 中，ZOrder 可用于对表进行物理排序，特别是在具有多个排序键的场景下。通过应用 ZOrder，Iceberg 可以将原本分散在多个分区的数据按排序键顺序排列在同一数据文件内，从而优化涉及范围查询、窗口函数或者需要特定顺序的数据处理任务。启用 ZOrder 后，查询性能可能会显著提升，尤其是对于需要跨分区扫描的查询。

Zorder排序压缩策略使得多个排序字段时，每个字段的优先级是相等的。

Zorder排序压缩策略优点是对于多个经常使用的字段可以提升读取的性能，缺点是合并压缩的时间较长。

Delta实现的z-order和Hudi、Iceberg的实现从本质上来说都是文件间的排序采用zorder， 文件内的排序任然采用线性排序的思想。这样可以在小范围查询中（查询正好落入单个文件内）使用线性排序会有更好的性能。但是不同的是生成z-value的方式上的不同，Delta生成z-value的方式是采用映射为rangeid的办法，并未采用直接转换为二进制的办法。这种方式避免了额外操作以及多次排序，但需要更多的专家经验。另外Delta的Zorder操作需要用户手动的执行优化。

Parquet BloomFilter

BloomFilter 是一种空间效率极高的概率型数据结构，用于快速判断一个元素是否可能属于一个集合，存在一定的误判率但没有漏判。在 Iceberg 使用的 Parquet 文件格式中，可以为特定列启用 BloomFilter，以加速谓词过滤。启用 BloomFilter 后，查询引擎在处理查询条件时，可以先利用 BloomFilter 快速排除掉大部分肯定不满足条件的数据，从而减少对实际数据的读取，提高查询性能。

binPack 压缩策略

binPack算法的本质就是在我们设置压缩的目标文件大小配置后target-file-size-bytes，使用装箱算法，快速的将较小的文件写入较大的文件。

binPack算法是默认的Iceberg压缩策略的算法，也是最快的压缩策略，其不会做全局的排序，可能会在任务内做本地排序。

binPack优势是”快“，缺点是数据并没有被聚集分类起来（数据没被排序），不利于join读取等。

CALL catalog.system.rewrite_data_files(
  table => 'streamingtable',
  strategy => 'binpack',
  where => 'created_at between "2023-01-26 09:00:00" and "2023-01-26 09:59:59" ',
  options => map(
    'rewrite-job-order','bytes-asc',
    'target-file-size-bytes','1073741824',
    'max-file-group-size-bytes','10737418240',
    'partial-progress-enabled', 'true'
  )
)

MOR-Position/Equality Delete

下面介绍一下Iceberg的upsert。Upsert有两种实现方式：copy on write和merge on read。

• copy on write：实现方式类似Spark的overwrite

• merge on read：Iceberg对merge on read的实现是写时生成DeleteFile，在读的时候将DeleteFile应用到DataFile上

DeleteFile有两种方式：Position Delete和Equality Delete。

（1）Position Delete

• 文件里记录的是哪个文件（file_path）的第几条记录（pos）需要被删除。

• 写Position Delete需要先读取DataFile，然后根据过滤条件判断哪些记录需要被删除，再写成Position DeleteFile。写入较慢，因为需要先进行task scan找到对应的文件，然后再写数据。

• Spark的MOR目前只支持Position Delete。

（2）Equality Delete

• 文件里记录的是过滤条件，写入的速度快，读的速度慢，因为并不能准确的定位到文件，可能读了很多的DataFile，但是并不一定被删除，即apply的过程较慢。

• Flink的CDC场景记录的就是这种方式。

Parquet Vectorized Read Decimal

Iceberg的向量化读不是采用Spark读Parquet/ORC的那一套，而是基于Apache Arrow实现的。我们在跑TPCDS的时候发现Iceberg Parquet的向量化读的性能和Spark是有差距的，主要原因是在读取Decimal时差距比较大。这里我们对Decimal的向量化读做了优化，在1TB TPCDS数据集上，对store_sales表full table scan有近两倍的性能提升。

import org.apache.iceberg.Table
import org.apache.iceberg.NullOrder

val table:Table = null
table.replaceSortOrder()
.asc("user_id", NullOrder.NULLS_LAST)
.desc("user_name", NullOrder.NULLS_FIRST)
// .commit()

import org.apache.iceberg.expressions.Expressions
import org.apache.iceberg.Table

val table:Table = null

// =========Partition更新==========
table.updateSpec()
// 添加分区字段user_id，且一个分区内分桶数量为10
.addField(Expressions.bucket("user_id", 10))
// 删除分区字段country
.removeField("country")
// .commit()

CALL catalog.system.rewrite_data_files(
  table => 'iceberg_03',
  strategy => 'sort',
  sort_order => 'team ASC NULLS LAST, name ASC NULLS FIRST'
)

paimon 高效处理的奥秘

文件布局

1 Snapshot Files

所有快照文件都存储在快照目录中。

快照文件是一个JSON 文件，包含有关此快照的信息，包括：

正在使用的Schema文件

包含此快照的所有更改的清单列表（manifest list）

2 Manifest Files

所有清单列表（manifest list）和清单文件（manifest file）都存储在清单（manifest）目录中。

清单列表（manifest list）是清单文件名（manifest file）的列表。

清单文件（manifest file）是包含有关LSM 数据文件和更改日志文件的文件信息。例如对应快照中创建了哪个LSM数据文件、删除了哪个文件。

3 Data Files

数据文件按分区和存储桶分组。每个存储桶目录都包含一个LSM 树及其变更日志文件。目前，Paimon 支持使用 orc（默认）、parquet 和 avro 作为数据文件格式。

4 LSM Trees

Paimon 采用 LSM 树（日志结构合并树）作为文件存储的数据结构。

4.1 Sorted Runs

LSM 树将文件组织成多个Sorted Run。Sorted Run由一个或多个数据文件组成，并且每个数据文件恰好属于一个Sorted Run。

数据文件中的记录按其主键排序。在Sorted Run中，数据文件的主键范围永远不会重叠。

正如您所看到的，不同的Sorted Run可能具有重叠的主键范围，甚至可能包含相同的主键。查询LSM树时，必须合并所有Sorted Run，并且必须根据用户指定的合并引擎和每条记录的时间戳来合并具有相同主键的所有记录。

写入LSM树的新记录将首先缓存在内存中。当内存缓冲区满时，内存中的所有记录将被排序并刷新到磁盘。

4.2 Compaction