??????點(diǎn)擊直達(dá)福利

??????點(diǎn)擊直達(dá)福利

前言

當(dāng)今，我們的世界已經(jīng)進(jìn)入一個(gè)數(shù)據(jù)時(shí)代。隨著互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、5G、大數(shù)據(jù)、人工智能、自動(dòng)駕駛、元宇宙等信息技術(shù)的快速發(fā)展，人們?cè)诋a(chǎn)生、收集、存儲(chǔ)、治理和分析的數(shù)據(jù)的總量呈快速增長(zhǎng)的趨勢(shì)。形態(tài)多樣、格式復(fù)雜、規(guī)模龐大、產(chǎn)生迅速的行業(yè)領(lǐng)域大規(guī)模數(shù)據(jù)驅(qū)動(dòng)了底層新型基礎(chǔ)支撐計(jì)算支撐技術(shù)的快速變革。通過過去10多年來工業(yè)界和學(xué)術(shù)界先行者的指引和實(shí)踐，分布式并行計(jì)算和分布式數(shù)據(jù)存儲(chǔ)的技術(shù)生態(tài)不斷演進(jìn)、豐富繁榮。其中，分布式數(shù)據(jù)存儲(chǔ)管理在這個(gè)海量數(shù)據(jù)處理技術(shù)棧中處于基礎(chǔ)地位，是眾多行業(yè)大數(shù)據(jù)應(yīng)用分析的基石。

分布式文件系統(tǒng)是從高性能計(jì)算到大數(shù)據(jù)計(jì)算時(shí)代一直廣為應(yīng)用的主流分布式數(shù)據(jù)存儲(chǔ)管理系統(tǒng)。近些年隨著云計(jì)算技術(shù)的持續(xù)發(fā)展，分布式對(duì)象存儲(chǔ)存儲(chǔ)、鍵值存儲(chǔ)等技術(shù)的應(yīng)用也開始大行其道。在這個(gè)背景下，很多分布式文件系統(tǒng)開始走上對(duì)數(shù)據(jù)存儲(chǔ)進(jìn)行統(tǒng)一高效管理的技術(shù)路線。其中，被用戶知曉和普遍應(yīng)該的一款系統(tǒng)是誕生于加州大學(xué)伯克利分校的AMPLab的Alluxio，它可以被看作一種統(tǒng)一化大數(shù)據(jù)虛擬文件系統(tǒng)，不同種類的分布式存儲(chǔ)系統(tǒng)（文件系統(tǒng)、對(duì)象存儲(chǔ)系統(tǒng)）都可以掛載到Alluxio目錄中，對(duì)提供提供高效統(tǒng)一的訪問模式和接口。元數(shù)據(jù)是一個(gè)存儲(chǔ)系統(tǒng)中關(guān)于數(shù)據(jù)信息最為重要、正常訪問最為頻繁的一類關(guān)鍵信息。為了有效地管理來自底層不同分布式存儲(chǔ)系統(tǒng)的大規(guī)模數(shù)據(jù)文件和對(duì)象，Alluxio需要提供一種高效可擴(kuò)展的大規(guī)模元數(shù)據(jù)管理機(jī)制。

本文以開源版本的Alluxio 2.8為例，揭秘分布式文件系統(tǒng)中常見的大規(guī)模元數(shù)據(jù)管理機(jī)制。對(duì)Alluxio用戶而言，用戶通過文件元信息和Alluxio文件系統(tǒng)接口進(jìn)行互動(dòng)，通過數(shù)據(jù)塊元信息來讀寫數(shù)據(jù)和緩存。文件和數(shù)據(jù)塊元信息由Alluxio Master統(tǒng)一存儲(chǔ)和管理。

一、分布式文件系統(tǒng)元數(shù)據(jù)的常見類型

Alluxio Master管理的元數(shù)據(jù)中，最重要的是文件元數(shù)據(jù)、數(shù)據(jù)塊元數(shù)據(jù)、掛載點(diǎn)元數(shù)據(jù)和Alluxio Worker元數(shù)據(jù)幾類。

