想象你有一套住了十年的房子，几乎每年都要折腾一次装修。今天拆一面墙，明天加个卫生间，后天把客厅地板换成大理石。如果没有一本详细的装修档案，你会彻底忘记哪面墙里埋着水管、哪一年的照片对应哪个布局、上次改水电是几月。等到你想“看看去年这时候屋子长什么样”，只能靠模糊的记忆。 Apache Iceberg 就是数据湖里那本“装修档案册”。它把一张数据表当作一栋不断变化的老房子，用一套清晰的元数据记录每一次“装修”（写入数据）之后屋子里长什么样——有多少文件、什么分区、什么字段。有了这些记录，你可以随时“回到过去”查看某天的屋子，也可以从容地改造格局（分区）、加装设施（字段），而且不会影响正在居住的人（读写互不干扰）。Iceberg 的出现，让数据湖从“堆放杂物的仓库”进化成了“有档案、有规划、可回溯的智慧之家”。

岗位关联

对 AI 从业者的价值：Iceberg 的版本化快照、Schema 演进与分区演进，是现代数据湖平台的地基。掌握它，你就能搭建出数据可回溯、架构可演进、读写可并发的高性能数据底座。

目录
  1. 可视化演示
  2. 表格式核心
  3. 元数据层
  4. 快照管理
  5. 分区演进
  6. Schema演进
  7. 读写性能
  8. 应用场景
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

元数据层级：数据文件的索引树 Iceberg采用三层元数据：元数据文件、清单列表和清单文件，实现高效的数据定位 每层元数据记录快照、分区和数据文件的映射关系，支持快速文件查找 三层元数据架构实现高效数据定位与快照管理

表格式核心

回到那套房子。装修最怕什么？最怕只有一面墙的施工记录，却没有整体蓝图。一开始你可能只想刷个墙，但住久了会发现：想给客厅加个插座，得先搞清楚墙壁后面的电线怎么走的。数据湖也面临同样的尴尬——早期大家用 Hive 表格式，它只记录了“家具摆在哪”，却没有一套统一的“房屋档案”。一旦你要改分区、改字段，Hive 就要求你重写整个表，仿佛要把房子推倒重建。

Iceberg 之所以被称为“表格式”（Table Format），是因为它定义了一套描述“一张表长什么样”的标准规范。这套规范把一张表拆成两半：一半是实实在在的数据文件（Data Files），也就是屋子里的墙体、地板、家具；另一半是元数据（Metadata），也就是那本记录了每次改动、当前布局、历史影像的装修档案。两半分离，意味着“看图纸”和“动房子”可以分开进行——读数据时查档案即可，不必翻箱倒柜找实物。

Iceberg 核心公式可以用一个集合来表达：一张表 = 元数据集合 + 数据文件集合。

正因如此，Iceberg 表才敢说“读不会被打断，写不会被阻塞”。装修工人（写入任务）改他的墙，你依然可以拿着旧照片（历史快照）安静地看家——这就是表格式带来的从容。

TableIceberg={M1,M2,…,Mk}∪{D1,D2,…,Dn}\text{Table}_{\text{Iceberg}} = \{M_1, M_2, \dots, M_k\} \cup \{D_1, D_2, \dots, D_n\}
这个公式表明：Iceberg 的“表”不是某一堆物理文件，而是“档案（元数据）”与“实体（数据文件）”的联合体。档案决定表的结构和版本，实体决定表的内容。
  1. 左边（表）代表一张完整的 Iceberg 表，它是你操作的最小单位。
    TableIceberg\text{Table}_{\text{Iceberg}}
  2. 并集符号表示表由两类信息组合而成，缺一不可。“档案”丢了，表就无法解析；“数据”丢了，档案就成了空壳。
    ∪\cup
  3. 元数据集合每一条 $M_i$ 都是表的一次布局记录，像一张张施工蓝图，描述列、分区、快照等。
    {M1,M2,…,Mk}\{M_1, M_2, \dots, M_k\}
  4. 数据文件集合每一条 $D_j$ 都是一个真实的数据文件，像一块块瓷砖、一根根木梁，真正承载着数据内容。
    {D1,D2,…,Dn}\{D_1, D_2, \dots, D_n\}

