1. 从“数据仓库”到“数据湖”为什么我们需要Paimon如果你在过去几年里处理过大数据大概率经历过这样的场景业务部门临时需要一个报表你发现数据源在MySQL一部分历史数据在Hive实时数据又跑在Kafka里。于是你开始写Spark作业吭哧吭哧地做ETL把数据统一格式、清洗、合并最后导入到一个新的Hive表里。几天后报表需求变了你发现之前合并的逻辑有问题或者需要回溯某一天的历史数据但原始Kafka数据因为保留策略已经被清理了。这种“数据孤岛”和“数据回溯”的痛是传统数仓架构难以根治的顽疾。数据湖的概念就是为了解决这些问题而生的。它不像数据仓库那样要求数据在入库前就必须有严格的结构Schema-on-Write而是允许你以原始格式如Parquet、ORC、JSON先把海量数据“倾倒”进来在查询时再定义结构Schema-on-Read。这带来了极大的灵活性但也引入了新的挑战如何管理这些海量文件如何保证流批数据的一致性如何高效地更新和删除记录如何支持时间旅行查询Time Travel这正是Apache Paimon原名Flink Table Store要回答的问题。它不是一个简单的文件存储格式而是一个构建在数据湖存储之上、具备数据库表管理能力的存储层。你可以把它理解为一个“湖仓一体”Lakehouse的实现。它底层使用对象存储如S3、OSS或HDFS来存放文件但在上层提供了像数据库一样的ACID事务、主键更新、增量读取和流批统一访问的能力。这意味着你可以用流的方式持续写入数据同时用批的方式做历史分析并且两者看到的数据状态是完全一致的。简单来说Paimon试图让你用管理数据库表一样简单的方式去管理存储在廉价对象存储里的海量数据同时兼顾流处理和批处理的效率。接下来我们就剥开它的外层看看它是如何实现这一目标的。2. Paimon架构总览三层抽象与两种“表”要理解Paimon首先要摒弃“它只是一个文件格式”的想法。它的架构可以抽象为三层存储层、表管理层和计算层。存储层是基石就是你的对象存储S3、OSS或分布式文件系统HDFS。Paimon的所有数据文件Data Files、清单文件Manifests和快照Snapshot都物理存储在这里。它的选择决定了存储的成本和持久性。表管理层是Paimon的核心大脑。它负责将上层计算层的“插入”、“更新”、“删除”等操作翻译成对底层文件系统的“新增文件”、“标记删除”等动作并维护一套元数据来保证数据的一致性视图。这层的关键组件是Snapshot快照这是Paimon实现ACID和时间旅行的核心。每次提交比如一批流数据写入完成都会生成一个新的快照。快照是一个指向当前所有有效数据文件的指针列表。查询时只需读取最新快照对应的文件就能获得一致的数据视图。回溯历史只需指定一个历史快照ID即可。Manifest清单快照不能直接指向成千上万个数据文件那样效率太低。清单文件就是快照和数据文件之间的索引。一个快照会引用一个或多个清单文件每个清单文件则记录了属于该快照的一批数据文件的路径、统计信息如最小值、最大值等。Data File数据文件实际存储用户数据的文件默认采用列式存储格式ORC或Parquet以提供高效的分析查询性能。计算层是Paimon的“手足”负责数据的读写。它完美集成了Apache Flink作为其原生的一等公民可以通过Flink SQL、DataStream API或Table API进行流式读写和批处理。同时它也支持通过Spark、Hive、Trino/Presto等引擎进行批查询实现了计算引擎的解耦。在表管理层Paimon设计了两种核心的“表”类型对应不同的数据变更处理模式这是理解其原理的关键2.1 Changelog表流式更新的核心这是Paimon的默认表类型也是其流批一体能力的体现。这种表要求你定义主键Primary Key。它的核心思想是将所有的数据变更插入、更新、删除都转化为带有“增/删”标记的记录Changelog并有序地存储下来。想象一下数据库的BinlogPaimon的Changelog表就在做类似的事情。当你执行一条UPDATE语句时Paimon不会去物理地修改已有的数据文件而是会生成两条记录一条-D删除记录表示旧值的“删除”一条I插入记录表示新值的“插入”。这些包含变更语义的记录会和其他插入的记录一起被写入新的数据文件中。为什么这么做简化流处理流计算引擎如Flink可以直接消费这些完整的Changelog流无需复杂的“拉链表”或“全量增量”合并逻辑就能构建实时物化视图或更新下游维度表。高效合并虽然存储的是变更日志但Paimon在后台会运行一个名为Compaction的进程。这个进程会将多个包含大量更新日志的文件合并成少数几个包含最终数据状态的文件从而优化查询性能。这个过程对用户是透明的。支持事务一次提交内的所有变更要么全部生效生成一个新快照要么全部失败快照不变保证了ACID中的原子性和一致性。实操心得在定义Changelog表时主键的选择至关重要。它不仅是数据更新的依据也直接影响Compaction的效率。主键字段应选择更新频率适中、区分度高的业务字段如order_id。避免使用像update_time这种持续变化的字段作为唯一主键否则会导致每次更新都被视为一条新记录产生大量无效的-D/I对加剧文件膨胀。2.2 Append-Only表高性能写入的权衡并非所有数据都需要更新。例如日志数据、交易流水、IoT传感器读数这些数据一旦产生就不会改变只会追加。对于这种场景使用Changelog表反而会引入不必要的主键约束和更新开销。Append-Only表就是为此而生。它不要求定义主键所有写入操作都被视为纯粹的插入Insert。它的架构因此变得非常轻量无主键管理省去了维护主键索引和解决更新冲突的开销。更简单的Compaction后台合并任务只需将小文件合并成大文件无需处理复杂的更新合并逻辑速度更快。更高的写入吞吐由于逻辑简单写入路径更短通常能获得比Changelog表更高的写入性能。如何选择如果你的数据有明确的更新需求如用户画像、商品库存、订单状态必须使用Changelog表。如果你的数据是只增不改的如操作日志、点击流、流水记录Append-Only表是更高效的选择。在Flink SQL中可以通过primary-key 不设置主键来创建此类表。3. 核心原理深度拆解快照、Compaction与索引理解了两种表类型我们深入到Paimon如何实现这些能力的细节中。三个核心机制构成了它的基石快照隔离、Compaction合并和索引加速。3.1 快照隔离与时间旅行数据一致性的基石这是Paimon区别于简单文件存储最核心的特性。它借鉴了数据库和多版本并发控制MVCC的思想。工作原理写入当一批数据写入完成并提交时Paimon会创建一个新的快照Snapshot。这个快照本身是一个很小的元数据文件记录了本次提交生成的新增数据文件列表并指向其父快照上一次提交的快照。快照链所有快照通过父子关系形成一个链表。最新的快照被称为“当前快照Current Snapshot”它代表了数据集的当前完整状态。读取任何查询在开始时都会“锚定”到一个特定的快照默认是最新快照。查询引擎根据该快照找到其引用的所有清单和数据文件读取这些文件就能获得一个在某个时间点上绝对一致的数据视图。时间旅行要查询历史数据只需在查询时指定一个历史快照ID或时间戳。Paimon会定位到那个时间点的快照并读取其对应的文件集合。因为历史数据文件从未被物理删除或覆盖所以这个查询是可行且高效的。带来的好处读写分离一个长时间运行的批处理查询可以锚定在开始时的快照不受后续流写入的影响保证了结果的可重复性。回滚与审计可以轻松地将表回滚到之前的任何一个健康状态或者审计历史上任意时刻的数据内容。增量读取流处理任务可以持续消费从一个快照到下一个快照之间新增的数据文件即增量数据这是实现流处理的基础。3.2 Compaction化“日志”为“状态”的魔法对于Changelog表如果一直存储原始的-D/I变更记录查询性能会急剧下降因为要扫描大量无效的中间状态。Compaction压缩合并就是那个在后台默默将“流水账”整理成“总账本”的管家。Compaction主要做两件事小文件合并将多次写入产生的小数据文件读放大合并成更大的文件减少查询时需要打开的文件句柄数提升I/O效率。Changelog合并关键这是针对Changelog表的专属优化。它会扫描多个文件将属于同一主键的多条变更记录如-D, I, -D, I合并成最终的状态记录一条最新的I或直接删除。合并后的文件只包含数据的最新状态查询时无需再遍历变更历史。Paimon的Compaction策略是可配置的。你可以设置触发Compaction的文件大小阈值、时间间隔等。在流写入场景下通常建议开启全异步Compaction让一个独立的Flink作业专门负责合并这样不会阻塞主写入流保证写入延迟的稳定。踩坑记录Compaction资源不足是线上常见问题。如果写入流量很大而Compaction速度跟不上会导致小文件和未合并的Changelog堆积查询速度变慢甚至最终因文件数过多导致元数据过大而影响稳定性。我们的经验是为Compaction作业单独分配足够的CPU和内存资源并监控number-of-files和changelog-size这类指标。对于更新非常频繁的热点数据可以考虑根据业务分区避免全表大合并。3.3 索引加速查询的利器虽然Paimon依赖计算引擎如Spark的文件过滤能力但它也内置了索引机制来进一步加速点查和范围查询。主键索引对于Changelog表主键是天然的索引维度。在Compaction合并文件时Paimon会按主键对数据进行排序和索引在ORC/Parquet文件内部。查询时引擎可以利用这些索引信息快速定位数据块。二级索引Paimon支持在非主键字段上创建二级索引如Bloom Filter。例如为常用的查询过滤字段user_id创建布隆过滤器索引可以在读取文件时快速跳过绝对不包含目标值的文件大幅减少I/O。分区与分桶这是最常用且高效的“索引”。通过PARTITIONED BY和BUCKET关键字可以将数据物理地组织到不同的目录和文件中。分区常用于时间维度如dt2024-05-20直接利用HDFS的目录结构进行剪枝对于按时间范围查询的过滤效果极佳。分桶根据主键或某个字段的哈希值将数据分散到固定数量的桶文件中。这能保证相同键值的数据落在同一个文件里对于点查和更新操作可以避免全表扫描只需读取一个桶文件。一个典型的表定义会结合使用这些技术CREATE TABLE orders ( order_id BIGINT, user_id BIGINT, amount DECIMAL(10,2), status STRING, dt STRING, PRIMARY KEY (dt, order_id) NOT ENFORCED ) PARTITIONED BY (dt) WITH ( bucket 10, index.bloom-filter.columns user_id );这个表按天分区每天的数据又哈希成10个桶。查询dt2024-05-20 and order_id123时Flink或Spark能快速定位到dt2024-05-20分区下的某个桶文件并利用主键排序和布隆过滤器快速找到数据。4. 典型应用场景与实战配置指南理解了原理我们来看看Paimon在哪些场景下能大放异彩以及如何针对性地进行配置。4.1 场景一CDC入湖与实时数仓这是Paimon最经典的应用。使用Flink CDC直接捕获MySQL、PostgreSQL等数据库的变更日志实时写入Paimon表。架构价值实时同步替代了传统的离线T1数据同步实现秒级延迟。流批统一同一张Paimon表流处理作业可以消费其增量日志做实时聚合批处理作业可以读取全量做T1报表数据同源一致。历史回溯任何数据问题都可以通过时间旅行查询定位到变更点。关键配置-- Flink SQL创建CDC源表并写入Paimon CREATE TABLE mysql_orders ( id BIGINT, ... , PRIMARY KEY (id) NOT ENFORCED ) WITH ( connector mysql-cdc, ... ); CREATE TABLE paimon_orders ( id BIGINT, ... , PRIMARY KEY (id) NOT ENFORCED ) PARTITIONED BY (dt) WITH ( bucket 5, changelog-producer full-compaction, -- 关键确保生成完整的Changelog供下游消费 compaction.interval 1h, snapshot.time-retained 7d -- 根据业务需要保留快照 ); -- 执行写入 INSERT INTO paimon_orders SELECT *, DATE_FORMAT(update_time, yyyy-MM-dd) as dt FROM mysql_orders;注意changelog-producer配置至关重要。full-compaction模式能保证在每次Compaction后为每个主键生成完整的-U/U变更流这对于下游流作业正确计算非常重要。如果下游只需要最终状态可以选用lookup模式以降低开销。4.2 场景二流计算结果的物化存储在实时数仓的DWD或DWS层经常需要将流式聚合如每分钟的GMV、UV的结果持久化存储供即席查询或下游批处理使用。传统痛点将结果写入Kafka再通过批作业周期性地导入Hive链路长、时效性差、一致性难保证。Paimon方案直接将Flink流聚合的结果写入Paimon表。优势查询即所得聚合结果一旦写入Paimon任何支持Paimon的查询引擎如Trino都可以立即查询到最新结果。自带分区可以按时间如hour分区方便按时间范围快速查询。更新自然如果聚合逻辑涉及对历史数据的修正如去重结果更新Paimon的主键更新能力可以轻松应对。配置要点此类表通常是Append-Only或低更新频率的Changelog表。应合理设置分区和分桶并调大compaction.file-size以减少小文件因为写入模式通常是规律的批量追加。4.3 场景三替代Hive作为统一的离线数仓表层对于已有的Hive离线数仓可以考虑将核心的ODS层或DWD层表迁移到Paimon。操作路径使用Spark或Flink批作业将历史Hive数据批量导入Bootstrap到Paimon表。将新的增量数据如每日调度任务产生的数据直接写入Paimon。将下游的Hive SQL查询逐步改为用Spark/Trino查询Paimon表。收益与挑战收益获得了更新删除能力、时间旅行、流批统一入口。挑战历史数据迁移成本、下游作业改造、生态工具适配如数据质量检查工具。建议从单点业务开始试点验证稳定性和性能收益后再推广。4.4 性能调优核心参数要让Paimon跑得又快又稳以下几个核心参数需要根据数据规模和模式进行调整bucket分桶数。这是影响并行度和文件大小的关键。建议设置为写入并行度的整数倍且每个桶最终的文件大小在128MB ~ 1GB为宜。太小则文件过多太大则不利于并行。compaction.intervalCompaction触发间隔。流处理中通常设置为1h或30min。对于写入压力大的场景可以缩短间隔但会增加后台资源消耗。changelog-producer变更日志生成模式。full-compaction保障完整流延迟高 vslookup延迟低可能丢失中间状态。根据下游消费者需求选择。snapshot.num-retained.min/snapshot.time-retained保留的快照数量/时间。用于控制时间旅行的深度和存储成本。需根据业务审计需求设置。scan.parallelism批查询时的并行度。在Spark或Flink批查询中合理设置此参数能充分利用集群资源加速全表扫描。5. 选型对比与生态定位Paimon vs. Iceberg vs. Hudi谈到数据湖格式Apache Iceberg和Apache Hudi是无法绕开的对比项。三者目标相似但设计哲学和适用场景各有侧重。特性维度Apache PaimonApache IcebergApache Hudi核心设计理念流批一体原生为Flink深度优化强调作为流处理Sink和Source的体验。通用表格式定义开放的、引擎无关的Table Format标准追求极致的兼容性和可靠性。快速Upsert最初为Spark生态的增量更新和删除场景设计强调低延迟的数据摄取。流处理集成原生最佳与Flink API无缝集成Changelog概念原生支持流读写体验最自然。通过Flink Connector支持功能完善但流式更新语义需要依靠“Equlity Delete”等实现稍显复杂。通过Flink Connector支持但核心流式模型如COW/MOR最初为Spark设计在Flink生态集成深度稍逊。批处理查询支持良好通过Spark、Hive、Trino Connector。支持极佳拥有最广泛的生态支持Spark, Trino, Presto, Impala等是批查询生态最成熟的格式。支持良好主要通过Spark和Hive。更新删除效率主键更新通过Compaction合并Changelog适合高频更新。通过“Copy-on-Write”或“Merge-on-Read”模式支持MoR模式适合写多读少。Upsert效率高特别是“Merge-on-Read”模式为频繁的插入/更新操作优化。事务与时间旅行基于快照支持ACID和时间旅行。基于快照支持ACID和时间旅行实现非常严谨。基于时间线Timeline支持增量读取和有限的时间旅行。学习与使用成本在Flink生态中简单直观概念较少。概念相对较多Snapshot, Manifest, Partition Spec等但文档和社区成熟。概念较多COW/MOR, Index类型等配置选项复杂。典型适用场景Flink为中心的实时数仓CDC实时入湖流计算结果物化。企业级离线/湖仓一体需要多引擎Spark, Trino稳定访问对开放性和可靠性要求高。近实时数据湖对数据摄取延迟要求极高有大量Upsert需求的场景如Spark流处理。如何选择如果你的技术栈以Apache Flink为核心构建实时数据管道和流批一体数仓追求极致的流处理开发体验Paimon是目前最自然、最顺畅的选择。它就像是Flink的“亲儿子”很多流处理中的痛点如Exactly-Once Sink、流读Changelog都被原生解决了。如果你需要一个稳定、开放、被众多查询引擎广泛支持的企业级表格式用于整合公司内多样化的计算工具Spark, Presto, Impala, Athena等Apache Iceberg是更稳妥的选择。它的社区更庞大设计更偏向于批处理和数据管理。如果你的场景是基于Spark的增量数据处理对数据摄取的延迟极其敏感比如需要分钟级甚至秒级将数据更新同步到数据湖供查询可以重点评估Hudi特别是其Merge-on-Read模式。Paimon的生态正在快速成长除了Flink其与Spark、StarRocks、Doris等的集成也在不断加强。它的定位非常清晰在流批一体特别是Flink流处理优先的架构中成为数据湖存储层的首选。它用数据库的思维来管理湖存储降低了流式数据管理的复杂度这是它最大的价值所在。