1.1 文件（inode）元數(shù)據(jù)

Alluxio文件系統(tǒng)中的每一個(gè)文件或文件夾都由一個(gè)inode代表，這個(gè)inode存儲(chǔ)著這個(gè)文件所有的屬性和元信息，包括文件基本屬性、權(quán)限信息、管理屬性、時(shí)間戳、包含的數(shù)據(jù)塊及每一個(gè)數(shù)據(jù)塊的元數(shù)據(jù)等?！癷node”這一概念來源于Unix類型的文件系統(tǒng)，在Linux和HDFS等文件系統(tǒng)中被廣泛使用，一個(gè)inode代表著文件系統(tǒng)目錄樹上的一個(gè)節(jié)點(diǎn)。因?yàn)锳lluxio管理著多個(gè)底層存儲(chǔ)，所以Alluxio命名空間中的潛在文件數(shù)量實(shí)際上是所有底層存儲(chǔ)中文件的總和。元數(shù)據(jù)服務(wù)作為Alluxio集群中最重要的服務(wù)，直接決定了系統(tǒng)的規(guī)模、性能和穩(wěn)定性。值得一提的是，Alluxio文件系統(tǒng)中的inode不一定在底層存儲(chǔ)中存在。例如，如果這個(gè)路徑是用MUST_CACHE方式寫入Alluxio，那么Alluxio并不會(huì)在底層存儲(chǔ)中創(chuàng)建這個(gè)文件。此外，如果底層存儲(chǔ)是一個(gè)對(duì)象存儲(chǔ)，因?yàn)閷?duì)象存儲(chǔ)沒有文件夾的概念，所以Alluxio中的文件夾并不會(huì)在底層存儲(chǔ)中對(duì)應(yīng)實(shí)際存在的對(duì)象。

總體來說，Alluxio Master對(duì)inode的管理可以抽象地分為以下幾類：

• 使用一個(gè)InodeTree存儲(chǔ)所有的inode信息及inode之間的樹狀結(jié)構(gòu)（文件夾和文件之間的父子關(guān)系），Alluxio Master維護(hù)著文件系統(tǒng)的樹狀結(jié)構(gòu)。

• 實(shí)現(xiàn)文件系統(tǒng)操作的接口并支持所有對(duì)文件的操作。Alluxio Master開放了一系列文件系統(tǒng)操作接口，并且對(duì)每一個(gè)操作提供了并發(fā)安全和持久化保證，通過這樣的方式向上層應(yīng)用提供了一個(gè)分布式文件系統(tǒng)。

• 通過Journal日志維護(hù)一個(gè)持久化的狀態(tài)，保證每一個(gè)inode操作的持久性和原子性。Alluxio Master通過保證inode信息和每一個(gè)操作記錄在Journal日志中，從而保障在任何情況下inode信息和更改都不會(huì)丟失。

• Alluxio的InodeTree通過將鎖粒度精細(xì)到每一個(gè)inode，支持inode級(jí)別的讀寫并發(fā)訪問。對(duì)每一個(gè)inode通過鎖進(jìn)行并發(fā)控制，保證在并發(fā)讀寫中inode的線程安全。

1.2數(shù)據(jù)塊（block）元數(shù)據(jù)

如果inode對(duì)應(yīng)一個(gè)文件，則它有0個(gè)（空文件）或多個(gè)數(shù)據(jù)塊。對(duì)一個(gè)新建文件而言，所有數(shù)據(jù)塊大小都由 alluxio.user.block.size.bytes.default 設(shè)置，只有最后一個(gè)數(shù)據(jù)塊除外。只有1個(gè)數(shù)據(jù)塊的文件也算作是最后一個(gè)數(shù)據(jù)塊。數(shù)據(jù)塊的元信息管理相對(duì)inode而言比較簡(jiǎn)單，因?yàn)閿?shù)據(jù)塊之間不具有樹狀的結(jié)構(gòu)或者親子關(guān)系。

