Tachyon在Spark中的做用（Tachyon: Reliable, Memory Speed Storage for Cluster Computing Frameworks 論文閱讀翻譯）

本人不多轉載別人的文章，但看了這篇文章感受很是不錯，我不曉得這篇文章是不是此人原創翻譯的，但給點個贊吧，加油

轉載於：http://blog.csdn.net/hust_sheng/article/details/47614925

摘要：

         Tachyon是一種分佈式文件系統，能夠藉助集羣計算框架使得數據之內存的速度進行共享。當今的緩存技術優化了read過程，可是，write過程由於須要 容錯機制， 就須要經過網絡或者是磁盤進行復制操做。 Tachyon經過將「血統」技術引入到存儲層進而消除了這個瓶頸。建立一個長期的以「血統機制」爲基礎的存儲系統的關鍵挑戰是失敗狀況發生的時候及時地進行數據恢復。 Tachyon經過引入一種檢查點的算法來解決這個問題，這種方法保證了恢復過程的有限開銷以及經過資源調度器下進行計算所須要的資源獲取策略。咱們的評審展現了 Tachyon的write性能超過HDFS達到100X，也將 現實 工做流的端到端的負載提高了4X。

 

（補充）：

         Tachyon是Spark生態系統內快速崛起的一個新項目。 本質上，  Tachyon是個分佈式的內存文件系統， 它在減輕Spark內存壓力的同時，也賦予了Spark內存快速大量數據讀寫的能力。Tachyon把內存存儲的功能從Spark中分離出來， 使Spark能夠更專一計算的自己， 以求經過更細的分工達到更高的執行效率。

        Spark平臺具體問題主要有如下幾個：

1. 當兩個Spark做業須要共享數據時，必須經過寫磁盤操做。好比：做業1要先把生成的數據寫入HDFS，而後做業2再從HDFS把數據讀出來。在此，磁盤的讀寫可能形成性能瓶頸。
2. 因爲Spark會利用自身的JVM對數據進行緩存，當Spark程序崩潰時，JVM進程退出，所緩存數據也隨之丟失，所以在工做重啓時又須要從HDFS把數據再次讀出。
3. 當兩個Spark做業需操做相同的數據時，每一個做業的JVM都須要緩存一份數據，不但形成資源浪費，也極易引起頻繁的垃圾收集，形成性能的下降。 

介紹：

         雖然如今有不少程序框架和存儲系統用來改善大規模數據的並行處理性能，可是，這些系統的瓶頸都是I/O操做過程，目前的解決方法是經過cache進行數據緩存。可是隨之而來的問題就出現了，cache能夠顯著改善read性能，可是由於容錯的須要，必須經過節點之間的數據傳遞對「寫的數據」進行復製備份，可是，因爲節點之間數據複製的過程當中網絡的延遲以及吞吐率性能的低下，致使即便數據被複制存儲在內存中，write過程的性能也不好。

         write性能低下會嚴重影響到job工做流的性能，由於job之間會彼此影響。爲了改善寫性能，咱們提出了 Tachyon（一個基於內存的存儲系統）來實現write和read的高吞吐率，同時沒有犧牲容錯機制。 Tachyon經過利用「血統「繞開了重複複製帶來的吞吐率的侷限性。採用的方法是經過再次對task之上的操做進行計算來 恢復 出錯或者丟失的數據（跟Saprk的容錯機制是同樣的，只是在 Tachyon進行存儲的階段也是採用「血統」機制 ）而無需進行數據備份。

         然而，將「血統機制」引入接二連三的分佈式存儲系統中也是有必定挑戰的。

         （1）第一個挑戰是，如何限制一個長期執行的存儲系統的重複計算（容錯操做）的開銷。該挑戰對於一個單一的計算job是不存在的，好比一個Mapreduce job或者是一個Spark job，由於在這種狀況下重複計算的時間被job的執行時間所限制。相反， Tachyon的執行過程是不肯定的，這意味着重複計算的時間可能沒法被限制。有一些框架好比Spark Streaming經過週期性（能夠本身設置時間間隔）地設置檢查點（checkpoint操做,設置checkpoint目錄進行數據備份以及執行位置的標記）能夠避開這個問題，但不幸的是， Tachyon中基本不能照作，由於存儲層不能感知到job當前的執行語義，job的計算特性的分類也十分普遍複雜。尤爲是，當 可用的帶寬沒法知足 數據的寫速度，固定時間間隔的檢查點操做可能會致使無限制的數據恢復操做（由於job的執行狀況是透明的，因此checkpoint設置的合理性相當重要）。相反，基於「血統圖」進行數據檢查點設置的 選擇反而能夠對重複計算過程進行限制。

         （2）第二個挑戰是如何爲重複計算過程獲取資源。好比，若是job之間有優先級的話， Tachyon在一方面必須確保重複計算獲取到足夠的資源，在另外一方面，重複計算不能影響到當前具備高優先級的正在執行的job的性能。

         解決上述挑戰的方法：

         （1）第一個挑戰： Tachyon在後臺經過異步執行某種算法不斷的對相應文件設置檢查點（文件信息備份）來解決第一個挑戰。咱們也提出了一個新奇的算法來決定什麼時候以及選擇哪個文件來檢查，這個算法叫作邊沿算法（Edge algorithm ），這種算法對重複計算的開銷進行了較好的限制。

           （2）對於第二個挑戰， Tachyon提供了一種資源申請方案，該方案能夠作到：準守嚴格的job優先級並按照權重進行資源分配。

         論文最終獲得的結論是： Tachyon的write性能超過HDFS達到100X，也將現實工做流的端到端的負載提高了4X（相對基於內存的 HDFS ）。另外， Tachyon能夠將複製備份引發的網絡傳輸減小高達50%。最後，基於對Facebook和Bing的跟蹤，能夠發現 Tachyon的重複計算開銷佔用的集羣資源不超過1.6%。

         更爲重要的是，因爲複製備份操做的固有帶寬限制，將來，一個基於「血統」的容錯模型多是讓集羣存儲系統可以匹配內存計算的惟一方法。

