Arctic 自动优化湖仓原理解析

背景

数据湖与数据仓库都是常见的大数据存储系统。得益于其低廉的成本优势，数据湖一般用来存储海量的原始数据。原始数据经过清洗、标准化后会再导入到数据仓库中进行数据分析。数据在两个系统间流转无疑增加了额外的存储与维护开销。

近年来随着 Apache lceberg、Apache Hudi、Delta Lake 等数据湖表格式技术的不断发展使得直接在数据湖上构建一套统一的存储系统来满足所有的大数据存储需求成为可能。业界将这种直接建立在数据湖之上，却能同时覆盖数据湖与数据仓库存储场景的架构为湖仓一体（LakeHouse）。

然而开源表格式距离生产可用的湖仓一体架构还有着较大的鸿沟，在这个背景下网易在 2022 年开源了湖仓管理系统——Arctic。Arctic 是一个开放式架构下的湖仓管理系统，在开放的数据湖格式之上，Arctic 提供更多面向流和更新场景的优化，以及一套可插拔的数据自优化机制和管理服务。基于 Arctic 可以帮助各类数据平台，工具和产品快速搭建开箱即用，流批统一的湖仓。

要构建一套开箱即用的湖仓系统，自动优化是第一个需要解决的需求。现在大部分开源的数据湖表格式都要求用户投入大量的精力来维护数据湖表中的文件结构，稍不留神表的查询性能就可能出现较大的下滑。

湖仓优化的需求与难点

湖仓上有两类常见的优化需求：文件合并与文件清理。文件合并可分为以下场景：

• 合并碎片文件：数据写入时受限于本次写入的数据量和写入并发，很难保证每个写入文件都达到用户预期的大小。特别的在实时场景下为了降低湖仓中数据的延迟，需要频繁地提交新文件，这无疑将会带来大量的碎片文件。过多的碎片文件会造成元数据膨胀，进一步降低湖仓表的读取性能，故及时地合并碎片文件到用户的预期大小对湖仓表的性能至关重要。

• 合并变更文件：现代的湖仓表格式通常都有行级更新的能力，而实现行级更新的一般方法是将更新操作写入到单独的变更文件里，这样能快速完成数据变更。但随着变更文件越来越多，在读取表中数据时用于合并变更文件与数据文件的资源也越来越多，而这个变化一般成指数级上升，故用户也需要及时合并变更文件到数据文件中。

常见的文件清理场景包括：

• 清理过期文件：表中被删除的文件现在一般不会被立即删除掉以应对用户查询历史数据的需求，而过期了的历史文件则需要文件清理流程来处理。

• 清理垃圾文件：写入失败的任务可能遗留下一些不再需要的垃圾文件，这些文件同样需要文件清理流程来应对。

Apache lceberg 通过在 Spark 引擎内提供了丰富的存储过程来应对文件合并与文件清理的优化需求。不过在实际使用时需要用户来判断何时需要进行优化、使用什么样的优化参数，并保证优化任务能正确完成工作。这无疑增大了用户的使用成本。

Apache Hudi 则提供在写入任务里同时运行优化任务，与使用另一个独立任务来完成优化的方式。前者可能造成写入任务与优化任务互相影响的问题。后者则需要为每个表维护一个长期运行的优化任务，任务多了将难以管