阿里云 EMR 基于 Paimon 和 Hudi 构建 Streaming Lakehouse

01

背景信息

数据湖与传统的数据仓库相比，可以更灵活地处理各种类型的数据，并支持高度可扩展的存储，通常被用于大数据分析。为了支持准实时乃至实时的数据处理，数据湖需要能够快速地接收和存储数据（数据入湖），同时提供低延迟的查询性能以满足分析需求。

Apache Paimon 和 Apache Hudi 作为数据湖存储格式，有着高吞吐的写入和低延迟的查询性能，是构建数据湖的常用组件。本文将在阿里云EMR^[1] 上，针对数据实时入湖场景，对 Paimon 和 Hudi 的性能进行比对，然后分别以 Paimon 和 Hudi 作为统一存储搭建准实时数仓。

02

集群环境

本文使用的集群环境是最新的阿里云 EMR 5.16.0（预计1月份正式发布），集群节点的属性如下：

• master: 1 * ecs.g7.2xlarge 8 vCPU 32 GiB

• core: 4 * ecs.g7.6xlarge 24 vCPU 96 GiB

使用的组件及版本如下：

• Paimon: 0.7-SNAPSHOT(Paimon社区0.6 release版本)

• Hudi: 0.14.0

• Flink: 1.15

• Spark: 3.3.1

• OSS-HDFS: 1.0.0

本文主要由两部分组成，分别是 Paimon 和 Hudi 数据实时入湖性能测试（Flink），以及 Paimon 和 Hudi 准实时数仓全链路搭建（Flink + Spark），测试数据均存储在 EMR 的 OSS-HDFS 中。

03

数据实时入湖

数据实时入湖是数据湖格式的一个重要应用场景，也是构建实时湖仓的第一步。本节测试参考的是 paimon-cluster-benchmark^[2] 。按照实际的业务情况，划分了两个具体场景：upsert 场景（数据存在更新与订正）和纯 append 场景，在两个场景上分别检验 Paimon 和 Hudi 的读写能力。

本节测试将使用 Flink 流式入湖，部署模式是 Flink Standalone 模式，Flink 配置如下，由于 TM 运行内存对测试结果影响较大，分别统计 8g/16g/20g 下的测试结果。并且由于本测试不需要用到 TM 的 managed 内存，将其设为1m。

parallelism.default: 16
jobmanager.memory.process.size: 4g
taskmanager.numberOfTaskSlots: 1
taskmanager.memory.process.size: 8g/16g/20g
execution.checkpointing.interval: 2min
execution.checkpointing.max-concurrent-checkpoints: 3
taskmanager.memory.managed.size: 1m
state.backend: rocksdb
state.backend.incremental: true
table.exec.sink.upsert-materialize: NONE

1. upsert 场景

数据湖 upsert 用于更新或插入新数据。在进行 upsert 时，会检查待写的数据是否已存在于数据湖中。如果数据已存在，则更新该数据；如果数据不存在，则插入新数据。upsert 通常是基于某种唯一标识符或主键来判断数据是否已存在。

本节测试数据源由 Flink datagen 产生，随机生成主键范围为 0~100,000,000 的数据，然后使用 Flink 将数据分别流式写入 Paimon 和 Hudi 表中，并统计写入 5 亿条数据（经统计，此时单个 bucket 内的 parquet 文件总大小在 2GB 内）的总耗时。同时，我们还使用 Flink 以批读的方式读取写入的 Paimon 和 Hudi 表，并统计总耗时。

对于 upsert 场景，Paimon 选择 primary-key 表，Hudi 选择 merge-on-read 表，由于它们都支持 compaction，所以测试将进一步划分为关闭和开启 compaction。

• 关闭 compaction

Paimon 表的配置如下，bucket 个数与 Flink 的并行度一致，设置为 16。由于 Hudi 默认文件格式为 parquet 格式，为了与 Hudi 保持一致，后续均采用 parquet 作为文件输出格式，压缩方式统一设为 snappy。

'bucket' = '16',
'file.format' = 'parquet',
'file.compression' = 'snappy',
'write-only' = 'true'

Hudi 表的配置如下，采用 BUCKET index，桶个数为 16，与 Flink 并行度一致。由于 Hudi MOR 表的读取会受到参数 compaction.max_memory 的影响，将其配置为 taskmanager.memory.process.size 的一半。

'table.type' = 'MERGE_ON_READ',
'metadata.enabled' = 'false',
'index.type' = 'BUCKET',
'hoodie.bucket.index.num.buckets' = '16',
'write.operation' = 'upsert',
'write.tasks' = '16',
'hoodie.parquet.compression.codec' = 'snappy',
'read.tasks' = '16',
'compaction.schedule.enabled' = 'false',
'compaction.async.enabled' = 'false',
'compaction.max_memory' = '4096/8192/10240' -- TM process memory的一半

测试结果如下：

可以发现在 upsert 场景，关闭 compaction 时，Paimon 读写性能均优于 Hudi，且 Hudi 对 TM 的内存要求更高。

• 开启 compaction

Paimon 配置：

'bucket' = '16',
'file.format' = 'parquet',
'file.compression' = 'snappy',
'num-sorted-run.compaction-trigger' = '5' -- 默认配置

Hudi 配置：

由于测试所需的总耗时不多（checkpoint 个数也相应较少），并且随着未 compaction 的 log 文件增加，Hudi 需要的 compaction 内存将变得更大，因此配置 compaction.delta_commits 为 2 来保证在写入期间有 compaction 执行完成。

'table.type' = 'MERGE_ON_READ',
'metadata.enabled' = 'false',
'index.type' = 'BUCKET',
'hoodie.bucket.index.num.buckets' = '16',
'write.operation' = 'upsert',
'write.tasks' = '16',
'hoodie.parquet.compression.codec' = 'snappy',
'read.tasks' = '16',
'compaction.schedule.enabled' = 'true',
'compaction.async.enabled' = 'true',
'compaction.tasks' = '16',
'compaction.delta_commits' = '2'
'compaction.max_memory' = '4096/8192/10240' -- TM process memory的一半

测试结果如下：

在 upsert 场景，开启 compaction 时，Paimon 读写性能均优于 Hudi。对比前面的关闭 compaction 测试，Paimon 和 Hudi 的写性能均有所下降，但读性能得到提升。

Hudi 的 compaction 比较消耗内存，运行时间较长，并且它是异步执行，当写入任务完成时，未完成的 compaction 是不会继续执行的。观察发现，当 TM 内存给到20G时，Hudi 仍有 4 个 delta commits 未被 compaction（即使配置了compaction.delta_commits=2）。并且，Paimon 的 compaction 默认也不是 full compaction。因此，我们还做了以下补充测试，手动对 Paimon 和 Hudi 做一次 full compaction，然后对比读取数据的时间，结果如下：

2. append 场景

数据入湖的另一种场景是数据 append 写࿰