背景：

•  （待改善的）目標的工做負載屬性
  

1. 數據的不變性。數據一旦進行write就不可變了，存儲系統只是提供數據之上的擴展操做。
2. 肯定性的工做任務。MapReduce和Spark等框架都要求用戶代碼肯定的狀況下執行「血統」機制。對於工做任務不具備肯定性的框架，就採用複製備份進行容錯處理。
3. 基於位置的調度。MapReduce和Spark等框架都是基於位置進行調度的，這樣能夠儘量地減小網絡傳輸的開銷。
4. 應用的工做區必須在內存，數據能夠在磁盤。
5. 儘可能進行程序操做的複製，而儘可能避免數據的複製。由於操做的複製開銷要更小。（好比：相同的操做在大量數據之上反覆被執行，代碼書寫的過程當中，要選擇讓操做程序進行屢次複製，而不是讓數據進行復制）

• 避免複製操做（避免memory與其餘媒介進行數據交換）的情景

    一些基於內存的計算框架例如Spark確實加速了一些特定job的執行速度，可是，不一樣種類的job之間可靠的數據共享卻成爲瓶頸。

    

    從上圖能夠看出，如今主流系統使用的媒介，HDD、SDD以及網絡傳輸所支持的帶寬都遠遠小於內存支持的帶寬。

    大數據處理過程當中的數據共享開銷每每會主導流水線端到端的時延。

    現實中的數據代表有34%的job， 其 輸出的 數據量 至少等於輸入的數據量，在集羣計算的過程當中，這些job就會限制write的吞吐率。

    硬件的改進沒法解決上述問題。一個節點之上，內存的帶寬比disk整體帶寬要高出1~3個數量級。SDD的出現也沒有太大做用，畢竟它相對磁盤的主要優點是隨機訪問的性能提高，而不是連續的I/O帶寬的提高（表中可見），後者纔是關鍵。

設計綜述：

•  系統架構
  

    Tachyon由兩層組成：「血統」和持久化存儲。「血統」層級提供很高的I/O吞吐率而且會追蹤job執行的連續過程。持久化層主要被用於異步檢查，持久化層能夠是任何以數據備份爲基礎的存儲系統，HDFS，S3等。

    

     Tachyon採用了標準的master/slave架構：爲了管理元數據，master必須包含一個workflow manager，該管理器的做用就是跟蹤「血統」信息，計算檢查點操做的順序（對應第一個挑戰）以及與集羣資源管理器進行交互來爲從新計算申請資源（第二個挑戰）。

    每個worker上都跑着一個守護進程用來管理本地資源而且按期將worker狀態報告給master節點。另外，每個worker節點都會用RAMdisk來存儲 內存映像文件，用戶的應用能夠繞過守護進程直接和 RAMdisk進行交互，這樣，一個具備數據本地性的應用能夠避免沒必要要的數據拷貝，之內存速度進行數據交互。【內存文件管理系統】

• 舉例

    

    須要注意的是，「血統」信息是存儲在 Tachyon的持久化層的。

    咱們都知道， Tachyon會經過避免複製備份來改善write性能，然而，複製備份對於不少job同時read讀取相同的數據的狀況有明顯的優化做用。雖然， Tachyon使用「血統」機制避免了數據的複製備份，可是 Tachyon並非徹底沒有數據備份的。 Tachyon也使用客戶端cache技術來對頻繁讀取操做的狀況進行優化：當一個文件不在當前機器時，該文件會被從遠程機器上讀取過來而且緩存在 Tachyon本地的cache裏面，這是 Tachyon中的數據備份現象 。

• API總結

    須要特別說明的是， Tachyon自己就是一個標準的文件管理系統，支持全部標準的文件管理操做，除此以外還提供了獲取job操做過程的「血統」信息的API接口。而且，使用者若是僅僅將 Tachyon做爲傳統的文件管理系統來用，而不使用 Tachyon的「血統」的API接口，這種狀況下，write性能將不會獲得改善，讀寫性能與其餘文件系統好比HDFS差很少。

• Lineage Overhead（「血統」開銷）
  

    從存儲的方面來講，「血統」信息被累積存儲在二進制文件當中，可是，根據微軟的數據統計：一個典型的數據中心平均天天執行1000個job，而且花費1TB大小的容量來存儲一年下來全部job執行生成的未壓縮的二進制文件，這樣的數據量對於一個很小的數據中心來講都是微不足道的。

    此外， Tachyon會對「血統」信息進行回收。 Tachyon在檢查完輸出文件以後會刪除「血統」記錄，這樣會明顯減小「血統」信息的大小。另外，在執行的過程當中，那些按期執行的job任務一般會變換參數屢次執行，在這種狀況下，只有一份程序的拷貝會被存儲。

