Apache Iceberg 湖仓架构设计——Apache Iceberg 湖仓的世界

数据架构的发展史，始终是在性能、成本与灵活性之间寻找平衡，同时确保数据可访问且受治理。多年来，企业在不同路径之间轮转——数据仓库（面向分析优化的数据库）、数据湖（在分布式存储上的文件进行分析）以及混合方案——每一种都试图解决分析可扩展性、复杂度降低与成本控制等难题。

此时出现了 Apache Iceberg：一种开放的表格式（open table format），它让分布式存储系统上的一组数据文件可以被当作传统数据库表来对待。借助 Apache Iceberg，你可以让同一份分析数据集被多种工具高效访问，从而提升业务部门之间的协作，并通过在数据湖上以“单一权威副本”（canonical single copy）开展工作，减少过度的 ETL（Extract-Transform-Load，抽取-转换-加载）和数据复制带来的成本，而不是在多个分析系统里维护多份拷贝。Apache Iceberg 湖仓（Lakehouse）是一种模块化、可扩展、具性价比的架构，融合了数据湖与数据仓库的优点，同时保持开放与灵活。Apache Iceberg 正在重塑数据行业。为什么？是什么让 Iceberg 成为现代数据平台的破局力量？为何 Netflix、Apple、Dremio、AWS、Snowflake、Databricks 等众多公司都在使用 Iceberg，并围绕它持续开发与构建工具？答案在于：Apache Iceberg 提供了一个由社区驱动的分析数据集存储标准格式，既能被整个分析工具生态灵活利用，又能提供传统闭源数据仓库系统的 ACID 保证（原子性、一致性、隔离性、持久性）与性能。

本书将聚焦于：如何理解并有效做出那些架构 Iceberg 湖仓所需的关键选择，以满足你的具体用例。全书将带你认识何为数据湖仓与 Apache Iceberg，在本地环境动手实践一个湖仓原型，并沿着“理解你的数据平台需求—审视各组件生态—做出架构取舍”的路径，帮助你打造理想的数据平台。本章将先交代 Iceberg 所处的语境：企业在传统架构下面临的挑战，以及数据湖仓模式作为回应如何崛起；随后我们将深入探讨 Apache Iceberg 如何把这一模式推向前进，提供一种可扩展、高性能且开放的现代数据架构解法。

1.1 什么是数据湖仓（data lakehouse）

数据从不“静止”——它始终在流动，驱动应用、分析以及AI 决策。多年来，组织为应对数据管理日益增长的复杂性，不断构建新的基础设施层。数据湖仓架构正是对数十年演进需求的回应：在成本、可扩展性与可达性之间达成平衡，同时拥抱开放性与互操作性。

虽然数据湖仓已成为主流范式，但若想真正理解其影响，就必须回看它之前的架构挑战。通过回顾从 OLTP（Online Transaction Processing，联机事务处理）数据库到数据仓库、数据湖乃至更远阶段的演进，我们便能更清晰地理解湖仓出现的缘由，以及它如何化解数据管理中长期存在的权衡取舍。图 1.1 展示了这一演进的整体脉络。

图 1.1 从本地数据仓库走向数据湖仓的数据平台演进示意图。

1.1.1 数据仓库的崛起

在早期，大多数数据都存放在 OLTP 数据库（Online Transaction Processing，联机事务处理）中——这类传统关系型系统旨在支撑实时的应用交互。这些数据库（如 Oracle、DB2、PostgreSQL、MySQL、各类 NoSQL 存储以及 SQL Server）针对事务型操作做了优化，能高效完成单条记录的插入、更新与读取。
然而，当组织希望对数据进行分析——生成汇总报表、分析型看板、聚合计算以及复杂的多表连接时——其事务型数据库就会吃力：这类系统以行式存储为主，并非为分析场景而生，面对不断增长的数据量往往难以胜任。

原因很清楚：OLTP 系统为快速的事务查询而设计，并不擅长扫描与聚合数百万甚至数十亿行的数据。尽管索引与分区能优化部分查询，但分析型负载依旧会显著挤占生产库资源，常常拖慢事务处理。这些系统也并非为海量历史数据的存取而构建，因而很难长期留存历史以供分析。

于是，企业级数据仓库（EDW） 登场，作为专用的分析系统。Teradata、IBM Netezza、Oracle Exadata 等方案允许企业从 OLTP 系统抽取数据、按优化过的模式（schema）转换后，加载进集中式仓库，用于 OLAP（Online Analytical Processing，联机分析处理）负载。但代价与刚性随之而来：成本高、灵活性不足。

1.1.2 向云数据仓库迁移