元数据层

装修档案本身不能是一团乱麻，得分类存放。经验丰富的管家会这样整理：先有一本总目录，指明“今天家里是什么版本”；总目录再指向几个文件柜，每个文件柜里是一叠叠凭证。Iceberg 的元数据层正是这种“三级抽屉”设计。

它的结构可以这样理解：最顶层是元数据文件（Metadata File），相当于总目录，记录了表当前指向哪一个快照；第二层是 Manifest 列表（Manifest List），相当于文件柜上的标签，告诉你这个快照包含了哪几组文件清单；第三层是 Manifest 文件，相当于一叠具体的凭证，里面的每一行都指向一个真实的数据文件，并记录了该文件的统计信息（行数、大小、列范围等）。

这个层级关系用箭头表示，就是一条清晰的“找数据”的路线图：

为什么要设计这么多层？想象你要在一栋写字楼里找一家公司：先看大楼总索引（元数据文件），再到对应楼层的公司铭牌（Manifest List），然后看门牌号（Manifest），最后推门进去（DataFile）。没有这套索引，你就只能挨家挨户敲门——那正是 Hive 表在大数据量下查询奇慢的原因之一。

Table→ManifestList→Manifest→DataFile\text{Table} \rightarrow \text{ManifestList} \rightarrow \text{Manifest} \rightarrow \text{DataFile}
读数据时，查询引擎沿着这条链路逐层下沉，每次都结合统计信息过滤掉不需要的分支，最终只读取真正命中的数据文件。
  1. 表入口查询从表名开始，通过 Catalog（元数据目录服务）定位到元数据文件。
    Table\text{Table}
  2. 清单列表一个快照通常对应一个 Manifest List，它聚合了该快照涉及的所有 Manifest。
    ManifestList\text{ManifestList}
  3. 清单文件每个 Manifest 管理一组数据文件，并附上列统计信息，用于查询裁剪。
    Manifest\text{Manifest}
  4. 数据文件链条的末端是真实存储的 Parquet / ORC 文件，真正开始读到数据。
    DataFile\text{DataFile}

快照管理

每次装修告一段落，你都会站在客厅中央拍一张“全家福”。Iceberg 的快照（Snapshot）就是数据表的全家福：它记录了某一时刻所有数据文件的“合影”——文件列表、统计信息、改动描述全部固化下来。这张照片一旦生成就不可修改，永远忠实于那一刻的房间状态。

有了快照，时间旅行就顺理成章了。所谓“时间旅行”（Time Travel），就是查询任意历史快照：想看上周的数据，就加载上周那张全家福；想对比本月和上月的指标，就直接读两个快照。这不是靠备份恢复，而是沿着快照链随手翻阅，毫秒级定位。Iceberg 还借助乐观并发控制实现了 ACID 事务：多个写作业同时提交时，只有版本号最新的那个能成功，其余自动重试，读取者始终看到完整的快照。

最新快照的选择可以用一个简单的最大化公式表示：

当然，相册不能无限厚。你可以配置“保留最近 N 个快照”或“保留最近 T 天”，让过期快照在清理任务中自动删除。这就像定期把十年前模糊的海边合影丢掉，为相册腾出空间，而不必担心丢掉最新生活。

Slatest=max⁡s∈Ss.timestampS_{\text{latest}} = \max_{s \in \mathcal{S}} s.\text{timestamp}
在 Iceberg 维护的快照集合 $\mathcal{S}$ 中，时间戳最大者就是“当前版本”。查询默认读取它；若指定历史时间戳，则读取当时的快照。
  1. 最新快照（左边）$S_{\text{latest}}$ 表示当前表的版本，所有不带历史条件的查询都默认访问它。
    SlatestS_{\text{latest}}
  2. 最大化操作$\max$ 符号表示在集合中找出时间戳最大的那个快照。
    max⁡\max
  3. 快照集合$\mathcal{S}$ 是所有未过期快照的集合，如同相册里保留的每一张全家福。
    S\mathcal{S}
  4. 时间戳字段$s.\text{timestamp}$ 是拍下这张照片的时刻，单调递增。
    s.timestamps.\text{timestamp}

分区演进

你住了几年后发现，两间小卧室太挤，干脆打通变成大客厅。这就是格局改造——但改造绝不能把整栋楼拆了重盖，而应该只是从“今天起”按新格局施工，老房间保持原样。Hive 表做不到这一点：分区规则写死在目录路径里（比如 /year=2024/month=01），想改成按天分区就要重写所有历史数据。Iceberg 则把分区规则放在元数据层，可以在任意时刻为表“换格局”。

这就是分区演进（Partition Evolution）：Iceberg 允许你随时新增、修改分区规则，且只对之后写入的新数据生效，历史数据保持原布局不动。查询时，引擎自动合并两种分区规则的结果，用户完全无感知。更有趣的是幂等式的隐藏分区（Hidden Partitioning）：你甚至不需要在建表时声明分区列，Iceberg 会自动根据查询条件推断和生成分区，比如按时间戳字段自动截取成天分区。

分区的变化可以用集合运算表示：

住在这样的房子里，你完全不用担心中途换了装修公司（计算引擎）会看不懂格局。老图纸、新图纸都挂在墙上，谁来都能一眼看懂过去和现在的差异。

Pnew=Pold∪{new_rule}\mathcal{P}_{\text{new}} = \mathcal{P}_{\text{old}} \cup \{\text{new\_rule}\}
新分区规则只是向原有规则集合中添加一项，旧的物理分区依然保留。这就是“改造不拆楼”的数学表达。
  1. 新分区规则集（左边）$\mathcal{P}_{\text{new}}$ 是表当前生效的全部分区规则，查询优化器会参考它做裁剪。
    Pnew\mathcal{P}_{\text{new}}
  2. 旧分区规则集$\mathcal{P}_{\text{old}}$ 是表历史上定义过的分区规则，它们仍对各自时间段的数据有效。
    Pold\mathcal{P}_{\text{old}}
  3. 并集运算$\cup$ 表示新增规则不会覆盖或删除旧规则，只会叠加共存。
    ∪\cup
  4. 新规则$\text{new\_rule}$ 可以是“按天分区”“按城市哈希分区”等任意新的布局策略。
    new_rule\text{new\_rule}

Schema演进

住了几年，你想加装一套地暖，或者把原来的储藏室改成书房。加装设施不必把房子从地基开始重盖——只需要在蓝图里加几笔标注。Iceberg 的 Schema 演进（Schema Evolution，表结构演进）正是这种“加几笔标注”的操作：新增一列、删除一列、重命名字段，都只是修改元数据，完全不需要重写底层数据文件。

比如，你现在有四列 id, name, age，想加一列 email。在 Hive 里这可能要全表扫描重写；而在 Iceberg 里，只是生成一个新 Schema 并把表的元数据指针指过去，旧文件依然原封不动地被新 Schema 解释。更厉害的是类型升级：int 扩到 long、float 扩到 double，Iceberg 会在读取时自动做安全转换，不用你手动改数据。列重命名也同理，只要元数据里维护好新旧名字的映射，历史文件里的旧字段名照常对应得上。

Schema 的变更可以抽象为集合操作：

这就像施工队拿到了新版施工图，只需要知道“多了哪面墙、少了哪扇门”，不必把整栋楼拆掉重砌。对于运营中的大数据平台而言，这意味着凌晨两点的加字段操作不再是一场灾难，而是几分钟就完成的平滑升级。

Schema′=Schema∪{cnew}∖{cold}\text{Schema}' = \text{Schema} \cup \{c_{\text{new}}\} \setminus \{c_{\text{old}}\}
新版表结构 = 原表结构 + 新字段 − 旧字段。所有修改都发生在“图纸”层面，物理文件纹丝不动。
  1. 新表结构（左边）$\text{Schema}'$ 是演进之后的表结构，查询和写入都按它来解读。
    Schema′\text{Schema}'
  2. 原表结构$\text{Schema}$ 是演进前的旧结构，Iceberg 会在元数据中保留它的历史版本，方便回溯。
    Schema\text{Schema}
  3. 加入新字段$\cup \{c_{\text{new}}\}$ 表示新增列，比如给用户表加一个 email 字段。
    ∪{cnew}\cup \{c_{\text{new}}\}
  4. 移除旧字段$\setminus \{c_{\text{old}}\}$ 表示删除列或安全转换类型，标记为遗弃但仍可读旧数据。
    ∖{cold}\setminus \{c_{\text{old}}\}