• Data Eviction（數據回收）
  

    當數據量不超過內存大小的時候， Tachyon的執行性能很好，因此，問題就出現了：當內存佔滿的時候，數據如何回收呢？（有些數據使用率過低，須要移除內存，或者說從內存中刪除）對於那些數據密集型的應用，咱們在數據回收的時候考慮如下兩個因素：

    （1）訪問頻率

    （2）訪問的臨時本地性（75%的二次訪問都發生在6個小時以內）

    在上述特性的影響下，咱們使用 LRU（近期最少使用算法） 做爲默認的數據回收策略，固然LRU不必定適用於全部場景，因此 Tachyon同時也支持其餘的數據回收策略。在下一個張章節中，咱們會給出這樣的描述： Tachyon會將最大的文件除外的全部文件存儲在內存中，大的文件直接存儲在持久層。（就是spill過程）

•  Master Fault-Tolerance
  

     Tachyon經過master的備用節點進行master的容錯處理。主master將自身每一步 的操做 以日誌的形式都持久化存儲在持久層之中，當主master節點出錯的時候，備用節點經過讀取日誌（日誌的大小微不足道）將自身改變成爲與以前的master同樣的狀態。

• Handling Environment Changes
  

    還有一類問題 Tachyon會遇到，就是若是框架的版本變了或者是系統版本變了咱們如何經過「血統」信息 的二進制文件來支持重計算進而恢復文件數據。

    （1）咱們發現，系統變化以後，能夠經過以前設置的 檢查點進行計算恢復操做。所以，在計算環境改變以前，咱們須要作一些工做：

    a）全部當前未複製的文件都被設置檢查點（備份）；

    b）全部的新數據都被同步保存

    固然，除了上述操做，咱們能夠直接簡單地將全部數據進行復制便可。

    （2）還有一種方法來更加高效地處理這種狀況， 用虛擬機映像單獨保存所需的計算環境（不作介紹）。

• Why Storage Layer（爲何選擇存儲層）
  

    選擇將「血統」機制引入存儲層的緣由：

    （1）多個job在流水線中會造成複雜的「血統」關係；而且，在一個生產環境中，數據的生產者和消費者可能會在不一樣的框架下面（一個job過程能夠會涉及到多個框架之間的交互）。並且，僅僅在job級別或者是框架級別理解「血統」關係並無什麼卵用，咱們應該深刻到存儲層對「血統」信息進行統計。

    （2）一些信息只有存儲層知道，好比何時文件重命名了或者何時文件被刪除了，在存儲層構建的「血統」纔是最準確的。

檢查點：

    該部分實際上是對Tachyon第一個挑戰的解決說明。

     Tachyon利用 checkpoint算法來限制由於出錯致使的文件恢復的時間開銷。不像MapReduce或Spark的job那樣，生命週期很短， Tachyon的job的生命週期很長 ，也正由於「血統」信息的複雜，若是沒有檢查點的設置，那麼會須要很長的時間來執行重計算（血統過於複雜）。還有就是持續執行的像Spark Streaming這樣的數據流系統， 會獲取到當前執行的job的動做語義來決定在那些文件上以及什麼時候進行檢查點操做。 Tachyon沒法獲取到job具體的語義動做，可是也要進行檢查點的設置。

     Tachyon的檢查點設置的關鍵是」血統「容許後臺之內存的速度異步執行檢查點操做而不用中止寫操做，且 Tachyon後臺的檢查點操做具備很低的優先級，目的是避免影響當前存在的job任務。

    理想的checkpoint算法須要知足一下幾點：

    （1）限制重計算的時間。像 Tachyon這樣長時間執行的系統，造成的」血統「鏈也很長，因此對於失敗狀況下的重計算操做的耗時要加以限制，須要注意的是，一旦咱們限制了重計算的時間就意味着咱們須要限制重計算所需的資源。

    （2）爲」熱「文件進行檢查點操做

    （3）儘可能避免爲臨時文件進行檢查點操做

• Edge Algorithm
  

    基於上述特性，咱們設計了 Edge算法：

    首先， Edge將要檢查的文件選擇的是」血統「圖的葉子（邊沿）文件；

    其次， Edge會結合文件的優先級進行檢查點操做，即優先爲優先級高的文件設置檢查點。

    最後， Edge會將能夠放入內存的數據集進行內存緩存，那些太大的文件會直接存儲在持久層，若是很大的文件也存儲在內存，須要進行checkpoint的時候，就會出現內存與磁盤的數據交換。目的就是避免同步設置檢查點將write的速度下降到磁盤的速度。接下來依次進行分析。

Checkpointing Leaves

     Edge算法用DAG表示文件之間的關係，其中，文件是節點，文件之間的關係（B是某job read A以後生成的）造成DAG圖的邊（A-B）。這種算法對DAG圖的葉子（邊沿）節點進行檢查點操做。以下圖：

    

    上圖表示了 Edge算法的工做過程。一開始，集羣中只有兩個job在運行，並生成了A1，B1。 Edge算法對A1，B1進行了檢查點操做（備份），以後的階段，A3，B4，B5，B6成爲了葉子，並依次被進行檢查點操做，以後階段，A6，B9成爲葉子。若是在A6進行檢查點操做的時候出現了錯誤， Tachyon只須要對A4~A6的過程進行 從新計算。