传统企业级数据仓库在存储与计算两方面都很昂贵，扩容需要在本地（on-prem）投入大量硬件；而构建与维护 ETL（抽取-转换-加载）流程也十分耗时。

随着云计算兴起，Snowflake、Google BigQuery、Amazon Redshift 等云数据仓库提供了弹性与按需计费（pay-as-you-go） 。它们带来了几项关键收益：

• 计算与存储解耦：业务可以按需独立伸缩各自的负载。
• 自助式分析更容易：更简化的访问与使用体验，面向更广的用户群体。
• 运维开销降低：基础设施由云厂商托管。

然而，随着大数据成为常态，云数据仓库仍有一些根本限制。虽然相较传统 EDW 成本更具优势，但存储与计算的单价仍偏高，让成本随规模线性上升成为隐忧。与此同时，数据搬运低效的问题凸显——企业常常需要将源数据复制到仓库中才能分析，引入了延迟与复杂度。此外，厂商锁定依旧存在：专有存储格式使得在不同云或分析引擎之间迁移数据变得困难。为应对这些挑战，企业开始重新思考大规模数据存储与分析的路径。

1.1.3 数据湖与 Hadoop 时代

数据仓库能够高效分析结构化数据，但企业还需要一个地方，能以更低成本存放海量的非结构化数据——如点击流日志、IoT 传感器数据、社交媒体流等。答案是：数据湖（data lake） 。这是一种直接在分布式存储上的文件之上运行分析的范式。

早期数据湖构建在 Hadoop 及其 HDFS（Hadoop Distributed File System）之上，它通过允许企业在无需预先建模的前提下将原始数据集中存放，并使用低成本、标准化硬件，从而革新了数据存储。与传统 EDW 相比，这种灵活性大幅降低了存储成本。不同于刚性的关系型系统，基于 Hadoop 的数据湖可同时存放结构化、半结构化与非结构化数据，为多样化数据集提供了统一的存储库；同时，Hadoop MapReduce 与 Apache Spark 等强大的处理框架能直接在原始数据上进行大规模计算，使大体量信息的洞察提取成为可能。

但当组织更加倚重基于 Hadoop 的数据湖时，重大挑战出现了：即便有 Hive 这类提供类 SQL 接口的工具，在 HDFS 上查询仍然缓慢且低效；跨团队保证数据一致性愈发困难，常导致数据陈旧或冲突；此外，模式（schema）演进也很麻烦——Hadoop 缺乏内建的模式约束，使数据治理与管理变得复杂且耗时。结果，许多企业陷入所谓的“数据沼泽（data swamp） ”：庞大却缺乏管理的非结构化数据堆积，难以检索、分析与变现。

与此同时，随着企业为了不同用例反复将数据子集复制到云数据仓库，总体成本不断攀升。业界迫切需要一种兼具数据仓库的性能/易用/结构化优势与数据湖的灵活/低成本的新路径。

1.1.4 Apache Iceberg：通向湖仓的关键

这正是 Apache Iceberg 登场之处。Iceberg 最初由 Netflix 开发，旨在解决数据湖中大规模数据集的管理难题。具体来说，Netflix 工程师对 Apache Hive 表的困境颇为不满：

• 元数据操作缓慢：当表有数百万级分区时，Hive 在 metastore 中的分区跟踪会举步维艰。
• 缺乏模式演进：更新 schema 往往需要代价高昂的整表重写。
• 缺少 ACID 保证：除非使用如 ORC 的格式，否则难以强制跨写入的一致性。
• 查询性能低效：扫描大数据集时常需读取整个目录而非仅相关文件。

Iceberg 引入了一种面向大数据规模分析的现代表格式规范，把仓库级能力带入数据湖。不同于传统数据湖在一致性与性能上的乏力，Iceberg 提供了元数据层以保证一致的数据定义与高效扫描。它暴露丰富的表级元数据，在无需时可避免代价高昂的整表扫描。借助内建 ACID 事务，Iceberg 确保数据一致性，并允许多用户并发读写而不牺牲正确性。此外，它还能基于元数据中的分区与列统计进行裁剪（pruning），显著提升效率，而无需大量手工调优。

Iceberg 标志着组织对数据湖使用方式的转折：将其从原始存储库转变为高性能分析平台。借助 Apache Iceberg，企业可以像使用数据仓库一样使用数据湖，而不牺牲性能、一致性或治理能力。

1.1.5 数据湖仓：兼得两全

数据湖仓（data lakehouse）作为数据架构的下一阶段应运而生。它通过 Apache Iceberg 等开放表格式，综合了数据湖的成本优势与数据仓库的性能与易用性。

