Apache Paimon：一种新的数据入湖实践

1. 数据仓库技术方案的演进与数据湖的兴起

在深入探讨 Apache Paimon 之前，有必要回顾一下数据处理架构的演进历程。这一过程清晰地反映了业务需求如何驱动技术变革。

传统 数据仓库 时代： 早期，企业数据处理以 Teradata、Oracle、IBM Db2 等商业解决方案为主导，构建了集中式的、模式固定的企业级数据仓库（EDW）。这些系统擅长处理结构化数据的批量分析，但架构封闭、扩展性差且成本高昂。

Hadoop 生态的革新： 随着互联网数据量爆炸式增长，以 Hadoop (HDFS + MapReduce) 为核心的开源生态崛起。Hive 的出现，通过 SQL-on-Hadoop 的方式极大降低了大数据处理的门槛，确立了以 HDFS 为存储、每日定时批处理（T+1）+ 实时流处理的经典 Lambda 架构。然而，Lambda 架构需要维护实时流处理和离线批处理两套独立的代码和计算链路，带来了开发与运维的复杂性。

流计算与实时化： Apache Storm、Spark Streaming，特别是 Apache Flink 的成熟，推动了流处理成为标配。企业对数据时效性的要求从"天级别"提升到"分钟级"甚至"秒级"。但单纯的流处理系统通常缺乏高效、统一的数据存储层。

数据湖概念的提出与实践： 为了解决数据孤岛、支持多种数据类型（结构化、半结构化、非结构化）和灵活的读写模式，数据湖概念应运而生。它倡导将原始数据以原生格式集中存储，然后按需进行处理和分析。Delta Lake、Apache Iceberg 和 Apache Hudi 是此阶段的杰出代表，它们在存储层实现了 ACID 事务、时间旅行等能力，将数据仓库的管理能力与数据湖的灵活性相结合，形成了"湖仓一体"（Lakehouse）架构。

新挑战与 Paimon 的定位： 尽管现有的数据湖框架取得了巨大成功，但在流批一体处理的深度整合、高频率更新删除（CDC）的原生支持以及实时分析性能方面，仍有优化空间。Apache Paimon（原名 Flink Table Store）正是在此背景下诞生，它被定义为一个"流式数据湖平台"，深度集成 Flink，旨在为流批一体处理架构提供高性能、高实时性的数据存储层，是数据湖技术演进的新实践。

2. Apache Paimon 核心特性解析

Apache Paimon 是一个专为流批一体架构设计的流式数据湖平台。它可以理解为部署在 Hadoop HDFS 或云存储（如 S3）之上，兼具高速实时读写能力的数据湖存储。

2.1 主键表与强大的更新能力

主键支持：Paimon 的表可以像传统数据库一样定义主键，这是实现高效更新的基础。
高效更新/删除：原生支持 UPDATE、DELETE 和 MERGE INTO 操作，完美适配 CDC 数据同步场景。
部分更新：通过 partial-update 合并引擎，可以轻松地将多个数据流合并到一张宽表中，实现字段级的灵活更新。

2.2 流批一体原生支持

一份数据，两种处理：同一张 Paimon 表可同时作为流处理（如 Flink Streaming）的源表以及批处理（如 Spark Batch）的查询对象，保证结果一致性。
架构简化：彻底消除了 Lambda 架构中维护两套代码和计算链路的复杂性。

2.3 高性能格式

LSM-Tree 结构：底层采用 Log-Structured Merge-Tree，对随机写入和更新操作非常友好。
列式存储：数据文件使用 ORC 或 Parquet 格式，确保高效的列式分析查询性能。
自动压缩：后台自动进行 Compaction，合并小文件并清理过期数据，持续保持查询性能。

2.4 丰富的合并引擎

在数据写入时，Paimon 提供多种策略处理相同主键的记录：

deduplicate：仅保留最新或最早的一条记录（默认）。
partial-update：将多条记录的列进行合并，形成一条完整的最新记录，是构建宽表的神器。
aggregation：对指定的数值列进行求和、求最大值等预聚合操作。

2.5 简化的 Changelog 生成

Paimon 表能自动产生标准的 Changelog 流（包含 +I, -U, +U, -D 消息）。
这使得它能直接作为 Flink SQL 的流式源表，下游任务可消费这些变更事件，轻松构建实时数仓的 ODS 或 DWD 层。

2.6 强大的生态集成

计算引擎：深度集成 Apache Flink，同时支持 Apache Spark、Trino、Hive 等。
存储系统：兼容 HDFS、S3、OSS、Azure Blob Storage 等主流存储。
消息系统：无缝对接 Kafka，用于消费 CDC 数据。

3. Paimon 与 Hive 的深度对比

3.1 核心定位对比

Paimon：面向实时数据湖和流批一体架构，为高速更新的流式数据提供湖存储。
Hive：传统的基于 HDFS 的批处理数据仓库，核心是 SQL-on-Hadoop 查询。

3.2 技术架构与数据模型

Paimon 支持主键与更新：

sql 复制代码

CREATE TABLE paimon_table (
    user_id BIGINT,
    email STRING,
    last_login TIMESTAMP(3),
    dt STRING,PRIMARY KEY (user_id, dt) NOT ENFORCED
) PARTITIONED BY (dt)
WITH ('bucket' = '4','changelog-producer' = 'input');

Hive 为仅追加模型：

sql 复制代码

CREATE TABLE hive_table (
    user_id BIGINT,
    email STRING,
    last_login TIMESTAMP,
    dt STRING
)
PARTITIONED BY (dt)
STORED AS PARQUET;

3.3 数据更新能力

Paimon 支持实时更新：

ini 复制代码

UPDATE paimon_table SET email = 'new@email.com' WHERE user_id = 123;
DELETE FROM paimon_table WHERE user_id = 456;

Hive 更新困难：通常需要重写整个分区，操作复杂且性能低下。

3.4 功能特性对比

ACID 事务：Paimon 提供完整的 ACID 保证；Hive 仅在特定条件下有限支持。
Schema 演进：Paimon 支持灵活的字段增删；Hive 的 Schema 演进则受限较多。
运维管理：Paimon 支持自动压缩、小文件合并和过期快照清理；Hive 多需手动操作。

3.5 具体业务场景对比

CDC 数据入湖：

Paimon：CDC 数据流可直接写入，自动处理 INSERT/UPDATE/DELETE。
Hive：需要复杂的旁路逻辑实现 Upsert，通常重写分区，性能和时效性差。

实时聚合：

Paimon：通过 aggregation 合并引擎，在写入时即可完成预聚合。
Hive：依赖定时批处理作业，延迟大。

3.6 总结与选型建议

选择 Paimon 当：

✅ 需要实时数据处理和低延迟分析
✅ 业务涉及频繁的数据更新和删除（CDC）
✅ 技术栈以 Flink 流处理为核心
✅ 追求简化的流批一体架构

选择 Hive 当：

✅ 以传统的 T+1 批处理报表和分析为主
✅ 需要与 Hadoop 生态工具（如 Atlas、Ranger）深度集成
✅ 团队熟悉且满足于现有的 SQL-on-Hadoop 技术栈

混合架构：许多企业采用 Hive（存历史冷数据，用于批处理分析）+ Paimon（处理实时热数据，用于低延迟查询）的混合模式，平衡性能与成本。

4. Paimon 文件结构解析

Paimon 采用多层文件结构来管理数据、元数据和事务。了解其文件组织对于深度运维和问题排查至关重要。

核心文件包括：

Snapshot Files：快照文件，指向当前有效的数据集。
Manifest Files：清单文件，记录了某个快照包含的所有数据文件列表及其统计信息（如最小/最大值），用于加速过滤查询。
Data Files：实际的数据文件，以 Parquet 或 ORC 格式存储。

通过官方工具可以解析 Manifest 文件内容，查看其内部 Avro 格式记录的元数据，如文件路径、行数、主键范围、序列号等，这对于理解 Compaction 行为和数据分布很有帮助。

5. 合并引擎详解

合并引擎是 Paimon 处理相同主键记录冲突的核心机制。

5.1 主要合并引擎

Deduplicate（去重，默认）：仅保留最新（或最早）的一条记录。需通过 sequence.field 指定判断新旧顺序的字段。
Partial-update（部分更新）：专为宽表场景设计。允许来自不同流的记录，按照主键合并其非空字段。可为数值字段配置聚合函数（如 sum）。
ini 复制代码
```
WITH (
    'merge-engine' = 'partial-update',
    'fields.total_orders.aggregate-function' = 'sum'
)
```
Aggregation（聚合）：在写入时即进行预聚合。需为每个需要聚合的字段显式指定聚合函数（如 sum， max）。

5.2 高级配置与调优

处理乱序数据：通过 sequence.field 指定一个单调递增的字段（如时间戳或序列号）来正确判断记录的新旧。
性能调优：可调整 compaction.max/min.file-num 控制压缩触发时机，调整 write-buffer-size 优化写入性能。

5.3 注意事项

主键必需：所有合并引擎都基于主键表工作。
性能开销：合并操作会带来额外的计算开销。
最终一致性：合并是异步过程，数据可见性有轻微延迟。

6. 压缩与存储优化

6.1 压缩过程

Compaction 是 Paimon 保持高性能的关键后台任务。它会：