Checkpointing Hot Files

     Tachyon分配優先級的策略是基於的是文件被讀取的次數，與cache回收的LFU（最近最不經常使用頁面置換算法）相似，保證了最頻繁被獲取的數據最早被進行checkpoint操做，這樣顯然能夠加快數據恢復速度（容錯處理）。

     Edge算法必須平衡葉子節點和優先級高的節點的checkpoint的操做。咱們經過下表進行分析。

    

    該表展現了來自雅虎的3000個節點的mapreduce集羣的文件使用次數統計。基於這個表，咱們認爲只要文件的訪問次數查過2次，該文件就屬於高優先級的文件。且基於該數據統計，發現86%的checkpointed文件都是葉子節點，所以，咱們能夠獲得這樣的結論：優先級高的文件最早被執行checkpoint操做 （優先級高的文件自己就少，大概只有14%，可是仍然在checkpointed文件中佔據14%的比例）。

    一個以複製備份爲基礎的文件系統必須複製每個文件，即便是job直接使用到的臨時文件（也須要進行備份）。可是 Tachyon很對會對臨時文件進行checkpoint（備份）操做，由於checkpoint操做針對的數據都比較靠後（葉子文件、優先級較高的文件），這樣就使得臨時文件在被執行checkpoint操做以前就會被刪除掉（nice啊！）。

Dealing with Large Data Sets（大型數據集的處理）

    job過程當中除了很大的文件以外的幾乎全部文件都被存儲在內存中。

    由於96%的活躍jobs能夠同時將本身的整個數據集保存在集羣的內存中去，同時 Tachyon的master節點配置爲能夠同步地將上述數據集一次性寫入磁盤。

    須要注意的是， 系統框架可能會遇到高叢發性（爆發性）的數據請求，在請求爆發期間， Edge算法會將內存中幾乎全部的葉子節點以及非葉子節點都進行checkpoint處理（爆發性的數據請求會提高非葉子節點優先級，最終致使幾乎全部的文件都checkpoint）。

     若是內存中的文件都是沒有被執行checkpoint的（特殊狀況），那麼 Tachyon會同時對這些文件進行checkpoint操做來避免產生較長的」血統「鏈。

Bounded Recovery Time

    咱們將對DAG圖上特定 葉子文件 i上執行checkpoint操做所花費的時間用Wi表示；將經過祖先轉換成葉子文件i的操做過程所花費的時間表示成Gi，能夠獲得：

     定理一： Edge算法能夠保證任何文件（發生錯誤）在3*M的時間被恢復，其中，M=maxi{Ti}，Ti=max(Wi, Gi).

    上述定理代表，重複計算與DAG圖的深度是無關的（ 當數據集在內存中的時候， cache的表如今重複計算的過程當中是同樣的）。

    上述對重複計算限制的 定理 沒法應用到checkpoint算法對優先級的考慮因素中去。可是咱們能夠很容易地獲得優先級下checkpoint操做對 重複計算的限制：若是對葉子文件進行checkpoint的時間花費是c（在總的重複計算的時間中佔用的比例），那麼，優先級的checkpoint操做佔用的時間就是1-c。

     推論二： 已知，對葉子文件進行checkpoint的時間花費是c（在總的重複計算的時間中佔用的比例）。Edge算法能夠保證任何文件（發生錯誤）在(3*M)/c的時間被恢復，其中，M=maxi{Ti}，Ti=max(Wi, Gi).

    

Resource Allocation資源申請

    該部分實際上是對Tachyon第二個挑戰的解決說明。

   雖然Edge算法已經對重計算進行了限制， Tachyon還須要一種資源分配策略用於調度job的重計算。此外， Tachyon還必須遵照集羣彙總現有的資源分配策略，好比均分或者是按照優先級分配。

    在不少狀況下會有空閒的資源能夠用於重計算，由於大部分計算中心計算資源的利用率只有30%~50%。當集羣資源用完的時候，就須要考慮到相關的資源的分配問題。舉一個例子，假如一個集羣資源被三個job J1，J2，J3佔據，同時有兩個 丟失的文件F1，F2，須要執行 R1，R2兩個job進行再計算才能夠恢復。J2僅僅須要F2。 Tachyon怎麼在考慮優先級的狀況下安排重計算過程？

     Tachyon的 一個解決方案是進行集羣資源的靜態分配，好比將集羣資源的25%分配給重計算過程。很顯然，若是沒有重計算任務這種方法限制了集羣的利用率。另外，採用靜態資源分配的策略，就會出現不少因素的影響，好比，上述狀況，若是更高優先級的jobJ3須要文件F2， Tachyon應該如何調整R2的優先級呢？所以，咱們須要明確三個目標：

    （1）優先級的配合度。若是一個低優先級的job須要文件，針對該過程的重計算過程應該儘量小地影響更高優先級的job。可是，若是該文件後來被一個更高優先級的job所須要，用於執行數據恢復工做的job的優先級應該提高。 （也就是說文件的恢復job的優先級會隨着獲取文件的job的優先級來決定）

    （2）資源共享。沒有重計算任務，集羣就執行正常任務 （不是靜態資源分配）。

     （3）避免重計算的串聯操做。出錯狀況發生的時候，同時可能不僅是一個文件會發生丟失，若是不考慮數據的依賴關係就對這些文件進行重計算可能會引發遞歸的重計算job的產生。

    咱們現提出能夠知足前兩個目標的策略，再來討論如何實現最後一個目標。

