揭秘分布式文件系统大规模元数据管理机制——以Alluxio文件系统为例

刺骨的言语ヽ痛彻心扉 2023-10-15 19:10 38阅读 0赞

> **作者主页**：[Designer 小郑][Designer]  
> **作者简介**：3年JAVA全栈开发经验，专注JAVA技术、系统定制、远程指导，致力于企业数字化转型，CSDN博客专家，蓝桥云课认证讲师。

#### 目录 ####

*  一、前言
 *  二、什么是分布式文件系统
 *  三、分布式文件系统元数据的常见类型
 *   *  3.1 文件（inode）元数据
     *  3.2 数据块（block）元数据
     *  3.3 MountTable
     *  3.4 Worker元数据
 *  四、分布式文件系统元数据的存储模式
 *   *  4.1 元数据存储在堆上（HEAP模式）
     *  4.2 元数据存储在堆外（ROCKS模式）
     *  4.3 堆外存储的内存和磁盘占用
     *  4.4 对堆外存储的缓存加速和调优
     *  4.5 在HEAP和ROCKS模式间切换

--------------------

## 一、前言 ##

当今，我们的世界已经进入一个数据时代。随着互联网、物联网、5G、大数据、人工智能、自动驾驶、元宇宙等信息技术的快速发展，人们在产生、收集、存储、治理和分析的数据的总量呈快速增长的趋势。形态多样、格式复杂、规模庞大、产生迅速的行业领域大规模数据驱动了底层新型基础支撑计算支撑技术的快速变革。通过过去10多年来工业界和学术界先行者的指引和实践，分布式并行计算和分布式数据存储的技术生态不断演进、丰富繁荣。其中，分布式数据存储管理在这个海量数据处理技术栈中处于基础地位，是众多行业大数据应用分析的基石。

## 二、什么是分布式文件系统 ##

分布式文件系统是从高性能计算到大数据计算时代一直广为应用的主流分布式数据存储管理系统。近些年随着云计算技术的持续发展，分布式对象存储存储、键值存储等技术的应用也开始大行其道。在这个背景下，很多分布式文件系统开始走上对数据存储进行统一高效管理的技术路线。其中，被用户知晓和普遍应该的一款系统是诞生于加州大学伯克利分校的AMPLab的Alluxio，它可以被看作一种统一化大数据虚拟文件系统，不同种类的分布式存储系统（文件系统、对象存储系统）都可以挂载到Alluxio目录中，对提供提供高效统一的访问模式和接口。元数据是一个存储系统中关于数据信息最为重要、正常访问最为频繁的一类关键信息。为了有效地管理来自底层不同分布式存储系统的大规模数据文件和对象，Alluxio需要提供一种高效可扩展的大规模元数据管理机制。

本文以开源版本的Alluxio 2.8为例，揭秘分布式文件系统中常见的大规模元数据管理机制。对Alluxio用户而言，用户通过文件元信息和Alluxio文件系统接口进行互动，通过数据块元信息来读写数据和缓存。文件和数据块元信息由Alluxio Master统一存储和管理。

## 三、分布式文件系统元数据的常见类型 ##

Alluxio Master管理的元数据中，最重要的是文件元数据、数据块元数据、挂载点元数据和Alluxio Worker元数据几类。

### 3.1 文件（inode）元数据 ###

Alluxio文件系统中的每一个文件或文件夹都由一个inode代表，这个inode存储着这个文件所有的属性和元信息，包括文件基本属性、权限信息、管理属性、时间戳、包含的数据块及每一个数据块的元数据等。“inode”这一概念来源于Unix类型的文件系统，在Linux和HDFS等文件系统中被广泛使用，一个inode代表着文件系统目录树上的一个节点。因为Alluxio管理着多个底层存储，所以Alluxio命名空间中的潜在文件数量实际上是所有底层存储中文件的总和。元数据服务作为Alluxio集群中最重要的服务，直接决定了系统的规模、性能和稳定性。值得一提的是，Alluxio文件系统中的inode不一定在底层存储中存在。例如，如果这个路径是用MUST\_CACHE方式写入Alluxio，那么Alluxio并不会在底层存储中创建这个文件。此外，如果底层存储是一个对象存储，因为对象存储没有文件夹的概念，所以Alluxio中的文件夹并不会在底层存储中对应实际存在的对象。

