本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据技术体系

Apache Iceberg 是一种用于庞大分析数据集的开放表格式。

表格式（Table Format）的功能是确定该如何管理、组织和跟踪构成表的所有文件。可以将其视为物理数据文件（用 Parquet 或 ORC 等编写）以及它们如何结构形成表之间的抽象层。

Iceberg 使用类似于 SQL 表的高性能表格式为计算引擎添加了表，包括 Spark、Trino、PrestoDB、Flink、Hive 和 Impala。

使用快照模式意味着 Iceberg 可以保证读写的隔离性。

读者将始终看到数据的一致版本（即没有“脏读”），而无需锁表。

写入器单独工作，不影响实时表，并且仅在写入完成时执行元数据交换，在一个原子提交中进行更改。

使用快照还可以启用时间旅行操作，因为用户可以通过指定要使用的快照对表的不同版本执行各种操作。

使用 Iceberg 也有巨大的性能优势。

在作业规划期间，Iceberg 并没有采用 O(n) 的时间复杂度来列出表中的分区，而是执行时间复杂度是 O(1) 的 RPC 来读取快照。

文件修剪和谓词下推也可以分发到作业中，因此 Hive 元存储不再是一个瓶颈。

这也消除了使用细粒度分区的障碍。

由于每个数据文件存储的统计数据，可用的文件修剪也大大加快了查询规划。

Iceberg 是因庞大数据表而诞生的。

生产环境中 Iceberg 单表可以包含几十 PB 的数据，即使在没有分布式 SQL 引擎的情况下这些大表也可以读取。

Iceberg 旨在解决最终一致的云对象存储中的正确性问题。

Iceberg 项目最初是在 Netflix 开发的，旨在解决他们使用庞大的 PB 规模表的长期问题。

它于 2018 年作为 Apache 孵化器项目开源，并于 2020 年 5 月 19 日从孵化器毕业 🎉

Iceberg 一开始就被设计用于云端，一个关键考虑因素是解决 Hive 在与位于 S3 中的数据一起使用时遇到的各种数据一致性和性能问题。

Hive 在“文件夹”级别（即非文件级别）跟踪数据，因此在处理表中的数据时需要执行文件列表（file list）操作。

当需要执行其中许多操作时，这可能会导致性能问题。

当文件列表操作在 S3 等最终一致的对象存储中执行文件列表操作时，数据也可能丢失。

Iceberg 通过使用持久树结构跟踪表中所有文件的完整列表来避免这种情况。

对表的更改使用原子的对象/文件级别的提交，将路径更新为包含一个新元数据文件，包含所有独立数据文件的位置。

Iceberg 跟踪单个文件而不是文件夹的另一个优势是，不再需要昂贵的列表操作，这导致在执行查询表中数据等操作时性能的提高。

表状态存储在许多不同的元数据文件中，这些文件如上图所示，并在下面更详细地描述：