• Resource Allocation Strategy
  

     資源申請策略依賴於Tachyon所使用的調度方法。

     Priority Based Scheduler

    在優先級的調度器中，舉一個相似的例子。 假如一個集羣資源被三個job J1，J2，J3佔據，三個job各自的優先級是P1，P2，P3。

    方法是，默認狀況下全部的重計算job都只有最低的優先級，因此他們對其餘的job有最低限度的影響。然而，這樣會致使 「優先級反轉」 ：例如，文件F2的重計算job R2比J2有更低的優先級，此時當J2佔用集羣中全部的優先級的時候對F2文件進行獲取，R2是得不到執行資源的，J2由於得不到F2也會所以被阻塞 。

    咱們經過優先級的繼承關係來解決。當J2獲取F2的時候， Tachyon增長R2的優先級到P2。當J3獲取F2的時候，再將R2的優先級升至P3，以下圖所示：

    

     Fair Sharing Based Scheduler

    在共享調度中，J1，J2，J3各自分享W1，W1，W3的資源 （最小的分享單位是1）。

    在咱們的解決方法中，重計算的jobs一塊兒共享分配的資源，被 Tachyon分配好的的默認的資源Wr。當錯誤發生的時候，全部丟失文件的重計算job能夠共享到Wr中的「1個資源」。

    此時，當一個job須要上述丟失的文件的時候，請求數據的job的一部分資源會被轉移到那些針對這些文件的重計算job上去。好比，當J2須要F2的時候，J2會分到（1-a）*W1的資源，而R2會分到a*W1的資源。以下圖所示；

    上述的方法知足了咱們的目標。由於重計算的job的 資源來自須要該缺失文件的job，因此，該過程不會對其餘正常的job產生影響。

Recomputation Order

    若是執行重計算的過程當中沒有對重計算的操做限定順序，那麼程序遞歸地對丟失的文件調用重計算操做就會有很低的性能。好比，若是job的優先級很低的話，該job很一直等待資源。若是改job的優先級很高，那麼針對一個未來註定丟失的文件的前期計算就顯得徒勞無功了。因此工做流管理器提早決定好文件重計算的順序進而能夠對他們進行調度。

     爲了決定哪些文件須要進行重計算， 工做流管理器維護了一個DAG圖。DAG圖中的每個節點表明一個須要進行恢復的文件。在這個DAG圖中，存在窄依賴和寬依賴（概念和Spark的一致）。這些依賴關係造成的DAG圖是總的DAG圖的子圖。

    爲了構建這樣的DAG圖，工做管理器會對目標文件進行DFS，若是當前文件節點在存儲層可用的時候， DFS過程會中止。DFS訪問到的節點必須是須要被重計算的。DAG圖中的節點的計算順序是逆序的，就是說，只有孩子節點都變爲可用的時候當前節點才能夠開始計算。上述計算過程是資源管理器執行的。

Implementation（實現）

     Tachyon使用已經存在的存儲系統來做爲本身的持久化層，且 Tachyon還使用 Apache  ZooKeeper來主導master的錯誤容忍。

• Lineage Metadata
  

    （1）Ordered input files list

    由於文件名可能會發生變化，可是每一個文件在順序表中都有一個獨特的不可變的文件ID，這樣就能夠保證應用在未來可能會出現重計算的狀況，若是發生的話，重計算的時候就能按照程序第一次執行時候的順序來讀取相同的文件進行後續操做。

    （2）Ordered output files list

    該列表與   input files list原理同樣。

    （3）Binary program for recomputation

    不少種方法實現一個重計算程序。一種天真的方法是爲每個應用寫一個有針對性的程序，一個稍微有點素養的程序員都不會這樣作的。另外一種方法是寫一個相似於「裝飾器」的程序，該程序既能「讀懂」Tachyon的 「血統」信息，又能理解 應用的邏輯關係。雖然這樣的程序貌似很是靈活，可是也只能在一些特殊的框架（兼容這樣的「裝飾器」）下實現。

    （4） Program configuration

    關於所需的配置文件，Tachyon使用「裝飾器」程序讀取配置文件：在「血統」提交的時候使用 」裝飾器「對配置文件進行序列化，以後在重計算階段解序列化。

    （5）Dependency type

    寬依賴和窄依賴。

• Framework Integration（框架整合）
  

    程序運行的過程當中，在它寫文件以前會將一些信息提交給 Tachyon，而後，當程序寫文件的時候， Tachyon會判斷該文件是否在」血統「之中，若是在，該文件就能夠被寫入內存（說明要採用」血統「機制進行容錯處理）。若是文件須要進行重計算， Tachyon會使用以前的」裝飾器「程序將文件的」血統「信息以及丟失的文件列表提交給重計算程序來從新生成相關的數據。

• Recomputation Granularity（粒度）
  

    關於重計算的粒度選擇問題。首先，咱們能夠選擇的粒度是job，好比，一個map job產生了10個文件，可是有一個文件丟失了，對於job級別的恢復， Tachyon會恢復10個文件。其次，若是咱們選擇的粒度是task，這樣，執行過程會變得複雜，可是效率會提高不少。MapReduce和Spark的層級是task級別的。

Evaluation

    基礎平臺：

     Ama zon EC2 cluster with 10 Gbps Ethernet. Each node had 32  cores, 244GB RAM, and 240GB of SSD. We used Hadoop  (2.3.0) and Spark (0.9).

    （1）Tachyon

    （2） in-memory installation of  Hadoop’s HDFS (over RAMFS), which we dub MemHDFS.  MemHDFS的writes操做的重計算數據的恢復仍舊會藉助network，可是沒有了disk的性能限制。

    比較結果以下：

   性能：

1. Tachyon的write速度比MemHDFS快100X；
2. 對於 multi-job workflow而言Tachyon的處理速度是MemHDFS的4X；在出錯的狀況下，大約花費了1分鐘的時間進行數據庫的恢復。Tachyon要比快3.8X；
3. Tachyon幫助基於內存的框架，經過將虛擬機存儲轉移至堆外內存（直接受操做系統管理）來改善的延遲；
   
