Use protobuf to FSImage

本篇是一篇译文,主要介绍下FSImage改进为protobuf的设计原理,原文地址

背景

为了能从故障中快速恢复,HDFS会周期性的将内存中的namespace在磁盘上的文件系统中进行持久化。FSImage的性能和扩展性在保证数据的耐用性和可用性上至关重要。随着越来越多的高级功能被引入HDFS中,FSImage已经从一个简单的blob演变为了一个需要存储在磁盘的复杂的数据结构。FSImage有3个方面需要改进:

  • 效率
    在生成环境中,我们观察到持久化到磁盘的FSImage大小能达到二三十GB。因为加载和停机时保存FSImage是NameNode的关键环节,其效率对确保NameNode操作的可用性非常重要。
  • 兼容性
    FSImage将随着HDFS的各种功能的不断发展和演变。FSImage的实现将能够被各种不同的版本所使用,这在某些功能下非常重要,比如滚动升级。
  • 互通性
    FSImage能被第三方工具访问的需求越来越强烈了。例如某个工具可以通过扫描FSImage收集一些统计信息。因此FSImage应该提供一个使第三方工具能与其进行交互的清晰规范。

当前FSImage模块有大约2500行代码,但是现在的设计与实现并不能解决上面的需求。首先,对于兼容性而言,当前代码中的一些实现并不理想。例如有些属性比如inode IDs和block IDs被编码为了固定长度的整数而不是变长整数。

其次,代码依赖与分支上的不同布局版本以保持向后兼容。在代码更新时在修改和测试上需要耗费很大的精力。然而,还不支持向前兼容,这使NameNode降级变的很困难

再次,FSImage的格式仅由代码的具体实现而决定。如果没有正式的FSImage规范,开发人员构建第三方工具时,只能通过offline image viewer来构建,这种方式时低效的而且还容易出错。

为了解决上面的挑战,我们提议使用Google的Protocol Buffers协议来定义一种新的FSImage格式。Protocol Buffers是可扩展的,与语言无关的,用于序列化结构数据。Protobuf能解决上面的挑战。首先,Protocol使用一个编译器为序列化和反序列化生成高效的代码。其次,它还支持向前和向后兼容。序列化后的每个属性都包含一个唯一的标签,因此反序列化的代码可以同时处理新加的字段和缺失的字段。最后,Protocol Buffers的源码直接定义了FSImage的格式。第三方工具仅根据protocol文件就能知道FSImage的格式。

HDFS-5698是关于FSImage新格式的issues。下面的内容介绍了设计的细节,新格式的一些实验参数,未来的方向和结论。

设计

下图是新FSImage格式的EBNF语法描述。整个FSImage包括4部分,分别为MAGIC、SECTION、FileSummary和FileSummaryLength,其中SECTION包含N个。
FSImage格式

FSImage将数据分成不同的部分。每部分在数据中都是相互独立的。开发人员可以添加新的部分来扩展FSImage。

FileSummary模块包含4个属性,分别为ondiskVersion、layoutVersion、codec和sections,其中sections中记录了每个section的名字、长度和偏移量。所有的section可以使用指定的codec对其进行压缩。每个section都是单独压缩的,而且section中记录的长度和偏移量都是压缩之后的,因此当读取的时候可以直接通过响应的偏移量而直接定位到某个section。

当解析FSImage时,先从文件的末尾读取4bytes,读取的4bytes数据记录了FileSummary模块的长度,通过解析FileSummary模块能得到所有section的位置信息,这样设计允许写入时按顺序保留FSImage。

序列化inode

FSImage将inode序列化为两种section。INodeSection记录了每个inode(包括INodeFile和INodeDirectory)的信息,INodeDirectorySection记录了每个目录的子inodes。这种将inodes当作图而不是树的设计模式有两个优点,第一与实际的图更加匹配,因此当快照存在时,inode不用再形成树。不同的目录能通过INodeReference对象指向同一个inode。第二它将结构扁平化,从而为并行性提供了机会。每个inode都独立的存储在FSImage中,因此可以并行的解析和构建不同的inodes。

在protobuf的规范中,INodeSection并不包含inode列表,而是在INodeSection随后的protobuf消息中隐式的指定了inode列表。这样做的原因时Protocol Buffers在生成代码的时候需要将所有的属性加载到内存,然而inodes列表可能太大而不能加载到内存。文中的这种设计允许FSImage以递增的方式解析。

令人惊讶的是,我们的初始分析结果表明序列化权限是代码中的瓶颈。权限是一个元组,包含用户名,组名和表示权限位的16位整数。简单的解决方案是直接序列化两个名称和16位整数。 但是,我们发现FSImage中的名称是高度冗余的,反序列化为Java的String对象需要大量的CPU时间。为了优化此用例,FSImage将名称映射为24位ID,以便可以使用64位整数表示权限。

实验

为了评估新FSImage的性能,我们比较了新旧格式的FSImage文件的大小,和持久化和加载FSImage所需要的时间。我们将生产中使用的FSImage缩放到五种不同的尺寸,以评估具有各种尺度集群的性能。所有的测试都运行在相同的机器上。

图2比较了新旧FSImage的大小。FSImage都是未压缩的。由图中所知新格式的FSImage能够节省6-13%的磁盘空间。
图2

图3展示了新旧FSImage加载和持久化的处理时间,也都是未压缩的。新FSImage有着较好的写性能。
图3

新FSImage读比旧FSImage所耗的时间长,大约为1.5x-2.3x。分析结果表明,解析字节和构造为protocol buffers生成的对象占用大部分时间。 旧格式的代码读取数据并直接构造HDFS中使用的对象,这不会受到这种类型的开销的影响。

未来工作

并行化

新FSImage的设计格式为并行加载提供了机会。新的FSImage单独存储每个inode,因此可以并行的解析数据和重构inode。同样,新FSImage也可以并行的填充不同目录的子节点。

重建BlockMap占用CPU时间的大约为20%。在新的FSImage格式下,可以将BlockMap的工作负载转移到单独的线程中,从而隐藏延迟。

直接构建对象

新的FSImage需要首先通过Protocol Buffers生成的对象,然后根据生成的对象构造HDFS中使用的对象。实验结果显示构造生成的对象需要大量时间。 可以手动解析Protocol Buffers并直接构造对象,从而消除了开销。

结论

FSImage的性能和可靠性对于提供HDFS的耐用性和可用性非常重要。本文描述了一种基于Protocol Buffers的新FSImage格式。新格式满足了FSImage的效率,兼容性和互操作性要求。 我们希望新格式可以促进HDFS的创新。

您的肯定,是我装逼的最大的动力!