湖仓路径直接解决三大痛点：

1. 跨业务线的数据一致性
   不再是各团队把同一份数据分别导入不同的专有数据仓库（导致厂商锁定与可移植性差），而是**直接查询数据湖中“单一事实来源”（single source of truth）**的文件。
2. 在数据湖上的高性能分析
   借助 Iceberg 的优化，团队可以在原始数据之上运行高速分析型负载，减少昂贵的 ETL 与数据搬运，并免去大量手工数据管理与调优。
3. 通过减少冗余实现成本节约
   传统架构需要多份副本——数据湖一份、数据仓库一份、另有数据集市与各类抽取。湖仓最小化冗余存储，同时降低计算成本。

Apache Iceberg 使组织能够摆脱传统束缚，构建可扩展、具成本效益、面向 AI 的新一代架构。下一节我们将深入 Iceberg 本身——它是什么、如何工作、以及为何能为现代湖仓带来颠覆性变化。

Apache Iceberg 与替代方案

与 Apache Hudi、Delta Lake、Apache Paimon 等替代表格式相比，差异往往体现在灵活性、生态支持与运维易用性。尽管这些表格式在功能上逐步趋同（如 ACID 事务、时光回溯（time travel） 、模式演进等），Iceberg 仍在若干关键点占优。其中最显著的一项是其分区策略：不同于依赖传统静态分区的 Delta 与 Hudi，Iceberg 支持“分区演进（partition evolution）”与“隐藏分区（hidden partitioning）” ，使其更易应对随时间变化的数据结构。

• 分区演进允许在无需重写存量数据的情况下更新分区策略；
• 隐藏分区无需用户手动定义与管理分区列，简化查询并降低运维复杂度。
  这些特性让 Iceberg 尤其适合动态、超大规模的分析型工作负载。

除了技术能力，Iceberg 的另一大优势是迅速扩张的生态，其工具链不止于“读/写格式”。虽然 Delta Lake 已进入 Linux 基金会，但主要仍由 Databricks 推进；Hudi 在流式场景上优化明显，但集成生态相较 Iceberg 与 Delta 更小。相比之下，Iceberg 获得了广泛平台支持：从数据仓库（如 Snowflake、BigQuery），到查询引擎（Trino、Dremio、Presto），再到处理框架（Spark、Flink），并且它是开放透明、社区治理的 Apache 基金会项目（其多元治理规则更为严格）。更重要的是，Iceberg 生态还涵盖高级湖仓治理/运维能力，如自动表优化、湖仓清理、访问控制与目录（catalog）集成，赋予用户更强的性能与治理把控力。
这种广泛兼容性确保采用 Iceberg 的组织拥有通往湖仓最灵活的路径，可在不被单一厂商或工具链锁定的前提下扩展并优化其架构。

1.2 什么是 Apache Iceberg？

现代数据平台同时追求灵活性、性能、规模与一致性，但传统路径往往迫使企业在其中做取舍：要么把数据存放在数据仓库表里，获得强 ACID 保证却付出高成本；要么把数据以原始文件形式放在数据湖中，成本更低但一致性与治理较弱。Apache Iceberg 改变了这个等式。

Iceberg 是一个开放、社区驱动、与厂商无关（vendor-agnostic）的标准表格式（standard table format） ——它作为一层抽象层覆盖在原始文件（通常是 Apache Parquet）之上，使其表现得像完全托管的表，类似数据仓库中的表。图 1.2 展示了表格式在数据湖仓（data lakehouse）中的角色：它把构成数据集的数据文件“打包”为表，并配套元数据（metadata） ，如同“图书馆索引”，指导引擎高效检索数据。与专有的仓库格式不同，Iceberg 开放且不绑定厂商，团队可以用偏好的工具访问同一份数据——无论是 Dremio、Spark、Flink、Trino、Snowflake、Qlik，甚至是 Puppygraph 这类图处理引擎。

图 1.2 表格式在数据湖仓中的作用。

下面我们来拆解 Apache Iceberg 解决的问题、其架构，以及让它有别于其他表格式的特性。

1.2.1 为何需要“表格式”

从本质上说，数据湖就是一堆文件的集合，通常是存放在对象存储（如 AWS S3、Azure Blob Storage、Google Cloud Storage）中的 Apache Parquet 文件。尽管 Parquet 很适合分析型工作负载，只依赖原始 Parquet 文件会带来若干问题。其中一个关键限制是：查询引擎不会自动把“由多个文件构成的 Parquet 数据集”识别为单一的结构化表，也就谈不上 ACID 保证与模式（Schema）演进——除非借助 Apache Hive 等目录（catalog）方案去跟踪数据集的目录与分区，从而“把它视为一张表”。即便如此，这些方案对 ACID 与演进的支持仍有限。没有专用表格式，系统缺乏内建机制去跟踪模式变更、分区或快照（snapshot） ，导致元数据操作低效、查询缓慢。