4. Tachyon恢復master的失敗僅僅須要不到1秒。
   

    異步檢查點的設置：

    Edge算法超過任何固定間隔的檢查點設置方法，分析代表 Tachyon能夠將數據複製備份引發的網絡交互降至50%。

    重計算的影響：

    重計算對其餘的job幾乎沒有影響；另外，經過對Facebook和Bing的跟蹤，重計算對集羣資源的消耗不會超過1.6%。

    接下來是具體的性能比較過程。

• 性能

    Raw Performance

    實驗中，集羣中的每個節點會開啓32個進程，每個進程讀/寫1GB的數據。結果以下圖：

    

    對於寫而言，Tachyon實現了15GB/sec/node的吞吐率。然而，儘管使用的是10Gbps的帶寬，MemHDFS的寫吞吐率只有0.14GB/sec/node，緣由就是因爲須要數據備份帶來的網絡瓶頸。咱們同時能夠看出，理論上在硬件之上採用一次備份的最大的性能也只有 0.5GB/sec/node。平均來看， Tachyon的write速度比 MemHDFS快100X，而理論上以複製爲基礎的write速度極限是 MemHDFS 的 30X。

    對於讀而言，Tachyon實現了38GB/sec/node。咱們經過加入cache緩存以及 short-circuit reads（數據的本地性）的方法優化了HDFS讀性能，可是MemHDFS也僅僅實現了17 GB/sec/node的速度。像這樣速度上2倍的差距的緣由就是，HDFS API由於調用了java I/O streams 仍然須要額外的內存數據備份。

    另外，Tachyon讀的性能要好於寫的性能，由於硬件的設計爲read留了更多帶寬。

    Realistic Workflow

    實驗中咱們測試Tachyon的工做流是基於一個媒體信息分析公司在一小時內執行較多job來進行的。包含週期性的提取、轉換、加載 （ETL過程：用來描述將數據歷來源端通過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。 ）過程以及針對job進行測量的相關報告。

    實驗運行的環境是擁有30個節點的EC2（ 亞馬遜彈性計算雲 ）集羣上面。整個工做流分爲20批次的做業，共包含240個job（其中每一個批次有8個Spark job以及4個MapReduce job）。每批做業讀1TB的數據併產生500GB的數據。咱們使用Spark的Grep job來仿真ETL應用，用MapReduce的WordCount來仿真測試分析的應用。且每批次的做業，咱們運行兩個Grep應用來提早處理數據，以後咱們運行WordCount做業來讀取處理以後的數據並計算最終的結果，獲得最終結果以後，數據就會被刪掉。

    咱們測量了Tachyon以及MemHDFS上面運行的工做流的端到端的延遲。爲了模仿真實的場景，元數據一旦寫入系統咱們就開始進行測量。對 Tachyon而言，咱們還測量了一個node失敗的時間消耗。

    

    上圖展現了相關性能：

    能夠看出 Tachyon上的執行時間大約爲16.6min，而MemHDFS則用時67min。加速比大約爲4倍關係。當 Tachyon上發生失敗狀況的時候，時間也僅僅多耗費了1min，加速比仍舊有3.8倍。

    對 Tachyon而言，主要的負載是序列化和反序列化（空間開銷和時間開銷） ，這個實驗使用的是  Hadoop TextInputFormat（ 主要用於描述輸入數據的格式,功能： 數據切分和 爲Mapper提供輸入數據 ），若是使用更加高效的序列化模式，性能會有所提高。

    

    Overhead in Single Job（單個job的負載）

    當咱們運行一個單獨的job的時候，能夠發現Tachyon能帶來更小的負載而且能夠經過減小沒用的負載來改善內存框架的性能。咱們使用Spark的一個worker節點（不要Tachyon）來運行Word Count job，經過兩種方式進行緩存，一種是解序列化的java對象，一種是序列化的字節數組。相比較使用Tachyon進行緩存，當數據量小的時候，二者是相似的。當數據量變大的時候， Tachyon 更快，由於Tachyon避免了使用java的內存管理機制。Spark1.0.0已經將Tachyon做爲默認的堆外存儲方法。

    Master Fault Tolerance

     Tachyon使用 熱門線路備份（以前的等待master節點）來實現更快的master節點恢復。時延發現熱門線路備份能夠在0.5s以內取代當前出錯的master節點，且在標準偏差0.1s以內。上述實現的性能是可能的，由於取代的過程是備用master不斷 經過當前master的日誌文件數據來 獲取更新本身的數據信息。

