本章内容包括：
- 什么是数据湖仓，以及它与传统数据架构有何不同
- Apache Iceberg 如何塑造湖仓范式
- 什么时候以及为什么要实现 Apache Iceberg lakehouse
数据架构的演进，与其说是为了创新而创新，不如说是由持续失败推动的。长期以来，组织一直很难在规模化场景下交付既快速、又经济、还可信的分析能力。表现良好的系统往往昂贵而僵硬；灵活且便宜的系统又常常缓慢、脆弱，并且难以治理。每一代新架构都承诺修复这些取舍，但也会引入新的技术和业务约束，限制数据的使用方式。
数据仓库提供了性能和治理能力，但也把数据锁定在高成本、专有格式和刚性 schema 之后，使变化变得缓慢。数据湖降低了存储成本并提高了灵活性，但牺牲了可靠性、性能和一致性，让分析变成了一个工程项目。混合方法试图弥合二者之间的差距，却往往增加了复杂性、重复和运维开销。结果就是一个碎片化的数据版图：团队花在移动、复制、修复数据上的时间，超过了真正使用数据的时间。我们会看到，这些缺陷如何催生出在数据湖上定义和管理数据集的新方式——这些方式结合了数据仓库和数据湖的关键优势，最终形成了数据湖仓。
Apache Iceberg 就是其中一种较新的方法。它是一种开放表格式，允许你像对待传统数据库表一样，对待分布式存储系统上的一组文件，从而让数据湖真正成为分析平台的中心。有了 Iceberg，多个工具可以高效访问存储在数据湖中的分析数据集。这种开放访问让团队协作更容易，也通过保留一份单一、规范的数据副本，减少不必要的 extract、transform、load（ETL）工作和数据复制。
Apache Iceberg lakehouse 是一种模块化、可扩展且成本高效的架构，它结合了数据湖和数据仓库的最佳方面，同时保持开放和灵活。为什么 Netflix、Apple、Dremio、AWS、Snowflake 和 Databricks 等公司都在使用 Iceberg，并围绕它构建工具？其中一个原因是，Iceberg 为存储分析数据集提供了一种由社区主导的标准格式。它可以跨广泛工具运行，同时仍然提供 ACID（atomicity、consistency、isolation、durability）保证，以及你期望从专有数据仓库系统中获得的性能。
本书会展示 Iceberg 的工作原理，以及如何为 Iceberg lakehouse 做出正确架构选择，以满足你的 use cases。我们会覆盖数据湖仓的一般概念，也会专门讲 Apache Iceberg，并提供可在本地运行的动手练习。你将把数据从数据库摄入 lakehouse，并在其上构建商业智能 dashboards。在这个过程中，我会帮助你评估自己的数据平台需求，并探索每个组件周围的生态系统，让你理解构建理想平台时有哪些选择。
让我们从 Apache Iceberg 所诞生的世界开始：传统架构的挑战，以及数据湖仓如何作为回应而出现。然后我们会看到，Iceberg 如何通过一种可扩展、高性能、开放的现代数据架构方案，把 lakehouse 推向更远。
1.1 从数据库到数据湖仓的演进
数据并不是存在于真空中。它始终处于流动中，驱动应用、分析和 AI-driven decision-making。多年来，组织构建了多层基础设施，用来处理数据管理日益增长的复杂性。数据湖仓是最新一步，目标是在保持开放和互操作性的同时，平衡成本、可扩展性和可访问性。
数据湖仓现在已经成为主导范式。要理解原因，最好先理解它之前那些架构挑战。我们将追踪从 online transaction processing（OLTP）数据库，到面向分析优化的系统，例如数据仓库和数据湖，再到更后续形态的演进，以解释为什么 lakehouse 会出现，以及它如何解决数据管理中长期存在的取舍问题。图 1.1 展示了从数据仓库到数据湖仓的演进过程，我们会在本节中反复回到这张图。
图 1.1：数据平台的演进，从 data warehouse 或 data lake 到 data lakehouse，以及部署模型从 on-premises 到 cloud 的演进
1.2 数据仓库的兴起
早期，大多数数据都位于 OLTP databases 中，也就是为实时应用交互构建的传统关系型系统。Oracle、Db2、PostgreSQL、MySQL、NoSQL stores 和 SQL Server 等数据库，都针对 transactional operations 进行了优化，例如插入、更新和检索单条记录。这些系统通常使用 row-based layout，将单条记录的所有字段存储在一起，因此非常适合 point lookups 和频繁的小规模更新。
当组织开始分析历史数据，以生成 roll-up reports、analytical dashboards、aggregations，以及跨长时间范围的 complex joins 时，问题就出现了。这些 analytical queries 会扫描许多行，但只触碰少数列，因此 row-based systems 会浪费时间读取整行，尽管大多数字段并不需要。Column-based layouts 会把同一列的值放在一起，因此 analytics engines 可以只读取和处理查询所需的数据。OLTP 存储设计与分析访问模式之间的这种不匹配，使 transactional databases 在数据量和分析需求增长时变得吃力。
这种吃力的原因很明确：OLTP systems 是为快速 transactional queries 设计的，而不是为扫描和聚合数百万甚至数十亿行而设计的。Indexing 和 partitioning 可以帮助优化某些 queries，但 analytical workloads 仍然会给 operational databases 带来显著压力，常常拖慢 transaction processing。这些系统并不是为大规模存储和检索构建的，因此很难保留历史数据用于长期分析。
于是，enterprise data warehouse（EDW）出现了，它是一种专用分析系统。Teradata、IBM Netezza 和 Oracle Exadata 等产品，让公司可以从 OLTP systems 中抽取数据，将其转换为优化后的 schemas，然后加载到 centralized warehouses 中，用于称为 online analytical processing（OLAP）的 analytical workloads。问题在于成本和刚性。
1.3 向云数据仓库迁移
传统 enterprise data warehouses 运维成本高，并且难以扩展，因为 storage 和 compute 被紧密耦合在一起。为了提升 query capacity 或保留更多历史数据，组织必须提前采购并配置额外的本地硬件，通常要提前数月。这种刚性让成本可预测，但缺乏灵活性，迫使组织为应对峰值 workloads 而过度配置基础设施，而大部分时间资源都处于低利用状态。ETL pipelines 也需要时间和资金维护，因为数据必须先转换并加载到 warehouse-specific schemas 中，才能被查询。
Snowflake、Google BigQuery 和 Amazon Redshift 等云数据仓库引入了更灵活的成本模型。由于 compute 和 storage 是分离的，组织可以独立于数据保留规模来扩展 query processing，并且只为实际使用付费。这使实验更容易，降低了前期资本支出，也减轻了管理基础设施的运维负担。Self-service analytics 也变得更容易，因为团队不再需要 sizing clusters 或管理硬件，就可以运行 analytical workloads。
即便有这些改进，云数据仓库仍然保留了一些根本限制。你仍然必须先把数据加载到 warehouse 中，才能分析它，而这在规模化场景下并不高效。组织经常会将同一份数据从 operational systems 复制到多个 warehouses 中，引入 latency，增加重复存储，并使 data pipelines 更复杂。数据进入 warehouse 后，会以 proprietary serialization formats、indexing strategies 和 query semantics 存储，而这些在不同 vendors 之间并不相同。这让数据和应用难以迁移，实际上把组织锁定在单一平台上。随着数据量和 use cases 增长，企业开始质疑：无论是在 cloud 中还是其他环境中，这种紧耦合、专有的分析系统，是否真的是大规模数据分析的长期基础。
1.4 数据湖与 Hadoop 时代
数据仓库能够很好地处理结构化数据上的分析，但组织仍然需要一种方式来存储和处理快速增长的半结构化和非结构化数据，包括 clickstream events、application logs、IoT sensor readings 和 social media data。这一缺口催生了数据湖，也就是一种架构模式，用于在 distributed storage 中存储大量文件集合，并直接在这些文件上运行分析。
早期数据湖出现在 2000 年代中期，建立在 Hadoop Distributed File System（HDFS）和 MapReduce programming model 之上。与现代云系统不同，Hadoop 并没有解耦 storage 和 compute；它是有意将二者 colocated，也就是放在一起。让 compute 靠近 commodity hardware 上的数据，可以降低网络成本，并以 enterprise data warehouses 成本的一小部分，使大规模 batch processing 成为可能。开源 Hadoop 生态系统与低成本硬件的结合，也让团队可以保存比传统 warehouses 中经济上可行的更多原始数据。
但基于 Hadoop 的数据湖也有取舍，使它们在分析场景中不够高效。MapReduce 擅长大型 batch jobs，但不适合 interactive 或 iterative queries。早期 SQL layers，例如 Hive，会将 queries 转换为多个 MapReduce stages，通常会把 intermediate results 写入磁盘，从而增加 latency 和资源消耗。后来的 engines，例如 Impala 和 Spark，通过减少不必要的 disk I/O，并将 query execution 压缩成更少 stages，显著提升了性能。但底层模型仍然需要仔细调优和深厚工程专业能力。
随着数据湖增长，新的挑战逐渐显现。由于数据被存储在松散组织的文件中，很难强制 schemas、处理 schema changes，或跨团队维护一致的数据视图。Jobs 和 tools 之间的协调很大程度上位于 storage layer 外部，增加了数据集不一致或冲突的风险。随着时间推移，这些问题导致了所谓的 “data swamps”，也就是数据很多，但难以查询、治理和信任。
与此同时，云数据仓库也有自己的取舍。它们将 storage 与 compute 解耦，但依赖 proprietary formats 和 execution engines。组织最终维护了并行系统：基于 Hadoop 的 lakes 用于原始、大规模处理，cloud warehouses 用于 analytics 和 business intelligence（BI）。数据经常必须被重新塑形或重新组织，以匹配每个系统的 execution model，从而增加架构复杂性。缺失的是一种方法，它能够结合数据湖的可扩展性和开放性，以及数据仓库的可靠性、性能和易用性，而不用迫使组织在两组取舍之间二选一。
1.5 Apache Iceberg：赋予数据湖数据仓库能力
Netflix 开发 Apache Iceberg，是为了解决在数据湖中管理大型分析表时出现的可扩展性和正确性限制。Netflix 工程师曾大量依赖 Apache Hive；在较小规模下它表现还算可以，但随着 tables、partitions 和 concurrent workloads 数量增长，它开始吃力。
一个主要限制是 metadata scalability。Hive 将 partition 和 table metadata 保存在 Hive Metastore 中，后者通常由 PostgreSQL 或 MySQL 等关系型数据库支撑。小规模下这很好用，但对于管理拥有数十万或数百万 partitions 的 tables 的组织来说，这会变得脆弱。随着 tables 增长、更多团队使用它们，metadata operations 会成为瓶颈。
Schema management 是另一个主要限制。在 Hive 中，table schemas 与底层 file layout 紧密耦合。添加 columns 通常成本低，但其他常见操作，例如重命名或删除 columns，如果不重写数据，就不安全或不现实。这种紧耦合使长期存在的数据集很难随着业务需求变化而安全演进。
Query efficiency 还取决于 pruning 发生的时间。Hive 使用 directory listings 和 file-footer reads 来查找 partitions 并应用 filters。在 HDFS 环境中，这相对便宜；但在 cloud object stores 中，这会显著更昂贵且更慢。虽然 Hive 可以 prune data，但它往往是在 query execution 后期，而不是 planning 阶段完成 pruning，从而在规模化场景下增加 latency 和资源消耗。
Apache Iceberg 通过一种可扩展表格式和定义良好的 metadata model 解决这些问题，它将逻辑表结构与物理文件布局分离。Iceberg 维护关于 files、partitions 和 statistics 的集中 metadata，因此 query engines 可以在 query planning 阶段进行 pruning，而不是在 runtime 进行。在 cloud environments 中，这意味着更少的 object listings 和 file reads，从而降低成本并加快 queries。
Iceberg 为 table updates 提供完整 ACID 保证，因此多个 writers 和 readers 可以在同一个 dataset 上安全工作，并拥有明确定义的 isolation 和 consistency semantics。Iceberg 并不依赖外部协调或 best-effort guarantees，而是使用 snapshot-based transactions 来确保 concurrent operations 保持正确。
这些能力结合起来，改变了数据湖的使用方式。Apache Iceberg 将数据湖从一个松散管理的文件仓库，转变为一个可扩展、可靠的分析系统。通过直接在低成本 object storage 上启用 warehouse-like table behavior，Iceberg 使数据湖可以成为真正的分析基础。我们将数据湖的这种演进称为 data lakehouse。
1.6 数据湖仓：两全其美
数据湖仓是数据架构的下一次演进，改变了组织构建分析系统的方式。Lakehouse 不再把团队锁定在某一种技术或 execution engine 中，而是通过 Apache Iceberg 等 open table formats，将数据湖的 cost efficiency 与数据仓库的 performance 和 usability 配对起来。这让你可以为每个 use case 选择最合适的工具，同时基于同一个开放数据基础工作。Lakehouse 方法解决了几个长期挑战：
跨团队和工具的一致数据访问——组织不再需要让每个团队把同一份数据摄入并重塑到各自独立的 proprietary warehouses 中，而是可以只定义一次 shared data products，并让不同工具直接查询它们。Iceberg 的开放格式让 BI tools、query engines 和 processing frameworks 能基于相同 datasets 工作，减少碎片化，并帮助团队为每个 workload 选择最合适工具，而不牺牲一致性。
在不过度移动数据的情况下提升分析性能——Lakehouse 并不会消除对 curated datasets、materialized views 或 preaggregations 的需求，但它大幅减少了为了每个系统移动和重新格式化数据的需求。有了 Iceberg，batch 和 streaming pipelines 可以写入同一批 tables，下游工具可以读取、join 和分析数据，而无需进一步转换。这简化了 ETL workflows，并降低了维护同一份数据并行表示的开销。
在全球数据规模下减少重复——组织每年管理的数据都在增加，估计已经超过 150 zettabytes，并预计到 2030 年接近 2,000 zettabytes。在这种规模下，在多个系统之间复制同一份数据会变得过于昂贵，并且在运维上不可持续。Apache Iceberg 不会阻止你复制数据，但它让避免复制变得更容易：一组单一的数据产品可以服务许多工具和 use cases。
Apache Iceberg 在低成本存储上提供对 managed datasets 的开放、互操作访问，帮助组织摆脱遗留架构约束，并构建可扩展、成本敏感、AI-ready 的数据平台。在下一章中，我们会更仔细地看 Iceberg 如何工作，以及为什么它让 lakehouse architecture 变得可实践。
Apache Iceberg 与替代方案
当你将 Apache Iceberg 与其他表格式比较时，例如 Apache Hudi、Delta Lake、Apache Paimon，以及 UniForm 等新兴互操作层，关键差异不在基础功能上，而体现在长期灵活性、生态广度和运维可扩展性上。大多数现代 table formats 都提供 ACID transactions、schema evolution 和 time travel 等核心功能，但它们在实现方式，以及跨工具和环境一致扩展的能力上有所不同。
Iceberg 的突出之处在于其 metadata design 和 query planning。它的 snapshot-based architecture 支持 time travel，因此你可以查询某张表在特定时间点的状态。这让你可以审计变更、调试数据问题，或回滚到早期版本，而无需维护额外副本。
Iceberg 还提供更灵活的 partitioning 方法，这在数据集增长和变化时非常有用。传统 table formats 使用 static partition schemes，一旦数据写入后就很难调整。Iceberg 支持 partition evolution，因此你可以随时间更新 partition strategy，而无需重写已有数据。它还支持 hidden partitioning，也就是你通过 transforms 定义 partition logic，而不是暴露 partition columns。这意味着你不必在 queries 中添加和维护 day 或 month 等字段，但 engine 仍然可以在 query planning 阶段高效 prune data。
Iceberg 最大优势是围绕它形成的生态系统。Delta Lake 现在是一个开源项目，Hudi 则非常适合 streaming-oriented workloads，但 Iceberg 已经被广泛采纳到 query engines、processing frameworks 和 lakehouse catalogs 中。它可以与 Snowflake 和 BigQuery 等 data warehouses，Trino、Dremio 和 Presto 等 query engines，以及 Spark 和 Flink 等 processing frameworks 协同工作。Iceberg 还是 Apache Software Foundation 的顶级项目，具有透明治理，并获得 vendors 和 users 的广泛参与。
Iceberg 生态系统并不止于 table read/write support。它还包括 catalog standards、table optimization services、access control integrations 和 lifecycle management tools，这些让大规模 lakehouse deployments 更容易在生产中运行。这种广度为组织构建和演进架构提供了灵活性。它们可以采用新的 engines、formats 或 interoperability layers，例如 UniForm，而无需重构数据基础，或绑定到某一家 vendor 的 execution model。
小结
现代数据架构是在一次次取舍中演进出来的。为性能和治理优化的系统昂贵且僵硬；而为灵活性和成本优化的系统，又常常在可靠性、一致性和运维复杂性上遇到困难。
数据仓库、数据湖和混合方法各自解决了部分问题，但也引入了新的限制。结果是平台碎片化，团队花费大量精力移动、复制和重塑数据，而不是分析数据。
数据湖仓正是对这些失败的回应：它通过定义 managed、interoperable datasets，而不是依赖 raw files 或 proprietary systems，让数据湖能够支持 warehouse-style analytics。
Apache Iceberg 是 lakehouse architecture 的核心推动者。它引入了一种可扩展表格式，将逻辑表结构与物理存储分离，从而支持 schema evolution、snapshot-based time travel，以及安全的 concurrent writes。
