建站
咨詢
售后
建站咨詢
新聞中心
???
創(chuàng)新互聯(lián)建站服務(wù)項目包括澤州網(wǎng)站建設(shè)、澤州網(wǎng)站制作、澤州網(wǎng)頁制作以及澤州網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，澤州網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到澤州省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
元數(shù)據(jù)同步是Alluxio的重要特性。這篇文章描述了設(shè)計、實現(xiàn)和其他內(nèi)部流程，用以調(diào)整性能。
元數(shù)據(jù)同步(sync)是Alluxio中的核心功能，它使文件和目錄與所在存儲系統(tǒng)下真實的來源保持一致，進而使用戶能夠輕松地從Alluxio中檢索出最新版的數(shù)據(jù)。同時了解內(nèi)部流程對調(diào)整性能也非常重要。本文介紹了Alluxio中保持元數(shù)據(jù)同步的設(shè)計和實現(xiàn)。
元數(shù)據(jù)同步為什么在Alluxio中很重要
在Alluxio中，元數(shù)據(jù)指的是Alluxio文件系統(tǒng)中文件和目錄的信息，包括它們的所有者、組、權(quán)限、創(chuàng)建以及修改時間等信息。元數(shù)據(jù)獨立于其內(nèi)容——即使文件或目錄是空的，但它仍然具有關(guān)聯(lián)的元數(shù)據(jù)。
Alluxio維護文件系統(tǒng)或底層存儲系統(tǒng)的對象存儲命名空間的副本。在Alluxio中，元數(shù)據(jù)一致性很重要，尤其是不同集群在數(shù)據(jù)管道中寫入或讀取數(shù)據(jù)后，并在Alluxio之外進行更改時。
???
在上圖中是一個典型的場景，結(jié)合了Spark ETL和Presto SQL的數(shù)據(jù)管道。ETL集群(不帶Alluxio)寫入數(shù)據(jù)，然后是分析集群，Alluxio讀取轉(zhuǎn)換后的數(shù)據(jù)。因為Alluxio維護了底層存儲的元數(shù)據(jù)副本并管理元數(shù)據(jù)，因此當(dāng)?shù)讓哟鎯χ械臄?shù)據(jù)通過ETL步驟發(fā)生變化時，必須使分析群集上的Alluxio實例感知到并與底層存儲系統(tǒng)中的元數(shù)據(jù)保持一致以便正確操作。
在Alluxio中元數(shù)據(jù)同步是如何工作的
Alluxio在一個或多個底層存儲系統(tǒng)上的統(tǒng)一命名空間中提供了文件系統(tǒng)抽象。通過Alluxio訪問文件或目錄，會得到和直接訪問under storage一樣的結(jié)果。比如如果掛載到Alluxio根目錄的底層存儲是s3://bucket/data，那么在Alluxio中列出“/”目錄與在s3://bucket/data中列出對象并在其中打印“/file”產(chǎn)生相同的結(jié)果應(yīng)該返回與s3://bucket/data/file一樣的結(jié)果。
在Alluxio中元數(shù)據(jù)只從Alluxio master中存儲和提供，但單個文件的內(nèi)容則由Alluxio worker提供。
默認情況下，Alluxio根據(jù)需要從底層存儲加載元數(shù)據(jù)。在上面的例子中，一個從空開始的Alluxio master在啟動后沒有任何關(guān)于s3://bucket/data/file的信息。僅當(dāng)某些用戶在Alluxio中列出“/”目錄或嘗試訪問“/file”時才會識別此文件。這種“惰性”行為可以防止不必要的工作并能顯著提高性能，因為底層存儲中的元數(shù)據(jù)操作可能很慢。
注意，更新元數(shù)據(jù)可以是雙向的。如果對文件系統(tǒng)的所有修改都是通過Alluxio發(fā)生，那么Alluxio只需要掃描一次under storage即可檢索初始狀態(tài)，然后作為文件系統(tǒng)RPC調(diào)用的一部分同步應(yīng)用Alluxio和under storage中的更改。這將為用戶提供一致的存儲不足視圖。然而實際上Alluxio之外的存儲不足經(jīng)常發(fā)生變化，因此Alluxio master必須監(jiān)控對under storage中文件和方向的添加、刪除和更新，并將更改應(yīng)用到Alluxio文件系統(tǒng)中。這個同步兩個命名空間的過程稱為元數(shù)據(jù)同步。
如何觸發(fā)元數(shù)據(jù)同步
當(dāng)應(yīng)用程序更改了 Alluxio 文件的元數(shù)據(jù)并且該文件被持久化時，更改將始終同步傳播到底層存儲無需觸發(fā)元數(shù)據(jù)同步。當(dāng)應(yīng)用程序在存儲文件下更新而不讓 Alluxio 知道時，有兩種方法可以控制元數(shù)據(jù)同步的時間。
1. 基于時間的自動同步
將同步間隔設(shè)置到Alluxio屬性鍵“alluxio.user.file.metadata.sync.interval”上。
- 當(dāng)該值為-1(默認值)時，Alluxio將永遠不會在初始加載后與under storage 重新同步;
- 當(dāng)它的值設(shè)置為0時，每當(dāng)訪問元數(shù)據(jù)Alluxio將始終與 under storage 重新同步;
- 當(dāng)該值為正數(shù)時(默認單位為毫秒)，Alluxio將(盡力而為)不會在該時間間隔內(nèi)重新同步路徑。
注意，使用這種方式如果從未訪問過Alluxio中的路徑，則它將永遠不會觸發(fā)同步。一旦在同步間隔到期后訪問路徑，Alluxio將再次與under storage同步。例如在Presto作業(yè)中，查詢計劃階段列出了該作業(yè)所需的所有文件，如果這些路徑最近未被訪問則會觸發(fā)同步。但是除非作業(yè)持續(xù)時間超過同步間隔，否則作業(yè)的后續(xù)階段將不會同步。
因此，在這種情況下，從技術(shù)上來講我們可以比同步間隔更頻繁地重新同步。
可以使用全新的全局默認值(在 alluxio-site.properties 中設(shè)置時)進行自定義，也可以在目錄基礎(chǔ)上遞歸地應(yīng)用其所有子項來自定義此屬性鍵。
2. 使用 LoadMetadata 標(biāo)志手動同步
如果同步元數(shù)據(jù)時由于同步間隔而未發(fā)生，則大多數(shù)Alluxio操作將繼續(xù)使用Alluxio文件系統(tǒng)中當(dāng)前的元數(shù)據(jù)執(zhí)行，但也有一些例外：
- 對于大多數(shù)用戶來說，Alluxio CLI“l(fā)oadMetadata”是手動觸發(fā)同步的最簡單方法。例如，可以運行“bin/alluxio fs loadMetadata /path/to/sync”來強制更新Alluxio路徑“/path/to/sync”的元數(shù)據(jù);
- 對于基于Alluxio文件系統(tǒng)SDK(Java)構(gòu)建的應(yīng)用程序，有兩種API方法getStatus和listStatus可以檢索路徑或目錄的元數(shù)據(jù)。在調(diào)用這些方法時，每次調(diào)用的option中都會多出一個LoadMetadataPType字段，這可能會在被查詢的Alluxio路徑上觸發(fā)master的“l(fā)oadMetadata“進程。這個過程可以說是同步的簡化版，只從底層存儲加載文件元數(shù)據(jù)。但如果文件已經(jīng)在Alluxio中了，就不會修改文件的元數(shù)據(jù)。如果LoadMetadataPType設(shè)置為NEVER，則不會加載任何內(nèi)容，如果文件不存在則會拋出FileNotFound異常。當(dāng)LoadMetadataPType為ONCE時，只會為每個目錄加載一次元數(shù)據(jù)。這僅影響這兩個文件系統(tǒng)的調(diào)用，并且僅在未發(fā)生同步時才考慮此選項。
如何實現(xiàn)元數(shù)據(jù)同步
當(dāng)Alluxio master收到RPC請求檢索此路徑的元數(shù)據(jù)時，Alluxio master可能會在Alluxio路徑上觸發(fā)元數(shù)據(jù)同步。而不是有一個專用的服務(wù)來遍歷整個文件系統(tǒng)inode樹并保持同步，這項工作由master上的每個單獨的Alluxio文件系統(tǒng)操作來分攤。在 RPC 請求中同步的高級過程是：
- 給定Alluxio路徑，確定它是否與相應(yīng)的存儲路徑一致。 這意味著存儲不足的路徑不存在或具有與Alluxio不同的元數(shù)據(jù)，這部分是使用RPC線程完成的;
- 步驟1填充到同步隊列中，我們循環(huán)訪問同步隊列，并從單獨的線程池處理工作線程中的每個路徑。遍歷順序是 BFS 順序，因為在隊列末尾添加了其他路徑。并行性和執(zhí)行器將在并行性部分中更詳細地討論。此部分由同步線程執(zhí)行，并使用存儲不足的預(yù)取線程讀取存儲不足的信息。這樣做的原因是與計算的通信重疊。同步線程需要操作 inode 樹，一旦我們確定在將來的某個時候需要該信息，存儲不足的預(yù)取就可以啟動。預(yù)取線程將存儲不足狀態(tài)信息加載到存儲不足狀態(tài)緩存中，緩存部分對此進行了討論。
注意如果元數(shù)據(jù)同步過程涉及inode樹的同一部分，則元數(shù)據(jù)同步過程可能會相對昂貴，并且會阻止其他操作。這是因為同步進程可能會寫鎖定它正在更新的文件系統(tǒng)的元數(shù)據(jù)部分。特別是當(dāng)同步樹中的特定路徑時，RPC處理線程將首先獲取文件整個路徑上的讀鎖。因為同步線程也需要創(chuàng)建路徑的能力，所以它需要同步根路徑的寫鎖。
當(dāng)同步線程處理根路徑下的每個路徑時會獲得額外的鎖，同步線程獲取文件路徑的寫鎖并在處理路徑后立即釋放。
Performance Optimization
調(diào)整并行度
可以通過控制三個配置參數(shù)來調(diào)整并行度來同步元數(shù)據(jù)：
- alluxio.master.metadata.sync.concurrency.level 表示在單個元數(shù)據(jù)同步請求中(比如在目錄上)要同步的單個文件的數(shù)量。
- alluxio.master.metadata.sync.executor.pool.size 表示所有同步操作的并發(fā)線程數(shù)。
- alluxio.master.metadata.sync.ufs.prefetch.pool.size 表示所有同步操作在存儲預(yù)取操作下可以執(zhí)行的并發(fā)線程數(shù)。
緩存結(jié)果
有三種類型的不同緩存，在元數(shù)據(jù)同步過程中具有不同的目標(biāo)和用途。以下是所有這些內(nèi)容的快速總結(jié)。
- AbsentCache 是負緩存，用于避免檢查那些已知不存在的路徑的存儲不足。它使用前綴匹配來確定路徑是否在底層存儲中。例如如果路徑/a/b在不存在的緩存中，我們知道/a/b/c 也不能存在于底層存儲中。此外AbsentCache條目附有時間戳，以便我們知道上次在under storage中檢查的時間。這在同步間隔是某個時間段時很有用，我們使用時間戳來確定是否需要重新檢查文件或目錄的存在。
- UfsStatusCache 是用于在同步過程中從存儲狀態(tài)下預(yù)取的緩存。我們通常可以在處理當(dāng)前目錄時預(yù)取一些文件狀態(tài)，而不是在需要時獲取路徑信息。
- UfsSyncPathCache 是一個正緩存，包含最近與底層存儲同步的路徑。當(dāng)我們收到元數(shù)據(jù)操作時，我們將檢查此緩存以確定我們是否需要同步特定路徑。
總結(jié)
元數(shù)據(jù)同步是Alluxio中最重要的功能之一。有多種不同的方法可以觸發(fā)同步，但需要權(quán)衡不同的性能。在Alluxio master內(nèi)部有一個優(yōu)化列表，用于加速同步。
譯者介紹
朱鋼，社區(qū)編輯，2019年CSDN博客專家20強，2020年騰訊云+社區(qū)優(yōu)秀作者，10年一線開發(fā)經(jīng)驗，曾參與獵頭服務(wù)網(wǎng)站架構(gòu)設(shè)計，企業(yè)智能客服以及大型電子政務(wù)系統(tǒng)開發(fā)，主導(dǎo)某大型央企內(nèi)部防泄密和電子文檔安全監(jiān)控系統(tǒng)的建設(shè)，目前在BIM頭部企業(yè)從事招投標(biāo)軟件開發(fā)。
原文標(biāo)題：Metadata Synchronization in Alluxio: Design, Implementation, and Optimization，作者：David Zhu
【譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為.com】
分享文章：關(guān)于Alluxio中元數(shù)據(jù)同步的設(shè)計、實現(xiàn)和優(yōu)化
分享URL：http://www.dlmjj.cn/article/ccccigp.html