• Asynchronous Checkpointing（異步檢查點的設置）
  

    Edge Checkpointing Algorithm

    咱們經過比較Edge算法和固定時間間隔的檢查點設置的算法來最終對Edge算法進行評估。 咱們用100個jobs模擬一個迭代的工做流，整個過程的執行時間聽從高斯分佈 （正態分佈 ）， 平均來看 每一個job用時爲10s。

     每一個job的數據輸出過程（write）都須要固定的15s的總時間來進行檢查點的設置。操做過程當中，任意時刻node均可能出錯。

    

    從上圖能夠看出，Edge算法優於固定時間間隔的算法。對固定時間間隔的策略而言，若是時間間隔設置的過小，檢查點的設置就跟不上程序執行速度。若是時間間隔設置太大，檢查點的設置間隔時間就會很長，數據恢復時間就會受到影響。而且，即便採用最優的固定時間間隔方法，性能也比不上 Edge算法，由於 Edge算法能夠根據程序執行的過程以及狀態進行檢查點設置的時間間隔的調整。

    Network Traffic Reduction

    那些採用數據複製進行容錯的文件系統在數據密集型的集羣中幾乎佔用了一半的網絡通訊。Tachyon能夠減小通訊的消耗，緣由是Tachyon在異步的檢查點設置的過程當中能夠避免對那些會被刪除的臨時文件進行檢查點的設置。帶寬節省下來了，性能天然會提高。

    分析以下：

    （1 ）T表示 job執行的時間 與 對job輸出的數據進行檢查點設置的時間 （網絡帶寬） 的比例。好比，測試一個Spark Grep程序，獲得T=4.5，說明job運行的速度是網絡帶寬的4.5倍。其實，T值的大小主要取決於網絡帶寬或者說是I/O。

    （2）X表示生成數據的job的百分比。

    （3）Y表示讀取前面job的輸出數據（組建「血統」）的job的百分比，若是Y=100，則會造成一個「血統」鏈，若是Y是0，則「血統」的深度就是1。

    所以，咱們嘗試着將X置爲60，將Y置爲84，並使用Edge算法 來模擬1000個jobs的執行過程。取決於T，經過複製備份操做以後保存下來的網絡通訊的百分比的狀況：當T=4是40%，當T>=10的時候是50%。（也就是說，X和Y固定的狀況下，檢查點設置操做的帶框越小，T越大，表示網絡通訊越快 ----Tachyon）

•  Recomputation Impact
  

    Recomputation Resource Consumption（消耗）

    咱們會經過計算模型以及對FaceBook和Bing的追蹤來計算重計算過程所需的資源。

    咱們的分析創建在下面的假設之上：

    （1）每一個機器的平均失效時間是3年。且若是一個集羣包含1000個節點，平均天天會有一個節點出現失敗的狀況。

    （2）能夠負擔的檢查點設置的吞吐率是200MB/s/node。

    （3）資源消耗用機器時間（machine-hours ）來測量。

    （4）分析的過程當中，認爲Tachyon僅僅在job級別，使用粗粒度的重計算在最差的狀況下進行測試（不用支持細粒度的task級別的重計算）

     Worst-case analysis

    最壞的狀況下，一個節點出錯，且其內存中的數據都是沒有設置檢查點的，須要task用超過200MB/sec的速度進行數據的再生。若是一個機器擁有128GB的內存，那麼須要655秒的時間重計算丟失的數據。即便數據是連續存放的，其餘的機器在這個過程都是阻塞的，由於這些機器都是須要依據這些數據進行並行計算的。在上述狀況下，重計算過程佔用了集羣運行時間的0.7%。

    上述的開銷是與集羣的大小和內存的大下呈線性關係的，若是集羣有5000個節點，每一個節點有1TB的內存，重計算的開銷能夠達到集羣資源的30%。

    Real traces

    現實的工做流程中，Tachyon的重計算的開銷要遠遠小於上述最差的狀況，由於job之間是獨立的，幾乎不會影響整個集羣，所以一個節點失敗不會阻塞其餘的節點。

    

    上圖根據對FaceBook和Bing的追蹤來比較不一樣內存和不一樣節點數的集羣資源佔用狀況，能夠看出正常狀況下Tachyon的性能 。

Related Work

• Distributed Storage Systems

    在大數據分析中，分佈式文件系統以及key/value存儲系統都是經過將數據複製到不一樣的節點進行容錯處理的。這些系統write的吞吐率是受到網絡帶寬的限制的。無論這些系統如何優化，他們的吞吐率與內存的吞吐率相比都查的很遠。Tachyon在存儲層使用「血統」的概念來避開復製備份的操做，且利用內存進行單一的存儲來提高性能。 Apache HDFS社區考慮將「血統」引入系統中，此靈感也是來自於Tachyon。

     【補充】 Batch-Aware Distributed File System（BAD-FS），該類型的系統有兩部分組成：

    （1） storage層expose了諸如caching、consistency、replication等一般固定的控制策略；

     （2）scheduler層使用這些控制來適應不一樣的工做流，這樣可以針對特定的工做流來處理例如cache consistency、fault tolerance、space management等問題，使存儲和計算協調一致。

     BAD-FS將傳統文件系統的各類控制從File system轉到了scheduler。這樣的好處是：提升性能；優化錯誤處理；簡化實現。

     [ BAD-FS]爲存儲過程單獨提供了一個調度器，提供額外的控制做用。用戶經過說明式的語言將jobs提交給調度器，系統也所以知道了jobs之間的「血統」關係。然而，爲了讓上述過程在並行大數據引擎上面成爲現實，有兩個基本的問題：

    （1）確保調度器和存儲層之間的交互是正確的，好比避免 死鎖或者是 優先級反轉狀況的出現。

    （2）限制重計算的時間

    對於第一個問題 （對應論文開始的資源申請的挑戰），咱們會提供避免死鎖或者是優先級反轉的機制，同時也會考慮到調度器的策略。對於第二個問題 （對應論文開始的限制重計算時間的挑戰），咱們會提供異步的檢查點設置算法，該算法利用「血統圖」在後臺不停地執行檢查點設置來確保優先的恢復時間。