总体来说，Alluxio Master对inode的管理可以抽象地分为以下几类：

*  使用一个InodeTree存储所有的inode信息及inode之间的树状结构（文件夹和文件之间的父子关系），Alluxio Master维护着文件系统的树状结构。
 *  实现文件系统操作的接口并支持所有对文件的操作。Alluxio Master开放了一系列文件系统操作接口，并且对每一个操作提供了并发安全和持久化保证，通过这样的方式向上层应用提供了一个分布式文件系统。
 *  通过Journal日志维护一个持久化的状态，保证每一个inode操作的持久性和原子性。Alluxio Master通过保证inode信息和每一个操作记录在Journal日志中，从而保障在任何情况下inode信息和更改都不会丢失。
 *  Alluxio的InodeTree通过将锁粒度精细到每一个inode，支持inode级别的读写并发访问。对每一个inode通过锁进行并发控制，保证在并发读写中inode的线程安全。

### 3.2 数据块（block）元数据 ###

如果inode对应一个文件，则它有0个（空文件）或多个数据块。对一个新建文件而言，所有数据块大小都由 alluxio.user.block.size.bytes.default 设置，只有最后一个数据块除外。只有1个数据块的文件也算作是最后一个数据块。数据块的元信息管理相对inode而言比较简单，因为数据块之间不具有树状的结构或者亲子关系。

Alluxio Master保存着数据块的元信息以及数据块缓存的当前位置，并对外提供了对这些信息的读写接口。Alluxio Master管理的数据块元数据可以简要地被看作两个键值存储：

（1）<BlockID, BlockMetadata>

（2）<BlockID, List>

其中，BlockMetadata记录了数据块的长度。BlockLocation记录了这个数据块（缓存）存在的Alluxio Worker节点地址，和这个数据块在Alluxio Worker节点上的具体存储位置。

这两个不同的信息被分开存储主要是因为它们的生命周期不同。Block Metadata是不变的（Immutable）。Alluxio不支持对已经写完的数据块进行随机更改或追加。如果这个文件被重写，它会得到新的FileID（即InodeID）和新的BlockID，旧的数据块会被舍弃。相反，BlockLocation列表是会不断变化的，比如当这个数据块被加载进一个新的Alluxio Worker，或者被从某一个Alluxio Worker上驱逐之后，这个列表信息都会对应地改变。

### 3.3 MountTable ###

MountTable管理着所有Alluxio文件系统中的挂载点，提供了诸如挂载点的创建和更改操作。同时Alluxio文件路径和底层存储的文件路径也通过MountTable互相解析对应。

### 3.4 Worker元数据 ###

Alluxio Master对Alluxio Worker元数据的管理包括了追踪当前有哪些正在工作的Alluxio Worker，并且不断更新Alluxio Worker上的缓存列表。Alluxio Master记录的信息主要包括：

（1）Alluxio Worker的地址、启动时间等不变信息。

（2）Alluxio Worker的空间使用情况，包括多层缓存中每层的使用量，随每次心跳更新。

（3）Alluxio Worker中被缓存的所有BlockID和将要从Alluxio Worker中移除的所有BlockID。这些信息随着每一次心跳和数据块操作（加载、驱逐等）而改变。

## 四、分布式文件系统元数据的存储模式 ##

分布式文件系统的元数据存储通常包括堆上存储和堆外存储两种。其中，堆上存储访问高效，但是空间有限，而堆外存储空间大，但如果设计不当会造成性能损失。

### 4.1 元数据存储在堆上（HEAP模式） ###

