2. 湖仓架构基础
在金融行业的数据平台演进中，我们经常听到"数据湖""数据仓库""湖仓一体"以及 Delta Lake、Iceberg、Hudi 这些名词。它们并非简单的营销概念，而是针对不同阶段数据管理痛点的技术回应。理解它们的核心差异，是后续小文件治理与 Compaction 实战的前提。
一、核心原理：三种架构范式的本质区别
数据仓库以 Schema-on-Write 为核心，数据在写入前必须经过清洗、建模，采用星型或雪花模型组织。它的优势是查询性能高、数据质量可控，适合 BI 报表与监管报送；但扩展成本高，对半结构化数据和非结构化数据支持弱，且难以承载机器学习所需的原始明细数据。
数据湖以 Schema-on-Read 为核心，通常构建在 HDFS 或对象存储之上，可以低成本存储任意格式的原始数据。它解决了仓库扩展性差的问题，但缺乏事务保证、缺少元数据管理，容易退化为"数据沼泽"——数据很多，却难以找到、难以信任。
湖仓一体试图在数据湖的低成本存储之上，叠加数据仓库的事务能力、Schema 管理和性能优化。它既保留开放格式，又提供 ACID、时间旅行、增量读取等能力。Delta Lake、Iceberg、Hudi 正是实现湖仓一体的三大主流表格式。
二、方法流程：三大表格式的写入与治理机制
三者都通过元数据层实现 ACID，但组织方式不同。Delta Lake 使用单一事务日志目录 _delta_log，每次提交生成一个 JSON 文件，记录新增和删除的文件清单；Iceberg 采用 Catalog → Metadata → Manifest → Data File 的四层结构，元数据可独立于计算引擎；Hudi 则维护一条 Timeline，将 commit、compaction、clustering 等操作按时间排列。
以 Hudi 的 MOR 表为例，写入流程如下：
# 写入时先追加到日志文件（Avro 格式）
hoodie write --table-type MERGE_ON_READ \
--op UPSERT \
--target-table trade_flow
# 达到阈值后触发 Compaction，将日志合并为列式 Parquet
hoodie compaction run \
--table trade_flow \
--compaction-trigger-strategy DELTA_COMMITS \
--compaction-delta-commits 5
# 小文件治理：Clustering 按大小重分布
hoodie clustering run \
--table trade_flow \
--clustering-plan-size 128MBDelta Lake 的治理命令更简洁：
-- 合并小文件并重写为 128MB 目标大小
OPTIMIZE trade_flow
WHERE dt >= '2024-01-01'
ZORDER BY (account_id);
-- 清理超过 7 天的旧版本文件
VACUUM trade_flow RETAIN 168 HOURS;Iceberg 则通过 rewrite_data_files 过程完成类似工作，并支持按分区并行执行。
三、金融场景选型：从业务特征出发
| 选型维度 | Delta Lake | Iceberg | Hudi |
|---|---|---|---|
| 典型写入模式 | 批流一体、追加为主 | 批量重写、分区演进 | 高频 Upsert、CDC |
| 引擎兼容性 | Spark 最佳，其他较弱 | Spark/Flink/Trino 均好 | Spark/Flink 较好 |
| 小文件治理手段 | OPTIMIZE + Z-Order | Rewrite Data Files | Clustering + Compaction |
| 金融适配场景 | Databricks 湖仓、报表加速 | 多引擎开放湖、数据共享 | 交易流水 CDC、实时风控 |
| 时间旅行 | 支持 | 支持 | 支持（有限） |
在金融实践中，选型往往不是非此即彼。例如，某银行在实时风控链路使用 Hudi 承接 CDC 交易流水，利用 MOR 表实现秒级 Upsert；在离线报表层使用 Iceberg 构建开放湖，供 Spark、Trino、Flink 多引擎共享；在 Databricks 平台上则用 Delta Lake 做特征工程与模型训练。关键是根据写入频率、更新比例、查询引擎和治理成本综合判断。
四、误区与复盘：选型中的常见陷阱
误区一：认为湖仓一体就是"数据湖 + 数据仓库"的简单叠加。实际上，湖仓一体的核心是表格式带来的事务与元数据能力，没有这层，湖和仓仍然是割裂的。
误区二：忽视小文件问题的架构根源。无论选择哪种表格式，高频写入、分区过细、并发提交都会产生小文件。Compaction 不是可选项，而是必须纳入日常调度的治理动作。
- 复盘要点一：选型前先明确写入模式——是追加、覆盖还是 Upsert，这直接决定 COW 与 MOR 的取舍。
- 复盘要点二：评估查询引擎矩阵，若存在 Trino、Flink、Spark 多引擎共享需求，Iceberg 的开放性更具优势。
- 复盘要点三：将 Compaction 与 Clustering 纳入 SLA 管理，设置文件大小阈值与调度频率，避免小文件累积到影响查询性能才被动处理。
- 复盘要点四：元数据规模同样需要治理，Iceberg 的 Manifest 和 Delta 的日志文件过多时，也会成为查询瓶颈。
理解这三种表格式的差异与适用边界，是后续深入 Compaction 参数调优、文件大小策略和调度设计的基础。在金融场景中，没有绝对最优的格式，只有与业务写入特征、查询模式和治理能力最匹配的选择。