Apache Iceberg 社区发布了1.4.0版本，其中包含了很多改进。在本文中，我将重点介绍一些改进，这些改进将使数据从业者的工作更加轻松。
核心改进
让我们从核心库开始。首先，这个版本修改了一些默认值，其中最重要的是默认的表格格式。表现在默认使用format v2。
format v2 格式规范采用于两年多前，即2021年8月初，现在得到了广泛支持。虽然老客户端在理论上可能缺乏支持，但是使用2年前的引擎版本的用户并不多。此外，v2已经是一些查询引擎(如 Trino)的默认版本。如果您选择创建 format-version 属性设置为1的表，那么仍然可以使用 v1，而且这不会影响现有的表。
升级到 v2有两个动机。在 v2中修复了一些不再需要变通方法的元数据问题，比如需要占位符来删除分区字段。此外，v 2增加了对行级删除文件的支持，可用于减少写入放大。Spark 的行级 命令 MERGE 和 UPDATE中的 MERGE-ON-READ策略会使用这些删除文件。某些引擎不支持在读取时合并删除文件，但是使用删除文件是一种可选的性能改进。在从 MERGE 生成文件之前，确保所有读取器都支持删除文件(默认情况下，Spark 使用copy-on-write)。
压缩编解码器的默认值从 gzip 更改为了 zstd。为每个表单独选择压缩编解码器和级别可以得到最好的结果，但是 zstd 是一个很好的默认选项。在 table 中，我们发现 zstd 经常(尽管不总是)被我们的表分析师选中，并且在具有相同读取性能的情况下具有更好的压缩率。
该版本还对 IO 和目录进行了一些值得注意的增强。现在使用 AzureFileIO 可以直接支持 ADLS。FileIO 是比文件系统更简单的抽象，因此更直接的支持有效避免了处理目录逻辑等不必要请求的开销。
最后，对 REST 协议进行了扩展，以支持多表提交。新endpoint 允许发送一组表的需求和更改，而不仅仅是一个表。这是支持多表事务所需的前提之一，一旦这些事务得到完全支持，就可以使用多表提交来协调对多个表的操作。例如，它现在支持跨多个表的写-审计-发布模式，方法是在分支中暂存更新，然后同时将所有表的主分支快速转换到最新状态。
Spark updates
这个版本还包括对 Spark 的一些重大更新。Spark 社区几周前发布了3.5版本，Iceberg 1.4中包含了对 Spark 3.5的支持。随着3.5的添加，社区已经移除 Spark 3.1，该支持版本是2年前发布的，不再得到 Spark 社区的支持。同时Spark 3.2已被标记为不推荐使用。
Spark 3.5带来了一些改进，使数据工程师的工作更加轻松。第一个是一个新的接口，它让 Iceberg 在编写数据时请求更优的任务资源。以前，自适应查询执行(adaptive query execution，AQE)在中间阶段使用相同的任务大小并默认写入ーー64 MB ーー尽管一旦编码和压缩后，写入 Parquet 的数据往往要小得多。因此，即使启用了 AQE，Spark 也会产生小文件。现在，目标任务大小(或 Spark 中的“advisory partition size”)可以由数据源连接器设置，因此 Iceberg 将请求更大的任务，以避免创建太多的小文件。
总的来说，我们认为这是正确的方法。但是，您可能会有一些任务比较大，写入需要更多的时间。在大多数情况下，您不必担心，因为首先能正常地写入数据至关重要。如果需要，您可以通过在表属性中设置write.spark.advisory-partition-size-bytes来设置每个表的目标大小。
3.5中的另一个主要变化是 Iceberg 的行级命令(比如 MERGE INTO)被移到了 Spark 自身。这对两个项目都是有利的。Spark 没有 MERGE 和 UPDATE 的实现，现在其他数据源可以利用写时复制和读时合并计划。对于 Iceberg 来说，这意味着随着 Spark 的更改，实现会保持更新，这将使得集成新的 Spark 版本更快。
除了支持 Spark 3.5之外，1.4版本还增加了一些性能改进:
写入未排序的表将跳过本地排序，并且速度更快。Iceberg 以前需要进行本地排序，以确保数据按照分区进行聚类。在 Spark 支持为传入数据请求分发之前，任务可以接收任何分区的数据。通过为每个分区保留一个打开的 Parquet 文件，这很容易耗尽内存。现在，Iceberg将请求一个避免大量打开文件的分发，这样就不再需要添加昂贵的本地排序。
扫描非常大的表可以在 Spark 集群中分布式规划。在非常大的表中，元数据变的臃肿。通常，Iceberg 可以使用元数据索引来跳过读取大多数元数据，并快速计划表扫描。但是元数据集群并不总是与扫描模式保持一致。对于这些情况，分布式规划可以利用 Spark 来并行化元数据读取，从而提高查询速度。
任务大小将进行调整，以最大限度地提高小型查询的并行性。很小的查询有时会因为使用几个大的Task而不是小的Task而产生相关瓶颈。当一个查询可以由几百MB满足时，集群可能会有多余的空闲容量，因为只有很少的任务。在1.4中，Iceberg将尝试检测何时存在过剩产能，并重新平衡工作以利用这一优势。
最后，新版本还支持函数下推，因此使用使用 Iceberg 函数(如 bucket (16，id) = 0)的过滤器的查询将被下推，并且可以直接选择 Iceberg 分区。
接下来呢？
在1.4中还有更多内容我不能在这里介绍，所以请查看 Releases 页面以获得更多信息。
接下来，社区正在努力开发1.5版本！
公共视图 API 已经到达main分支，在内存目录中有一个测试实现。我们还将为 REST 协议添加视图支持，并致力于 Spark 集成。
此外，最近关于表加密的工作预计将在1.5中完成。这将包括使用 AES GCM 加密流的元数据加密和数据文件的原生Parquet加密。
END
看到这里记得关注、点赞、转发 一键三连哦~
精彩回顾：
Amoro Mixed Format 上海钢联的构建实时湖仓实践