在“只用 Parquet”的设置下，数据一致性也难以保障：当多个用户或工具同时写入同一数据集时，容易产生重复记录或跨查询视图不一致。此外，性能优化受限——查询引擎往往需要扫描整个目录才能取到相关数据，即使实际只需其中的一小部分。这些低效之处解释了为何现代表格式（如 Apache Iceberg、Delta Lake、Apache Hudi）对于把原始数据湖升级为高性能、受治理的数据平台至关重要——它们让表级的更新/删除具备 ACID 保证。

像 Apache Iceberg 这样的表格式通过在原始文件外包裹一层元数据来解决上述问题。这样，查询引擎便能像操作传统数据库表一样与之交互，同时保留数据湖的成本优势。如图 1.3 所示，一张湖仓表由数据文件（构成数据集）以及元数据文件组成，后者帮助查询引擎更高效地扫描数据。

图 1.3 湖仓表的构成：元数据文件与数据文件。

Iceberg 通过多层元数据结构来实现：既能快速读取、高效写入，又能在多引擎间保持完整的事务一致性。

1.2.2 Apache Iceberg 如何管理元数据

Iceberg 最强大的创新之一，就是它对元数据的组织方式——这对让湖仓更快、更高效至关重要。但“元数据”究竟是什么、为何如此重要？可以把数据湖想象成一个超大的厨房：如果你要找一把勺子，可以把每个抽屉都翻一遍，但这会很费时间；若墙上有一块夹板（清单） ，详细标记每件物品放在哪里，你只需瞥一眼清单就能直达目标。那块“夹板”就是元数据——一种帮助定位与检索的结构化索引。

在传统数据湖中，查询引擎常常需要“翻遍整个厨房”：为找相关数据扫描成千上万（甚至数百万）的 Parquet 文件，使查询又慢又低效（Parquet 数据集可能通过分区提升性能，但稍后我们会看到 Iceberg 在分区能力上还有进一步改进）。Iceberg 通过分层、结构化的元数据系统改变了这一点：像一块组织良好的夹板，引导查询直达所需文件。Iceberg 并非依赖一个单体元数据文件（任何变更都可能拖慢操作），而是把元数据组织为三层（metadata.json、manifest list、manifests），各司其职（见下方图 1.4）。一个目录（catalog）负责跟踪表并帮助发现这三层元数据，从而让引擎判定该扫描哪些数据文件。这种分层方法极大改进了查询规划，支持更好的模式演进，并优化大数据集的可扩展性，使 Iceberg 成为现代湖仓的基础构件。

图 1.4 Apache Iceberg 表的读写操作：结构与流程。

一张 Apache Iceberg 表的元数据文件主要由三类文件构成，它们携带的数据使引擎能更高效地理解与扫描该表：

metadata.json（表级元数据）

• 跟踪 snapshot（表随时间演化的各版本）；
• 存放 schema 定义与分区策略；
• 让查询引擎理解表的结构；
• 启用 schema 演进、时光回溯（time travel）与数据一致性等能力。

Manifest Lists（快照级元数据）

• 表示表的一个快照；
• 列出一组manifest 及其汇总统计，以便裁剪（prune）不必要的文件扫描。

Manifests（文件级元数据）

• 列出数据集中各个 Parquet 数据文件；
• 存放文件位置与统计信息，帮助查询引擎在扫描前过滤无关文件。

通过这样的组织方式，Iceberg 使查询引擎在执行查询时可以跳过无关文件，在无需复杂索引系统的前提下提升性能。举例来说，若查询只需要 2024 年 1 月的数据，Iceberg 可利用 Manifest List 的统计信息剔除不必要的分区；随后，Manifest 会在真正扫描之前进一步过滤与条件不匹配的 Parquet 文件。这样的**智能裁剪（pruning）**显著减少数据扫描量，提升性能并降低计算成本。图 1.5 展示了这一基于元数据的裁剪过程。

图 1.5 引擎利用元数据统计剔除待扫文件，从而获得更快的查询。

1.2.3 Apache Iceberg 的关键特性

