一、三巨头概览1.1 数据湖格式要解决什么传统数据湖HDFS Parquet的问题是问题说明无 ACID并发写入数据不一致无 Schema 演进加列需要重写整表无 Time Travel无法回到历史版本无 Upsert不支持行级更新小文件问题流式写入产生大量小文件数据湖格式Table Format在 Parquet 之上加了元数据管理层解决上述问题。1.2 三引擎对比一览维度IcebergHudiDelta Lake起源Netflix(2018) → ApacheUber(2017) → ApacheDatabricks(2019)核心引擎Spark/Flink/TrinoSpark/FlinkSpark(深度集成)表类型仅 Copy-on-WriteCoW Merge-on-ReadCoW MoR(2023)索引分区 ManifestBloom/Record Level/分区分区 Data Skipping社区活跃度高(多引擎)高中(Databricks 主导)生态开放最开放开放偏 Databricks二、架构设计对比2.1 Iceberg 架构┌─────────────────────────────────────────┐ │ Iceberg Table │ │ │ │ ┌─────────────┐ ┌─────────────────┐ │ │ │ Metadata │ │ Manifest List │ │ │ │ (.json) │ │ (Snapshot 层级) │ │ │ └──────┬──────┘ └────────┬────────┘ │ │ │ │ │ │ ┌──────▼──────────────────▼────────┐ │ │ │ Manifest Files │ │ │ │ (文件级元数据: 路径/统计/分区) │ │ │ └──────────────┬──────────────────┘ │ │ │ │ │ ┌──────────────▼──────────────────┐ │ │ │ Data Files (Parquet) │ │ │ │ file_1.parquet file_2.parquet │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘ 特点: - 三层元数据: metadata.json → manifest list → manifest - Manifest 文件记录每个数据文件的分区值和统计信息(min/max) - 读取时通过 Manifest 过滤无关文件效率极高 - 不依赖 Hive Metastore可独立工作2.2 Hudi 架构┌─────────────────────────────────────────┐ │ Hudi Table │ │ │ │ ┌─────────────────────────────────────┐│ │ │ Timeline ││ │ │ (instants: commit/deltacommit/...) ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ Index (多种类型) ││ │ │ Bloom / Simple / Bucket / Record ││ │ │ Level (HBase / RocksDB) ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ File Groups ││ │ │ ┌──────────┐ ┌──────────────────┐││ │ │ │ Base │ │ Log Files │││ │ │ │ (.parquet)│ │(.log, MoR 模式) │││ │ │ └──────────┘ └──────────────────┘││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ 特点: - Timeline 串起所有操作天然支持增量查询 - Index 实现 Upsert 的快速定位O(1) 或 O(log n) - MoR 模式: 写入先写 Log读取时合并 Base Log - 强项: CDC、Upsert、近实时流式入湖2.3 Delta Lake 架构┌─────────────────────────────────────────┐ │ Delta Table │ │ │ │ ┌─────────────────────────────────────┐│ │ │ _delta_log/ (事务日志) ││ │ │ 00000000000000000000.json ││ │ │ 00000000000000000001.json ││ │ │ ... ││ │ │ - 每次 commit 一个 JSON ││ │ │ - 记录 AddFile/RemoveFile 操作 ││ │ │ - Checkpoint 文件定期生成 ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ Data Files (Parquet) ││ │ │ file_1.parquet file_2.parquet ││ │ │ 每个文件记录 stats (min/max/count) ││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ 特点: - 最简单的元数据结构: 事务日志 JSON 序列 - Data Skipping: 基于 Parquet 文件的 min/max 统计 - 与 Spark 深度集成, 性能优化好 - Databricks 商业主导, 开源版部分功能受限三、特性矩阵对比特性IcebergHudiDelta LakeACID 事务✅✅✅Schema 演进✅ 加列/删列/改类型✅ 加列/删列✅ 加列/删列分区演进✅ 隐藏分区✅ 基本支持❌ 固定分区Time Travel✅✅ 增量查询✅Upsert/Delete✅ (CoW)✅ CoW MoR✅ CoW MoR并发写入✅ 乐观锁✅ 乐观锁(Lock)✅ 乐观锁小文件合并✅ 合并文件✅ Compaction✅ OPTIMIZEBloom Filter✅✅✅增量查询✅✅ (原生强项)⚠️ 有限支持引擎兼容Spark/Flink/Trino/PrestoSpark/FlinkSpark(最佳)流批一体✅✅✅四、压测环境4.1 硬件与集群集群: 5 节点 (1 Master 4 Worker) CPU: 32C64G per node 磁盘: 4TB NVMe SSD per node 内存: 256GB per node 网络: 10Gbps Spark: 3.5.0 (YARN 模式) 引擎版本: Iceberg 1.5.2 / Hudi 0.15.0 / Delta 3.2.04.2 测试数据数据集: 模拟电商订单数据 总行数: 1 亿行 数据量: ~500 GB (Parquet 未压缩) Schema: order_id, user_id, product_id, amount, status, city, ts 分区: 按日期分区 (2026-01-01 ~ 2026-08-31, 共 243 天)五、写入性能压测5.1 批量写入全量初始化# Iceberg 批量写入 spark.sql( CREATE TABLE iceberg.orders ( order_id STRING, user_id STRING, product_id STRING, amount DOUBLE, status STRING, city STRING, ts TIMESTAMP ) USING iceberg PARTITIONED BY (days(ts)) ) # 写入 1 亿行 spark.sql(INSERT INTO iceberg.orders SELECT * FROM source_orders)引擎写入时间写入吞吐(rows/s)数据文件数平均文件大小Iceberg38 min43,8604861.03 GBHudi (CoW)52 min32,0515120.98 GBHudi (MoR)41 min40,650486243 log1.0 GB logsDelta35 min47,6194701.06 GB分析Delta 写入最快因为与 Spark 深度集成优化Hudi CoW 最慢因为 Upsert 需要查 Index 定位Iceberg 表现稳定均衡5.2 流式写入增量 Upsert模拟 CDC 增量入湖每分钟 10 万行 Upsert# Hudi MoR 流式 Upsert (最强项) hudi_df.write.format(hudi) \ .option(hoodie.table.type, MERGE_ON_READ) \ .option(hoodie.datasource.write.operation, upsert) \ .option(hoodie.index.type, BUCKET) \ .option(hoodie.bucket.index.num.buckets, 64) \ .mode(append).save(base_path)引擎Upsert 吞吐延迟(P99)小文件增长Iceberg12,000 rows/s4.2s中(需合并)Hudi (MoR)28,000 rows/s1.8s低(log 模式)Hudi (CoW)5,500 rows/s8.5s中Delta15,000 rows/s3.5s中(需 OPTIMIZE)分析Hudi MoR 在 Upsert 场景碾压因为 Log 文件写入极快延迟低 3-5 倍。5.3 Delete 性能删除 500 万行数据按 user_id 删除引擎Delete 时间方式Iceberg3.2 min写 Delete File不重写数据Hudi4.8 min重写受影响的 File GroupDelta3.5 min写 Tombstone 标记六、读取性能压测6.1 全表扫描SELECT city, COUNT(*), SUM(amount) FROM orders GROUP BY city引擎扫描耗时扫描文件数数据跳过效率Iceberg4.2 min486/486 (100%)基线Hudi4.5 min512/512 (100%)基线Delta4.0 min470/470 (100%)基线全表扫描差异不大因为都要读全部数据。6.2 分区裁剪查询SELECT * FROM orders WHERE ts BETWEEN引擎扫描耗时扫描文件数跳过比例Iceberg8s14/48697.1%Hudi11s16/51296.9%Delta9s14/47097.0%Iceberg 的 Manifest 过滤最精准分区裁剪效率最高。6.3 Data Skipping / 文件级过滤-- 基于 user_id 的等值查询 SELECT * FROM orders WHERE user_id U12345678引擎扫描耗时扫描文件数命中行数Iceberg2.1s3/4861,245Hudi (Bloom)1.8s2/5121,245Delta2.3s5/4701,245Hudi 的 Bloom Filter 在等值查询上效率最高Delta 的 Data Skipping 依赖列统计效果一般。6.4 Time Travel 性能-- Iceberg: 查询 3 天前的快照 SELECT COUNT(*) FROM orders.history WHERE ts BETWEEN 2026-01-01 AND 2026-01-31 -- 使用 snapshot_id 指定历史版本 -- Hudi: 增量查询 SELECT * FROM hudi_orders WHERE _hoodie_commit_time 20260801000000 AND _hoodie_commit_time 20260802000000 -- Delta: 历史版本 SELECT COUNT(*) FROM delta.orders VERSION AS OF v123引擎Time Travel 查询延迟实现方式Iceberg基线Snapshot Manifest 切换Hudi增量查询快 3 倍Timeline 原生增量Delta基线事务日志版本七、Compaction 性能7.1 小文件合并流式写入 24 小时后每个引擎平均产生约 5000 个小文件平均 5MB引擎Compaction 命令耗时合并后文件数Icebergrewrite_data_files18 min486Hudi自动 Compaction12 min512DeltaOPTIMIZE15 min4707.2 Compaction 期间对读写的影响引擎写入影响读取影响Iceberg无影响(写新文件)无影响(读旧 snapshot)Hudi轻微影响轻微影响(MoR 需合并)Delta无影响无影响八、综合对比矩阵评分维度IcebergHudiDelta Lake批量写入★★★★☆★★★☆☆★★★★★流式 Upsert★★★☆☆★★★★★★★★★☆读取-全表★★★★☆★★★☆☆★★★★★读取-分区裁剪★★★★★★★★★☆★★★★☆读取-等值查询★★★★☆★★★★★★★★☆☆Time Travel★★★★☆★★★★★★★★★☆Schema 演进★★★★★★★★★☆★★★★☆Compaction★★★★☆★★★★★★★★★☆引擎兼容性★★★★★★★★★☆★★☆☆☆社区活跃★★★★★★★★★☆★★★☆☆综合4.34.13.9九、选型决策树你的场景是什么? │ ├─ 批处理为主多引擎查询 (Trino/Presto/Spark) │ └─→ Iceberg (引擎兼容性最佳) │ ├─ 流式 CDC Upsert 近实时 │ └─→ Hudi MoR (Upsert 吞吐 3 倍领先) │ ├─ Databricks 平台用户 │ └─→ Delta Lake (深度集成) │ ├─ 纯 Spark 批处理 │ └─→ Delta 或 Iceberg 皆可 │ ├─ 需要增量查询 (CDC 同步) │ └─→ Hudi (Timeline 原生增量) │ ├─ 分区演进/隐藏分区 │ └─→ Iceberg (唯一支持) │ └─ 不确定/想要最均衡 └─→ Iceberg (综合评分最高生态最开放)场景化推荐场景推荐理由日志归档 Trino 即席查询Iceberg多引擎兼容 分区裁剪强订单 CDC 实时入湖Hudi MoRUpsert 吞吐 增量查询Databricks 上的数仓Delta深度集成Z-Order 优化数据湖 AI 特征工程Iceberg引擎兼容多框架读流批一体 LakehouseHudiMoR/CoW 双模式灵活十、部署实战代码10.1 Iceberg 快速开始# Spark Iceberg spark SparkSession.builder \ .config(spark.sql.extensions, org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions) \ .config(spark.sql.catalog.iceberg, org.apache.iceberg.spark.SparkCatalog) \ .config(spark.sql.catalog.iceberg.type, hadoop) \ .config(spark.sql.catalog.iceberg.warehouse, s3://bucket/warehouse) \ .getOrCreate() # 建表 spark.sql( CREATE TABLE iceberg.orders ( order_id STRING, user_id STRING, amount DOUBLE, status STRING, ts TIMESTAMP ) USING iceberg PARTITIONED BY (days(ts)) ) # 写入 spark.sql(INSERT INTO iceberg.orders SELECT * FROM source) # 查询历史快照 spark.sql(SELECT * FROM iceberg.orders.history).show() # 输出: snapshot_id, timestamp, operation, ... # 小文件合并 spark.sql(CALL iceberg.system.rewrite_data_files(iceberg.orders))10.2 Hudi 快速开始# Spark Hudi hudi_options { hoodie.table.name: orders, hoodie.table.type: MERGE_ON_READ, hoodie.datasource.write.operation: upsert, hoodie.datasource.write.recordkey.field: order_id, hoodie.datasource.write.precombine.field: ts, hoodie.datasource.write.partitionpath.field: ts, hoodie.index.type: BUCKET, hoodie.bucket.index.num.buckets: 64, } # 写入 (Upsert) df.write.format(hudi).options(**hudi_options).mode(append).save(base_path) # 增量查询 spark.read.format(hudi) \ .option(hoodie.datasource.query.type, incremental) \ .option(hoodie.datasource.read.begin.instanttime, 20260801000000) \ .load(base_path)10.3 Delta Lake 快速开始# Spark Delta spark SparkSession.builder \ .config(spark.sql.extensions, io.delta.sql.DeltaSparkSessionExtension) \ .config(spark.sql.catalog.spark_catalog, org.apache.spark.sql.delta.catalog.DeltaCatalog) \ .getOrCreate() # 建表 spark.sql( CREATE TABLE delta.orders ( order_id STRING, user_id STRING, amount DOUBLE, ts TIMESTAMP ) USING DELTA PARTITIONED BY (DATE(ts)) ) # 写入 spark.sql(INSERT INTO delta.orders SELECT * FROM source) # 优化小文件 spark.sql(OPTIMIZE delta.orders) # Time Travel spark.sql(DESCRIBE HISTORY delta.orders).show() spark.sql(SELECT * FROM delta.orders VERSION AS OF 5).show()十一、总结没有最好的数据湖格式只有最适合的引擎一句话定位Iceberg最开放、最均衡多引擎生态首选Hudi流式 Upsert 增量查询最强项DeltaSpark 深度集成Databricks 用户首选选型时先确定核心场景再按决策树走。不确定就选 Iceberg综合评分最高且生态最开放。下一篇预告下一篇我们进入硬件 Edge AI 领域从 ESP32 传感器数据采集到 MQTT 上行到云端大模型推理的完整链路搭建。往期文章vLLM Continuous Batching5800 t/s 吞吐量的核心引擎。Spark 3.5 AQE 调优10 个生产环境案例让作业提速 3-10 倍。RAG 架构设计 7 个关键决策从 Chunk 策略到 Reranker 的生产级方案。GPTQ vs AWQ vs GGUF三大量化方案性能与精度横评。树莓派 5 TFLite 边缘部署实战YOLOv8 目标检测跑出 30fps 的完整方案。Kafka acks 机制性能实测acksall 在百万级吞吐下的延迟代价有多大。llama.cpp Q4 量化原理拆解10GB 显存跑 70B 模型的秘密。觉得有帮助请点赞收藏。关注专栏「AI大模型大数据硬件编程」每周更新技术选型的深度对比内容。 Iceberg vs Hudi vs Delta Lake：数据湖三引擎深度压测与选型
一、三巨头概览1.1 数据湖格式要解决什么传统数据湖HDFS Parquet的问题是问题说明无 ACID并发写入数据不一致无 Schema 演进加列需要重写整表无 Time Travel无法回到历史版本无 Upsert不支持行级更新小文件问题流式写入产生大量小文件数据湖格式Table Format在 Parquet 之上加了元数据管理层解决上述问题。1.2 三引擎对比一览维度IcebergHudiDelta Lake起源Netflix(2018) → ApacheUber(2017) → ApacheDatabricks(2019)核心引擎Spark/Flink/TrinoSpark/FlinkSpark(深度集成)表类型仅 Copy-on-WriteCoW Merge-on-ReadCoW MoR(2023)索引分区 ManifestBloom/Record Level/分区分区 Data Skipping社区活跃度高(多引擎)高中(Databricks 主导)生态开放最开放开放偏 Databricks二、架构设计对比2.1 Iceberg 架构┌─────────────────────────────────────────┐ │ Iceberg Table │ │ │ │ ┌─────────────┐ ┌─────────────────┐ │ │ │ Metadata │ │ Manifest List │ │ │ │ (.json) │ │ (Snapshot 层级) │ │ │ └──────┬──────┘ └────────┬────────┘ │ │ │ │ │ │ ┌──────▼──────────────────▼────────┐ │ │ │ Manifest Files │ │ │ │ (文件级元数据: 路径/统计/分区) │ │ │ └──────────────┬──────────────────┘ │ │ │ │ │ ┌──────────────▼──────────────────┐ │ │ │ Data Files (Parquet) │ │ │ │ file_1.parquet file_2.parquet │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘ 特点: - 三层元数据: metadata.json → manifest list → manifest - Manifest 文件记录每个数据文件的分区值和统计信息(min/max) - 读取时通过 Manifest 过滤无关文件效率极高 - 不依赖 Hive Metastore可独立工作2.2 Hudi 架构┌─────────────────────────────────────────┐ │ Hudi Table │ │ │ │ ┌─────────────────────────────────────┐│ │ │ Timeline ││ │ │ (instants: commit/deltacommit/...) ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ Index (多种类型) ││ │ │ Bloom / Simple / Bucket / Record ││ │ │ Level (HBase / RocksDB) ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ File Groups ││ │ │ ┌──────────┐ ┌──────────────────┐││ │ │ │ Base │ │ Log Files │││ │ │ │ (.parquet)│ │(.log, MoR 模式) │││ │ │ └──────────┘ └──────────────────┘││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ 特点: - Timeline 串起所有操作天然支持增量查询 - Index 实现 Upsert 的快速定位O(1) 或 O(log n) - MoR 模式: 写入先写 Log读取时合并 Base Log - 强项: CDC、Upsert、近实时流式入湖2.3 Delta Lake 架构┌─────────────────────────────────────────┐ │ Delta Table │ │ │ │ ┌─────────────────────────────────────┐│ │ │ _delta_log/ (事务日志) ││ │ │ 00000000000000000000.json ││ │ │ 00000000000000000001.json ││ │ │ ... ││ │ │ - 每次 commit 一个 JSON ││ │ │ - 记录 AddFile/RemoveFile 操作 ││ │ │ - Checkpoint 文件定期生成 ││ │ └──────────────────┬──────────────────┘│ │ │ │ │ ┌──────────────────▼──────────────────┐│ │ │ Data Files (Parquet) ││ │ │ file_1.parquet file_2.parquet ││ │ │ 每个文件记录 stats (min/max/count) ││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ 特点: - 最简单的元数据结构: 事务日志 JSON 序列 - Data Skipping: 基于 Parquet 文件的 min/max 统计 - 与 Spark 深度集成, 性能优化好 - Databricks 商业主导, 开源版部分功能受限三、特性矩阵对比特性IcebergHudiDelta LakeACID 事务✅✅✅Schema 演进✅ 加列/删列/改类型✅ 加列/删列✅ 加列/删列分区演进✅ 隐藏分区✅ 基本支持❌ 固定分区Time Travel✅✅ 增量查询✅Upsert/Delete✅ (CoW)✅ CoW MoR✅ CoW MoR并发写入✅ 乐观锁✅ 乐观锁(Lock)✅ 乐观锁小文件合并✅ 合并文件✅ Compaction✅ OPTIMIZEBloom Filter✅✅✅增量查询✅✅ (原生强项)⚠️ 有限支持引擎兼容Spark/Flink/Trino/PrestoSpark/FlinkSpark(最佳)流批一体✅✅✅四、压测环境4.1 硬件与集群集群: 5 节点 (1 Master 4 Worker) CPU: 32C64G per node 磁盘: 4TB NVMe SSD per node 内存: 256GB per node 网络: 10Gbps Spark: 3.5.0 (YARN 模式) 引擎版本: Iceberg 1.5.2 / Hudi 0.15.0 / Delta 3.2.04.2 测试数据数据集: 模拟电商订单数据 总行数: 1 亿行 数据量: ~500 GB (Parquet 未压缩) Schema: order_id, user_id, product_id, amount, status, city, ts 分区: 按日期分区 (2026-01-01 ~ 2026-08-31, 共 243 天)五、写入性能压测5.1 批量写入全量初始化# Iceberg 批量写入 spark.sql( CREATE TABLE iceberg.orders ( order_id STRING, user_id STRING, product_id STRING, amount DOUBLE, status STRING, city STRING, ts TIMESTAMP ) USING iceberg PARTITIONED BY (days(ts)) ) # 写入 1 亿行 spark.sql(INSERT INTO iceberg.orders SELECT * FROM source_orders)引擎写入时间写入吞吐(rows/s)数据文件数平均文件大小Iceberg38 min43,8604861.03 GBHudi (CoW)52 min32,0515120.98 GBHudi (MoR)41 min40,650486243 log1.0 GB logsDelta35 min47,6194701.06 GB分析Delta 写入最快因为与 Spark 深度集成优化Hudi CoW 最慢因为 Upsert 需要查 Index 定位Iceberg 表现稳定均衡5.2 流式写入增量 Upsert模拟 CDC 增量入湖每分钟 10 万行 Upsert# Hudi MoR 流式 Upsert (最强项) hudi_df.write.format(hudi) \ .option(hoodie.table.type, MERGE_ON_READ) \ .option(hoodie.datasource.write.operation, upsert) \ .option(hoodie.index.type, BUCKET) \ .option(hoodie.bucket.index.num.buckets, 64) \ .mode(append).save(base_path)引擎Upsert 吞吐延迟(P99)小文件增长Iceberg12,000 rows/s4.2s中(需合并)Hudi (MoR)28,000 rows/s1.8s低(log 模式)Hudi (CoW)5,500 rows/s8.5s中Delta15,000 rows/s3.5s中(需 OPTIMIZE)分析Hudi MoR 在 Upsert 场景碾压因为 Log 文件写入极快延迟低 3-5 倍。5.3 Delete 性能删除 500 万行数据按 user_id 删除引擎Delete 时间方式Iceberg3.2 min写 Delete File不重写数据Hudi4.8 min重写受影响的 File GroupDelta3.5 min写 Tombstone 标记六、读取性能压测6.1 全表扫描SELECT city, COUNT(*), SUM(amount) FROM orders GROUP BY city引擎扫描耗时扫描文件数数据跳过效率Iceberg4.2 min486/486 (100%)基线Hudi4.5 min512/512 (100%)基线Delta4.0 min470/470 (100%)基线全表扫描差异不大因为都要读全部数据。6.2 分区裁剪查询SELECT * FROM orders WHERE ts BETWEEN引擎扫描耗时扫描文件数跳过比例Iceberg8s14/48697.1%Hudi11s16/51296.9%Delta9s14/47097.0%Iceberg 的 Manifest 过滤最精准分区裁剪效率最高。6.3 Data Skipping / 文件级过滤-- 基于 user_id 的等值查询 SELECT * FROM orders WHERE user_id U12345678引擎扫描耗时扫描文件数命中行数Iceberg2.1s3/4861,245Hudi (Bloom)1.8s2/5121,245Delta2.3s5/4701,245Hudi 的 Bloom Filter 在等值查询上效率最高Delta 的 Data Skipping 依赖列统计效果一般。6.4 Time Travel 性能-- Iceberg: 查询 3 天前的快照 SELECT COUNT(*) FROM orders.history WHERE ts BETWEEN 2026-01-01 AND 2026-01-31 -- 使用 snapshot_id 指定历史版本 -- Hudi: 增量查询 SELECT * FROM hudi_orders WHERE _hoodie_commit_time 20260801000000 AND _hoodie_commit_time 20260802000000 -- Delta: 历史版本 SELECT COUNT(*) FROM delta.orders VERSION AS OF v123引擎Time Travel 查询延迟实现方式Iceberg基线Snapshot Manifest 切换Hudi增量查询快 3 倍Timeline 原生增量Delta基线事务日志版本七、Compaction 性能7.1 小文件合并流式写入 24 小时后每个引擎平均产生约 5000 个小文件平均 5MB引擎Compaction 命令耗时合并后文件数Icebergrewrite_data_files18 min486Hudi自动 Compaction12 min512DeltaOPTIMIZE15 min4707.2 Compaction 期间对读写的影响引擎写入影响读取影响Iceberg无影响(写新文件)无影响(读旧 snapshot)Hudi轻微影响轻微影响(MoR 需合并)Delta无影响无影响八、综合对比矩阵评分维度IcebergHudiDelta Lake批量写入★★★★☆★★★☆☆★★★★★流式 Upsert★★★☆☆★★★★★★★★★☆读取-全表★★★★☆★★★☆☆★★★★★读取-分区裁剪★★★★★★★★★☆★★★★☆读取-等值查询★★★★☆★★★★★★★★☆☆Time Travel★★★★☆★★★★★★★★★☆Schema 演进★★★★★★★★★☆★★★★☆Compaction★★★★☆★★★★★★★★★☆引擎兼容性★★★★★★★★★☆★★☆☆☆社区活跃★★★★★★★★★☆★★★☆☆综合4.34.13.9九、选型决策树你的场景是什么? │ ├─ 批处理为主多引擎查询 (Trino/Presto/Spark) │ └─→ Iceberg (引擎兼容性最佳) │ ├─ 流式 CDC Upsert 近实时 │ └─→ Hudi MoR (Upsert 吞吐 3 倍领先) │ ├─ Databricks 平台用户 │ └─→ Delta Lake (深度集成) │ ├─ 纯 Spark 批处理 │ └─→ Delta 或 Iceberg 皆可 │ ├─ 需要增量查询 (CDC 同步) │ └─→ Hudi (Timeline 原生增量) │ ├─ 分区演进/隐藏分区 │ └─→ Iceberg (唯一支持) │ └─ 不确定/想要最均衡 └─→ Iceberg (综合评分最高生态最开放)场景化推荐场景推荐理由日志归档 Trino 即席查询Iceberg多引擎兼容 分区裁剪强订单 CDC 实时入湖Hudi MoRUpsert 吞吐 增量查询Databricks 上的数仓Delta深度集成Z-Order 优化数据湖 AI 特征工程Iceberg引擎兼容多框架读流批一体 LakehouseHudiMoR/CoW 双模式灵活十、部署实战代码10.1 Iceberg 快速开始# Spark Iceberg spark SparkSession.builder \ .config(spark.sql.extensions, org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions) \ .config(spark.sql.catalog.iceberg, org.apache.iceberg.spark.SparkCatalog) \ .config(spark.sql.catalog.iceberg.type, hadoop) \ .config(spark.sql.catalog.iceberg.warehouse, s3://bucket/warehouse) \ .getOrCreate() # 建表 spark.sql( CREATE TABLE iceberg.orders ( order_id STRING, user_id STRING, amount DOUBLE, status STRING, ts TIMESTAMP ) USING iceberg PARTITIONED BY (days(ts)) ) # 写入 spark.sql(INSERT INTO iceberg.orders SELECT * FROM source) # 查询历史快照 spark.sql(SELECT * FROM iceberg.orders.history).show() # 输出: snapshot_id, timestamp, operation, ... # 小文件合并 spark.sql(CALL iceberg.system.rewrite_data_files(iceberg.orders))10.2 Hudi 快速开始# Spark Hudi hudi_options { hoodie.table.name: orders, hoodie.table.type: MERGE_ON_READ, hoodie.datasource.write.operation: upsert, hoodie.datasource.write.recordkey.field: order_id, hoodie.datasource.write.precombine.field: ts, hoodie.datasource.write.partitionpath.field: ts, hoodie.index.type: BUCKET, hoodie.bucket.index.num.buckets: 64, } # 写入 (Upsert) df.write.format(hudi).options(**hudi_options).mode(append).save(base_path) # 增量查询 spark.read.format(hudi) \ .option(hoodie.datasource.query.type, incremental) \ .option(hoodie.datasource.read.begin.instanttime, 20260801000000) \ .load(base_path)10.3 Delta Lake 快速开始# Spark Delta spark SparkSession.builder \ .config(spark.sql.extensions, io.delta.sql.DeltaSparkSessionExtension) \ .config(spark.sql.catalog.spark_catalog, org.apache.spark.sql.delta.catalog.DeltaCatalog) \ .getOrCreate() # 建表 spark.sql( CREATE TABLE delta.orders ( order_id STRING, user_id STRING, amount DOUBLE, ts TIMESTAMP ) USING DELTA PARTITIONED BY (DATE(ts)) ) # 写入 spark.sql(INSERT INTO delta.orders SELECT * FROM source) # 优化小文件 spark.sql(OPTIMIZE delta.orders) # Time Travel spark.sql(DESCRIBE HISTORY delta.orders).show() spark.sql(SELECT * FROM delta.orders VERSION AS OF 5).show()十一、总结没有最好的数据湖格式只有最适合的引擎一句话定位Iceberg最开放、最均衡多引擎生态首选Hudi流式 Upsert 增量查询最强项DeltaSpark 深度集成Databricks 用户首选选型时先确定核心场景再按决策树走。不确定就选 Iceberg综合评分最高且生态最开放。下一篇预告下一篇我们进入硬件 Edge AI 领域从 ESP32 传感器数据采集到 MQTT 上行到云端大模型推理的完整链路搭建。往期文章vLLM Continuous Batching5800 t/s 吞吐量的核心引擎。Spark 3.5 AQE 调优10 个生产环境案例让作业提速 3-10 倍。RAG 架构设计 7 个关键决策从 Chunk 策略到 Reranker 的生产级方案。GPTQ vs AWQ vs GGUF三大量化方案性能与精度横评。树莓派 5 TFLite 边缘部署实战YOLOv8 目标检测跑出 30fps 的完整方案。Kafka acks 机制性能实测acksall 在百万级吞吐下的延迟代价有多大。llama.cpp Q4 量化原理拆解10GB 显存跑 70B 模型的秘密。觉得有帮助请点赞收藏。关注专栏「AI大模型大数据硬件编程」每周更新技术选型的深度对比内容。