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

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
对象存储 OSS,20GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 揭秘分布式文件系统大规模元数据管理机制——以Alluxio文件系统为例

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


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


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

01 分布式文件系统元数据的常见类型

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

文件(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的线程安全。

数据块(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上驱逐之后,这个列表信息都会对应地改变。

MountTable

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


Worker元数据

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


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


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


(3)Alluxio Worker中被缓存的所有BlockID和将要从Alluxio

Worker中移除的所有BlockID。这些信息随着每一次心跳和数据块操作(加载、驱逐等)而改变。

02 分布式文件系统元数据的存储模式

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

2.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可能在未来随着业务扩展可能超出物理机内存的上限。

2.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

2.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。

2.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时停止驱逐。


2.5在HEAP和ROCKS模式间切换

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

相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
相关文章
|
5月前
|
NoSQL Java Redis
实现基于Redis的分布式锁机制
实现基于Redis的分布式锁机制
|
2月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
82 3
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现
消息队列系统中的确认机制在分布式系统中如何实现
|
6月前
|
消息中间件 NoSQL Java
Redis系列学习文章分享---第六篇(Redis实战篇--Redis分布式锁+实现思路+误删问题+原子性+lua脚本+Redisson功能介绍+可重入锁+WatchDog机制+multiLock)
Redis系列学习文章分享---第六篇(Redis实战篇--Redis分布式锁+实现思路+误删问题+原子性+lua脚本+Redisson功能介绍+可重入锁+WatchDog机制+multiLock)
236 0
|
7月前
|
关系型数据库 分布式数据库 数据库
【PolarDB开源】PolarDB-X源码解读:分布式事务处理机制揭秘
【5月更文挑战第20天】PolarDB-X,PolarDB家族的一员,专注于大规模分布式事务处理,采用2PC协议保证ACID特性。源码解析揭示其通过预提交、一致性快照隔离和乐观锁优化事务性能,以及利用事务日志进行故障恢复。深入理解其事务处理机制对开发者掌握分布式数据库核心技术至关重要。随着开源社区的发展,更多优化方案将涌现,助力构建更强大的分布式数据库系统。
229 6
|
2月前
|
消息中间件 存储 监控
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
4月前
|
机器学习/深度学习 分布式计算 PyTorch
大规模数据集管理:DataLoader在分布式环境中的应用
【8月更文第29天】随着大数据时代的到来,如何高效地处理和利用大规模数据集成为了许多领域面临的关键挑战之一。本文将探讨如何在分布式环境中使用`DataLoader`来优化大规模数据集的管理与加载过程,并通过具体的代码示例展示其实现方法。
230 1
|
4月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
4月前
|
消息中间件 Java Kafka
如何在Kafka分布式环境中保证消息的顺序消费?深入剖析Kafka机制,带你一探究竟!
【8月更文挑战第24天】Apache Kafka是一款专为实时数据管道和流处理设计的分布式平台,以其高效的消息发布与订阅功能著称。在分布式环境中确保消息按序消费颇具挑战。本文首先介绍了Kafka通过Topic分区实现消息排序的基本机制,随后详细阐述了几种保证消息顺序性的策略,包括使用单分区Topic、消费者组搭配单分区消费、幂等性生产者以及事务支持等技术手段。最后,通过一个Java示例演示了如何利用Kafka消费者确保消息按序消费的具体实现过程。
160 3

热门文章

最新文章