alluxio 1.4.0已經釋出了大量的新功能和改進。本篇部落格介紹alluxio 1.4.0開源版本的一些重要特性。
• 改進的alluxio底層存儲api
• 檔案系統rest接口
• 資料包流
1.改進的alluxio底層存儲api
alluxio是計算和資料存儲之間的橋梁。底層存儲api的初始版本是alluxio檔案系統api的鏡像，并針對底層存儲系統進行了裁剪，這些底層存儲系統提供了類hdfs的檔案系統api。對象存儲，無論是公共的還是私有的，已經日益成為各種用例的背景存儲選擇。是以，底層存儲 api需要改進，以更好地為對象存儲和檔案系統存儲提供最好的服務。
對象存儲具有扁平的命名空間，其隻有一個位于頂層的類似目錄的實體（桶）。但它可以建立僞目錄，就好像底層存儲中的目錄一樣。由于對象存儲api不區分檔案對象和目錄對象，檔案系統api對于對象存儲是非常低效的。例如，ufs api中删除路徑指令并不知道該路徑指向的是檔案還是目錄，必須調用遠端查詢擷取該中繼資料。由于與遠端存儲系統通信存在延遲，對象存儲之上的中繼資料操作代價是非常高的。在alluxio 1.4.0中，ufs api已經更新以更好地處理這樣的情況，其依據是在大部分情況下，使得這些調用高效的額外中繼資料往往已經被alluxio擷取了。
改進底層存儲api使alluxio對對象存儲更友好主要有以下兩個優勢：
優化的對象存儲連接配接器：除檔案系統外，改進的适用于對象存儲的ufs api顯示出顯著的性能優勢。
簡化的對象存儲內建：對象存儲的新抽象意味着将對象存儲內建到alluxio更容易。不必擔心其他對象存儲共有的模式，隻要在java用戶端為與特定對象存儲通信的rest接口實作一個輕量級包裝器就足夠了。
1.1 優化的對象存儲連接配接器
alluxio 1.4.0在對象存儲上的小檔案和小規模讀取的性能方面有了重大改進。改進ufs api提升了對象存儲中擷取中繼資料的性能。下面的實驗資料可以表明了帶來的好處：
1.1.1 建立或删除空檔案的性能
在alluxio 1.4.0帶來的變化中，受到顯著影響的操作之一是在底層存儲中建立零位元組檔案。對于寫性能，在s3a中提升了5倍，在ceph中提升了10倍。注意，對ceph的性能提升更大；alluxio 1.3.0中針對s3a的優化，即稱為objectunderfilesystem的新抽象，現在也适用于所有其他對象存儲。另一個受到較大影響的操作是删除，在s3a和ceph中分别帶來了3倍與15倍的性能提升。
1.1.2 粗略計算
一個擁有10gbps網絡鍊路（約1gbps用于計算）的資料中心在alluxio和遠端存儲叢集之間有1ms 的傳輸時延。在此鍊路上傳輸1mb資料塊的i / o時間為1mb / 1gbps = 1 ms。在寫1mb檔案時，create操作中中繼資料的往返次數将從10減少到1（在ceph中提升了10倍），執行總時間從11ms（10ms+1ms）減少到2ms（1ms+1ms），獲得了超過5倍的性能提升。以此類推，對于10mb的資料塊将會得到約兩倍的性能提升。以上例子說明了優化中繼資料性能是如何有效改善小檔案和小規模讀取性能的。在遠端存儲叢集網絡距離非常遙遠時，性能提升将變得更加明顯。
1.2 簡化的對象存儲內建
類似于rest接口用戶端支援的功能，如今內建新的對象存儲僅需要實作少得多的方法。隻需要原先實作的方法中的一半即可。在源代碼行數方面，現在僅需要不到400行代碼即可完成新的對象存儲的內建，不到原來的一半。
2.檔案系統原生rest接口
新引入的rest接口提供了與alluxio native java api的對等性，其目的是促進非java環境與alluxio的互動。
rest接口通過名為alluxio proxy的alluxio程序實作，該程序使用一個内部alluxio java用戶端對rest接口和alluxio伺服器之間的通信進行代理。
alluxio proxy的啟動方法如下：
在本地通過 . /bin/alluxio-start.sh本地指令，啟動本地alluxio叢集
通過 ./bin/alluxio-start.sh all指令啟動所有alluxio master和alluxio worker程序
顯式地調用 ./bin/alluxio-start.sh proxy指令，在本地啟動代理程序
2.1 api
rest api由兩種類型的端點組成：
host參數可以是運作alluxio代理的任何機器。
端點path通過路徑執行給定的操作（例如，清單狀态，建立或删除檔案）。其餘參數以json對象的形式傳遞到端點。
一些path端點，特别是在建立檔案或打開檔案時，會建立一個流并傳回一個整數句柄id。 此句柄可用于調用流端點以執行給定操作（例如讀取，寫入或關閉）。
2.2 examples
本節通過curl指令與本地alluxio代理進行通信介紹一些rest api的功能。
2.2.1 建立目錄
以下指令建立/ hello / world目錄; 參數 recursive = true用于遞歸建立缺少的父目錄：
2.2.2 列出目錄
以下指令列出/ hello目錄的内容：
2.2.3 删除目錄
以下指令删除/ hello目錄的内容; recursive = true參數用于遞歸删除目錄：
2.2.4 上傳檔案
以下指令建立/hello-world.txt檔案，寫入内容并将其關閉：
2.2.5 下載下傳檔案
以下指令打開/hello-world.txt檔案，讀取内容并将其關閉：
2.3 性能
為了獲得最佳性能，我們建議将alluxio代理與alluxio服務程序放在一起。這可以讓非java應用以記憶體級的速度通路存儲在alluxio中的資料，同時最小化alluxio代理和alluxio服務之間額外網絡的開銷。
3.資料包流
alluxio 1.4.0引入了一種新的網絡傳輸協定，旨在充分利用alluxio元件之間的可用網絡帶寬。為了實作這一點，我們減少了網絡傳輸期間使用的緩存，并且依賴于使用連續流傳輸協定取代資料傳輸中的請求-響應協定。
3.1 優勢
1.在标準網絡中高達2倍的i / o性能改進，以及在高延遲吞吐量産品環境下取得更好的結果
2.最優化少量讀取和随機讀取，無需調整配置
3.2 協定細節
通過使用這種方法，我們能確定網絡管道持續飽和，因為我們不需要發送周期性的額外資料請求。而按照原來的方法，在讀取請求的往返時間内，網絡管道将處于空閑狀态。這将帶來顯着的i/o性能改進，特别是在往返時間相當長并且可用吞吐量大的情況下。
此外，資料傳輸的機關已縮減為一個資料包（預設為64kb）。 使用流協定，更小的分組不會影響大規模順序i/o的工作負載，因為存在恒定數量的setup/teardown消息。 不僅如此，小分組也有利于少量讀取，因為讀取的資料的總量更接近讀取者請求的量。 是以，分組流可以滿足兩種工作負載類型的用戶端，而不需要不同的配置。
資料包流式傳輸目前仍處于試驗階段，我們将在未來版本中積極改進此功能，以進一步提高alluxio的性能和易用性。
4.更多内容
版權申明：本文由南京大學顧榮等專家翻譯整理自alluxio公司技術部落格，由alluxio公司授權雲栖社群及csdn首發（聯合），版權歸alluxio公司所有，未經版權所有者同意請勿轉載。