一、为什么要把湖仓放进 K8s 语境
传统大数据平台通常围绕固定集群构建：Spark 跑在 YARN 上，Hive Metastore 管表，HDFS 或对象存储放文件，调度系统负责提交任务。这种架构在离线数仓时代有效，但在实时数据、弹性资源、多云部署、多引擎协同和精细化治理场景下，会逐渐暴露出耦合重、扩缩容慢、元数据瓶颈明显、治理颗粒度粗的问题。
Kubernetes 改变的是计算与平台运行方式，Spark 可以运行在 Kubernetes 上，spark-submit 提交应用后会创建 driver Pod，driver 再创建 executor Pod，driver 与 executor 的调度由 Kubernetes 负责 。Flink Kubernetes Operator 则通过 FlinkDeployment、FlinkSessionJob 等自定义资源，把 Flink 应用或 Session 集群交给 Operator 持续声明式管理 。
换句话说，K8s 让计算引擎从"长期固定集群"转向"按需编排的工作负载"；而 Iceberg、Hudi、Paimon 让对象存储上的文件从"松散文件集合"升级为"有事务、有快照、有元数据、有治理语义的表"。
二、湖仓一体真正解决什么
数据湖的优势是开放、低成本、可扩展，但传统数据湖往往缺少数据库级能力。文件可以存下来，但一旦遇到并发写入、更新删除、Schema 演进、历史回溯、流批统一、多引擎一致访问，就会出现复杂度。
湖仓表格式要解决的核心问题是：如何让对象存储上的文件具备表的语义 。Iceberg 在 Spark 中通过 DataSourceV2 API 实现数据源与 Catalog，并支持 USING iceberg 创建表、隐藏分区、原子 CTAS/RTAS、Schema 演进和分区演进等能力 。Hudi 将其描述为在数据湖之上增加仓库和数据库能力的 lakehouse 平台，包含表格式、存储引擎、索引、并发控制和表服务 。Paimon 则强调其支持大规模分析、时间旅行、Schema 演进、增量聚类，以及基于 LSM 的实时流式更新能力 。
三、Iceberg、Hudi、Paimon 的不同定位
三者都在做湖仓，但架构思想不同。Iceberg 更偏"开放表协议"，Hudi 更偏"湖上数据库内核"，Paimon 更偏"流批一体存储"。
| 维度 | Iceberg | Hudi | Paimon |
|---|---|---|---|
| 核心定位 | 开放表格式，多引擎一致访问 | 事务型 lakehouse 平台，强调写入和表服务 | 流批一体 lakehouse 存储，强调主键表和实时更新 |
| 关键抽象 | Snapshot、Manifest、Catalog、隐藏分区 | Timeline、File Group、File Slice、Metadata Table、Table Services | Snapshot、Manifest、Bucket、Primary Key、LSM Tree |
| 计算引擎关系 | Spark、Flink、Trino 等多引擎友好 | Spark/Flink 写入，Spark/Flink/Trino/Presto 等读取生态 | Flink 体验突出，同时支持 Spark 等生态 |
| 元数据侧重点 | 表元数据文件 + Catalog 服务 | 表内 Timeline + Metadata Table | Snapshot + Manifest + LSM 文件组织 |
| 写入侧重点 | 批处理、流式写入、多引擎表管理 | Upsert/Delete、CDC、增量写入、表服务 | 主键更新、流式写入、changelog、LSM compaction |
| 平台治理重点 | Catalog、快照、Schema/分区演进 | Compaction、Clustering、Cleaning、Indexing | Bucket、Compaction、Checkpoint、主键与 changelog |
Paimon 的特点尤其适合放到流批一体语境下理解。Paimon 主键表支持插入、更新和删除；主键在 bucket 内排序，bucket 是读写的最小存储单元，同时每个 bucket 目录包含 LSM tree 和 changelog 文件 。这使它更贴近 Flink 实时链路中"持续更新的动态表"语义。
四、K8s 如何影响计算引擎
K8s 对大数据计算引擎的影响，不只是资源调度，而是改变了计算引擎的交付、运行和治理方式。
Spark 在 K8s 上运行时，driver 和 executor 都成为 Pod。driver 创建 executor Pod 并连接它们执行应用代码，应用完成后 executor Pod 终止，driver Pod 保留完成状态和日志直到被清理 。这让 Spark 作业可以像云原生 Job 一样被提交、隔离、扩缩容、观测和回收。
Flink 在 K8s 上更自然地走向 Operator 模式。Flink Kubernetes Operator 的用户侧 API 是一组 Kubernetes 自定义资源，其中 FlinkDeployment 可运行一个 Flink Application 集群或 Session 集群，FlinkSessionJob 可向已有 Session 集群提交单个作业 。这使得 Flink 作业的升级、状态、快照、回滚和生命周期管理可以进入 K8s 声明式体系。
这也解释了为什么表格式变得更重要：当计算 Pod 可以随时创建和销毁，状态就不能绑定在计算集群里，而必须沉淀到可靠的存储、表元数据、checkpoint 和事务提交协议中。
五、K8s 如何影响元数据服务
传统大数据平台常把 Hive Metastore 当作中心元数据服务。但进入湖仓时代后，元数据被拆成两部分：Catalog 层负责表发现、命名空间、权限入口和元数据定位；表格式自身负责快照、文件列表、统计信息、事务提交和版本演进。
Iceberg 的 Catalog 抽象非常适合 K8s。Flink 可以创建 Iceberg Catalog，内置支持 hive、hadoop、rest、glue、jdbc、nessie 等 Catalog 类型；REST Catalog 可通过 'catalog-type'='rest' 和 uri 配置加载表 。在 K8s 中，REST Catalog 可以作为独立服务部署，Spark、Flink、Trino 等计算 Pod 通过网络访问它，而不是把元数据连接逻辑硬编码进每个作业。
Hudi 则把元数据加速能力更深地放进表内部。Metadata Table 用于避免云存储上的昂贵文件 listing，并暴露列统计以支持查询规划和数据跳过；它是一个内部 Hudi Merge-On-Read 表，可保存文件列表、列统计、分区统计等元数据 。这对对象存储湖仓很关键，因为大表、多分区、多文件场景下，元数据扫描本身就可能成为瓶颈。
Paimon 的元数据组织也带有表内生特征。表的所有文件存储在一个 base directory 下，snapshot 文件记录当前 schema 和 manifest list，manifest 文件记录 LSM 数据文件和 changelog 文件的变更；读者可从 snapshot 递归访问表数据 。
六、K8s 如何影响平台治理
传统平台治理主要围绕"作业"展开：谁提交、跑多久、占多少资源、失败如何重试、日志在哪里。云原生湖仓的治理对象会进一步升级为"数据资产"：表的版本、Schema、权限、血缘、质量、生命周期、成本和维护任务都需要被统一管理。
Hudi 的表服务体系说明了这个趋势。Hudi 提供 Clustering、Compaction、Cleaning、Indexing 等表服务，可以 inline、半异步或全异步运行，Spark 和 Flink streaming writers 也可以在 continuous mode 下异步调用表服务 。这意味着湖仓平台不只是调度 ETL 作业，还要调度和治理表维护任务。
Iceberg 的治理重点在于表演进和多引擎一致性。添加或删除分区字段是元数据操作，不会改变已有数据文件，但会影响后续写入布局和动态分区覆盖语义 。这类能力要求平台理解表格式语义，而不能只把表当成对象存储目录。
Paimon 的治理重点更靠近实时链路。在流式模式写入 Paimon 时需要 checkpoint interval，并提供 OLAP 查询和 streaming query 示例；同时还支持通过 Flink managed memory 改善 sink 稳定性和性能 。因此，对 Paimon 表的治理不能只看离线文件大小，还要关注 checkpoint、bucket、compaction、changelog 和写入内存。
七、云原生湖仓架构
一个可落地的云原生湖仓平台，可以按如下方式理解：
在这个架构中，Spark 更适合大规模离线 ETL、批处理和机器学习特征加工；Flink 更适合 CDC、实时入湖、动态表更新和流式计算；Trino 或 SQL Gateway 更适合交互式查询和多源联邦分析。表格式层则承担计算引擎之间的一致数据语义。
八、选型建议
如果平台目标是多引擎、开放中立、长期演进，Iceberg 通常更适合作为统一湖仓表格式。它的 Catalog 抽象、隐藏分区、Schema 演进和分区演进能力，使其适合构建跨 Spark、Flink、Trino 的开放湖仓底座 。
如果业务有大量 CDC、upsert、delete、近实时写入和表服务自动化需求，Hudi 更有优势。它不仅提供表格式，还提供索引、并发控制、Metadata Table、Compaction、Clustering、Cleaning 等更接近数据库内核的能力 。
如果业务以 Flink 实时链路为核心，并希望天然支持主键更新、流式写入、changelog 和实时湖仓查询，Paimon 值得重点考虑。Paimon 主键表基于 bucket 和 LSM tree 组织数据，支持插入、更新和删除，并通过 snapshot 与 manifest 管理表状态 。
- 不要把"容器化"误认为"云原生"。如果只是把 Spark、Flink 镜像化运行，但作业发布、依赖管理、权限、日志、监控、成本、表维护仍然靠人工脚本，那么平台能力并没有真正升级。
- 要把 Catalog 当作平台核心服务，而不是普通配置。K8s 上的计算 Pod 生命周期短、数量多、变更频繁，Catalog 的高可用、鉴权、审计、连接池、版本兼容和灰度升级，会直接影响多引擎访问稳定性。
- 要重视表维护任务。Iceberg 的快照过期、Manifest 优化和分区演进，Hudi 的 Compaction、Clustering、Cleaning、Indexing，Paimon 的 LSM compaction、bucket 规划和 changelog 管理，都是生产湖仓长期稳定运行的核心。
- 要把实时链路和离线链路统一治理。Paimon 和 Hudi 都明显面向高频写入和增量更新场景，Iceberg 也支持 Flink 流批读写能力；平台不能再把"实时表"和"离线表"完全分开治理，而应统一看待表版本、Schema、主键、数据质量和血缘。