Apache Iceberg 提供了现代表格式应有的核心能力，同时引入了多项突破性创新，使其有别于 Delta Lake 与 Apache Hudi。在基础层面，Iceberg 支持模式演进（schema evolution） ，允许用户在不破坏既有查询的情况下按需修改表的 schema。不同于需要代价高昂“整表重写”的传统系统，Iceberg 可以轻松完成列的新增、重命名与删除，使数据模型能随业务需求演进而演进。Iceberg 还提供ACID 保证，意味着每一次事务——无论是小规模更新还是大规模导入（ingestion）——都具备原子性、一致性、隔离性与持久性。在多写入者（multi-writer）的并发环境中，这种可靠性尤为关键，否则并发修改极易引发不一致。

在这些基础能力之上，Iceberg 通过重新定义分区与数据访问进一步创新。借助时光回溯（time travel） ，用户可以查询数据集的历史版本，从而支持审计、调试，甚至回滚非预期更改。对于分区策略调整，其他格式往往需要整表重写，而 Iceberg 的分区演进（partition evolution）则允许无需昂贵的数据重组织即可修改分区方案，使数据随时间推移更具灵活性。

此外，隐藏分区（hidden partitioning）将分区列的跟踪自动化并写入元数据，无需用户在查询中手工指定分区过滤条件。这既简化了查询逻辑，也提升了执行效率，使引擎在无需了解底层数据布局的前提下就能进行优化。这些创新让 Iceberg 成为灵活且面向未来（future-proof）的表格式，为组织构建可扩展、高性能的数据湖仓提供了坚实基础。

1.2.4 作为开源标准的 Apache Iceberg

Apache Iceberg 并不受单一厂商控制。不同于绑定特定平台的专有格式，Iceberg 是 Apache 软件基金会（ASF） 项目，贡献者来自 Netflix、Apple、Dremio、Snowflake、AWS 等众多企业。

这种广泛的行业支持带来了与各类工具与引擎的深度集成，包括但不限于：

• Dremio —— 联邦 SQL、原生查询加速与 Reflections，在 Iceberg 表上实现快速 BI 性能
• AWS —— 主流云厂商，对 Apache Iceberg 的集成数量持续增长
• Puppygraph —— 在 Iceberg 数据集上运行图查询
• Apache Spark & Flink —— 大规模 ETL 与流式工作负载
• Kafka Connect —— 将流数据写入 Iceberg 表
• Qlik Talend Cloud —— 基于 Iceberg 的全功能数据集成与管理方案

由于 Iceberg 开放且不绑定厂商（vendor-agnostic） ，组织不会被单一的供应商或技术栈所锁定。团队可以构建灵活、可互操作的湖仓体系，在无需重构整个平台的前提下，按需引入新的工具与工作流。

Iceberg 使组织能够释放数据湖的全部潜力，将其视为相较传统数据仓库更可扩展、更具成本效益的替代方案。接下来，我们将进一步探讨 Apache Iceberg 的优势，以及它为何正成为现代数据平台的事实标准（de facto standard） 。

1.3 Apache Iceberg 的优势

Apache Iceberg 不只是另一种表格式——它从根本上改变了组织在数据湖中管理、查询与优化数据的方式。传统数据湖虽然具备低成本、易扩展的存储优势，但常常遭遇查询性能缓慢、数据不一致以及治理复杂等问题，而克服这些问题通常需要大量手工数据管理。Iceberg 通过引入结构化、且高性能的方法，将类似数据仓库的能力带入数据湖。借助模式演进（schema evolution） 、ACID 事务与先进的分区等特性，Iceberg 让组织能够在不落入传统架构常见取舍的情况下，高效存储、管理并分析海量数据集。

不过，引入 Iceberg 也并非“零门槛”。它显著提升性能与灵活性的同时，也需要与查询引擎和目录系统（catalog）进行谨慎集成，才能释放全部潜力。与此同时，随着 Iceberg 将“原始文件”转变为“受管表”，组织也需要重思传统的数据湖实践。下面我们将展开 Iceberg 的关键优势，并说明它如何解决长期存在的数据管理难题。

1.3.1 ACID 事务

在缺乏事务保证的场景下，多个作业同时向同一数据集写入，极易导致冲突更新、重复记录以及不可靠的查询结果。为避免冲突，组织往往被迫采用复杂绕行方案：写临时文件、使用外部锁或错峰调度作业等。然而这些做法不仅增加运维开销，也无法根除不一致风险。

Apache Iceberg 通过提供完整的 ACID 保证来解决这一问题，确保对数据集的每一次变更都可靠且可预测。ACID 指原子性（Atomicity） 、一致性（Consistency） 、隔离性（Isolation）与持久性（Durability） ：