Alluxio Master保存著數(shù)據(jù)塊的元信息以及數(shù)據(jù)塊緩存的當(dāng)前位置，并對(duì)外提供了對(duì)這些信息的讀寫接口。Alluxio Master管理的數(shù)據(jù)塊元數(shù)據(jù)可以簡(jiǎn)要地被看作兩個(gè)鍵值存儲(chǔ)：

• （1）<BlockID, BlockMetadata>
• （2）<BlockID, List>
  其中，BlockMetadata記錄了數(shù)據(jù)塊的長(zhǎng)度。BlockLocation記錄了這個(gè)數(shù)據(jù)塊（緩存）存在的Alluxio Worker節(jié)點(diǎn)地址，和這個(gè)數(shù)據(jù)塊在Alluxio Worker節(jié)點(diǎn)上的具體存儲(chǔ)位置。

這兩個(gè)不同的信息被分開存儲(chǔ)主要是因?yàn)樗鼈兊纳芷诓煌?。Block Metadata是不變的（Immutable）。Alluxio不支持對(duì)已經(jīng)寫完的數(shù)據(jù)塊進(jìn)行隨機(jī)更改或追加。如果這個(gè)文件被重寫，它會(huì)得到新的FileID（即InodeID）和新的BlockID，舊的數(shù)據(jù)塊會(huì)被舍棄。相反，BlockLocation列表是會(huì)不斷變化的，比如當(dāng)這個(gè)數(shù)據(jù)塊被加載進(jìn)一個(gè)新的Alluxio Worker，或者被從某一個(gè)Alluxio Worker上驅(qū)逐之后，這個(gè)列表信息都會(huì)對(duì)應(yīng)地改變。

1.3 MountTable

MountTable管理著所有Alluxio文件系統(tǒng)中的掛載點(diǎn)，提供了諸如掛載點(diǎn)的創(chuàng)建和更改操作。同時(shí)Alluxio文件路徑和底層存儲(chǔ)的文件路徑也通過MountTable互相解析對(duì)應(yīng)。

1.4 Worker元數(shù)據(jù)

Alluxio Master對(duì)Alluxio Worker元數(shù)據(jù)的管理包括了追蹤當(dāng)前有哪些正在工作的Alluxio Worker，并且不斷更新Alluxio Worker上的緩存列表。Alluxio Master記錄的信息主要包括：

（1）Alluxio Worker的地址、啟動(dòng)時(shí)間等不變信息。

（2）Alluxio Worker的空間使用情況，包括多層緩存中每層的使用量，隨每次心跳更新。

（3）Alluxio Worker中被緩存的所有BlockID和將要從Alluxio Worker中移除的所有BlockID。這些信息隨著每一次心跳和數(shù)據(jù)塊操作（加載、驅(qū)逐等）而改變。

二、分布式文件系統(tǒng)元數(shù)據(jù)的存儲(chǔ)模式

分布式文件系統(tǒng)的元數(shù)據(jù)存儲(chǔ)通常包括堆上存儲(chǔ)和堆外存儲(chǔ)兩種。其中，堆上存儲(chǔ)訪問高效，但是空間有限，而堆外存儲(chǔ)空間大，但如果設(shè)計(jì)不當(dāng)會(huì)造成性能損失。

2.1 元數(shù)據(jù)存儲(chǔ)在堆上（HEAP模式）

以Alluxio為例，在HEAP模式下，所有元信息都以Java對(duì)象的形式存儲(chǔ)在JVM的堆中。每一個(gè)文件在堆上的內(nèi)存占用大約為2KB_{4KB。因此，當(dāng)Alluxio文件系統(tǒng)中有大量的文件時(shí)，堆上元信息將會(huì)給JVM帶來大量?jī)?nèi)存壓力。不難算出，系統(tǒng)中有1億文件時(shí)，JVM上僅僅是存儲(chǔ)這些文件的元信息就會(huì)占用200GB}400GB。加上Master JVM必須承擔(dān)的大量RPC操作內(nèi)存開銷，這個(gè)JVM對(duì)內(nèi)存的需求是普通服務(wù)器很難承受的。

此外，對(duì)大部分JVM版本而言，如此數(shù)據(jù)規(guī)模下的GC會(huì)變得非常難以管理。Alluxio Master JVM中的這些元信息都是長(zhǎng)久存在的對(duì)象，尤其會(huì)給老年代的GC效率帶來很大的影響。盡管有一些商業(yè)版JVM可以避免部分或大部分JVM帶來的性能和管理問題，但是對(duì)大多數(shù)用戶來說，JVM占用過多還是一個(gè)十分棘手的痛點(diǎn)，尤其是Alluxio Master 的JVM可能在未來隨著業(yè)務(wù)擴(kuò)展可能超出物理機(jī)內(nèi)存的上限。

2.2 元數(shù)據(jù)存儲(chǔ)在堆外（ROCKS模式）

針對(duì)HEAP模式難以擴(kuò)展的問題，Alluxio優(yōu)化了設(shè)計(jì)方向。Alluxio 在2.0版本中引入了ROCKS模式，將元信息存儲(chǔ)挪到了JVM之外。在ROCKS模式下，Alluxio Master內(nèi)嵌了一個(gè)RocksDB，將文件（和數(shù)據(jù)塊）的元信息從之前的JVM堆上挪到了RocksDB中，而RocksDB的存儲(chǔ)介質(zhì)實(shí)際是硬盤而非內(nèi)存。使用RocksDB存儲(chǔ)元數(shù)據(jù)只需要配置元數(shù)據(jù)存儲(chǔ)模式并指定RocksDB存儲(chǔ)的路徑：

alluxio.master.metastore=ROCKS

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

Alluxio內(nèi)嵌的RocksDB會(huì)使用 alluxio.master.metastore.dir 配置的路徑作為自己的元數(shù)據(jù)存儲(chǔ)。以下示例中，我們查看一個(gè)運(yùn)行中的Alluxio集群的RocksDB存儲(chǔ)，可以見到Alluxio在RocksDB中保存的Inode和Block元數(shù)據(jù)各有一個(gè)存儲(chǔ)目錄，并維護(hù)了由RocksDB管理的數(shù)據(jù)文件。RocksDB的存儲(chǔ)目錄結(jié)構(gòu)在本書中不做贅述，讀者可以查看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 堆外存儲(chǔ)的內(nèi)存和磁盤占用

在ROCKS模式下，元信息被存儲(chǔ)在堆外的RocksDB中，這樣會(huì)極大地降低元信息存儲(chǔ)對(duì)Alluxio Master進(jìn)程的內(nèi)存壓力。與HEAP模式相比，所有的元信息讀寫從內(nèi)存速度降低到了硬盤速度，這將會(huì)很大程度上影響Alluxio Master的性能和吞吐量。因此Alluxio Master在內(nèi)存中加入了一個(gè)緩存來加速對(duì)RocksDB的訪問。換言之，在ROCKS模式下，元信息存儲(chǔ)的內(nèi)存占用變成了這部分緩存的內(nèi)存占用。與HEAP模式下的內(nèi)存占用估算類似，緩存中每一個(gè)文件的元信息存儲(chǔ)占用同樣的2KB~4KB。

緩存的大小由 alluxio.master.metastore.inode.cache.max.size 控制。這個(gè)配置項(xiàng)的值根據(jù)Alluxio版本可能有所不同。Alluxio Master會(huì)先寫入緩存，當(dāng)緩存達(dá)到一定使用量之后才開始寫入RocksDB（磁盤）。RocksDB的磁盤占用情況如下：大約100萬個(gè)文件的元信息占用約4GB的硬盤空間。值得注意的是，當(dāng)Alluxio命名空間內(nèi)文件數(shù)量未觸發(fā)基于 alluxio.master.metastore.inode.cache.max.size 的驅(qū)逐時(shí)，所有文件元信息都在基于內(nèi)存的緩存內(nèi)，未寫入RocksDB，此時(shí)這些文件的元信息磁盤占用接近于0。

2.4 對(duì)堆外存儲(chǔ)的緩存加速和調(diào)優(yōu)

