湖仓一体之Apache Iceberg

Apache Iceberg 详细介绍

什么是 Iceberg

Apache Iceberg 是一个面向大规模分析数据集的 开放表格式（Open Table Format），最初由 Netflix 开发，后来捐赠给 Apache Software Foundation。

它的核心目标是：

解决传统 Hive 表在数据湖中的缺陷
提供类似数据仓库（DW）的能力
支持 PB 级数据管理
支持批流一体
支持 ACID 事务
支持多引擎统一访问

Iceberg 本质上是：

"运行在对象存储/HDFS上的下一代大数据表格式"

它通常运行在：

HDFS
S3
OSS
GCS
Azure Blob Storage

之上。

一、为什么需要 Iceberg

传统 Hive 数据湖的问题

传统 Hive 表存在很多问题：

问题	描述
元数据依赖目录	分区=目录
小文件严重	查询慢
Rename 成本高	云存储性能差
不支持事务	数据不一致
Schema 演进困难	改字段容易出错
分区管理复杂	手工维护
流批难统一	实时支持差
多引擎兼容差	元数据不统一

例如：

复制代码

dt=20250515/hour=10/

Hive 依赖目录表达分区。

但在对象存储：

rename 很慢
list 很贵
consistency 问题明显

因此：

Hive 不适合现代云原生 Lakehouse。

二、Iceberg 核心思想

Iceberg 的核心：

1. 数据与元数据彻底解耦

传统 Hive：

复制代码

目录 = 分区

Iceberg：

复制代码

元数据决定数据位置

而不是目录结构。

即：

复制代码

Table Metadata
    ↓
Manifest List
    ↓
Manifest File
    ↓
Data File

这是 Iceberg 最核心设计。

三、Iceberg 架构

整体架构

复制代码

                Query Engine
      (Spark/Flink/Trino/Doris)

                    ↓

              Iceberg Catalog
     (Hive/Nessie/REST/JDBC)

                    ↓

            Iceberg Metadata

                    ↓

        Manifest / Snapshot

                    ↓

          Parquet/ORC/Avro

                    ↓

          S3/HDFS/OSS

四、Iceberg 核心组件

1. Catalog（目录服务）

Catalog 管理：

表
Namespace
Snapshot
元数据位置

常见 Catalog：

Catalog	用途
HiveCatalog	Hive Metastore
HadoopCatalog	文件系统
REST Catalog	云原生
JDBC Catalog	数据库存储
Nessie Catalog	Git-like 数据版本

Nessie 非常重要

Project Nessie 提供：

Branch
Tag
Time Travel
Data DevOps

类似：

复制代码

Git for Data

Lakehouse 趋势里非常重要。

2. Snapshot（快照）

Iceberg 的核心能力之一。

每次写入：

不会覆盖原文件。

而是：

复制代码

生成新 Snapshot

例如：

复制代码

Snapshot 100
Snapshot 101
Snapshot 102

查询默认读取：

复制代码

Current Snapshot

因此：

天然支持回滚
支持 Time Travel
支持审计

3. Manifest File

Manifest 记录：

复制代码

哪些 Data File 属于当前 Snapshot

类似：

复制代码

文件索引

Manifest 中记录：

文件路径
分区值
min/max
null count
row count

因此：

Iceberg 可以进行文件级裁剪。

4. Metadata File

Metadata File 是总入口。

包括：

schema
partition spec
snapshots
manifests
properties

结构：

复制代码

metadata.json

类似数据库：

复制代码

事务日志入口

五、Iceberg 写入原理

Copy-on-Write（COW）

更新数据时：

复制代码

重写整个 Data File

优点：

查询快

缺点：

写放大严重

适合：

OLAP 查询

Merge-on-Read（MOR）

增量写：

复制代码

Delta File + Base File

读取时合并。

优点：

实时写入性能高

缺点：

查询复杂

适合：

实时流式场景

六、Iceberg 元数据树

元数据层次

复制代码

metadata.json
    ↓
manifest list
    ↓
manifest file
    ↓
data file

这是 Iceberg 的灵魂。

七、Iceberg 分区机制

隐式分区（Hidden Partition）

传统 Hive：

复制代码

WHERE dt='2025-05-15'

必须知道分区字段。

Iceberg：

用户无需关心。

例如：

复制代码

WHERE create_time > now()-1d

Iceberg 自动裁剪分区。

分区 Transform

支持：

Transform	示例
identity	原值
year	年
month	月
day	日
hour	小时
bucket	hash桶
truncate	截断

例如：

复制代码

PARTITIONED BY (
  days(ts),
  bucket(16, user_id)
)

八、Iceberg Schema Evolution

Iceberg 支持真正安全的 Schema 演进。

支持：

操作	是否支持
Add Column	√
Rename Column	√
Drop Column	√
Reorder Column	√
Type Promotion	√

原因：

Iceberg 使用 Field ID，而不是字段名。

例如：

复制代码

id=1 name=user_id

即使改名：

复制代码

id=1 name=uid

仍然兼容。

这是 Iceberg 非常先进的设计。

九、Iceberg 的 ACID 事务

Iceberg 使用：

复制代码

Optimistic Concurrency Control

提交时：

检查 metadata version。

