本章内容包括：
- Apache 的 Iceberg table format 是什么
- Apache Iceberg 的优势
- 基于 Apache Iceberg 的数据湖仓组件
Apache Iceberg 是一种社区驱动的表格式，用来定义大型分析数据集如何在数据湖上被组织、版本化和访问。它并不改变数据在文件层面的存储方式。相反，它会在文件之上增加一个标准 metadata layer；这些文件通常以 Apache Parquet 存储。通过这一层 metadata，文件集合可以像连贯的关系型表一样被处理，同时仍然保留在低成本 object storage 上。本章将探索 Apache Iceberg 作为数据湖仓开放表格式的架构和价值。
2.1 Iceberg 是一种 Table Format，这意味着什么？
Table format 定义了 data files、schemas、partitions 和 snapshots 如何存储，使不同 engines 可以一致地读取同一个 dataset。如图 2.1 所示，它是包在数据外面的一层逻辑包装，将物理文件与 metadata 结合起来。这些 metadata 支持高效 discovery、pruning 和 versioning，很像图书馆索引可以让你不用阅读每一页就快速查找内容。
图 2.1：Table formats 让数据湖仓可以在数据湖上存储类似数据仓库的表，并具备 ACID 保证，因此数据湖可以像数据仓库一样工作。
Iceberg 独立于任何单一 execution engine 来定义自己的 table abstraction。这意味着你可以用很多工具访问同一个 dataset，包括 Dremio、Spark、Flink、Trino、Snowflake、Qlik，以及 PuppyGraph 等 graph-processing engines。通过共享对 table structure 和 metadata 的同一视图，各团队可以继续使用自己偏好的工具，同时在同一份数据上工作。
什么是 Apache Parquet？
Apache Parquet 是一种为大规模分析 workloads 构建的列式文件格式，广泛用于现代数据湖和数据湖仓架构。它不是逐行存储完整 records，而是逐列存储 values，把磁盘上同一类型的数据分组存放。这种布局非常适合分析，因为 queries 通常会扫描许多行，但只访问一部分 columns。
Parquet 的列式设计支持高压缩率，并通过从存储中读取更少数据来加快 I/O。由于每一列都是单独存储的，query engines 可以跳过无关 columns，只扫描 query 所请求的数据。Columnar storage 也支持 vectorized execution：engines 会批量处理 values，而不是一次处理一行。这让现代处理器可以利用 CPU cache locality 和 single instruction, multiple data（SIMD）instructions，从而加速 scans 和 aggregations。
在 Apache Iceberg 生态中，Parquet 是存储 table data 的主要文件格式。Iceberg 定义 Parquet files 如何被组织、版本化，并在 metadata 中描述。Iceberg 管理 table schemas、snapshots 和 file-level statistics，而 Parquet 提供数据的高效物理表示。
Iceberg 和 Parquet 共同形成一对互补组合。Parquet 在文件层面提供快速、高效的列式数据访问；Iceberg 则增加 transactional guarantees、schema evolution，以及跨 engines 的一致 table semantics。通过分离这些职责，Iceberg tables 可以在不同 engines 和 execution models 中实现扩展、演进，并保持良好性能。
接下来，我们来看 Apache Iceberg 修复了什么问题、它如何设计，以及它与其他 table formats 有何不同。
2.2 为什么需要 Table Format？
从本质上讲，数据湖是一组存储在 distributed system 中的数据文件，通常是 Amazon S3、Azure Blob Storage 或 Google Cloud Storage 这样的 object store。这些文件通常以 Apache Parquet 或 ORC 等列式格式写入，但 CSV 这类 row-based formats 也很常见。这些文件格式非常适合存储和扫描数据，但它们并不像关系型系统那样定义 tables。
File formats 描述 records 如何存储在单个文件中，但它们不定义跨多个文件的数据集。因此，query engines 无法把一个 multifile dataset 当作带 transactional guarantees、schema evolution 和 consistent snapshots 的单一 versioned table 来处理。Apache Hive 等系统曾试图通过 Hive Metastore 支撑的 table abstraction 来弥合这一差距，Hive Metastore 会跟踪 schemas、partitions 和 file locations。这种方法支持对文件进行 SQL 访问，但它提供的 transactional guarantees 有限，而且随着 datasets 增长，metadata 管理无法良好扩展。
如果没有专门的 table format，无论底层文件格式是什么，管理一致性都会变得困难。当多个 jobs 或 tools 写入同一个 dataset 时，它们可能发生冲突，导致 partial updates、duplicate records 或 inconsistent query results。Schema changes 也需要手动协调，而且没有内置机制来跟踪 dataset 如何演进。
Performance optimization 也受到限制。如果没有集中式、query-aware metadata，engines 通常依赖 directory listings 和 file-level inspection 来查找数据。这让 query planning 阶段更难 prune files。这些挑战在 file-based data lakes 中都很常见，并不特定于 Parquet、ORC 或 CSV。这就是为什么 Apache Iceberg、Delta Lake 和 Apache Hudi 等现代 table formats 现在已经变得必要。它们将文件集合转变成可靠、高性能、治理良好的分析表。
如图 2.2 所示，一个 lakehouse table 由 data files 和 metadata files 组成。Data files 存储 dataset，而 metadata files 帮助 query engines 更高效地扫描数据。
图 2.2：Lakehouse table 的组成部分：metadata files 描述构成 table 的文件，data files 保存数据。
2.3 Apache Iceberg 如何管理 Metadata？
Apache Iceberg 最大创新之一，就是它组织 metadata 的方式，这有助于让 lakehouse 保持快速和高效。但 metadata 是什么？为什么它在数据湖仓中如此重要？
想象一个装满抽屉和柜子的大厨房。如果你需要一把勺子，你可以逐个抽屉翻找，直到找到，但这会花很多时间。现在想象墙上有一个 clipboard，告诉你每样东西准确存放在哪里。你不用翻箱倒柜，只要查看 clipboard，就能直接去正确位置。这个 clipboard 就是 metadata：一种结构化索引，帮助你高效定位和获取信息。
在传统数据湖中，query engines 往往不得不“搜索整个厨房”，扫描成千上万甚至数百万个文件，以定位相关 records。Partitioning 会有帮助，但 engines 仍然高度依赖 directory listings 和 file-level inspection 来决定读取什么。Iceberg 用结构化、多层次的 metadata system 改变了这个模型，它就像一个组织良好的 clipboard，直接引导 queries 找到正确文件。
Iceberg 并不是把所有 metadata 存在一个单体结构中，而是将 table metadata 分层组织。例如，它会将 table-level metadata 与 file-level metadata 分离。每一层都承担不同职责，用于描述 table 的结构和内容，如图 2.3 所示。Catalog 会跟踪这些 metadata layers，并为 query engines 提供稳定入口，使它们能够快速定位 table definitions，并决定应该扫描哪些 data files。
这种分层 metadata 让 query engines 可以在 query planning 阶段 prune data，而不是在 execution 阶段才做。它还支持 schema evolution，并且可以扩展到非常大的 tables，而不会形成集中式瓶颈。因此，Iceberg 让 analytical queries 更快、更可靠，并已经成为现代数据湖仓的核心组成部分。
图 2.3：Apache Iceberg table read-and-write operation 的结构和流程
Apache Iceberg table 的 metadata files 主要由三类文件组成，帮助 engines 高效扫描和读取 table：
metadata.json（table-level metadata）
- 跟踪 table 的版本，也就是 snapshots
- 存储 schema definitions 和 partitioning strategies
- 让 query engines 理解 table structure
- 支持 schema evolution、time travel 和 data consistency 等功能
Manifest lists（snapshot-level metadata）
- 表示 table 的单个 snapshot
- 列出文件组，也就是 manifests，以及 summary statistics，以帮助减少不必要的 file scans
Manifests（file-level metadata）
- 列出 dataset 中的单个 Parquet files
- 存储 file locations 和 statistics，帮助 query engines 在扫描前过滤无关数据
通过这种方式组织 metadata，Iceberg 让 query engines 在执行 queries 时跳过不必要文件，从而无需复杂 indexing systems 就能提升性能。例如，如果一个 query 只需要 2024 年 1 月的数据，Iceberg 可以使用 manifest list statistics 跳过不必要 partitions。然后，manifest files 可以在扫描任何数据之前，进一步过滤掉不符合 query conditions 的单个 Parquet files。这种智能 pruning 显著减少扫描数据量，提升性能并降低 compute costs。图 2.4 展示了 metadata pruning 的过程。
图 2.4：Engines 使用 metadata statistics 将 data files 排除在 scans 之外，从而加速 queries。
2.4 Apache Iceberg 的关键特性
Apache Iceberg 提供了现代 table format 应有的功能，同时也提供了一些架构特性，使其能够在大型、多 engine 环境中可靠扩展。其核心是完整 ACID transactions，因此 concurrent reads 和 writes 可以生成一致、隔离且持久的 table states。这种 transactional model 允许多个 jobs 和 tools 在不依赖外部协调、也不冒 partial updates 风险的情况下，安全地操作同一批 datasets。
Iceberg 也支持受控 schema evolution。你可以添加、重命名或重排列 columns，而不会破坏现有 queries，也无需重写整张 table。Schema changes 会在 table level 被跟踪，因此你的 data model 可以演进，同时仍然与 downstream consumers 保持兼容。
Iceberg 最具特色的许多功能，都与大规模访问和管理数据有关。它基于 snapshot 的设计支持 time travel，因此 queries 可以读取 table data 的历史版本，用于 auditing、debugging 或 recovery。Time travel 适用于 table snapshots 捕获的数据变化；它不能撤销破坏性 schema operations，例如 dropping columns。Snapshot retention policies 决定你可以回溯多远。
Iceberg 通过 partition evolution 和 hidden partitioning 增加灵活性。Partition evolution 允许你的 partitioning strategy 随时间变化，而无需重写已有数据。Hidden partitioning 将 partition columns 从用户可见 schema 中隐藏起来，而是以 metadata transforms 的形式存储。二者结合起来，可以简化 queries，并让 engines 在不要求用户理解数据物理布局的情况下优化执行。
在 table level，Iceberg 支持 table states 的 branching 和 tagging。这使你可以隔离地进行实验、暂存数据变更，并控制何时将 updates 提升为正式版本。这些功能结合起来，帮助你构建可扩展、可维护、面向未来的 lakehouse data architectures。
2.5 Apache Iceberg：开源标准
Apache Iceberg 不受单一 vendor 控制，这是它成为现代数据架构基础技术的一个关键原因。就像 TCP、REST 或 Kubernetes 这样的 standards 一样，Iceberg 定义了一个公共契约，使独立系统可以实现它，而不必把控制权交给某个平台。这种中立性帮助组织构建长期存在的数据架构：即使 tools、engines 和 vendors 变化，table format 仍然保持稳定。
Iceberg 是 Apache Software Foundation 的顶级项目，贡献者来自 Netflix、Apple、Dremio、Snowflake、AWS、Databricks 以及许多其他组织。没有任何一家公司单独决定项目 roadmap 或方向。相反，Iceberg 由拥有多样需求的用户和 vendors 组成的广泛社区共同塑造。这有助于保持格式的 interoperable、scalable，并适用于许多 use cases 和 deployment environments。
凭借如此广泛的行业支持，它现在已经深度集成到许多工具和 engines 中，包括：
Dremio——Federated SQL，以及针对 Iceberg tables 的 native query acceleration 和 reflections，用于实现快速 BI performance。
AWS——主要云厂商，拥有越来越多 Apache Iceberg integrations。
PuppyGraph——在 Iceberg datasets 上运行 graph queries。
Apache Spark 和 Flink——大规模 ETL 和 streaming workloads。
Kafka Connect——将 streaming data 摄入 Iceberg tables。
Qlik Talend Cloud——使用 Iceberg 的全功能 data integration 和 management solution。
由于 Iceberg 是开放的，组织不会被锁定到单一 vendor 或 technology stack。团队可以构建灵活、可互操作的 lakehouse，并添加新 tools 和 workflows，而无需重构数据平台。有了 Iceberg，数据湖可以成为传统数据仓库之外可扩展、成本高效的替代方案。
2.6 Apache Iceberg 的优势
Apache Iceberg 可以提升 performance 和 flexibility，但需要与 query engines 和 catalog systems 认真集成，才能释放其全部潜力。组织还需要重新思考传统数据湖实践，因为 Iceberg 改变了我们处理 data lake data 的方式：不再把数据看作 raw files，例如“sales dataset 就是这一文件夹 parquet files”，而是把数据当作 managed tables，例如“我的 sales data 是 catalog 中看到的这张 table”。接下来，我们来看 Apache Iceberg 的关键优势，以及它们如何解决长期存在的数据管理问题。
2.6.1 ACID Transactions
在数据湖中，如果多个 jobs 在没有 transactional guarantees 的情况下写入同一个 dataset，就可能出现 conflicting updates、duplicate records 和 unreliable query results。缺少协调时，团队通常会采用复杂 workaround，例如写 temporary files、使用 external locking mechanisms，或通过调度 jobs 来尽量减少冲突。这些方案会增加运维开销，并且仍然无法防止 inconsistencies。
Apache Iceberg 通过提供完整 ACID guarantees 解决这个问题，使 dataset changes 以受控、可预测的方式应用。ACID 代表 atomicity、consistency、isolation 和 durability，每一个都在 concurrent access 下维护 correctness 方面发挥特定作用：
Atomicity 意味着每个 write operation 都作为 all-or-nothing change 提交，防止 partial updates 让 table 处于未定义状态。
Consistency 保证每个 committed change 都会将 dataset 从一个有效状态移动到另一个有效状态，并跨 tools 和 processing frameworks 保留已定义 invariants，例如 schema rules 和 table constraints。
Isolation 通过强制 well-defined ordering 和 conflict detection，确保 concurrent writers 能看到并尊重彼此的 changes。如果某个 write 基于 stale view，并与另一个已提交 change 冲突，它会被拒绝，而不是悄悄覆盖数据。
Durability 意味着一旦某个 change 被提交，它就会被记录下来，并且即使在 failures 之后也可以恢复。
这些 guarantees 结合起来，使多个 teams 和 tools 可以在不使用 external locking 或 coordination 的情况下，安全地读取和写入同一张 Iceberg table。通过在 commit time 强制 correctness，并保留一系列一致的 table states，Iceberg 让 shared data lakes 更可靠，也更容易在规模化环境中运维。
2.6.2 表如何演进
在传统数据湖中，修改 schemas 和 partitions 非常麻烦，哪怕只是简单结构变更，也常常需要重新加载或重写 datasets。这种刚性迫使组织提前做出设计选择，而这些选择可能无法随着业务需求演进而扩展。随着时间推移，这些限制会造成低效、数据重复和复杂 workaround，从而拖慢 analytics 和 data-engineering workflows。
Apache Iceberg 通过 schema evolution 解决这些挑战，使 datasets 能随时间适配变化，而无需昂贵 rewrites。你可以添加、重命名或删除 columns，而不会破坏现有 queries，并保持 across applications 的 backward compatibility。不同于 Hive 中 partition schemes 在 table 创建时固定，Iceberg 的 partition evolution 功能允许你随时间改变 partitioning strategies，而无需 data migration。
此外，Iceberg 会跟踪 schema history，因此你可以查看 table structure 随时间如何变化。这对 auditing 和长期数据管理很有用。这种灵活性使 Iceberg 非常适合需要随业务需求演进的长期 datasets，降低 schema 和 partition management 的摩擦。
2.6.3 Time Travel 和 Snapshot-Based Queries
在传统数据湖中，一旦数据被覆盖，它就消失了。没有简单方式可以恢复之前版本用于 historical analysis，或撤销错误。这种缺少 version control 的状态，让 disaster recovery 和 historical analysis 更困难，通常迫使团队创建 duplicate datasets 或依赖 manual backups。没有结构化方式跟踪 changes 时，即使 data ingestion 中一个小错误，也可能导致不可逆的数据丢失或 corrupted records。
Apache Iceberg 通过 time travel 改变这一点。它允许你像特定时间点那样查询旧的 table versions。如果摄入了错误或不完整数据，你可以回滚到之前 snapshot，无需复杂 recovery steps 就能恢复 dataset。Iceberg 还支持 versioned analytics，因此你可以分析历史趋势，而无需复制数据或管理同一 dataset 的多个副本。这通过让数据在人为或系统错误后更容易恢复，支持 data governance、compliance 和 debugging。图 2.5 展示了 time travel 的工作方式：被使用的 data file listing 取决于扫描的是哪个 snapshot。
图 2.5：Engines 可以扫描较旧 snapshots，以获得不同文件列表，然后扫描较旧版本的数据。
2.6.4 Hidden Partitioning，用于减少意外 Full-Table Scans
Partitioning 可以加快 queries，但传统 Hive-style tables 要求在 queries 中手动指定 partition columns。如果一个 query 的 WHERE clause 中缺少 partition filter，query engines 就必须扫描大量不必要数据，从而拖慢 queries 并浪费资源。这种手动方式会增加用户复杂性，也提高了写出次优 queries 的风险，因为这些 queries 没有利用 partition pruning。
Apache Iceberg 使用 hidden partitioning 消除了这一负担。Partition logic 被定义在 table metadata 中，而不是作为物理 columns 或 directory names 暴露。你不需要自己创建和查询 partition columns；Iceberg 会在 query planning 阶段应用 partition transforms。
例如，一张 table 可能存储一个类型为 TIMESTAMP 的原始 event_timestamp column，而该 table 可能使用 hour(event_timestamp) 或 day(event_timestamp) 这样的 transform 进行 partition。不会向 schema 添加额外 partition columns，也不会有 directory structure 反映这种 partitioning。当 query 对 event_timestamp 做过滤时，即使 query 从未提到 partition key，Iceberg 也会使用 metadata 识别相关 partitions，并相应 prune files。
Partition transforms 只存在于 metadata 中，因此它们可以不同于原始 column type，并对用户保持不可见。例如，一个过滤 timestamp range 的 query，仍然可以利用 hour-level 或 day-level partitions，而无需用户知道数据在物理上如何组织。这既防止了大型不必要 scans，又保持 logical schema 干净稳定。
通过将 partitioning strategy 与 schema 和 storage layout 分离，hidden partitioning 让 queries 更容易写、更安全地演进，并在规模化时更高效。它降低了 accidental full-table scans 的风险，并允许 partitioning strategies 随时间变化，而不会破坏 queries 或重写数据。这改善了大型 lakehouse deployments 的 performance 和 usability。
2.6.5 成本效率与查询性能
组织通常会在 data lakes、data warehouses 和 downstream data marts，也就是为特定团队或 reporting use cases 构建的 curated subsets of data，之间保留同一数据的多个副本。这可以简化消费，但也增加了运维成本和复杂性。每增加一个副本，都需要单独 ingestion、transformation、storage 和持续维护。
在 cloud environments 中，这些低效会更加严重。在系统之间移动数据，通常意味着重复 file listings、metadata lookups 和 footer reads，这会增加 object storage 中的 network latency 和 per-operation costs。大型 ETL pipelines 必须反复扫描、重写并 materialize 数据到每个目标系统所需的新 formats 和 layouts。随着数据量增长，duplicate storage、transformation jobs 和 compute-intensive scans 的累计成本会快速增加。
常见模式是先将 raw data 摄入 lake，经过一个或多个 ETL stages，再加载到 warehouse 或 data mart 中用于 analytics。每一步单独看可能都有合理性，但加起来就是难以在规模化时持续承担的成本。随着时间推移，组织会花费大量资源，只是为了让数据在系统之间保持同步，而不是交付新的分析价值。
Apache Iceberg 通过消除不必要数据复制，并优化 query performance 来降低这些成本。团队不需要把数据从 lake 复制到 warehouse 后再做 analytics，而是可以直接从 data lake 查询 Iceberg tables，从而避免冗余 storage expenses。Iceberg 还会优化 data scans，允许 query engines 在执行前 prune 不必要 files，减少读取的数据量并降低 compute costs。
Iceberg 简化 ETL workflows，因为你可以将 streaming 和 batch data 都摄入同一张 table，而不必在不同 environments 之间搬运数据。当你移动更少数据、创建更少副本，并优化 queries 时，就可以用一小部分成本获得高性能 analytics。例如，Insider 使用 Apache Iceberg 将 S3 成本降低了 90%，可参考 “Apache Iceberg Reduced Our S3 Cost by 90%”（Medium，2022 年 9 月 28 日，mng.bz/PwQ2）。
2.7 Apache Iceberg Lakehouse 组件
Iceberg lakehouse 的核心是模块化，因此组织可以为每个组件选择最合适的工具。结合 Iceberg 广泛生态，这种设计提供了很高的 interoperability 和 openness。
传统单体数据仓库往往会把组织锁定在某一家 vendor 的生态中。相比之下，模块化 lakehouse architecture 让企业可以：
- 根据不断变化的需求独立扩展每个组件。
- 使用 Apache Iceberg 等开放标准，减少 vendor lock-in。
- 通过为 ingestion、federation 和 consumption 选择合适工具，优化 performance 和 cost。
通过将 lakehouse 结构拆分为五个关键组件，你可以为自己的需求选择最佳工具，并避免 vendor lock-in：
Storage layer——在 object storage 中以成本高效方式存储数据。
Ingestion layer——通过 streaming 或 batch 将数据写入 Iceberg tables。
Catalog layer——跟踪并治理所有 Iceberg metadata。
Federation layer——为 analytics 建模并加速数据。
Consumption layer——支持 BI、AI 和 real-time applications。
我们来拆解 Apache Iceberg lakehouse 的五个关键组件，并看看它们如何组合，如图 2.6 所示。本书第 2 部分会更详细地深入每个组件。
图 2.6：完整数据湖仓实现的组件
2.7.1 Storage Layer：Lakehouse 的基础
Storage layer 保存 raw data 和 metadata。它通常是为 scalability、durability 和 cost efficiency 设计的 distributed object store 或 filesystem。
数据存储在哪里：
Cloud——Amazon S3、Azure Blob Storage、Google Cloud Storage
On premises——HDFS、MinIO、Ceph
Hybrid——当业务需求要求时，将二者组合使用
存储什么：
Data files——通常是 Apache Parquet，也可以是 ORC 或 Avro，针对 analytics 优化
Metadata files——Iceberg 的 table metadata、manifests 和 snapshots
为什么它重要
Lakehouse model 的一个关键好处，是 storage 和 compute 分离。不同于将二者捆绑的数据仓库，Iceberg 允许你独立扩展 compute workloads。这可以降低 storage costs，提升 performance，并让团队使用自己偏好的工具。
2.7.2 Ingestion Layer：向 Iceberg Tables 注入数据
从不同系统收集数据后，你会处理它们，并将其作为 Iceberg tables 存储在 storage layer 中。Ingestion layer 是一组 tools 和 frameworks，通过 batch processing 或持续 streaming，将数据 transform、clean 并 load 到这些 Iceberg tables 中。
Batch ingestion：
Apache Spark——将大规模 ETL workloads 摄入 Iceberg。
Fivetran——管理 ETL workloads 的 ingestion。
Streaming ingestion：
Apache Flink——执行实时数据处理并写入 Iceberg。
Kafka Connect——从 Kafka topics 向 Iceberg tables 提供 streaming ingestion。
Estuary——用于 real-time 和 batch ingestion 的 managed platform。
Qlik Talend Cloud——支持 batch 和 streaming workloads。
这些只是部分选项。本书第 2 部分第 6 章会看到更多选择。
为什么它重要
灵活的 ingestion layer 可以帮助你高效地将 batch 和 streaming data 写入 Iceberg tables。由于它是模块化的，你可以让数据更新鲜，并降低 analytics 和 AI use cases 的 latency。
2.7.3 Catalog Layer：进入 Lakehouse 的入口
Lakehouse catalog 让 Iceberg 在规模化下可查询、可管理。它充当 storage layer 和 query engines 之间的接口，跟踪 tables 及其 metadata locations。
Lakehouse catalog options：
Hive Metastore——遗留支持，但对 Iceberg 0123 AQ+ 来说并不理想。
AWS Glue Data Catalog——用于管理 Iceberg tables 的 cloud-native 选项。
Project Nessie——Git-like versioned catalog，支持 time travel 和 data as code。
Apache Polaris——开源 lakehouse catalog，具备稳健 role-based access control（RBAC）能力。
Apache Gravitino——Geodistributed lakehouse catalog。
Lakekeeper——为 enforceable governance 构建的 Iceberg catalog。
Iceberg REST Catalog——Iceberg-compatible catalogs 的开放标准。
为什么它重要
Catalog layer 是所有 Iceberg tables 的 single source of truth，为 query engines 提供一致性和治理。它支持：
- Atomic table updates，不打断用户
- Cross-tool interoperability，让 Dremio、Spark、Flink、Trino、Snowflake 等 engines 能看到相同 tables
- 跨工具 portable access controls
选择得当的 catalog 可以让组织中的团队安全协作，共同使用相同 Iceberg datasets，并消除 data silos。
2.7.4 Federation Layer：建模并加速数据
Federation layer 是 raw data 被建模、丰富并优化，以服务 analytics、AI 和 reporting 的地方。团队在这里定义 business logic，统一跨来源数据，并优化 query performance。下面讨论一些让 federation layers 在处理数据时特别强大的功能。
Key capabilities：
Semantic layer——定义组织内一致 metrics。
Federated query engines——支持跨 Iceberg 和外部 databases 进行查询。
Query acceleration——在不复制数据的情况下加速 analytics。
Example tools：
Dremio——通过内置 semantic layer 和用于加速的 Reflections 功能，统一 Iceberg、databases 和 warehouses。
Trino——提供开源、基于 SQL 的多源数据统一能力。它可能需要外部 semantic layer 和 acceleration tools。
为什么它重要
Federation layer 避免 Iceberg tables 成为孤岛。组织的数据经常分散在不同 locations 和 formats 中：
- Relational databases，例如 PostgreSQL、MySQL、SQL Server
- Cloud data warehouses，例如 Snowflake、Redshift、BigQuery
- 其他 lakehouse formats，例如 Delta Lake、Apache Hudi
强大的 federation layer 帮助团队创建统一 business views，使 Iceberg 无缝融入企业级 data strategy。
2.7.5 Consumption Layer：交付业务价值
数据的价值取决于它能带来的 outcomes。Consumption layer 是数据被用于 analytics、AI 和 operational workflows 的地方。
Use cases：
Business intelligence（BI） ——驱动 dashboards 和 reporting。
AI and machine learning（ML） ——训练模型，并为 AI applications 和 AI agents 提供数据燃料。
Embedded analytics——将洞察直接交付到业务应用中。
Data APIs and apps——基于 Iceberg data 构建面向客户的 applications。
Example tools：
BI and dashboards——Tableau、Power BI、Looker、Preset（Superset）。
AI and ML——Databricks、Sagemaker、Bedrock、Hugging Face、Jupyter、LangChain。
Data APIs——用于 application integration 的 GraphQL、REST APIs。
为什么它重要
Lakehouses 是模块化的，而 Iceberg 是开放标准，因此你的数据可以跨 tools 访问，而无需重复 ETL。这消除了：
- 为不同 workloads 将数据复制进多个 warehouses
- 在不同 departments 之间产生 data inconsistencies 的风险
- 为 operational analytics 支付昂贵 cloud warehouse query costs
有了 Iceberg lakehouse，你可以只定义一次 data products，然后在任何地方使用它们。这为整个企业提供了单一、可信的事实来源。
下一章中，我们会进入动手实践，让你看到 data lakehouse 如何实际运行。之后，在本书第 2 部分，我们会探索架构 Apache Iceberg lakehouse 的五个组件。目标是在深入设计工作之前，让你更好感受 lakehouse experience。
小结
Apache Iceberg 是一种现代 table format，支持 high-performance analytics、schema evolution、ACID transactions 和 metadata scalability。它将数据湖转变为结构化、可变更、可治理的存储平台。
Iceberg 解决了 OLTP databases、enterprise data warehouses 和 Hadoop-based data lakes 的关键痛点，包括高成本、刚性 schemas、慢 queries 和不一致的数据治理。
通过 time travel、partition evolution 和 hidden partitioning 等功能，Iceberg 降低存储成本，简化 ETL，并优化 compute resources，使数据分析更高效。
Iceberg 可与 Trino、Dremio 和 Snowflake 等 query engines，Spark 和 Flink 等 processing frameworks，以及 Nessie、Polaris 和 Gravitino 等 open lakehouse catalogs 集成，从而支持模块化、vendor-agnostic architectures。
Apache Iceberg lakehouse 有五个关键组件：storage、ingestion、catalog、federation 和 consumption。
