当今组织正在生成海量信息，因此高效地存储、管理与分析这些数据变得至关重要。数据的庞大规模与多样性带来了独特挑战——从确保可访问性到在大规模下维持性能。现代数据架构正是为此而生。要全面理解开源数据湖仓目录 Apache Polaris 的价值，首先需要了解“数据湖仓”概念的起源，以及 Apache Iceberg 在实现可扩展、高性能数据管理中的作用。
本章旨在为这些概念打下基础。我们先探讨促成湖仓架构演进的现代数据挑战，随后深入说明“表格式（table format）”在简化数据管理、确保跨系统一致性方面的作用，并重点介绍为云数据时代而设计的表格式 Apache Iceberg。读完本章，你将对数据湖仓以及 Iceberg 在构建可扩展、可管理且具成本效益的数据解决方案中的关键作用有扎实理解，为进一步认识 Apache Polaris 的独特贡献做好铺垫。
现代数据挑战
数字时代的数据爆炸催生了对面向大规模分析的系统的需求。传统为事务处理而设计的数据库，难以满足现代分析型工作负载的要求。这推动了数据仓库的兴起——一种为结构化数据查询提供高性能而专门构建的系统。随着组织需要存储与分析更为多样的数据形态，数据湖随之出现：以更低成本存放海量的结构化、半结构化与非结构化数据。
然而，当数据规模增长到 PB 级时，数据仓库与数据湖各自的局限逐步显现。数据仓库虽强大，但存储成本高，且缺乏处理非结构化数据的灵活性；数据湖虽然灵活且可扩展，但在实时分析所需的速度与可靠性方面常常性能不足。
云上部署的进一步创新，使组织能够更灵活、以更低成本扩展基础设施。同时，诸如 Apache Parquet 与 ORC（Optimized Row Columnar） 这类面向分析优化的文件格式，通过让存储格式更契合大规模查询工作负载，提升了数据处理效率。
尽管如此，一个核心难题仍未解决：如何融合两者之长——既保留数据湖的灵活与可扩展性，又具备数据仓库的性能与结构化能力。对此的回答，就是数据湖仓：一种统一架构，用以满足不断演进的现代数据管理需求。
本章将回顾这些系统的演进，以及它们的局限如何最终为数据湖仓铺平道路，并引出随之而来的创新——包括 Apache Iceberg，以及最终的 Apache Polaris。
数据仓库的世界
传统关系型数据库面向事务型（OLTP）工作负载设计，随着数据量增长，它们在分析查询的速度与效率上显得捉襟见肘。数据仓库应运而生，通过针对 OLAP（联机分析处理） 优化数据存储与查询执行，帮助组织更快速、有效地生成报表、运行 BI 工具并做出数据驱动决策。
数据仓库在架构上与 OLTP（联机事务处理） 系统有显著区别。OLTP 数据库为插入、更新、删除少量记录等短事务查询而优化，强调一致性与高并发下的小变更支持；而数据仓库专为 OLAP 场景打造，目标是分析海量历史数据，提取趋势、模式与洞察。因此，数据仓库更偏向批处理与复杂、读密集型跨大数据集的查询，而非处理单笔事务。
在底层实现上，数据仓库常采用列式存储，即按列而非按行组织数据（见图 1-1）。这让针对大数据集特定字段的查询更高效，因为只需将相关列载入内存。数据仓库也常使用反规范化与物化视图等技术，预先计算并存储汇总或聚合表，以加速分析查询。不同于强调频繁更新的 OLTP 系统，数据仓库通过减少复杂关联与分组操作来强化读取性能，从而更有效地承载复杂分析型工作负载。
图 1-1 行式与列式数据的差异
然而，随着数据体量与多样性不断提升，数据仓库的若干限制逐渐显露：
- 成本
在数据仓库中存放大量数据代价高昂，尤其当存储与高性能硬件绑定时更是如此。对于 TB 到 PB 级数据，将所有业务数据都放入仓库在经济上并不现实。 - 缺乏灵活性
数据仓库主要面向结构化数据（整齐的行列表格）。对于日志、多媒体、传感器等半结构化/非结构化数据，支持不足，而这类数据在现代业务分析中日益重要。 - 扩展难度
随着需要摄取与查询的数据增多，若无大幅硬件投入与精细调优，性能容易下降。此种刚性使其难以适应快速变化的业务需求。 - ETL 瓶颈
将数据写入仓库通常依赖 ETL（抽取-转换-加载） 流程，往往既耗时又易出错。必须先清洗、结构化并格式化数据才可入仓，导致从数据生成到可用于分析之间存在延迟。
数据仓库在其时代具有革命意义，解决了早期的诸多数据管理难题。但在一个产出更大规模、更高多样性数据的世界里，上述限制开始制约其效能。随着组织寻求更可扩展、更灵活的方案，数据湖时代开启，以更可负担的方式管理不断增长、形态各异的数据——不过它也带来了自己的权衡。下一节我们将继续探讨这些演进如何最终催生数据湖仓，并为 Apache Iceberg 与 Apache Polaris 等创新奠定基础。
迈向数据湖之路（Moving Forward with Data Lakes）
随着数据仓库在成本、可扩展性以及模式（schema）刚性方面的局限日益显现，组织需要一种更灵活、性价比更高的方式来应对不断增长的数据多样性与规模。这催生了数据湖：一种用于以原始形态（无论结构化、半结构化还是非结构化）存储海量数据的系统。2000 年代中期 Hadoop 的出现是关键创新，使得希望摆脱传统数据仓库约束、管理不断增长数据集的组织，能够以务实且可获得的方式落地数据湖。
Hadoop 作为开源框架，通过引入分布式存储系统与分布式计算引擎，革新了数据的存储与处理方式。组织可以将数据分布存放在由廉价通用硬件构成的集群上，与依赖昂贵、高性能硬件的数据仓库相比，巨量数据的存储成本被大幅降低。
Hadoop 的架构
从核心上看，Hadoop 由两个主要组件构成：Hadoop 分布式文件系统（HDFS） 与 MapReduce 处理框架。
HDFS（Hadoop Distributed File System）
HDFS 是高度可扩展的分布式文件系统，将数据拆分为数据块（通常为 128MB 或 256MB），并在集群中分布保存，同时通过冗余保障容错性。该架构允许组织通过横向扩展（向集群添加更多廉价服务器）来满足存储需求，从而解决数据仓库难以承受的存储成本问题。
MapReduce
MapReduce 是一种编程模型，通过将计算任务分发到 Hadoop 集群的多个节点，实现大规模数据处理。Map 阶段将数据处理为键值对，Reduce 阶段聚合这些结果生成最终输出。这种分布式计算方式使 Hadoop 能够并行处理 PB 级数据，高效完成分析。
随着生态的发展，诸多关键技术相继出现，弥补了 Hadoop 的一些早期不足，推动了数据湖成长：
- Apache Hive
首批重要进展之一，为 Hadoop 引入类 SQL 的查询接口。用户无需编写复杂的 MapReduce 作业即可在 HDFS 上查询大数据集，显著提升了可用性，尤其便利了习惯使用 SQL 的数据分析师。 - Hive Metastore
在 Hive 中承担元数据管理的核心角色，作为集中目录追踪 HDFS 中的数据表结构、分区、数据类型等信息。它为原本“无模式”的数据湖世界引入了更多结构与组织性，便于管理与查询海量数据集。 - Apache Spark
随着对更快、更灵活处理的需求增长，Spark 成为关键力量，提供内存计算引擎，相比 MapReduce 在多类分析工作负载上更快。Spark 不仅支持批处理，还支持实时流处理、机器学习与迭代计算，这些都是 MapReduce 的短板。Spark 能与 HDFS、Hive Metastore 无缝协作，同时提供更强大灵活的处理与分析工具集。
上述技术（Hive、Hive Metastore、Spark）共同塑造了现代数据湖：提升了可访问性、元数据治理与处理性能，使组织更容易释放大数据价值。然而，即便如此，管理与优化超大规模数据湖的复杂性仍是挑战。
数据湖的挑战
虽然数据湖解决了数据仓库在成本、灵活性、可扩展性方面的诸多问题，但也带来了自己的难题。与数据仓库的严格结构化环境不同，数据湖若治理不当，容易蜕变为“数据沼泽（data swamp） ”——难以管理、整理或高效查询的原始数据大池。缺乏结构导致以下问题：
- 数据治理不足
数据湖以原始数据为主，缺乏严格的模式约束，数据质量、一致性与治理难以维护。随着数据湖规模增长，确保数据可信可用愈发困难。 - 性能问题
尽管 Hadoop 的分布式架构让存储大数据变得经济，但分析查询性能经常落后于传统数据仓库。MapReduce 适合批处理，却并非为实时分析优化，限制了需要快速洞察的场景。 - 访问复杂
使用数据湖中的数据常常需要分布式计算与编程的专业技能。业务用户或数据分析师难以自助访问，导致数据湖中数据利用不足。
因此，尽管 Hadoop 与数据湖解决了传统数据仓库的关键限制（成本、灵活性、扩展性），上述挑战表明仍需进一步创新。随着组织持续演进，它们开始探索云上的解决方案：既保留数据湖的灵活与低成本存储，又具备数据仓库的性能与结构化能力。这引出了下一阶段的数据管理演进。
云端革命（The Cloud Revolution）
当组织面临数据管理规模与复杂度的持续攀升，迁移到云成为重大转折。数据仓库与数据湖在云上焕发新生，得益于可扩展、弹性的基础设施。云化解决了诸多本地（on-premise）系统的限制，带来前所未有的灵活性、更低的运维开销与成本效率。组织无需自购和维护昂贵硬件，而是按需存储与处理数据，按使用量计费。
- 云数据仓库
云厂商提供了全托管服务，如 Amazon Redshift、Google BigQuery、Snowflake，既提供传统数据仓库级别的性能，又具备云的弹性与可扩展性。计算与存储可独立扩展，既能承载大型分析查询，又避免为峰值过度预留资源；近乎无限的存储也缓解了本地仓库的核心成本忧虑。 - 云数据湖
在云上，组织可以以极低成本存储海量结构化、半结构化与非结构化数据。诸如 Amazon S3、Azure Data Lake Storage、Google Cloud Storage 提供高持久性、可扩展的存储与按量计费。云厂商还替组织承担了许多原本困扰本地 Hadoop 集群的运维挑战。云数据湖既能保存原始数据，又能叠加多样的处理框架（从 Spark 到 Dremio），拓展了使用场景。
尽管将数据仓库与数据湖迁至云端带来巨大收益，若干问题仍然存在。首要挑战之一是数据性能：云数据湖的存储成本虽低，但对海量数据的检索与处理仍可能偏慢，特别是在实时分析场景中。此外，缺乏标准化的数据组织与查询格式导致碎片化与低效；当数据以多种格式存放时，跨源查询就变得繁琐，而性能与优化尤为关键。
云端革命亟需一种同时优化存储效率与查询性能的数据格式：既能在云数据湖中原生工作，又能弥合数据湖的原始灵活性与数据仓库的高性能查询能力之间的鸿沟。
基于文件的分析与 Apache Parquet（File-Based Analytics with Apache Parquet）
Apache Parquet 的引入是数据湖发展的一个转折点，使其在大规模分析方面更具可行性。Parquet 是一种列式存储格式，专门用来解决当数据湖仍以 CSV、JSON 等不够面向分析的格式存放时在大数据集查询上遇到的性能难题。其高效的设计通过减少必读数据量来加速分析，从而兼顾查询性能与存储效率。
Apache Parquet 的工作原理
与传统行式存储（如 CSV、JSON）不同，Parquet 将数据按列存储。这意味着当查询只需访问数据集中的若干特定字段/列时，Parquet 只需读取这些相关列，而无需把整行加载进内存。对于经常在大数据集上跨多列聚合或过滤的分析型查询，这一点尤为有利。通过只读所需的数据，Parquet 显著降低了 I/O 开销与磁盘传输量，从而带来更快的查询与更低的存储成本。
Parquet 还采用多种技术以进一步提升性能并降低存储成本：
- 压缩（Compression）
原生支持多种压缩算法（如 Snappy、Gzip），相较未压缩格式大幅缩小数据体积；同时因需读取的数据字节数更少，也加速查询。 - 编码（Encoding）
采用游程长度编码（RLE） 、字典编码等高级编码技术，进一步压缩数据，并通过减少查询扫描的数据量来提升查询性能。 - 元数据与统计信息（Metadata and statistics）
为每一列存储元数据与最小/最大值统计信息，使查询引擎能够跳过无关的数据块。这种优化称为谓词下推（predicate pushdown） ，在对大型数据集进行过滤时可进一步减少所需 I/O。
得益于上述设计，Parquet 在数据湖场景中表现出色，显著提升了大规模读写与查询的效率（图 1-2 展示了 Parquet 格式的设计）。对于在云端数据湖中保存 PB 级数据的组织而言，Parquet 让分析变得更快、性价比更高，在一定程度上缩小了数据湖与传统数据仓库在性能上的差距。
图 1-2 Apache Parquet 文件的设计
多文件数据集的挑战
尽管 Apache Parquet 带来了显著的性能提升，但它并未解决数据湖中管理大型数据集的全部难题。即便使用 Parquet，数据湖的一个主要问题仍然是多文件数据集的复杂性。随着数据集不断增长，往往会被拆分成成千上万、甚至上百万个独立的 Parquet 文件。这种碎片化不利于高效地管理与查询。
例如，当向基于 Parquet 的数据集中追加新数据时，缺乏内置机制来将新文件与现有文件合并，或对数据集进行面向未来查询的优化。另外，大型数据湖数据集缺少事务层：进行更新、删除或并发写入时容易出现不一致。若没有对模式演进、数据版本化与原子事务的支持，多文件数据集的管理就会复杂且易出错。
这些挑战凸显出需要一个比 Parquet 文件更高一层的抽象：它应当把数据集当作一个整体而非一堆独立文件来管理。该抽象需要解决文件管理、模式约束与查询优化等问题，并提供事务保证，以支撑可靠的数据操作。
数据湖仓解决方案（The Data Lakehouse Solution）
当组织开始利用数据湖来存储海量原始数据时，很快就遇到一个关键难题：数据湖缺乏传统数据仓库所依赖的事务保证。如果不能可靠地管理数据更新、强制执行模式（schema）、或稳妥地处理并发写入，数据湖就无法提供与数据仓库同等的数据完整性与一致性。这一差距催生了创新契机——数据湖仓（Data Lakehouse） 概念由此而来。
数据湖仓架构旨在将数据湖的灵活存储与数据仓库的事务能力相结合：在数据湖之上叠加事务层。若数据湖也能提供数据仓库在复杂分析中赖以可信的 ACID（原子性、一致性、隔离性、持久性） 保证，组织就能同时获得原始数据存储与快速、可靠分析的能力。通过在 Apache Parquet 等文件格式之上构建事务层，数据湖仓使数据能够被像仓库中的表一样对待：以结构化、受 schema 驱动的接口供分析师、工程师和数据科学家放心使用。
数据湖仓的关键收益
让我们看看使用数据湖仓策略（在数据湖存储之上赋能）的核心价值，使数据湖更像数据仓库运行。
统一的数据存储（Unified data storage）
数据湖仓的首要价值在于可作为单一事实来源。组织无需再为原始数据（数据湖）与结构化、可查询数据（数据仓库）维护两套系统。借助湖仓，数据一次存储即可同时支持业务与分析，避免昂贵且耗时的多份拷贝。
ACID 事务（ACID transactions）
通过引入事务层，湖仓可确保写入、更新、删除等操作具备事务安全性。即便多用户或多进程并发访问，湖仓也能维持数据一致性，避免部分写入或数据集损坏等早期数据湖常见问题。
模式约束与演进（Schema enforcement and evolution）
湖仓可在表级强制执行 schema。它将 Parquet 等文件格式在文件级可实现的元数据跟踪，借助 Apache Iceberg 等表格式（table format） 扩展到多文件层面。不同于传统数据湖“随倒随存”的无结构方式，湖仓确保数据遵循既定 schema；同时支持schema 演进（如新增列），而不破坏既有管道或查询。
性能优化（Performance optimization）
借助事务层，湖仓可以进行传统数据湖无法实现的存取优化。例如，压缩合并（compaction） 将小文件合并为大文件以提升查询性能；数据裁剪（pruning） 在执行时自动排除无关数据，显著加速分析。湖仓表还维护数据文件清单，使查询可精准定位所需文件，避免代价高昂的文件列举，从而使准实时分析成为可能。
成本效率（Cost efficiency）
湖仓构建在分布式存储（对象存储或 HDFS）之上，保留了数据湖的低成本优势，同时减少维护独立且昂贵数据仓库的需求。统一架构抑制数据蔓延，消除跨系统复制。在本质上，湖仓以更低的存储成本提供近似仓库的性能收益。
同时支持流式与批处理（Streaming & batch）
湖仓可无缝处理实时流数据与批处理，从实时 BI 看板到历史分析皆可胜任，因而具备更广的适用性。
开放标准与灵活性（Open standards & flexibility）
湖仓基于 Parquet 等开放文件格式与开源框架，避免专有数据仓库方案常见的供应商锁定。这种开放架构允许组织选择多样工具与引擎（如 Spark、Presto、Dremio），而不被单一平台束缚。
前行之路：数据湖仓的表格式（Table Formats）
数据湖仓的核心在于：让湖中的数据具备与传统仓库同等的结构与可靠性。要达成这一点，仅有 Parquet 等文件格式还不够；必须有表格式在原始数据之上提供必要的抽象与事务保证。这些表格式带来湖仓在大规模落地所需的结构化控制与性能保障，使数据湖仓在实践中可用且高效。
表格式（Table Formats）的角色
随着组织采用数据湖仓架构，如何更好地管理、提速并提升大规模数据集的可靠性变得愈发重要。仅仅把数据以 Apache Parquet 这类高效格式存成文件，还不足以满足现代分析型工作负载对事务性、性能与模式（schema）的要求。这一缺口催生了表格式（table format） ：它们在原始文件之上增加一层抽象，把文件集合转化为可管理、可查询且具备事务保证的“表”。
表格式的优势（The Benefits of Table Formats）
表格式是释放数据湖仓全部潜能的关键，带来多项核心价值：
- ACID 事务
表格式确保 ACID 合规，安全处理复杂数据操作（如并发读写），避免数据损坏或部分更新。这正是传统数据湖所欠缺的能力。 - 模式约束与演进
使用表格式，用户既能强制执行 schema，又能随时间演进 schema。数据在写入前可按定义结构校验，保证一致性的同时，支持新增/删除/修改列等变更，而无需重写整张表。 - 数据版本化
表格式支持时光回溯（time travel） ，可查询数据集的历史版本，便于调试、审计与回滚。 - 高效查询性能
通过元数据管理、文件合并（compaction）与高级分区策略，表格式显著加速分析型查询。 - 分区管理
提供强大的分区机制，帮助引擎跳过无关数据，减少扫描量、提升性能。有些格式还引入分区演进（partition evolution） ，使分区能随时间变化而无需重构整个数据集。
现有表格式（Existing Table Formats）
为解决上述问题，业界涌现出多种表格式，各具优势与特性：
- Apache Iceberg
最初由 Netflix 开发，面向在数据湖中进行 PB 级高性能分析的强大表格式。提供强事务、schema 演进，并具备分区演进、隐藏分区等特性，是构建数据湖仓最灵活、可扩展的选项之一。 - Apache Hudi
由 Uber 创建，聚焦事务性更新与流数据。支持 ACID 与实时数据摄取，在增量处理与保障实时分析的数据新鲜度方面表现突出。 - Delta Lake
由 Databricks 开发，通过提供 ACID 事务与schema 约束来提升数据湖的可靠性与性能。虽起步于 Spark 工作负载，但凭借与 Databricks 平台的紧密集成而被广泛采用。 - Apache Paimon
前身为 Flink Table Store，与 Apache Flink 等流处理框架深度集成。同时支持流式与批处理，在实时、低延迟场景中十分强劲。
Apache Iceberg
Apache Iceberg 已成为数据湖仓架构中的基石。其灵活性、性能与开放治理促成了在数据生态中的广泛采用。推动 Iceberg 普及的因素包括：
- 广泛的生态支持（Broad ecosystem support）
Iceberg 天生工具无关，并已获得众多平台与工具的一等公民级支持，如 Dremio、Snowflake、AWS、Google Cloud、Upsolver 等。这种广泛采纳体现了其在不同环境下的通用性与可靠性，使其成为湖仓的首选方案。 - Databricks 收购 Tabular
作为重要行业事件，Databricks（Delta Lake 的创建者）收购了 Tabular。Tabular 由 Ryan Blue、Daniel Weeks、Jason Reid 创立，他们在 Netflix 期间创建并主导了 Iceberg 的研发。此次收购凸显了 Iceberg 影响力的持续上升。 - 透明、社区驱动（Transparent, community-driven project）
与部分由单一厂商强控的格式不同，Iceberg 以开源、社区驱动的方式运作：公开邮件列表、定期开发会议与多渠道的透明反馈。开放治理促成了跨行业协作，让不同组织共同参与并影响项目方向。 - 独特特性（Unique features）
分区演进允许在不重写整个数据集的情况下变更分区方案，解决大型数据湖中的常见难题；隐藏分区（hidden partitioning）屏蔽了分区管理的复杂性，带来更灵活高效的数据组织。这些创新让 Iceberg 在管理大规模、复杂数据集时既易用又适配性强。
凭借强事务保证、灵活的数据布局能力以及庞大的生态，Apache Iceberg 已成为现代数据湖仓中的常备选型。
什么是 Apache Iceberg？（What Is Apache Iceberg?）
Apache Iceberg 是一种现代的开源表格式（open table format） ，用于在数据湖中管理大规模数据集，同时提供类似传统数据仓库的功能与性能。Iceberg 引入了 ACID 事务、Schema 演进、时光回溯（time travel） 、分区演进（partition evolution） 等强大能力，使组织能够在长期演进中高效查询、管理并演化其数据。
Iceberg 的核心是元数据驱动（metadata-driven）架构，可实现快速而可靠的数据管理（见图 1-3）。该架构围绕数类关键元数据文件来追踪数据集状态，从而无缝处理查询、更新与删除等操作。
图 1-3 Apache Iceberg 表的结构（The Structure of an Apache Iceberg Table）
下面各节将拆解 Iceberg 的主要元数据文件类型，并解释它们在该格式中的角色。
元数据文件（metadata.json）
元数据文件（metadata.json） 是管理表整体状态的中心文件。可以将其视为 Iceberg 表的“大脑”，连接数据集的结构与历史。每张 Iceberg 表都有一个主元数据文件，用于追踪关键信息，包括：
- 表 Schema
表的结构：列名、数据类型，以及随时间发生的任何 schema 变更。 - 快照（Snapshots）
记录表的所有历史版本，支持时光回溯，可按过去任意时间点查询表。 - 当前快照（Current snapshot）
指向最新快照，代表表的当前状态。 - 分区（Partitioning）
表的分区策略与分区演进（随时间变化的分区方案）。 - 表属性（Table properties）
配置细节，如文件格式、压缩设置及其他与优化相关的参数。
每当表发生修改（如增删数据），该元数据文件都会更新，确保 Iceberg 对整个数据集保持准确、最新的视图。
清单列表（Manifest List）
清单列表（manifest list） 是更高一级的元数据文件，引用与表关联的所有清单文件（manifest files） 。它相当于 Iceberg 在决定为某个查询或操作应扫描哪些清单文件时所查阅的目录。借助此结构，Iceberg 仅扫描相关数据区域，从而高效管理大数据集。
通过清单列表，Iceberg 能快速定位包含某次查询所需数据的清单文件，进而减少从存储读取的数据量，在处理 PB 级数据集时显著提升查询性能并降低 I/O 成本。
清单文件（Manifest Files）
每个清单文件都包含一组**数据文件（data files）**的详细元数据，记录例如：
- 文件路径（File paths）
实际数据文件在存储系统（如对象存储或 HDFS）中的位置。 - 分区值（Partition values）
每个数据文件的分区信息，便于 Iceberg 执行分区裁剪（partition pruning） ，过滤无关分区以缩小查询范围。 - 文件统计（File statistics）
各列的最小/最大值等统计，用于谓词下推（predicate pushdown） ——在读取前先按条件过滤行，以提高查询效率。
清单文件是 Iceberg 能在超大规模数据集上扩展的关键：系统以组织化、优化的方式管理数据文件分组。将数据文件的元数据与数据本身分离，也使 Iceberg 支持分区演进——无需重写整个数据集即可调整分区方案。
数据文件（Data Files）
数据文件存放数据集中的实际记录。这些文件通常采用面向分析优化的列式格式，如 Apache Parquet 或 ORC。读取与写入过程中处理的即是这些原始数据文件，清单文件会引用它们。
Iceberg 屏蔽了底层文件管理的复杂性，用户通过高级表接口与数据集交互。当有新数据写入时，Iceberg 将其写入新的数据文件，并更新相关元数据，确保表的最新状态始终可见。数据文件是 Iceberg 通过其元数据层进行管理的核心存储单元，从而实现高效的数据操作。
删除文件（Delete Files）
删除文件（delete files） 是 Iceberg 用于跟踪行级删除的一类特殊文件。Iceberg 并不直接物理删除数据文件中的行，而是在独立的删除文件中记录删除标记，这些标记引用现有数据文件中的行，并将其标记为“已删除”。这种方式在删除频繁时显著降低了管理大数据集的成本与复杂度。
Iceberg 中有两类删除文件：
- 位置删除（Position deletes）
记录每条被删除行所在的数据文件路径与行位置。 - 等值删除（Equality deletes）
记录行级条件（例如 “删除customer_id = 123的行”），以表达哪些行应被视为已删除。
借助删除文件，Iceberg 可在查询时动态应用删除，而无需重写整个数据文件，从而保持快速查询性能。同时，这也支持 Iceberg 的时光回溯：既往版本的数据保持完好，删除可按需选择性地应用。
结语（Conclusion）
当代数据版图的特征在于：数据体量呈指数级增长、数据类型日益多样，以及对实时分析需求不断提高。传统架构（如数据湖与数据仓库）常因可扩展性受限或运维成本高而难以满足这些不断演进的要求。为应对这些挑战，采用湖仓架构——尤其是引入 Apache Iceberg ——已成为业界趋势。
Apache Iceberg 的架构为数据湖带来了全新的可控性与优化能力，将其真正升级为能够应对现代分析在规模、复杂度与性能方面需求的数据湖仓。通过引入一系列元数据文件——如 metadata.json、manifest list、manifest files 以及专门的 delete files——Iceberg 提供了 ACID 事务、Schema 演进与时光回溯（time travel） 等强大能力。借此，数据工程师与分析师可以高效操作海量数据集，而不必被成千上万底层数据文件的管理复杂度所淹没；同时也能在需要时轻松回滚到先前状态。
然而，随着组织规模化建设湖仓，集中化地追踪与组织不断增长的 Iceberg 表 变得至关重要：在分布式环境中管理每张表的元数据、快照与 schema 版本，需要一个健壮的系统充当所有表的中心目录（catalog） ，为全组织的数据基础设施提供可见性与治理。
在下一章中，我们将探讨 Iceberg Catalog 如何提供这一关键能力，帮助组织轻松管理其 Iceberg 表。无论部署在云端还是本地，Catalog 都能确保每张表可发现、受版本控制且可访问，并支持与多种查询引擎与数据工具的集成。有了 Catalog，Iceberg 才真正成为现代、可扩展且高效的数据湖仓架构的中坚。