• 原子性：更新以“要么全部成功、要么全不应用”的方式提交，防止部分写入导致数据处于不一致状态；
• 一致性：所有写入遵循严格的完整性规则，避免不同工具与处理框架之间产生冲突；
• 隔离性：查询引擎始终看到稳定的数据版本，避免读操作受到进行中的写操作干扰；
• 持久性：一旦提交即永久可恢复，防止意外的数据丢失。

有了这些保障，多个团队与工具就能安全地并发读写同一数据集，而无须担心数据损坏或不一致，使数据湖更可靠、更易于管理。

1.3.2 表演进（Table Evolution）

在传统数据湖中，修改 schema 与分区一直十分繁琐，哪怕是微小的结构变化，也常常需要重载或重写整个数据集。这种刚性迫使组织在早期做出诸多“前置设计决策”，而这些决策未必能随业务演进而良好扩展。久而久之，就会带来低效、数据不必要复制以及各类曲线救国的权宜之计，从而拖慢分析与数据工程的协作效率。

Apache Iceberg 通过无缝的 schema 演进消除了这些痛点，使数据集能够随时间演变而演变，且无需代价高昂的重写。借助 Iceberg，用户可新增、重命名或删除列而不破坏既有查询，确保在不同应用间保持后向兼容。与 Hive 在建表时就锁死分区方案不同，Iceberg 的分区演进（partition evolution）允许无需数据迁移就能动态修改分区策略。

此外，Iceberg 会跟踪 schema 历史，提供表结构随时间变化的可见性——这对审计与长期数据管理至关重要。上述灵活性，使 Iceberg 尤其适用于需要长期存在并持续演进的数据集，去除以往在 schema 与分区管理上的摩擦与约束。

1.3.3 时光回溯与基于快照的查询（Time Travel & Snapshot-based Queries）

在传统数据湖中，一旦数据被覆盖就无法找回，既不便进行历史分析，也难以撤销错误。缺乏版本控制会显著增加容灾与历史分析的难度，组织往往只能复制数据集或依赖手工备份。在没有结构化变更追踪的情况下，即便是一个小小的入湖错误，也可能造成不可逆的数据丢失或记录损坏。

Apache Iceberg 通过引入时光回溯（Time Travel）改变了这一切。这个强大的特性允许用户在特定时间点精确查询表的历史版本。如果错误或不完整的数据被摄入，团队可以回滚到此前的快照（snapshot） ，无需复杂的恢复流程。此外，Iceberg 支持版本化分析，可在不复制数据或维护多份数据集的前提下，进行历史趋势分析。对于强调数据治理、合规与调试的组织而言，这些能力极具价值，确保数据对人为或系统错误具备足够的弹性。
图 1.6 展示了时光回溯的工作方式：引擎在扫描不同快照时，会得到不同的数据文件清单，从而实现对历史版本的扫描。

图 1.6 引擎可扫描较早的快照；不同快照给出不同的待扫文件列表，从而实现对旧版本数据的查询。

1.3.4 隐藏分区：减少意外的整表扫描

分区对查询性能优化至关重要，但传统 Hive 风格表要求用户在查询中手动指定分区列。若在 WHERE 子句中缺失分区过滤，查询引擎就必须扫描大量无关数据，导致性能低下与资源浪费。这种“手工式”的做法不仅增加使用复杂度，也提高了编写次优查询的风险，无法充分利用分区裁剪（partition pruning） 。

Apache Iceberg 通过隐藏分区（Hidden Partitioning）消除了这类负担：它在后台自动应用分区过滤。即便用户未显式写出分区键，查询引擎也能无缝优化扫描。分析师与数据工程师因此无需再刻意写分区过滤，查询既更简洁也更高效。通过减少昂贵的整表扫描风险并简化查询编写，隐藏分区显著提升了性能与可用性，让大规模数据分析更快、更易用。

1.3.5 成本效率与查询性能优化

许多组织会在数据仓库、数据湖与数据集市之间维护多份副本。这种重复会推高存储成本、增加 ETL 复杂度，并在处理大数据集时带来过高的计算开销。典型流程是：将原始数据抽取到数据湖，通过 ETL 转换，再装载进数据仓库用于分析——每一步都在消耗额外的存储与计算。这些低效很快就会叠加，企业不得不投入巨资来维持数据基础设施的运行。

Apache Iceberg 通过减少不必要的数据副本与优化查询，显著降低上述成本。团队可以直接在数据湖上查询 Iceberg 表，而无需把数据再复制进仓库进行分析，从而避免冗余存储开销。Iceberg 还会优化数据扫描：在执行前智能裁剪（prune）无关文件，减少读取数据量，直接降低计算成本。