读写性能

家里东西再多，只要档案管理得好，找起来就不费劲。每次找东西你会先翻索引，而不是翻箱倒柜。Iceberg 在提升读写性能上正是靠“先看图纸，再动身手”。它的 Manifest 文件里预存了每个数据文件的列统计信息（最小值、最大值、行数等）。当查询条件带有 WHERE date > '2024-01-01' 时，引擎直接扫一眼清单，把不满足条件的文件全部跳过，只读取命中文件。

另一个性能杀手是“小文件泛滥”。想象你把一百双袜子散落在地板各处，每次收衣服都要满屋跑。Iceberg 提供 rewrite_data_files 这类小文件合并操作，把大量小文件重写为几个大文件，显著减少文件数量和元数据开销。此外，底层数据文件采用 Parquet/ORC 列式存储并按列压缩，查询时只解压涉及的列，进一步降低 IO。

“跳过率”可以用这个公式来刻画：

住久了的房子，只要定期整理、贴好标签，再大也能住得舒心。Iceberg 的压缩和合并策略就是你的“定期大扫除”，让数据湖始终轻盈、好找、快读。

SkipRate=1−∣Fscan∣∣Ftotal∣\text{SkipRate} = 1 - \frac{|\mathcal{F}_{\text{scan}}|}{|\mathcal{F}_{\text{total}}|}
SkipRate 表示查询中被裁剪掉的文件占比。它越高，说明元数据过滤越有效，查询速度越快。
  1. 跳过率（左边）$\text{SkipRate}$ 是衡量查询效率的关键指标，理想值接近 1。
    SkipRate\text{SkipRate}
  2. 1 减去表示“总文件里没被读的那部分”，用 1 减去扫描比例得到。
    1−1 -
  3. 实际扫描文件数$\mathcal{F}_{\text{scan}}$ 是经过元数据过滤后真正需要读的文件集合，通常远小于总数。
    Fscan\mathcal{F}_{\text{scan}}
  4. 总文件数$\mathcal{F}_{\text{total}}$ 是当前快照下的全部数据文件数量。
    Ftotal\mathcal{F}_{\text{total}}

应用场景

当一套房子既有了完整档案、又能随时改造、还能翻阅历史照片，它就不再是普通的居所，而是一个“智慧之家”。Iceberg 在真实世界中正是这样的核心底座，催生了三大典型场景。数据湖分析是最基础的用法：分析师用 Spark 或 Trino 直接查询 Iceberg 表，数据规模从 TB 到 PB 都能稳定应对，还能跑历史快照对比月度指标。流批一体则是把 Flink 写实时数据、Spark 跑离线任务放在同一张 Iceberg 表上，读写互不干扰，实时和离线共用一套数据，彻底告别“两条链路、两份数据”的烟囱式架构。CDC 入湖（Change Data Capture）把数据库的 Binlog 数据实时同步进 Iceberg，让数据仓库与生产库保持分钟级一致，同时保留历史变更轨迹，方便审计与回溯。再配合数据归档，将冷数据按生命周期自动迁移和清理，存储成本大幅下降。

这些场景可以凝练成一个公式：

当这三个部分组合在一起，数据团队就拥有了一栋“会自己写档案的高科技住宅”。查历史像翻相册，加字段像改图纸，实时和离线像一家人共享客厅——这就是 Iceberg 带来的现代化数据湖体验。