以Alluxio为例，在HEAP模式下，所有元信息都以Java对象的形式存储在JVM的堆中。每一个文件在堆上的内存占用大约为2KB4KB。因此，当Alluxio文件系统中有大量的文件时，堆上元信息将会给JVM带来大量内存压力。不难算出，系统中有1亿文件时，JVM上仅仅是存储这些文件的元信息就会占用200GB400GB。加上Master JVM必须承担的大量RPC操作内存开销，这个JVM对内存的需求是普通服务器很难承受的。

此外，对大部分JVM版本而言，如此数据规模下的GC会变得非常难以管理。Alluxio Master JVM中的这些元信息都是长久存在的对象，尤其会给老年代的GC效率带来很大的影响。尽管有一些商业版JVM可以避免部分或大部分JVM带来的性能和管理问题，但是对大多数用户来说，JVM占用过多还是一个十分棘手的痛点，尤其是Alluxio Master 的JVM可能在未来随着业务扩展可能超出物理机内存的上限。

### 4.2 元数据存储在堆外（ROCKS模式） ###

针对HEAP模式难以扩展的问题，Alluxio优化了设计方向。Alluxio 在2.0版本中引入了ROCKS模式，将元信息存储挪到了JVM之外。在ROCKS模式下，Alluxio Master内嵌了一个RocksDB，将文件（和数据块）的元信息从之前的JVM堆上挪到了RocksDB中，而RocksDB的存储介质实际是硬盘而非内存。使用RocksDB存储元数据只需要配置元数据存储模式并指定RocksDB存储的路径：

alluxio.master.metastore=ROCKS
    alluxio.master.metastore.dir=${
        alluxio.work.dir}/metastore

Alluxio内嵌的RocksDB会使用 alluxio.master.metastore.dir 配置的路径作为自己的元数据存储。以下示例中，我们查看一个运行中的Alluxio集群的RocksDB存储，可以见到Alluxio在RocksDB中保存的Inode和Block元数据各有一个存储目录，并维护了由RocksDB管理的数据文件。RocksDB的存储目录结构在本书中不做赘述，读者可以查看RocksDB的官方文档。

$ ls -al -R metastore/
    metastore/:
    
    total 8
    drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:20 blocks
    drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:33 inodes
    
    metastore/blocks:
    total 4264
    -rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 000005.log
    -rw-r--r--. 1 alluxio-user alluxio-group    16 May 21 03:20 CURRENT
    -rw-r--r--. 1 alluxio-user alluxio-group    36 May 21 03:20 IDENTITY
    -rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 LOCK
    -rw-r--r--. 1 alluxio-user alluxio-group 52837 May 21 03:30 LOG
    -rw-r--r--. 1 alluxio-user alluxio-group   176 May 21 03:20 MANIFEST-000004
    -rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000009
    -rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000011
    
    metastore/inodes:
    
    total 4268
    -rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 000005.log
    -rw-r--r--. 1 alluxio-user alluxio-group  1211 May 21 03:33 000012.sst
    -rw-r--r--. 1 alluxio-user alluxio-group    16 May 21 03:20 CURRENT
    -rw-r--r--. 1 alluxio-user alluxio-group    36 May 21 03:20 IDENTITY
    -rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 LOCK
    -rw-r--r--. 1 alluxio-user alluxio-group 58083 May 21 03:33 LOG
    -rw-r--r--. 1 alluxio-user alluxio-group   247 May 21 03:33 MANIFEST-000004
    -rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-000009
    -rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-000011

### 4.3 堆外存储的内存和磁盘占用 ###

在ROCKS模式下，元信息被存储在堆外的RocksDB中，这样会极大地降低元信息存储对Alluxio Master进程的内存压力。与HEAP模式相比，所有的元信息读写从内存速度降低到了硬盘速度，这将会很大程度上影响Alluxio Master的性能和吞吐量。因此Alluxio Master在内存中加入了一个缓存来加速对RocksDB的访问。换言之，在ROCKS模式下，元信息存储的内存占用变成了这部分缓存的内存占用。与HEAP模式下的内存占用估算类似，缓存中每一个文件的元信息存储占用同样的2KB~4KB。