Iceberg 进一步简化 ETL：它支持流式与批量共同摄入到同一张表，无需在不同环境之间做复杂的数据搬运。通过减少数据移动、最小化副本并优化查询，组织能以更低成本获得高性能分析，这使 Iceberg 成为提升数据基础设施效率的“游戏规则改变者（game-changer）”。例如，Insider 借助 Apache Iceberg 将其 S3 成本降低了 90% （medium.com/insiderengi…）。

1.4 Apache Iceberg 湖仓的组成

湖仓（lakehouse）不只是存放数据的地方，它是一种将灵活性、性能与治理融为一体的系统架构。Apache Iceberg 湖仓的核心在于其模块化设计：组织可以为每个组件选择最合适的工具，同时保持互操作性与开放性。

不同于传统的单体式数据仓库常将组织锁定在单一厂商生态之中，模块化的湖仓架构使企业能够：

• 按需独立扩展各个组件，适配不断演进的需求；
• 依托 Apache Iceberg 等开放标准，降低厂商锁定；
• 通过为摄取（ingestion） 、**联邦（federation）与消费（consumption）**选用合适工具，优化性能与成本。

将湖仓划分为五大关键组件后，组织可以针对自身需求自由搭配最佳工具组合，而不被供应商锁定：

• 存储层（Storage Layer） ——以对象存储为主，低成本存放数据
• 摄取层（Ingestion Layer） ——以流式或批量方式将数据写入 Iceberg 表
• 目录层（Catalog Layer） ——跟踪并治理所有 Iceberg 元数据
• 联邦层（Federation Layer） ——为分析建模并加速数据
• 消费层（Consumption Layer） ——支撑 BI、AI 与实时应用

下面我们对 Apache Iceberg 湖仓的五大组件做高层概览，说明它们如何协同工作（见图 1.7）。在本书第二部分，我们将对每个组件进行更深入的探讨。

图 1.7 完整数据湖仓实现的组成部分。

1.4.1 存储层：湖仓的地基

存储层（storage layer）是原始数据（raw data）与元数据（metadata）所在之处。该层通常是为可扩展性、持久性与成本效率优化的分布式对象存储或文件系统。

数据存放在哪里：

• 云端——Amazon S3、Azure Blob Storage、Google Cloud Storage
• 本地（On-premises） ——HDFS、MinIO、Ceph
• 混合（Hybrid） ——云与本地结合，以获得更大的灵活性

存放的内容：

• 数据文件（Data files） ——通常为 Apache Parquet（也可为 ORC 或 Avro），面向分析进行优化
• 元数据文件（Metadata files） ——Iceberg 的表元数据、manifest 与快照（snapshots）

1.4.2 摄取层：将数据导入 Iceberg 表

当数据从各个系统收集完成后，需要进行处理并以 Iceberg 表 的形式存入存储层。摄取层（ingestion layer）由各种工具与框架组成，用于转换（transform） 、清洗（clean） 并加载（load） 数据到 Iceberg 表中。

批量摄取（Batch ingestion）：

• Apache Spark —— 面向 Iceberg 的大规模 ETL 工作负载
• Fivetran —— 托管式 ETL 摄取服务

流式摄取（Streaming ingestion）：

• Apache Flink —— 将实时数据处理后写入 Iceberg
• Kafka Connect —— 从 Kafka 主题流式写入 Iceberg 表
• Estuary —— 托管式平台，支持实时与批量摄取
• Qlik Talend Cloud —— 同时支持批量与流式工作负载

以上仅是部分选项；第 5 章（摄取）将介绍更多方案。

为何重要
一个灵活的摄取层可确保批量与流式数据都能高效写入 Iceberg 表。这种模块化使组织能够优化数据新鲜度、降低分析与 AI 场景的时延（latency） 。

下面是专业、通顺的中文译文（保留常用术语与缩写；首次出现处给出中文释义）。注：原文小节标题“.4.3”应为“1.4.3”。

1.4.3 目录层：通向湖仓的入口（The catalog layer: The entry point to your lakehouse）

湖仓目录（Lakehouse Catalog）让 Iceberg 在大规模场景下可查询且可管理。它充当存储层与查询引擎之间的接口，负责跟踪所有表及其元数据的位置。

开放目录选项（Open Catalog Options）：

• Apache Hive Metastore —— 兼容传统方案，但并非 Iceberg 的理想选择
• AWS Glue Data Catalog —— 管理 Iceberg 表的云原生选项
• Project Nessie —— 类 Git 的版本化目录，支持时光回溯与“数据即代码”
• Apache Polaris —— 开源湖仓目录，具备健全的 RBAC（基于角色的访问控制）能力
• Apache Gravitino —— 地理分布式湖仓目录
• Lakekeeper —— 具备**数据契约（data contract）**能力的湖仓目录
• Iceberg REST Catalog —— 兼容 Iceberg 的开放标准目录协议

