【Iceberg学习五】Iceberg中性能和可靠性保证_iceberg查询性能

Performance

性能

1. Iceberg 旨在处理巨大的表格，在生产环境中使用，单个表格可以包含数十PB（拍字节）的数据。
2. 即使是多PB级别的表格，也可以从单个节点读取，无需依赖分布式SQL引擎来筛查表格元数据。

扫描计划

扫描计划是找到查询所需表中文件的过程。

在Iceberg表中的计划可以在单个节点上完成，因为Iceberg的元数据可以用来剪除不需要的元数据文件，除了过滤不包含匹配数据的数据文件。

从单个节点快速扫描计划使得：

1. 低延迟SQL查询 – 通过消除分布式扫描来规划分布式扫描
2. 任何客户端访问 – 独立进程可以直接从Iceberg表读取数据

元数据过滤

Iceberg使用两级元数据来跟踪快照中的文件。

1. 清单文件 存储数据文件列表，以及每个数据文件的分区数据和列级统计信息
2. 清单列表存储快照的清单列表，以及每个分区字段的值范围
   为了快速扫描计划，Iceberg首先使用清单列表中的分区值范围来过滤清单。然后，它读取每个清单以获取数据文件。有了这个方案，清单列表就像是对清单文件的索引，使得无需读取所有清单就可以进行计划。

除了分区值范围，清单列表还存储了清单中添加或删除的文件数量，以加速操作，如快照过期。

数据过滤

清单文件为每个数据文件包括一组分区数据和列级统计信息。

在计划期间，查询谓词会自动转换为分区数据上的谓词，并首先应用于过滤数据文件。接下来，使用列级值计数、空值计数、下界和上界来排除不能匹配查询谓词的文件。

通过在计划时使用上下界过滤数据文件，Iceberg使用集群数据来消除不运行任务的分片。在某些情况下，这是10倍的性能提升。

Reliability（可靠性）

Iceberg 被设计用来解决在 S3 上运行的 Hive 表面临的正确性问题。

Hive 表通过一个中心元数据存储来跟踪分区，并通过文件系统来跟踪单个文件。这使得对表内容进行原子性更改成为不可能，并且像 S3 这样最终一致性的存储可能会由于使用文件列表来重建表状态而返回不正确的结果。这同样要求作业规划时进行许多缓慢的列表调用：与分区数量成 O(n) 关系。

Iceberg 通过一个持久的树状结构来跟踪每个快照中的完整数据文件列表。每次写入或删除都会产生一个新的快照，尽可能多地重用前一个快照的元数据树，以避免高写入量。

Iceberg 表中的有效快照存储在表元数据文件中，同时附有对当前快照的引用。提交操作通过原子操作替换当前表元数据文件的路径。这确保了对表数据和元数据的所有更新都是原子性的，这是可串行化隔离性的基础。

这带来了更可靠的保证：

可串行化隔离性：所有表更改都发生在原子表更新的线性历史中
可靠读取：读取器始终使用表的一致快照，无需持有锁
版本历史和回滚：表快照作为历史保留，如果作业生成了错误数据，表可以回滚
安全的文件级操作：通过支持原子更改，Iceberg支持新的用例，比如安全地压缩小文件和安全地将延迟数据追加到表中
这种设计也有性能上的好处：

计划时 O(1) 的 RPC 调用：与列出表中 O(n) 个目录来规划作业不同，读取快照只需要 O(1) 的 RPC 调用
分布式规划：文件修剪和谓词下推分布到作业中，移除了元数据存储作为瓶颈
更细粒度的分区：分布式规划和 O(1) 的 RPC 调用消除了当前对更细粒度分区的障碍

并发写操作

Iceberg 支持使用乐观并发来进行多个并发写入。

每个写入器假设没有其他写入器在操作，并为一个操作写出新的表元数据。然后，写入器尝试通过原子性地交换新的表元数据文件和现有的元数据文件来提交。

如果因为另一个写入器已经提交而导致原子交换失败，失败的写入器会通过基于新的当前表状态写出一个新的元数据树来重试。

重试的成本

写入器通过构建变更来避免昂贵的重试操作，以便在重试中可以重用工作。

例如，追加通常会为追加的数据文件创建一个新的清单文件，这个清单文件可以在每次尝试时不重写清单的情况下添加到表中。

重试验证

提交被构建为假设和行动。在冲突后，写入器检查当前表状态是否满足假设。如果满足假设，那么重新应用行动并提交是安全的。

例如，压缩可能会将 file_a.avro 和 file_b.avro 重写为 merged.parquet。只要表中仍然包含 file_a.avro 和 file_b.avro，就可以安全地提交。如果任一文件被冲突提交删除，则操作必须失败。否则，可以安全地移除源文件并添加合并后的文件。

兼容性

通过避免文件列表和重命名操作，Iceberg 表与任何对象存储兼容。不需要一致的列表。

Schemas

Iceberg tables support the following types: