神武八荒一颗小说,小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

關(guān)于Alluxio中元數(shù)據(jù)同步的設(shè)計(jì)、實(shí)現(xiàn)和優(yōu)化

???

創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括澤州網(wǎng)站建設(shè)、澤州網(wǎng)站制作、澤州網(wǎng)頁(yè)制作以及澤州網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，澤州網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到澤州省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

元數(shù)據(jù)同步是Alluxio的重要特性。這篇文章描述了設(shè)計(jì)、實(shí)現(xiàn)和其他內(nèi)部流程，用以調(diào)整性能。

元數(shù)據(jù)同步(sync)是Alluxio中的核心功能，它使文件和目錄與所在存儲(chǔ)系統(tǒng)下真實(shí)的來(lái)源保持一致，進(jìn)而使用戶能夠輕松地從Alluxio中檢索出最新版的數(shù)據(jù)。同時(shí)了解內(nèi)部流程對(duì)調(diào)整性能也非常重要。本文介紹了Alluxio中保持元數(shù)據(jù)同步的設(shè)計(jì)和實(shí)現(xiàn)。

元數(shù)據(jù)同步為什么在Alluxio中很重要

在Alluxio中，元數(shù)據(jù)指的是Alluxio文件系統(tǒng)中文件和目錄的信息，包括它們的所有者、組、權(quán)限、創(chuàng)建以及修改時(shí)間等信息。元數(shù)據(jù)獨(dú)立于其內(nèi)容——即使文件或目錄是空的，但它仍然具有關(guān)聯(lián)的元數(shù)據(jù)。

Alluxio維護(hù)文件系統(tǒng)或底層存儲(chǔ)系統(tǒng)的對(duì)象存儲(chǔ)命名空間的副本。在Alluxio中，元數(shù)據(jù)一致性很重要，尤其是不同集群在數(shù)據(jù)管道中寫入或讀取數(shù)據(jù)后，并在Alluxio之外進(jìn)行更改時(shí)。

???

在上圖中是一個(gè)典型的場(chǎng)景，結(jié)合了Spark ETL和Presto SQL的數(shù)據(jù)管道。ETL集群(不帶Alluxio)寫入數(shù)據(jù)，然后是分析集群，Alluxio讀取轉(zhuǎn)換后的數(shù)據(jù)。因?yàn)锳lluxio維護(hù)了底層存儲(chǔ)的元數(shù)據(jù)副本并管理元數(shù)據(jù)，因此當(dāng)?shù)讓哟鎯?chǔ)中的數(shù)據(jù)通過(guò)ETL步驟發(fā)生變化時(shí)，必須使分析群集上的Alluxio實(shí)例感知到并與底層存儲(chǔ)系統(tǒng)中的元數(shù)據(jù)保持一致以便正確操作。

在Alluxio中元數(shù)據(jù)同步是如何工作的

Alluxio在一個(gè)或多個(gè)底層存儲(chǔ)系統(tǒng)上的統(tǒng)一命名空間中提供了文件系統(tǒng)抽象。通過(guò)Alluxio訪問(wèn)文件或目錄，會(huì)得到和直接訪問(wèn)under storage一樣的結(jié)果。比如如果掛載到Alluxio根目錄的底層存儲(chǔ)是s3://bucket/data，那么在Alluxio中列出“/”目錄與在s3://bucket/data中列出對(duì)象并在其中打印“/file”產(chǎn)生相同的結(jié)果應(yīng)該返回與s3://bucket/data/file一樣的結(jié)果。

在Alluxio中元數(shù)據(jù)只從Alluxio master中存儲(chǔ)和提供，但單個(gè)文件的內(nèi)容則由Alluxio worker提供。

默認(rèn)情況下，Alluxio根據(jù)需要從底層存儲(chǔ)加載元數(shù)據(jù)。在上面的例子中，一個(gè)從空開(kāi)始的Alluxio master在啟動(dòng)后沒(méi)有任何關(guān)于s3://bucket/data/file的信息。僅當(dāng)某些用戶在Alluxio中列出“/”目錄或嘗試訪問(wèn)“/file”時(shí)才會(huì)識(shí)別此文件。這種“惰性”行為可以防止不必要的工作并能顯著提高性能，因?yàn)榈讓哟鎯?chǔ)中的元數(shù)據(jù)操作可能很慢。

注意，更新元數(shù)據(jù)可以是雙向的。如果對(duì)文件系統(tǒng)的所有修改都是通過(guò)Alluxio發(fā)生，那么Alluxio只需要掃描一次under storage即可檢索初始狀態(tài)，然后作為文件系統(tǒng)RPC調(diào)用的一部分同步應(yīng)用Alluxio和under storage中的更改。這將為用戶提供一致的存儲(chǔ)不足視圖。然而實(shí)際上Alluxio之外的存儲(chǔ)不足經(jīng)常發(fā)生變化，因此Alluxio master必須監(jiān)控對(duì)under storage中文件和方向的添加、刪除和更新，并將更改應(yīng)用到Alluxio文件系統(tǒng)中。這個(gè)同步兩個(gè)命名空間的過(guò)程稱為元數(shù)據(jù)同步。

如何觸發(fā)元數(shù)據(jù)同步

當(dāng)應(yīng)用程序更改了 Alluxio 文件的元數(shù)據(jù)并且該文件被持久化時(shí)，更改將始終同步傳播到底層存儲(chǔ)無(wú)需觸發(fā)元數(shù)據(jù)同步。當(dāng)應(yīng)用程序在存儲(chǔ)文件下更新而不讓 Alluxio 知道時(shí)，有兩種方法可以控制元數(shù)據(jù)同步的時(shí)間。

1. 基于時(shí)間的自動(dòng)同步

將同步間隔設(shè)置到Alluxio屬性鍵“alluxio.user.file.metadata.sync.interval”上。

當(dāng)該值為-1(默認(rèn)值)時(shí)，Alluxio將永遠(yuǎn)不會(huì)在初始加載后與under storage 重新同步;
當(dāng)它的值設(shè)置為0時(shí)，每當(dāng)訪問(wèn)元數(shù)據(jù)Alluxio將始終與 under storage 重新同步;
當(dāng)該值為正數(shù)時(shí)(默認(rèn)單位為毫秒)，Alluxio將(盡力而為)不會(huì)在該時(shí)間間隔內(nèi)重新同步路徑。

注意，使用這種方式如果從未訪問(wèn)過(guò)Alluxio中的路徑，則它將永遠(yuǎn)不會(huì)觸發(fā)同步。一旦在同步間隔到期后訪問(wèn)路徑，Alluxio將再次與under storage同步。例如在Presto作業(yè)中，查詢計(jì)劃階段列出了該作業(yè)所需的所有文件，如果這些路徑最近未被訪問(wèn)則會(huì)觸發(fā)同步。但是除非作業(yè)持續(xù)時(shí)間超過(guò)同步間隔，否則作業(yè)的后續(xù)階段將不會(huì)同步。

因此，在這種情況下，從技術(shù)上來(lái)講我們可以比同步間隔更頻繁地重新同步。

可以使用全新的全局默認(rèn)值(在 alluxio-site.properties 中設(shè)置時(shí))進(jìn)行自定義，也可以在目錄基礎(chǔ)上遞歸地應(yīng)用其所有子項(xiàng)來(lái)自定義此屬性鍵。

2. 使用 LoadMetadata 標(biāo)志手動(dòng)同步

如果同步元數(shù)據(jù)時(shí)由于同步間隔而未發(fā)生，則大多數(shù)Alluxio操作將繼續(xù)使用Alluxio文件系統(tǒng)中當(dāng)前的元數(shù)據(jù)執(zhí)行，但也有一些例外：

對(duì)于大多數(shù)用戶來(lái)說(shuō)，Alluxio CLI“l(fā)oadMetadata”是手動(dòng)觸發(fā)同步的最簡(jiǎn)單方法。例如，可以運(yùn)行“bin/alluxio fs loadMetadata /path/to/sync”來(lái)強(qiáng)制更新Alluxio路徑“/path/to/sync”的元數(shù)據(jù);
對(duì)于基于Alluxio文件系統(tǒng)SDK(Java)構(gòu)建的應(yīng)用程序，有兩種API方法getStatus和listStatus可以檢索路徑或目錄的元數(shù)據(jù)。在調(diào)用這些方法時(shí)，每次調(diào)用的option中都會(huì)多出一個(gè)LoadMetadataPType字段，這可能會(huì)在被查詢的Alluxio路徑上觸發(fā)master的“l(fā)oadMetadata“進(jìn)程。這個(gè)過(guò)程可以說(shuō)是同步的簡(jiǎn)化版，只從底層存儲(chǔ)加載文件元數(shù)據(jù)。但如果文件已經(jīng)在Alluxio中了，就不會(huì)修改文件的元數(shù)據(jù)。如果LoadMetadataPType設(shè)置為NEVER，則不會(huì)加載任何內(nèi)容，如果文件不存在則會(huì)拋出FileNotFound異常。當(dāng)LoadMetadataPType為ONCE時(shí)，只會(huì)為每個(gè)目錄加載一次元數(shù)據(jù)。這僅影響這兩個(gè)文件系統(tǒng)的調(diào)用，并且僅在未發(fā)生同步時(shí)才考慮此選項(xiàng)。

如何實(shí)現(xiàn)元數(shù)據(jù)同步

當(dāng)Alluxio master收到RPC請(qǐng)求檢索此路徑的元數(shù)據(jù)時(shí)，Alluxio master可能會(huì)在Alluxio路徑上觸發(fā)元數(shù)據(jù)同步。而不是有一個(gè)專用的服務(wù)來(lái)遍歷整個(gè)文件系統(tǒng)inode樹(shù)并保持同步，這項(xiàng)工作由master上的每個(gè)單獨(dú)的Alluxio文件系統(tǒng)操作來(lái)分?jǐn)?。?RPC 請(qǐng)求中同步的高級(jí)過(guò)程是：

給定Alluxio路徑，確定它是否與相應(yīng)的存儲(chǔ)路徑一致。這意味著存儲(chǔ)不足的路徑不存在或具有與Alluxio不同的元數(shù)據(jù)，這部分是使用RPC線程完成的;
步驟1填充到同步隊(duì)列中，我們循環(huán)訪問(wèn)同步隊(duì)列，并從單獨(dú)的線程池處理工作線程中的每個(gè)路徑。遍歷順序是 BFS 順序，因?yàn)樵陉?duì)列末尾添加了其他路徑。并行性和執(zhí)行器將在并行性部分中更詳細(xì)地討論。此部分由同步線程執(zhí)行，并使用存儲(chǔ)不足的預(yù)取線程讀取存儲(chǔ)不足的信息。這樣做的原因是與計(jì)算的通信重疊。同步線程需要操作 inode 樹(shù)，一旦我們確定在將來(lái)的某個(gè)時(shí)候需要該信息，存儲(chǔ)不足的預(yù)取就可以啟動(dòng)。預(yù)取線程將存儲(chǔ)不足狀態(tài)信息加載到存儲(chǔ)不足狀態(tài)緩存中，緩存部分對(duì)此進(jìn)行了討論。

注意如果元數(shù)據(jù)同步過(guò)程涉及inode樹(shù)的同一部分，則元數(shù)據(jù)同步過(guò)程可能會(huì)相對(duì)昂貴，并且會(huì)阻止其他操作。這是因?yàn)橥竭M(jìn)程可能會(huì)寫鎖定它正在更新的文件系統(tǒng)的元數(shù)據(jù)部分。特別是當(dāng)同步樹(shù)中的特定路徑時(shí)，RPC處理線程將首先獲取文件整個(gè)路徑上的讀鎖。因?yàn)橥骄€程也需要?jiǎng)?chuàng)建路徑的能力，所以它需要同步根路徑的寫鎖。

當(dāng)同步線程處理根路徑下的每個(gè)路徑時(shí)會(huì)獲得額外的鎖，同步線程獲取文件路徑的寫鎖并在處理路徑后立即釋放。

Performance Optimization

調(diào)整并行度

可以通過(guò)控制三個(gè)配置參數(shù)來(lái)調(diào)整并行度來(lái)同步元數(shù)據(jù)：

alluxio.master.metadata.sync.concurrency.level 表示在單個(gè)元數(shù)據(jù)同步請(qǐng)求中(比如在目錄上)要同步的單個(gè)文件的數(shù)量。
alluxio.master.metadata.sync.executor.pool.size 表示所有同步操作的并發(fā)線程數(shù)。
alluxio.master.metadata.sync.ufs.prefetch.pool.size 表示所有同步操作在存儲(chǔ)預(yù)取操作下可以執(zhí)行的并發(fā)線程數(shù)。

緩存結(jié)果

有三種類型的不同緩存，在元數(shù)據(jù)同步過(guò)程中具有不同的目標(biāo)和用途。以下是所有這些內(nèi)容的快速總結(jié)。

AbsentCache 是負(fù)緩存，用于避免檢查那些已知不存在的路徑的存儲(chǔ)不足。它使用前綴匹配來(lái)確定路徑是否在底層存儲(chǔ)中。例如如果路徑/a/b在不存在的緩存中，我們知道/a/b/c 也不能存在于底層存儲(chǔ)中。此外AbsentCache條目附有時(shí)間戳，以便我們知道上次在under storage中檢查的時(shí)間。這在同步間隔是某個(gè)時(shí)間段時(shí)很有用，我們使用時(shí)間戳來(lái)確定是否需要重新檢查文件或目錄的存在。
UfsStatusCache 是用于在同步過(guò)程中從存儲(chǔ)狀態(tài)下預(yù)取的緩存。我們通常可以在處理當(dāng)前目錄時(shí)預(yù)取一些文件狀態(tài)，而不是在需要時(shí)獲取路徑信息。
UfsSyncPathCache 是一個(gè)正緩存，包含最近與底層存儲(chǔ)同步的路徑。當(dāng)我們收到元數(shù)據(jù)操作時(shí)，我們將檢查此緩存以確定我們是否需要同步特定路徑。

總結(jié)

元數(shù)據(jù)同步是Alluxio中最重要的功能之一。有多種不同的方法可以觸發(fā)同步，但需要權(quán)衡不同的性能。在Alluxio master內(nèi)部有一個(gè)優(yōu)化列表，用于加速同步。

譯者介紹

朱鋼，社區(qū)編輯，2019年CSDN博客專家20強(qiáng)，2020年騰訊云+社區(qū)優(yōu)秀作者，10年一線開(kāi)發(fā)經(jīng)驗(yàn)，曾參與獵頭服務(wù)網(wǎng)站架構(gòu)設(shè)計(jì)，企業(yè)智能客服以及大型電子政務(wù)系統(tǒng)開(kāi)發(fā)，主導(dǎo)某大型央企內(nèi)部防泄密和電子文檔安全監(jiān)控系統(tǒng)的建設(shè)，目前在BIM頭部企業(yè)從事招投標(biāo)軟件開(kāi)發(fā)。

原文標(biāo)題：Metadata Synchronization in Alluxio: Design, Implementation, and Optimization，作者：David Zhu

【譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為.com】

新聞名稱：關(guān)于Alluxio中元數(shù)據(jù)同步的設(shè)計(jì)、實(shí)現(xiàn)和優(yōu)化
網(wǎng)站鏈接：http://m.fisionsoft.com.cn/article/ccccigp.html