为何重要（Why it’s important）
目录层是所有 Iceberg 表的单一事实来源（single source of truth） ，在多查询引擎场景下保障一致性与治理。它支持：

• 原子性的表更新，且不打扰正在使用的用户
• 跨工具互操作：Dremio、Spark、Flink、Trino、Snowflake 等看到的是同一张表
• 可移植的访问控制：得益于湖仓目录，可在各工具间复用

选择得当的目录能确保全组织团队安全协作于同一批 Iceberg 数据集，消除数据孤岛。

1.4.4 联邦层：建模与加速（The federation layer: Modeling & accelerating data）

联邦层（federation layer）负责将原始数据建模、丰富与优化，以服务分析、AI 与报表。团队在这一层定义业务逻辑、统一多源数据，并优化查询性能。

关键能力（Key capabilities）：

• 语义层（Semantic Layer） —— 定义组织范围内一致的度量（metrics）
• 联邦查询引擎（Federated Query Engines） —— 跨 Iceberg 与外部数据库进行查询
• 查询加速（Query Acceleration） —— 在不复制数据的前提下提升分析性能

示例工具（Example tools）：

• Dremio —— 统一 Iceberg、各类数据库与数据仓库，内建语义层与 Reflections 加速
• Trino —— 开源 SQL 联邦查询，跨多源统一访问（常需外部语义层与加速组件）
• dbt —— 直接在 Iceberg 上进行转换与建模

为何重要（Why it’s important）
联邦层确保 Iceberg 表不是“孤岛”。企业的数据常分布在：

• 关系型数据库（PostgreSQL、MySQL、SQL Server）
• 云数据仓库（Snowflake、Redshift、BigQuery）
• 其他湖仓格式（Delta Lake、Apache Hudi）

强大的联邦层可构建统一的业务视图，确保 Iceberg 无缝融入企业级数据战略。

1.4.5 消费层：把数据价值交付给业务（The consumption layer: Delivering value to the business）

数据的价值取决于其产生的影响。消费层（consumption layer）是数据用于分析、AI 与业务运营的地方。

典型用例（Use Cases）：

• 商业智能（BI） —— 驱动仪表盘与报表
• AI 与机器学习（ML） —— 训练模型，支撑 AI 应用与 AI Agents
• 内嵌分析（Embedded Analytics） —— 直接在业务应用中交付洞察
• 数据 API 与应用 —— 在 Iceberg 数据之上构建面向客户的应用

示例工具（Example tools）：

• BI & 仪表盘 —— Tableau、Power BI、Looker、Preset（Superset）
• AI & ML —— Databricks、Hugging Face、Jupyter、LangChain
• 数据 API —— GraphQL、REST API（用于应用集成）

为何重要（Why it’s important）
湖仓的模块化与 Iceberg 的开放标准确保数据可被各类消费工具使用，且无需不必要的 ETL 复制。这消除了：

• 为不同负载将数据复制到多个数据仓库的需求
• 部门间数据不一致的风险
• 在云数仓上做运营分析时高昂的查询成本

有了 Iceberg 湖仓，数据产品可以“一处定义、处处消费”，为全公司提供单一且优化的事实来源。

下一章我们将进入动手实践，先直观看到数据湖仓的运行，再在本书第二部分逐一深入构建 Apache Iceberg 湖仓的五大组件。

1.5 小结（Summary）

• 数据湖仓架构把数据湖的可扩展/低成本与数据仓库的高性能/易用/结构化结合起来，解决了治理、查询性能与成本管理等关键挑战。
• Apache Iceberg 是现代表格式，支持高性能分析、schema 演进、ACID 事务与可扩展的元数据，将数据湖转变为结构化、可变更、受治理的存储平台。
• Iceberg 消除了 OLTP 数据库、企业数据仓库与基于 Hadoop 的数据湖中的痛点：高成本、刚性 schema、查询缓慢、治理不一致等。
• 借助时光回溯、分区演进、隐藏分区等特性，Iceberg 降低存储成本、简化 ETL、优化计算资源，显著提升数据分析效率。
• Iceberg 与查询引擎（Trino、Dremio、Snowflake）、处理框架（Spark、Flink）及开源湖仓目录（Nessie、Polaris、Gravitino）深度集成，支持模块化、厂商无关的架构。
• Apache Iceberg 湖仓由五大关键组件构成：存储（storage） 、摄取（ingestion） 、目录（catalog） 、联邦（federation）与消费（consumption） 。