缓存的大小由 alluxio.master.metastore.inode.cache.max.size 控制。这个配置项的值根据Alluxio版本可能有所不同。Alluxio Master会先写入缓存，当缓存达到一定使用量之后才开始写入RocksDB（磁盘）。RocksDB的磁盘占用情况如下：大约100万个文件的元信息占用约4GB的硬盘空间。值得注意的是，当Alluxio命名空间内文件数量未触发基于 alluxio.master.metastore.inode.cache.max.size 的驱逐时，所有文件元信息都在基于内存的缓存内，未写入RocksDB，此时这些文件的元信息磁盘占用接近于0。

### 4.4 对堆外存储的缓存加速和调优 ###

当内存空间充足时，适当调大 alluxio.master.metastore.inode.cache.max.size 可以将更多文件元信息缓存在内存中来提升性能。同时需注意，Alluxio Master上的RPC操作也会消耗内存。即使没有进行中的RPC操作，Alluxio Master上仍然会有一些定期的文件扫描等内部管理逻辑会消耗内存。在估算Alluxio Master进程中内存时，需要一定要预留足够内存给这些操作，不要让元信息存储占用了所有的内存。这和在服务器上不能把100%的内存都分配给应用而不给操作系统预留内存空间的道理是一样的。元信息缓存的管理是基于水位机制的，用户配置一个高水位参数和一个低水位参数，比如以下是默认配置：

alluxio.master.metastore.inode.cache.high.water.mark.ratio=0.85
    alluxio.master.metastore.inode.cache.low.water.mark.ratio=0.8

在缓存使用达到 0.85 \* alluxio.master.metastore.inode.cache.max.size时，缓存数据会开始驱逐，将缓存中的数据内容写入RocksDB存储。在缓存占用率降低到0.8时停止驱逐。

### 4.5 在HEAP和ROCKS模式间切换 ###

使用HEAP模式和ROCKS模式下Journal日志的格式不同，因此从一种模式切换到另一种不能通过简单的更改配置并重启Alluxio Master进程来完成。元数据存储模式的切换可以通过从备份中启动集群完成，见4.5章节。

本文以Alluxio为例，简要介绍了分布式文件系统的元数据基本类型及其管理和优化方法，更多的数据访问优化细节可以进一步参考查阅Alluxio开源社区代码，也欢迎阅读最近机械工业出版社出版的技术书籍《分布式统一大数据虚拟文件系统——Alluxio原理、技术与实践》：

![在这里插入图片描述][5568a895adf64ca7b177545f744e8572.png_pic_center]

> 本书以广泛使用的Alluxio 2.8.0开源版本为基础编写，深入介绍Alluxio相关分布式统一大数据文件系统的技术原理与实践案例，主要内容包括系统入门与使用、内核组件设计实现原理，同时详细介绍了大型企业应用案例与实践，并附有Alluxio的开源社区开发者指南。本书为Alluxio开源社区用户、高校大数据系统课程师生以及潜在企业用户提供了较为完整的技术指南和实用教程，既可作为大数据专业方向的专业教材，也可作为大数据从业者和研究者的重要专业资料。

![在这里插入图片描述][c0c29d27f7d44ce5b8bcbaf976fcc854.jpeg_pic_center]

--------------------

![在这里插入图片描述][3a01dc60e62c415b812015851343f1c0.png_pic_center]

[Designer]: https://blog.csdn.net/qq_41464123
[5568a895adf64ca7b177545f744e8572.png_pic_center]: https://img-blog.csdnimg.cn/5568a895adf64ca7b177545f744e8572.png#pic_center
[c0c29d27f7d44ce5b8bcbaf976fcc854.jpeg_pic_center]: https://img-blog.csdnimg.cn/c0c29d27f7d44ce5b8bcbaf976fcc854.jpeg#pic_center
[3a01dc60e62c415b812015851343f1c0.png_pic_center]: https://img-blog.csdnimg.cn/3a01dc60e62c415b812015851343f1c0.png#pic_center