Lakehouse=Storage+TableFormat+ComputeEngine\text{Lakehouse} = \text{Storage} + \text{TableFormat} + \text{ComputeEngine}
湖仓一体（Lakehouse）不是新的存储系统，而是“对象存储 + Iceberg 表格式 + 计算引擎”的组合。Iceberg 在其中充当“档案管理员”的角色。
  1. 湖仓一体（左边）$\text{Lakehouse}$ 是融合数据湖灵活性与数仓可靠性的新一代架构形态。
    Lakehouse\text{Lakehouse}
  2. 存储层$\text{Storage}$ 指 S3、OSS、HDFS 等廉价对象存储，负责存放海量数据文件。
    Storage\text{Storage}
  3. 表格式层$\text{TableFormat}$ 是 Iceberg 所在的位置，它让存储层上的文件变成有架构、有版本的表。
    TableFormat\text{TableFormat}
  4. 计算引擎层$\text{ComputeEngine}$ 指 Spark、Flink、Trino 等分布式计算框架，真正执行查询和写入。
    ComputeEngine\text{ComputeEngine}

AI 应用场景

电商用户行为分析平台

阶段：特征工程 / 数据准备阶段

解决的问题：传统 Hive 表在新增特征列或修改分区规则时，需要全表重写，导致特征回溯耗时数天；AI 工程师想要基于“过去 30 天任意一天的用户特征快照”训练模型，Hive 根本无法实现。

具体案例：某电商平台将用户点击、加购、下单行为统一写入 Iceberg 表，Flink 实时写入当天数据，Spark 每天凌晨跑批合并小文件。训练团队用时间旅行特性，直接读取 TIMESTAMP AS OF '2024-05-01' 的历史快照，快速构造带时序标签的训练样本，特征回溯从 3 天压缩到 2 小时。

数据库 CDC 实时入湖

阶段：数据集成 / 实时特征管道

解决的问题：业务数据库的 Binlog 同步到数仓时，既要保证实时性，又要保留历史变更痕迹。普通同步工具只能覆盖最新状态，无法回溯“这个订单三天前是什么状态”。

具体案例：金融客户将 MySQL Binlog 通过 Flink CDC 写入 Iceberg，Iceberg 每次事务生成一个快照，审计部门可以查询任意时刻的账务状态，风控模型能基于完整变更链提取特征（如同一用户短时间内的价格变更次数），异常检测准确率明显提升。

流批一体推荐系统

阶段：模型训练与在线推理的特征统一

解决的问题：传统架构中离线训练用 Hive 表、在线推理用 Redis/Kafka，两份特征容易不一致。Iceberg 让离线特征表和在线特征流共用同一张表，数据口径天然统一。

具体案例：短视频平台的推荐系统将用户实时行为写入 Iceberg，离线 Spark 任务用同一张表训练 CTR 模型，在线服务读取最新的小文件增量做特征拼接，训练与推理的特征分布偏差从 8% 降到 1% 以内。

Python 演示

python52 行
class DemoIcebergTable:    """用列表模拟 Iceberg 的版本化表"""     def __init__(self, name):        self.name = name        self._id_count = 0        self.snapshots = []        self._record_snapshot([], "建表")     def _record_snapshot(self, files, op):        self._id_count += 1        self.snapshots.append({            "id": self._id_count,            "files": list(files),            "op": op,            "timestamp": self._id_count * 10,        })     def insert(self, records):        latest = self.snapshots[-1]["files"][:]        latest.extend(records)        self._record_snapshot(latest, "INSERT %d rows" % len(records))     def delete(self, row_id):        latest = self.snapshots[-1]["files"][:]        latest = [r for r in latest if r["id"] != row_id]        self._record_snapshot(latest, "DELETE id=%d" % row_id)     def time_travel(self, t):        return self.snapshots[t - 1]["files"]     def expire(self, keep=2):        self.snapshots = self.snapshots[-keep:]  def main():    table = DemoIcebergTable("orders")    table.insert([        {"id": 1, "city": "北京"},        {"id": 2, "city": "上海"},        {"id": 3, "city": "广州"},    ])    table.insert([{"id": 4, "city": "深圳"}])    table.delete(2)    print("当前快照文件:", table.time_travel(3))    print("回到快照1:", table.time_travel(1))    table.expire(keep=1)    print("过期清理后快照数:", len(table.snapshots))  if __name__ == "__main__":    main()
目的：以最简单的方式演示 Iceberg 的快照链、时间旅行和过期清理三大核心概念，帮助理解底层原理。
  1. snapshots.append({...})每次变更都追加一个不可变快照，而不是修改旧快照，这是 Iceberg 版本管理的基石。
  2. latest = self.snapshots[-1]["files"][:]复制最新文件列表作为基础，模拟 Iceberg 新快照复用旧数据文件的特性。
  3. def insert(self, records):插入操作不覆盖旧文件，只生成新快照并追加文件路径。
  4. def time_travel(self, t):按快照编号直接读取历史状态，对应 Iceberg 的 TIMESTAMP AS OF 查询。
  5. def expire(self, keep=2):模拟 Iceberg 的 expire_snapshots 清理任务，只保留最近 N 个快照。