當(dāng)內(nèi)存空間充足時(shí)，適當(dāng)調(diào)大 alluxio.master.metastore.inode.cache.max.size 可以將更多文件元信息緩存在內(nèi)存中來提升性能。同時(shí)需注意，Alluxio Master上的RPC操作也會(huì)消耗內(nèi)存。即使沒有進(jìn)行中的RPC操作，Alluxio Master上仍然會(huì)有一些定期的文件掃描等內(nèi)部管理邏輯會(huì)消耗內(nèi)存。在估算Alluxio Master進(jìn)程中內(nèi)存時(shí)，需要一定要預(yù)留足夠內(nèi)存給這些操作，不要讓元信息存儲(chǔ)占用了所有的內(nèi)存。這和在服務(wù)器上不能把100%的內(nèi)存都分配給應(yīng)用而不給操作系統(tǒng)預(yù)留內(nèi)存空間的道理是一樣的。元信息緩存的管理是基于水位機(jī)制的，用戶配置一個(gè)高水位參數(shù)和一個(gè)低水位參數(shù)，比如以下是默認(rèn)配置：

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

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

在緩存使用達(dá)到 0.85 * alluxio.master.metastore.inode.cache.max.size時(shí)，緩存數(shù)據(jù)會(huì)開始驅(qū)逐，將緩存中的數(shù)據(jù)內(nèi)容寫入RocksDB存儲(chǔ)。在緩存占用率降低到0.8時(shí)停止驅(qū)逐。

2.5 在HEAP和ROCKS模式間切換

使用HEAP模式和ROCKS模式下Journal日志的格式不同，因此從一種模式切換到另一種不能通過簡(jiǎn)單的更改配置并重啟Alluxio Master進(jìn)程來完成。元數(shù)據(jù)存儲(chǔ)模式的切換可以通過從備份中啟動(dòng)集群完成，見4.5章節(jié)。

三、書籍介紹：《分布式統(tǒng)一大數(shù)據(jù)虛擬文件系統(tǒng)——Alluxio原理、技術(shù)與實(shí)踐》

本書以廣泛使用的Alluxio 2.8.0開源版本為基礎(chǔ)編寫，深入介紹Alluxio相關(guān)分布式統(tǒng)一大數(shù)據(jù)文件系統(tǒng)的技術(shù)原理與實(shí)踐案例，主要內(nèi)容包括系統(tǒng)入門與使用、內(nèi)核組件設(shè)計(jì)實(shí)現(xiàn)原理，同時(shí)詳細(xì)介紹了大型企業(yè)應(yīng)用案例與實(shí)踐，并附有Alluxio的開源社區(qū)開發(fā)者指南。本書為Alluxio開源社區(qū)用戶、高校大數(shù)據(jù)系統(tǒng)課程師生以及潛在企業(yè)用戶提供了較為完整的技術(shù)指南和實(shí)用教程，既可作為大數(shù)據(jù)專業(yè)方向的專業(yè)教材，也可作為大數(shù)據(jù)從業(yè)者和研究者的重要專業(yè)資料。

四、??文末福利（切記關(guān)注+三連，否則抽獎(jiǎng)無效）

• ??本次送書1~5本【取決于閱讀量，閱讀量越多，送的越多】??
• ??活動(dòng)時(shí)間：截止到2023-09-22 10:00
• ??參與方式： 關(guān)注博主+三連（點(diǎn)贊、收藏、評(píng)論）

??有特別想要的朋友，還可以額外關(guān)注同名公眾號(hào)，發(fā)送內(nèi)容格式：自己的CSDN的ID+參與第四期送書【如：qq_40332045參與第四期送書】，可以增加抽獎(jiǎng)權(quán)重（前提是本文要關(guān)注+三連，否則參與無效）文章來源地址http://www.zghlxwxcb.cn/news/detail-707976.html

• ???? 抽獎(jiǎng)方式： 評(píng)論區(qū)隨機(jī)抽取小伙伴免費(fèi)送出??！

到了這里，關(guān)于【程序猿包郵送書：第四期】《分布式統(tǒng)一大數(shù)據(jù)虛擬文件系統(tǒng)——Alluxio原理、技術(shù)與實(shí)踐》的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！