赘婿动画在线观看免费完整版,国产免费一级在线观看,色综久久天天综合绕视看

關于Alluxio中元數據同步的設計、實現和優化

【51CTO.com快譯】元數據同步是Alluxio的重要特性。這篇文章描述了設計、實現和其他內部流程，用以調整性能。

元數據同步(sync)是Alluxio中的核心功能，它使文件和目錄與所在存儲系統下真實的來源保持一致，進而使用戶能夠輕松地從Alluxio中檢索出最新版的數據。同時了解內部流程對調整性能也非常重要。本文介紹了Alluxio中保持元數據同步的設計和實現。

元數據同步為什么在Alluxio中很重要

在Alluxio中，元數據指的是Alluxio文件系統中文件和目錄的信息，包括它們的所有者、組、權限、創建以及修改時間等信息。元數據獨立于其內容——即使文件或目錄是空的，但它仍然具有關聯的元數據。

Alluxio維護文件系統或底層存儲系統的對象存儲命名空間的副本。在Alluxio中，元數據一致性很重要，尤其是不同集群在數據管道中寫入或讀取數據后，并在Alluxio之外進行更改時。

關于Alluxio中元數據同步的設計、實現和優化

在上圖中是一個典型的場景，結合了Spark ETL和Presto SQL的數據管道。ETL集群(不帶Alluxio)寫入數據，然后是分析集群，Alluxio讀取轉換后的數據。因為Alluxio維護了底層存儲的元數據副本并管理元數據，因此當底層存儲中的數據通過ETL步驟發生變化時，必須使分析群集上的Alluxio實例感知到并與底層存儲系統中的元數據保持一致以便正確操作。

在Alluxio中元數據同步是如何工作的

Alluxio在一個或多個底層存儲系統上的統一命名空間中提供了文件系統抽象。通過Alluxio訪問文件或目錄，會得到和直接訪問under storage一樣的結果。比如如果掛載到Alluxio根目錄的底層存儲是s3://bucket/data，那么在Alluxio中列出“/”目錄與在s3://bucket/data中列出對象并在其中打印“/file”產生相同的結果應該返回與s3://bucket/data/file一樣的結果。

在Alluxio中元數據只從Alluxio master中存儲和提供，但單個文件的內容則由Alluxio worker提供。

默認情況下，Alluxio根據需要從底層存儲加載元數據。在上面的例子中，一個從空開始的Alluxio master在啟動后沒有任何關于s3://bucket/data/file的信息。僅當某些用戶在Alluxio中列出“/”目錄或嘗試訪問“/file”時才會識別此文件。這種“惰性”行為可以防止不必要的工作并能顯著提高性能，因為底層存儲中的元數據操作可能很慢。

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

如何觸發元數據同步

當應用程序更改了 Alluxio 文件的元數據并且該文件被持久化時，更改將始終同步傳播到底層存儲無需觸發元數據同步。當應用程序在存儲文件下更新而不讓 Alluxio 知道時，有兩種方法可以控制元數據同步的時間。

1. 基于時間的自動同步

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

當該值為-1(默認值)時，Alluxio將永遠不會在初始加載后與under storage 重新同步;
當它的值設置為0時，每當訪問元數據Alluxio將始終與 under storage 重新同步;
當該值為正數時(默認單位為毫秒)，Alluxio將(盡力而為)不會在該時間間隔內重新同步路徑。

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

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

可以使用全新的全局默認值(在 alluxio-site.properties 中設置時)進行自定義，也可以在目錄基礎上遞歸地應用其所有子項來自定義此屬性鍵。

2. 使用 LoadMetadata 標志手動同步

如果同步元數據時由于同步間隔而未發生，則大多數Alluxio操作將繼續使用Alluxio文件系統中當前的元數據執行，但也有一些例外：

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

如何實現元數據同步

當Alluxio master收到RPC請求檢索此路徑的元數據時，Alluxio master可能會在Alluxio路徑上觸發元數據同步。而不是有一個專用的服務來遍歷整個文件系統inode樹并保持同步，這項工作由master上的每個單獨的Alluxio文件系統操作來分攤。在 RPC 請求中同步的高級過程是：

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

注意如果元數據同步過程涉及inode樹的同一部分，則元數據同步過程可能會相對昂貴，并且會阻止其他操作。這是因為同步進程可能會寫鎖定它正在更新的文件系統的元數據部分。特別是當同步樹中的特定路徑時，RPC處理線程將首先獲取文件整個路徑上的讀鎖。因為同步線程也需要創建路徑的能力，所以它需要同步根路徑的寫鎖。

當同步線程處理根路徑下的每個路徑時會獲得額外的鎖，同步線程獲取文件路徑的寫鎖并在處理路徑后立即釋放。

Performance Optimization

調整并行度

可以通過控制三個配置參數來調整并行度來同步元數據：

alluxio.master.metadata.sync.concurrency.level 表示在單個元數據同步請求中(比如在目錄上)要同步的單個文件的數量。
alluxio.master.metadata.sync.executor.pool.size 表示所有同步操作的并發線程數。
alluxio.master.metadata.sync.ufs.prefetch.pool.size 表示所有同步操作在存儲預取操作下可以執行的并發線程數。

緩存結果

有三種類型的不同緩存，在元數據同步過程中具有不同的目標和用途。以下是所有這些內容的快速總結。

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