• Cluster Computation Frameworks
  

    Spark在一個單獨job的執行過程當中使用「血統」信息，且運行在一個單獨的JVM裏面。Spark中不一樣的不一樣種類的查詢沒法用一個穩定且高吞吐率的方法來共享數據集（RDD），由於Spark是一個計算框架，而不是一個存儲系統。咱們經過將Tachyon與Spark進行集成，經過 進行穩定的數據集共享 充分改善了Spark jobs的工做流程處理性能 。而且，Spark在Tachyon的異步檢查點設置的過程當中也會受益，由於它實現了高吞吐率的write過程。

    其餘的系統好比MapReduce和Dryad（微軟的分佈式運算框架）也會在一個job的執行過程當中跟蹤task的「血統」信息。可是這些系統不像Spark能夠整合Tachyon，他們沒法跟蹤文件之間的關係，也所以沒法在不一樣的job之間提供高吞吐率的數據共享。

• Caching Systems 
  

     【補充】DryadLINQ 是一個把LINQ 程序（ LINQ即Language Integrated Query(語言集成查詢)，LINQ是集成到C#和Visual Basic.NET這些語言中用於提供查詢數據能力的一個新特性 ）轉化成分佈式計算指令，以便運行於PC集羣的編譯器。

     [ Nectar] 相似Tachyon， Nectar也會使用「血統」的概念，可是， Nectar僅僅服務於特定的程序框架 DryadLINQ，而且整合於傳統的，複製的文件系統中。 Nectar是一個數據複用系統，服務於 DryadLINQ查詢操做，目標是節省空間且避免多餘計算。

    （1） 節省空間：刪除大量無用文件，若是須要再次使用，就會從新運行產生這些文件的job。可是數據的恢復過程是沒有時間限制的。

    （2） 避免多餘計算：標示不一樣程序裏面比較廣泛的代碼塊進而找到那些通過相同計算獲得的文件，加以重複利用。做爲對比， Tachyon的目標是經過不一樣的基於內存的以及有限的數據恢復時間的框架來提供數據共享。

    [ PACMan]是一個基於內存的緩存系統，適用於數據密集型的並行工做。該系統探索了不一樣的策略，目的是讓數據倉庫的緩存效率更加高效。然而，PACMan沒有改善write的性能，也沒有改善第一次read的性能。

• Lineage
  

    除了上述領域，「血統」已經被應用在不少其餘的領域當中了，好比科學計算、數據庫、分佈式計算等等，也被應用在提供歷史數據的應用中。Tachyon在不一樣的環境下使用「血統」來實現內存速度的讀寫吞吐率。

• Checkpoint Research
  

    檢查點的設置已經成爲了一個很值得的研究領域。大多數的研究是在當失敗狀況發生的時候如何將從新計算的開銷最小化。可是，不像以前 使用同步的檢查點設置 的那些work操做， Tachyon會在後臺進行異步的檢查點設置，這樣的話就算一個檢查點設置操做沒有完成，也能夠經過「血統」來進行丟失數據的重計算。

Limitations and Future Work

     Tachyon致力於改善其目標工做多負載的性能，且評估也展現出了使人欣喜的結果。可是咱們也從中意識到了 Tachyon的侷限性，好比CPU密集型或者是網絡密集型的jobs的處理。另外，還有一些未來要面臨的挑戰：

    （1）Random Access Abstractions（隨機訪問抽象）

     運行jobs的數據密集型的應用會向 像 Tachyon這樣的 存儲系統輸出文件。一般，這些文件會被DBMS進行再加工來讓面向用戶的應用使用這些數據。所以，Tachyon提供高層次的只讀隨機訪問抽象，好比在已有的文件之上提供key/value接口，能夠縮短數據管道而且讓數據密集型的jobs輸出的數據當即變爲可用的數據。

    （2）Mutable data（可變的數據）

    「血統」通常沒法進行高效率的細粒度的隨機訪問更新也是挑戰之一。可是針對這個問題有不少的方向，好比定向更新一集批量更新。

    （3）Multi-tenancy（多重租賃 ）

    對於Tachyon而言，內存公平共享是重要的研究方向。像LRU/LFU這些策略能夠提供好的總體性能，可是要以對每個用戶進行隔離操做爲代價。另外，安全也是處理過程的另一個有趣的問題。

    （4）Hierarchical（分等級） storage

    雖然內存的容量每一年都是以置數形式增加的，可是相對於內存的替代品而言仍是很昂貴的。一個早期的Tachyon研究者表示，除了要使用內存這一層級， Tachyon也應該使用NVRAM（  非易失隨機存取存儲器 ）和SSDs。未來，咱們將會研究如何在 Tachyon中支持層級存儲。

    （5）Checkpoint Algorithm Optimizations

    咱們已經提出了Edge算法來提供一個受限的重計算時間。然而，也會有其餘的技術考慮到不一樣的度量標準，好比檢查點設置開銷，單個文件恢復開銷，多有文件恢復開銷等。咱們將這些改進留給社區來進一步探索。

Conclusion

    隨着以數據爲中心的工做負載開始存在於內存，write的吞吐率就成爲了應用的主要瓶頸。所以，咱們認爲以「血統」爲基礎的數據恢復的方法或許是惟一實現集羣儲存系統 加速 內存吞吐率的方法。咱們提出了 Tachyon，一個基於內存的存儲系統，該系統引進了「血統」來加速由決定性的批量jobs組成的工做負載的關鍵部分的處理。在讓Tachyon有實際用途的過程當中，咱們定位並解決了一些關鍵的挑戰。咱們的評估展現了Tachyon在目前的存儲方案上提供了可靠的加速。類似的方法也被HDFS社區採納以便在集羣中高效地利用內存。Tachyon目前已經開源。