常见误区

误区“Iceberg 是不是像 HDFS 那样存数据的？装一个 Iceberg 就能替代 HDFS 了吧？”初学者常把 Iceberg 和底层存储混为一谈。

正解Iceberg 不存储任何数据，它是一个“表格式”层，运行在对象存储（S3/OSS）或 HDFS 之上，负责管理文件清单、快照和表结构。它像装修档案册，负责记录房子有哪些墙、哪些家具，但墙体本身是存储系统在承载。

为何常见：因为 Iceberg 名字太像存储系统，而且它对表的管理方式让初学者误以为数据就存在 Iceberg 里。实际上部署 Iceberg 只需要在计算引擎上添加依赖即可。

误区“想改分区规则？那得把全表数据重新按新分区写一遍，跟 Hive 一样吧？”

正解Iceberg 的分区演进只影响新写入的数据文件，历史数据保持原分区布局不变。查询引擎会自动合并新旧分区规则的元数据，实现无缝读取。这就像重新规划房间格局时，已经盖好的承重墙不必拆除，只是新砌的隔断按新设计来。

为何常见：因为 Hive 的分区写死在目录路径里，很多人的经验被 Hive 固化，默认所有表格式都必须“改分区=全表重建”。

误区“有了时间旅行就可以无限回溯到任意一天，所以历史快照会一直保存吧？”

正解Iceberg 默认会清理过期快照（通过 expire_snapshots 任务），保留时长由策略配置决定。如果你不配置清理，快照会一直堆积，导致元数据膨胀和存储浪费。所以时间旅行是基于“保留策略”的，而非无限的全量历史。

为何常见：广告宣传中常强调“任意时间点查询”，让人误以为全部历史都永久保留；实际生产环境必须权衡存储成本。

误区“加一列？那得把底层所有 Parquet 文件重写一遍，把新列填上默认值吧？”

正解Iceberg 的 Schema 演进是纯元数据操作，新增列只是更新表的元数据文件，底层数据文件完全不动。读取时新列返回默认值或 null，类型升级也在读取时自动转换。这就像在施工图上加一个插座标记，不需要把墙拆开重新布线。

为何常见：因为传统数据库的 ALTER TABLE 在某些引擎中会触发数据重写，人们习惯性把这种代价带入 Iceberg。

面试题

Q1. Iceberg 在数据湖架构中扮演什么角色？

单选题 · easy

  • A.数据表格式管理层← 正确答案
  • B.分布式对象存储层
  • C.大数据分析计算引擎
  • D.数据库数据加密模块

答案：A。Iceberg 是表格式（Table Format），负责管理元数据与数据文件的关系，不存储数据（不是 B），也不是计算引擎（不是 C）或加密模块（不是 D）。它像是数据湖的“档案管理员”，记录表的结构、快照与文件清单。

Q2. Iceberg 中的“时间旅行”功能基于以下哪种机制实现？

单选题 · mid

  • A.快照版本链← 正确答案
  • B.分区目录树
  • C.字段索引表
  • D.数据压缩包

答案：A。时间旅行通过读取历史快照（Snapshot）实现。每个快照记录了某一时刻所有数据文件的清单，像一张“全家福”，查询时可以随时加载任意一张旧照片。分区目录树和字段索引都不具备版本回溯能力。

Q3. 与传统 Hive 表相比，Iceberg 的分区演进有哪些优势？

多选题 · hard

  • A.修改分区规则不会重写历史数据← 正确答案
  • B.分区规则自动适配新写入数据← 正确答案
  • C.必须手动维护每个分区目录
  • D.查询时自动裁剪无关数据文件← 正确答案

