本文轉載自： https://zhuanlan.zhihu.com/p/49499385
我們在這篇文章介紹最新版本（1.8.1版本）的Alluxio如何通過使用指紋特性和底層存儲批量操作加快Alluxio中繼資料操作。中繼資料操作是所有檔案系統的重要組成部分。其性能對于像Alluxio這樣一個經常管理幾個大型底層檔案系統的存儲系統來說更加關鍵。本文詳細介紹了我們最近在Alluxio 1.8.1版本中所做的兩個優化，以顯著地提升大規模遞歸加載中繼資料操作的性能。
概述
Alluxio的主要功能之一是提供簡單而統一的接口，用來管理不同底層存儲系統内的檔案和目錄。即使底層存儲系統可能是具有不同接口類型的對象存儲，Alluxio也可以充當中間層，并提供一個統一的檔案接口供應用程式與多個底層存儲系統進行互動。這在将應用程式從本地伺服器遷移到雲服務的場景中非常常見，本地部署的應用程式使用POSIX之類的檔案接口處理本地存儲，而雲存儲使用S3之類的對象存儲接口通路資料。在應用程式和存儲系統之間使用Alluxio可以節省大量開發時間，否則需要花費大量精力将應用程式從原始檔案接口更改為對象存儲接口。
挑戰
與其他底層存儲系統相比，對象存儲通常是遠端部署的，通路速度較慢。使用者在使用Alluxio的檔案系統接口時，可能會無意間頻繁觸發對這些對象儲存的遠端通路。當使用者遞歸地調用某些涉及大量檔案的中繼資料操作(ls或chmod / chgrp)時，由于會頻繁調用底層對象存儲接口，中繼資料通路速度将會更慢。本文關注了最近在Alluxio中針對加速這些中繼資料操作所做的一些優化。
加速Alluxio/底層存儲同步
自從Alluxio v1.7問世以來，指紋串技術已經被用來檢測檔案或目錄是否已經改變。這可以讓Alluxio快速确定Alluxio中的檔案與S3存儲中的檔案或其他對象存儲(底層存儲)中的檔案是否同步。當使用者不通過Alluxio而直接在底層存儲中修改一個檔案可能會發生這種不同步的情況。當指紋不同步時，将執行底層存儲同步操作。1.8版本通過将指紋劃分為兩個元件(中繼資料元件和内容元件)改進了這一特性，進而進一步減少了Alluxio和底層存儲之間所需的同步次數。
在此使用雙元件指紋技術之前，如果底層檔案系統(UFS)中檔案/對象(所有者、模式等)的中繼資料發生更改，那麼Alluxio則認為整個檔案都不再同步，并認為對應的整個檔案将無效。這可能會導緻不必要的檔案失效和資料的重新加載，進而增加大規模中繼資料操作的成本，比如在包含許多檔案和目錄的目錄上遞歸地更改權限。中繼資料操作本身并不一定很慢，但是後續的檔案内容操作會慢一些，因為在下一次讀取操作中，Alluxio必須重新加載檔案内容。
通過将檔案中繼資料指紋和檔案内容指紋分離開來，當檔案隻有中繼資料發生更改時，隻有檔案中繼資料的指紋是不同的，而檔案内容的指紋并沒有發生變化。是以，Alluxio不需要從底層存儲重新加載資料，而是可以直接在記憶體中更新中繼資料。是以，在隻有中繼資料發生更改的情況下，這是一種低成本的同步底層存儲系統和Alluxio中繼資料的方法。
加速遞歸執行的指令ListStatus和DiskUsage
最常用的中繼資料操作之一是listStatus操作或ls指令。使用者經常通過指令行以互動的方式使用這兩個指令。從使用者的角度來看，在互動過程中任何高延遲都是不可取的。此外，這些指令還用于許多分布式計算架構，如Spark和MapReduce，是以效率的提高可以加速計算任務的執行。listStatus的選項之一是遞歸選項。使用recursive選項，使用者可以遞歸地查詢整個檔案夾的中繼資料資訊。這通常會導緻查詢很多的檔案和目錄，是以會非常耗時。
實驗結果表明，檔案系統主節點為了查詢中繼資料資訊，需要調用底層存儲系統接口，而事實上該過程是執行上述指令的瓶頸。對于将對象存儲作為其底層存儲進行部署來說，此問題更加嚴重。因為這些對象存儲通常是遠端部署的，是以listStatus等操作通常比在同一處部署的檔案系統(如HDFS)慢。提高listStatus遞歸操作性能的關鍵是減少對底層存儲的調用。
Alluxio最近引入了兩個特性，改善了listStatus調用的性能。首先，Alluxio v1.8開始利用一些對象存儲(如Amazon S3)支援遞歸listStatus調用這一特性。通過一次API調用，Alluxio可以獲得整個檔案和目錄清單及其中繼資料。此外，Alluxio可以緩存從這個遞歸調用中獲得的資訊以用于其他場合，如指紋生成和驗證。
此外，1.8.1版本的Alluxio還包含了另一項優化：當由于從底層存儲系統加載中繼資料而在Alluxio空間中建立了一個檔案時，因為檔案是從底層存儲系統端開始建立的，是以檔案應該已經存在于底層存儲系統中了，Alluxio将不會把檔案資訊持久化到底層存儲系統中。
聯合這兩種優化的效果是，對底層存儲系統的調用操作的時間複雜度将從O(n)減少至O(1)，其中n代表被查詢的檔案數量。我們通過實驗評估了該優化的效果。我們建立一個具有深層嵌套的目錄結構，每一層有10個或4個目錄，總共有10000個檔案。實驗在本地機器上部署了Alluxio并将Amazon S3作為底層存儲。通過對比Alluxio 1.7.1版本和Alluxio 1.8.0版本的性能，首次運作listStatus遞歸操作時性能有了一定的改進，運作時間能夠減少75%。第二次調用listStatus遞歸指令的運作時間則大大減少，時間從900秒減少到8秒。
Alluxio 1.8.1版本則顯著提高了ls –R指令的首次運作耗時性能。聯合優化後第一次ls –R指令的時間從2000秒以上降低到20秒左右，随後ls –R指令運作時間僅為7秒左右。下表總結了每次優化後遞歸執行listStatus的運作時間。
結論
中繼資料操作是所有檔案系統的重要組成部分。其性能對于像Alluxio這樣一個經常管理幾個大型底層檔案系統的存儲系統來說更加關鍵。本文詳細介紹了我們最近在Alluxio 1.8.1版本中所做的兩個優化，以顯著地提升大規模遞歸加載中繼資料操作的性能。該優化改善了在指令行界面使用ls和du查詢Alluxio檔案的使用者體驗。此外，這些優化還加快了一個名為UFS sync的程序的執行，該程序旨在保持UFS和Alluxio命名空間之間的檔案同步。
未來的工作
中繼資料管理是Alluxio的關鍵部分，在本文中我們詳細介紹了最近為提高中繼資料載入速度所做的一些優化。與此同時，我們還在研究如何更有效地同步底層存儲系統中繼資料和存儲在Alluxio master中的中繼資料。除了速度和效率之外，我們還緻力于中繼資料管理的可擴充性。我們希望擴充中繼資料管理，以支援管理更大規模的檔案數量。本文中介紹的改進和未來的改進工作如下:
- 在内容相關資訊和中繼資料相關資訊之間劃分UFS指紋(ALLUXIO-3150, https://alluxio.atlassian.net/browse/ALLUXIO-3150 )
- 在底層存儲系統中使用遞歸listStatus實作loadMetadata (ALLUXIO-3205, https://alluxio.atlassian.net/browse/ALLUXIO-3205
- 減少在loadMetadata中與底層存儲系統互動的數量(ALLUXIO-3300, https://alluxio.atlassian.net/browse/ALLUXIO-3300
在 Alluxio 1.8.1版本釋出說明(
https://www.alluxio.org/download/releases/alluxio-181-release)中閱讀更多内容
作者簡介：朱禹 (David Zhu) 是Alluxio的軟體工程師。 加入Allxuio之前， 曾在Google, Intel Research從事分布式系統及系統安全性的研究。博士畢業于UC Berkeley計算機系，博士期間參與了衆核作業系統Akaros以及分布式資料庫的結構演變的研究與開發。