百度案例：利用Alluxio實現安全的即插即用分佈式文件系統

全文共3361字，預計學習時長7分鐘

本文介紹了百度如何依靠開源項目Alluxio，在一個企業大數據分析解決項目Pingo中建立了一個安全、模塊化和可擴展的分佈式文件系統服務。

在這篇文章中，你將學習如何依靠Alluxio來實現一個統一的分佈式文件系統服務，以及如何在Alluxio之上添加插件，這包括自定義身份驗證方案和Alluxio文件上的用戶函數UDF。

目標和挑戰

Pingo是百度的產品，提供離線大數據分析解決方案，依靠Apache Spark做爲資源調度、數據和元數據管理，以及工做流管理的計算引擎。Pingo不只應用於百度的內部基礎設施建設，還用於服務百度公共雲和私有云的部署。

鑑於這些目標用例的需求，Pingo在設計上須要支持高效和統一的數據訪問：不管數據是本地的仍是遠程的，結構化的仍是非結構化的，存儲在on-prem存儲設備或雲存儲服務中。此外，因爲企業須要處理大量的文件，在身份驗證和受權方面的安全需求迫使Pingo作出更加複雜的設計。

Pingo利用Alluxio從各類存儲解決方案裏抽象出數據差別。Pingo還對Alluxio進行了改進，從而可以提供統一的身份驗證管理，而不暴露原始存儲系統的身份驗證信息。

實施和定製

在Pingo中，文件系統管理服務(PFS)是基於Alluxio實現的。利用Alluxio提供的安裝能力，PFS能夠輕鬆地整合各類文件系統或對象存儲，如HDFS、S三、百度對象存儲(BOS)或Linux中的本地文件系統(詳見第2.1節)。

將特定分佈式文件系統使用統一的文件系統API安裝到PFS後，用戶只需使用Pingo的內置賬戶和權限管理系統，就能夠隱藏多樣的特定分佈式文件系統。Pingo還在Alluxio中添加了一個自定義ACL權限機制，用來幫助企業內大型團隊的數據管理(參見2.2,2.3節)。

此外，產品中還配備了帶有文件系統級權限檢查的表級受權(第2.4節)，而且實現了基於PFS的文件化UDF管理機制(第2.5節)

支持新的文件系統類型

Pingo支持掛載BOS，這是百度公共雲提供的對象存儲服務。BOS提供了一個相似於AWSS3的接口，然而，在使用S3協議將BOS掛載到Alluxio時仍然存在一些問題。爲了訪問BOS中的文件，咱們整合了BOSUnderFileSystem類，擴展了Allurxio現有的ObjectUnderFileSystem抽象類。

此外，還整合了另外一個名爲SshUnderFileSystem的下端存儲系統，它經過基於Github的Alluxio、Alluxio擴展代碼上使用的FTP（SSH文件傳輸協議）訪問文件。

自定義身份驗證

如前所述，Pingo已經內置UserService用於用戶身份驗證。咱們擴展了Alluxio現有的身份驗證機制，添加了一個新的，基於Pingo UserService的身份驗證服務類型。具體而言，咱們爲alluxio.security.authentication.Authtype添加了一個枚舉值PINGO。

在Alluxio Master端，咱們添加了一個PingoAuthenticationProvider，它能將客戶端發送的用戶名和身份驗證信息轉發至Pingo的UserService。

細粒度受權

因爲一些針對大數據工做負載的特殊需求，咱們應用了一種新的機制來管理PFS中的ACL權限。咱們發現不管是傳統的Unix特權模型Unix privilege model(Linux中的默認特權模型)仍是POSIX ACL privilege model都不能知足咱們的需求。

如下面的需求爲例:但願遞歸地授予用戶「ua」和「ub」對目錄/a/b/data中全部子路徑的閱讀訪問權；不管在/a/b/data下新增多少子路徑，用戶「ua」和「ub」均可以自動得到閱讀訪問權。可是，若是管理員決定撤消對該目錄下「ub」的閱讀訪問權限，那麼他只須要在/a/b/data目錄上更改權限級別便可。

有大數據平臺工做經驗的用戶應該知道，一個文件夾中很容易塞滿成千上萬份文件甚至更多，而現有的受權系統還不能有效地解決這樣數量級的文件。

PFS同時支持Unix特權模型和PFS獨有的ACL特權模型。對於閱讀和寫入訪問，PFS將首先遵循路徑上任何存在的被定義ACL記錄；不然，它將回退到Unix權限模型。對於管理訪問，例如須要管理權限的Linux chmod命令，它則遵循ACL或Unix模型對訪問請求進行身份驗證。

ACL定義了三種類型的權限:閱讀、寫入和管理。Unix權限模型中的可執行權限合併爲閱讀權限（READ）。文件(剪輯)的ACL受權記錄能夠被引用以下:

Inherit: true/false

USER: uname_1 READ/WRITE/MANAGE

...

USER: uname_n READ/WRITE/MANAGE

GROUP: gname_1 READ/WRITE/MANAGE

...

GROUP: gname_n READ/WRITE/MANAGE

受權記錄中的每一個USER: uname_n READ/WRITE/MANAGE規則定義了用戶是否能夠讀取、寫入、管理文件或目錄。本節前面提到的示例是經過繼承屬性（inherit attribute）解決的。

與Unix特權模型只在要訪問的路徑的最後一個級別進行身份驗證不一樣，當繼承爲「正確」（True）時，只要有記錄知足條件——從路徑最後一級路徑到根節點或繼承「錯誤」（False）的任何節點，PFS就會受權訪問。

集成表和文件權限

像Pingo這樣的分析平臺，和像MySQL這樣的傳統數據庫之間一個有趣的區別是：在Pingo，工做臺和文件都是可訪問的，而在MySQL中，想要訪問工做臺只能經過客戶端或JDBC在工做臺上運行查詢。訪問實際存儲數據的文件是沒有意義的。在大數據系統中，工做臺能夠經過Spark這樣的SQL引擎查詢，可是原始文件也能夠直接經過MapReduce或Dataframe查詢。

這給訪問控制帶來了挑戰:若是受權用戶訪問工做臺T1，管理員可能只但願用戶經過提供的SQL接口訪問T1的數據，而不容許訪問相應的分區文件。若是管理員撤銷用戶對T1的訪問，用戶將再也不可以經過SQL或文件系統訪問對應於T1工做臺的文件數據。

在Pingo，連PFS和Pingo的賬戶身份驗證系統，用來實現權限代理機制，正以下面圖2所示。最初建立工做臺T1時，T1建立者的信息保存在了TMetaServer中。

執行查詢時，用戶首先完成T1的訪問身份驗證。經過身份驗證以後，查詢引擎能夠得到與T1對應的PFS路徑、建立者信息，以及身份驗證信息，而後在PFS中對T1的建立者進行實際身份驗證。這樣，只要用戶可以訪問工做臺，就能夠讀取工做臺數據。

基於文件的UDF管理

UDF普遍應用於SQL查詢引擎。用戶一般須要首先上傳一個jar文件，而後在SQL引擎中註冊一個臨時函數。這種使用UDF的方法不只須要額外的步驟，並且很難管理和版本控制jar文件，所以，它一般會下降迭代的速度。

如圖3所示，在PFS中實現了一個基於文件的UDF管理解決方案。UDF的建立者只須要將相應的jar文件上傳到PFS中的指定目錄。Alluxio Worker端將自動從jar文件中提取UDF信息並將其報告給Master端，根據文件名自動跟蹤不一樣的UDF版本。用戶在執行SQL時不須要註冊UDF——他們只須要指定函數的名稱或版本。

此方法相似於Linux管理「.so」文件(動態連接庫)，但有更多好處:UDF變得很是容易使用，而且很容易在PFS中實現將權限管理做爲文件系統ACL權限的一部分，它還容許小團隊快速迭代和共享源代碼。

結語

本文介紹了Pingo如何使用開源項目Alluxio構建其文件系統服務，以及如何實現自定義身份驗證、細粒度受權、基於文件的UDF管理等附加功能。

留言 點贊 關注

咱們一塊兒分享AI學習與發展的乾貨
歡迎關注全平臺AI垂類自媒體 「讀芯術」

（添加小編微信：dxsxbb，加入讀者圈，一塊兒討論最新鮮的人工智能科技哦～）