类似：

复制代码

CAS(compare and swap)

流程：

复制代码

读取metadata v10
    ↓
生成新metadata v11
    ↓
提交
    ↓
若已变v12 → retry

因此：

支持：

并发写
原子提交
Snapshot Isolation

十、Iceberg 与 Hive 的区别

对比	Hive	Iceberg
分区	目录	元数据
Schema Evolution	差	强
Time Travel	无	有
ACID	弱	强
Streaming	差	强
云存储	不友好	原生支持
小文件优化	弱	强
多引擎	差	强

十一、Iceberg 与 Hudi 与 Delta Lake 对比

核心定位

技术	定位
Iceberg	通用 Lakehouse
Hudi	实时增量
Delta Lake	Databricks生态

详细对比

能力	Iceberg	Hudi	Delta
开放性	强	强	中
流式写入	强	非常强	强
查询性能	强	中	强
元数据设计	最先进	较复杂	简单
多引擎支持	最强	中	中
隐式分区	√	×	×
Schema演进	强	中	强
Time Travel	√	√	√

十二、Iceberg 生态

计算引擎支持

引擎	支持情况
Apache Spark	非常成熟
Apache Flink	流批一体
Trino	查询强
Apache Doris	新增支持
StarRocks	支持较好
Apache Hive	部分支持
Snowflake	开始支持

存储格式

支持：

Parquet（主流）
ORC
Avro

通常：

复制代码

Iceberg + Parquet

最常见。

十三、Iceberg 核心能力

1. Time Travel

查询历史版本：

复制代码

SELECT * FROM t VERSION AS OF 100;

或者：

复制代码

SELECT * FROM t TIMESTAMP AS OF '2025-05-15';

2. Incremental Read

增量读取：

复制代码

read between snapshot 100 and 101

用于：

CDC
增量同步
流处理

3. Branch & Tag

配合 Nessie：

复制代码

dev branch
prod branch

实现：

数据 CI/CD
数据实验
数据回滚

十四、Iceberg 在实时数仓中的作用

现代架构：

复制代码

Kafka
   ↓
Flink
   ↓
Iceberg
   ↓
Trino/Spark/Doris

实现：

流批统一
实时湖仓
CDC
AI数据底座

十五、Iceberg 在 AI 场景中的价值

AI 数据平台越来越依赖 Iceberg。

原因：

1. 支持海量训练数据

例如：

PB级日志
多模态数据
Feature 数据

2. 支持版本化

训练集：

复制代码

dataset v1
dataset v2

可追溯。

3. 支持 Time Travel

可复现训练。

这是 MLOps 非常关键能力。

4. 支持多引擎共享

例如：

复制代码

Spark 做ETL
Flink 做实时
Trino 做查询
PyTorch 做训练

统一数据源。

十六、Iceberg 性能优化

小文件治理

非常关键。

常用：

复制代码

rewrite data files

进行 compaction。

Manifest 合并

复制代码

rewrite manifests

减少 metadata 开销。

分区设计

避免：

复制代码

高基数分区

排序优化

支持：

复制代码

Z-order
sort order

提升 scan 性能。

十七、Iceberg 典型架构

1. 离线湖仓

复制代码

Spark + Iceberg + Trino

2. 实时湖仓

复制代码

Kafka + Flink + Iceberg

3. AI Lakehouse

复制代码

Feature Store
    ↓
Iceberg
    ↓
Vector DB
    ↓
LLM

十八、Iceberg 使用示例

Spark 创建 Iceberg 表

复制代码

CREATE TABLE lake.user (
  id BIGINT,
  name STRING,
  ts TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(ts));

Flink 写入

复制代码

CREATE TABLE iceberg_sink (
  id BIGINT,
  name STRING
) WITH (
  'connector'='iceberg',
  'catalog-name'='iceberg'
);

十九、Iceberg 最大优势总结

Iceberg 真正解决了：

1. 云存储问题

适合：

2. 多引擎共享问题

真正：

复制代码

One Table
Multi Engine

3. 数据版本问题

支持：

snapshot
rollback
audit
time travel

4. 实时湖仓问题

支持：

Flink CDC
Streaming Upsert
Incremental Read

二十、Iceberg 未来趋势

Iceberg 正在成为：

Lakehouse 默认标准

越来越多系统正在转向 Iceberg：

Snowflake
Databricks
AWS
StarRocks
Doris
Fluss/Flink生态

未来趋势：

复制代码

Iceberg + REST Catalog + Nessie

会越来越重要。

二十一、适合你的学习路线（大数据/AI方向）

结合你已有的大数据背景，建议重点学习：

第一阶段

Iceberg 基础
Snapshot
Manifest
Catalog

第二阶段

Spark + Iceberg
Flink + Iceberg
CDC → Iceberg

第三阶段

Nessie
Branch/Tag
Lakehouse治理

第四阶段（AI方向）

Feature Store + Iceberg
向量数据管理
AI训练集版本化
RAG 数据底座

二十二、推荐技术组合

你当前背景非常适合：

复制代码

Flink + Iceberg + Doris + Kafka

以及：

复制代码

Iceberg + Nessie + Spark + AI Pipeline

这是未来 AI Data Platform 的核心方向。