答案：ABD。Iceberg 的分区规则存放在元数据层，修改后只影响新数据（A 对）；隐藏分区能力让引擎自动处理分区逻辑（B 对）；查询时会使用分区统计信息裁剪文件（D 对）。C 正是传统 Hive 的痛点，Iceberg 无需手动维护目录。

Q4. Iceberg 元数据层级从高到低的正确顺序是？

单选题 · easy

  • A.目录到清单再到文件← 正确答案
  • B.文件到清单再到目录
  • C.清单到文件再到目录
  • D.目录到文件再到清单

答案：A。正确链路为：表入口（Catalog）→ Manifest 列表 → Manifest 清单 → 数据文件。它像查档案先找总目录、再看文件柜标签、最后拿到具体凭证。其他顺序都颠倒了层级关系。

Q5. Iceberg 的 Schema 演进中，以下哪项操作需要重写底层数据文件？

单选题 · mid

  • A.新增列与删除列
  • B.升级字段的类型
  • C.字段安全重命名
  • D.以上都不需要← 正确答案

答案：D。Iceberg 的加列、删列、类型升级、重命名都是元数据层面的修改，不触碰底层数据文件。删列只是在 Schema 中标记保留，历史文件照常可读；类型升级靠读取时安全转换完成。

Q6. Iceberg 执行小文件合并（rewrite）主要解决什么问题？

单选题 · mid

  • A.元数据膨胀与查询性能下降← 正确答案
  • B.数据加密的密钥管理问题
  • C.网络传输中的数据丢包
  • D.数据湖的权限控制缺陷

答案：A。大量小文件会让 Manifest 清单越来越长，查询规划变慢、扫描开销增大。小文件合并重写为大文件，好比把散落一地的袜子叠好放进抽屉，减少文件数量、压缩元数据、提升查询速度。

Q7. 配置 Iceberg 过期快照清理（expire snapshots）后，会产生哪些效果？

多选题 · hard

  • A.回收无用历史版本的存储空间← 正确答案
  • B.缩短元数据扫描链提升规划速度← 正确答案
  • C.永久删除当前表所有历史版本
  • D.减少查询时需要遍历的数据文件← 正确答案

答案：ABD。清理过期快照会删除旧快照指向且不再被引用的数据文件（A 对），减少 Manifest 数量从而加速规划（B 对），查询时候选文件更少扫描更快（D 对）。但清理保留的最近 N 个版本，不是删光所有历史（C 错）。

Q8. Iceberg 与 Hive 表格式的核心区别是什么？

单选题 · easy

  • A.支持数据布局持续演进← 正确答案
  • B.支持 SQL 标准查询
  • C.不支持数据文件分区
  • D.不支持并发事务控制

答案：A。Hive 的数据布局（分区、Schema）被写入目录结构，难以修改；Iceberg 将这些信息放进元数据层，可自由演进（A 对）。B 不是区别，Hive 也支持 SQL；C、D 与事实相反。

Q9. 以下哪些业务场景适合采用 Apache Iceberg？

多选题 · extreme

  • A.Kafka 流数据实时写入并回溯分析← 正确答案
  • B.银行核心账务高频在线交易处理
  • C.数据库 Binlog 同步入湖做审计← 正确答案
  • D.海量历史日志按生命周期归档← 正确答案

答案：ACD。Iceberg 支持流批一体写入与时间旅行（A 对），CDC 入湖能保留变更链并做审计（C 对），归档场景利用分层存储与清理策略降低成本（D 对）。B 是 OLTP 高频事务场景，Iceberg 面向分析型工作负载，不适用。

Q10. Iceberg 的 ACID 事务特性主要体现在哪个方面？

单选题 · mid

  • A.快照隔离与并发提交安全← 正确答案
  • B.数据文件的透明加密存储
  • C.自动创建分区目录结构
  • D.加速集群节点间网络传输

答案：A。Iceberg 通过乐观锁控制并发写入，多个提交同时发生时只有一个成功，读取方始终看到一个完整快照，实现快照隔离（A 对）。加密、分区创建、网络加速都不是 ACID 的核心含义。