读取多个已排序的输入文件。
进行归并排序，并按主键去重或合并。
生成新的、更大且完全有序的数据文件。此过程不仅减少了文件数量，更重要的是维持了数据按主键有序的状态，从而极大地提升了点查和范围查询的效率。

6.2 压缩与小文件管理

Paimon 支持自动压缩以合并小文件。关键配置参数包括：

compaction.max.file-num / compaction.min.file-num：触发压缩的文件数量阈值。
num-sorted-run.compaction-trigger：一个桶内"排序运行"的数量阈值，是更直接的调节参数。
target-file-size：目标输出文件大小。对于流式持续写入场景，建议配置 full-compaction.delta-commits 以定期触发全量压缩，防止小文件无限累积。

6.3 极致存储优化案例

对于只关心最新数据、需要最小化存储成本的场景（如宽表结果层），可以进行极限配置，代价是丧失时间旅行、增量读取、CDC 同步和历史审计能力，以换取极致的存储空间节省。

sql 复制代码

WITH (
    'snapshot.num-retained.max' = '1',   -- 只保留1个最新快照
    'changelog-producer' = 'none',       -- 不生成 changelog（最大节省项）
    'log.system' = 'none',               -- 禁用日志系统
    'full-compaction.delta-commits' = '1' -- 每次提交都压缩
)

7. Hive 集成实践

Paimon 与 Hive Metastore 无缝集成，使得 Hive 可以直接查询 Paimon 表数据。

集成步骤简述：

下载 Connector Jar：获取对应版本的 paimon-hive-connector-*.jar。
部署 Jar 包：将 Jar 包放入 Hive 服务器的 $HIVE_HOME/auxlib/ 目录。
配置 Hive：在 hive-site.xml 中配置 hive.aux.jars.path 和 hive.input.format 等参数，指向 Paimon 的 InputFormat。
创建 Catalog：在 Flink 中创建使用 Hive Metastore 的 Paimon Catalog。
查询：在 Hive 中即可像查询普通表一样直接查询 Paimon 表，并支持 MSCK REPAIR TABLE 自动发现分区。

8. 概念验证与场景实践

8.1 场景一：MySQL CDC 维度数据同步

现有痛点：Binlog → Kafka → Hive 链路长，增量合并需要日级批量作业。
Paimon 方案：Binlog 通过 Flink CDC 直接写入 Paimon 表。Paimon 作为目标表，凭借主键和更新能力，直接完成维度表的实时同步与更新，实现秒级延迟。

8.2 场景二：主键宽表产出与维护

现有痛点：宽表依赖多个上游任务，耦合度高、产出链路过长、鲁棒性差。
Paimon 方案：利用 partial-update 合并引擎。各上游子任务独立写入宽表，Paimon 自动按主键合并字段。任务间解耦，任意子任务失败不影响其他字段的可用性，大幅提升时效性和鲁棒性。

8.3 场景三：分析查询性能对比

在相同数据集（客户、订单等）上对比 Hive (ORC+MR/Spark) 与 Paimon (Parquet+Spark) 的查询性能。测试表明：

基础查询：Paimon 凭借有序存储，在过滤和点查上表现优异。
复杂关联：在数据有序性优势不明显的多表复杂关联场景，两者性能接近。
Paimon 特有功能：支持时间旅行查询、增量读取等，是 Hive 不具备的。

9. 高并发写入场景架构

面对 150万 QPS 的纯追加写入场景（如日志入库），Paimon 可以通过精心设计的 Append-Only 无主键表来实现。

核心架构要点：

表设计：创建无主键表，采用多级分区（如 dt, hour, bucket_num）充分分散写入热点。
性能配置：
1. 设置高桶数（bucket = 32 或更高）。
2. 增大写缓冲区（write-buffer-size = '512 mb'）。
3. 禁用非必需特性（changelog-producer = 'none'）。
4. 使用写入性能更优的 ORC + Snappy 格式。
Flink 作业优化：
1. 高并行度（如 128）。
2. 合理的内存配置（增大 TaskManager 堆外和网络内存）。
3. 调整检查点间隔和超时时间。
资源保障：提供充足的 CPU 和内存资源，并根据桶数和并行度线性扩展。

通过以上优化，Paimon 完全有能力支撑百万级 QPS 的高吞吐写入。

10. 总结

Apache Paimon 作为流式数据湖领域的新锐，通过深度集成 Flink、原生支持主键更新和丰富的合并引擎，为实时数据入湖、CDC 同步和流批一体分析提供了优雅且高效的解决方案。它并非要完全替代 Hive 或 Iceberg，而是在实时性要求更高、更新更频繁的场景下，填补了现有生态的空白，是企业构建下一代实时数据架构的重要拼图。技术选型应基于具体的业务场景、数据特性和团队技术栈，Paimon 无疑是实时数据湖赛道上一个极具竞争力的选择。