大資料時代——分散式記憶體檔案系統：Tachyon
Tachyon架構
Tachyon的架構是傳統的Master—slave架構，這裡和Hadoop類似，TachyonMaster裡WorkflowManager是 Master程序，因為是為了防止單點問題，通過Zookeeper做了HA，可以部署多臺Standby Master。Slave是由Worker Daemon和Ramdisk構成。這裡個人理解只有Worker Daemon是基於JVM的，Ramdisk是一個off heap memory。Master和Worker直接的通訊協議是Thrift。 下圖來自Tachyon的作者Haoyuan Li：
三、Fault Tolerant
Tachyon是一個分散式檔案儲存系統，但是如果Tachyon裡的容錯機制是怎麼樣的呢？ Tachyon使用血統這個我們在Spark裡的RDD裡已經很熟悉了，這裡也有血統這一概念。會使用血統，通過非同步的向Tachyon的底層檔案系統做Checkpoint。 當我們向Tachyon裡面寫入檔案的時候，Tachyon會在後臺非同步的把這個檔案給checkpoint到它的底層儲存，比如HDFS，S3.. etc... 這裡用到了一個Edge的演算法，來決定checkpoint的順序。 比較好的策略是每次當前一個checkpoint完成之後，就會checkpoint一個最新生成的檔案。當然想Hadoop，Hive這樣的中間檔案，需要刪除的，是不需要checkpoint的。 下圖來自Tachyon的作者Haoyuan Li：
關於重新計算時，資源的分配策略：
目前Tachyon支援2種資源分配策略：
1、優先順序的資源分配策略
2、公平排程的分配策略
四、總結
Tachyon是一個基於記憶體的分散式檔案系統，通常位於分散式儲存系統和計算框架直接，可以在不同框架內共享記憶體，同時可以減少記憶體冗餘和基於Jvm記憶體計算框架的GC時間。Tachyon也有類似RDD的血統概念，input檔案和output檔案都是會有血統關係，這樣來達到容錯。並且Tachyon也利用血統關係，非同步的做checkpoint，檔案丟失情況下，也能利用兩種資源分配策略來優先計算丟失掉的資源。
該專案的地址：http://tachyon-project.org/index.html
博文轉自：http://www.open-open.com/lib/view/open1409754088791.html
Tachyon架構分析和現存問題討論
Tachyon是AmpLab的Li Haoyuan所開發的一個基於記憶體的分散式檔案系統，出發點是作為AMPLAB的BDAS的一個組成部分
總體設計思想
從Tachyon的設計目標來看，是要提供一個基於記憶體的分散式的檔案共享框架，需要具備容錯的能力，還要體現記憶體的效能優勢
Tachyon以常見的Master/worker的方式組織叢集，由Master節點負責管理維護檔案系統MetaData，檔案資料維護在Worker節點的記憶體中。
在容錯性方面，主要的技術要點包括：
- 底層支援Plugable的檔案系統如HDFS用於使用者指定檔案的持久化
- 使用Journal機制持久化檔案系統的Metadata
- 使用Zookeeper構建Master的HA
- 沒有使用replica複製記憶體資料，而是採用和Spark RDD類似的Lineage的思想用於災難恢復（這一點後面再討論）
此外為了相容Hadoop應用，提供了HDFS相容的API介面
具體實現分析
初始化流程
Tachyon檔案系統的初始化，其實就是建立和清空Master/worker所需的工作目錄
對Master節點來說這些目錄包括底層持久化檔案系統上的Data/worker/Journal目錄，實際上這裡的Worker目錄是由Worker節點使用的（用於存放一些零時的持久化檔案，丟失Meta資訊的資料塊等），但是放在Master節點來建立，本質上是為了簡化建立邏輯（因為放在HDFS上，只建立一次）
對worker節點來說所需的目錄就是本地Ramdisk目錄
此外，在master的Journal資料夾中，會建立一個特定字首的空檔案用於標誌檔案系統格式化完畢
Tachyon Master的啟動過程
Tachyon Master的啟動過程，首先當然是要讀取Master相關配置引數，目前都是通過-D引數傳給Java的，理想的是通過配置檔案來做。目前這些引數，一部分是在Env檔案裡設定變數，再通過-D引數設定，也有的直接寫死在-D引數中的，也有啟動指令碼中預設未配置，在MasterConf程式碼裡使用了預設值的
通過讀取特定的format檔案判斷檔案系統是否格式化
接下來就是在記憶體中重建檔案系統資訊
Tachyon的檔案系統資訊依靠Journal日誌儲存，Journal包括兩部分，一是meta資訊在某個時刻的快照Image，二是增量Log。Tachyon Master啟動時首先從快照Image檔案中讀取檔案系統meta資訊，包括各種資料節點（檔案/目錄/Raw表/Checkpoint/依賴關係等）資訊，而後再從繼續EditLog（可能多個）中讀取增量操作記錄，EditLog的內容基本對應於Tachyon檔案系統Client的一些相關操作，包括檔案的新增，刪除，重新命名，資料塊的新增等等
需要注意的是，這裡的Log記錄不包括實際的檔案內容資料，只是meta資訊，所以如果Cache中的檔案內容丟失，如果沒有持久化，也沒有繫結相關lineage資訊，那麼對應的檔案的具體內容也就丟失了
檔案系統資訊恢復完畢以後，在Tachyon Master正式啟動服務之前，Tachyon Master會先把當前的Meta Data寫出為新的快照Image
在啟用zookeepeer的情況下，standby的Master會定期將Editlog合併並建立Standby的Image，如果沒有Standby的Master則只有在啟動過程中，才通過上述步驟合併到新的Image中。這裡多個Master併發操作Image的editlog，沒有Lock或者互斥的機制，不知道會不會存在競爭衝突，資料stale或丟失的問題
檔案的儲存
Tachyon存放在RamDisk上的檔案以Block（預設為1G）為單位劃分，Master為每個Block分配一個BlockID，Worker直接以BlockID作為實際的檔名在Ramdisk上儲存對應Block的資料
資料的讀寫
Tachyon的檔案讀寫，儘可能的通過Java NIO API將檔案直接對映到記憶體中，做為資料流進行讀寫操作，目的在於避免在Java Heap中使用大量的記憶體，由此減小GC的開銷，提升響應速度
讀寫過程中，所有涉及到Meta相關資訊的，都需要通過呼叫Tachyon Master經由Thrift暴露的ServerAPI來執行
Tachyon的檔案讀操作支援本地和遠端兩種模式，從Client API的角度來說對使用者是透明的。讀檔案的實現，其流程基本就是先從Master處獲取對應檔案Offset位置對應的Block的ID
而後連線本地Worker取得相應ID對應的檔名，如果檔案存在，Client端程式碼會通知Worker鎖定對應的Block，而後Client端程式碼直接對映相關檔案為RandomAccessFile直接進行讀操作，並不經由Worker代理讀取實際的資料
如果本地沒有Worker，或者檔案在本地worker上不存在，Client程式碼再進一步通過Master的API獲取相關Block所對應的Worker，而後通過Worker暴露的DataServer介面讀取對應Block的內容，在DataServer內部，同樣延續鎖定對應Block，對映檔案的流程讀取並將資料返回給Client
另外，基於讀資料的時候使用的TachyonFile的API介面，如果使用的是FileStream的介面，當遠端Worker也沒有對應檔案Block時，RemoteBlockInStream還會嘗試從底層持久化檔案系統層（如果存在對應的檔案的話）去讀取資料，而ReadByteBuffer介面則沒有對應的流程（個人感覺，應該做到兩種方式的行為匹配才對）。
Tachyon目前只支援本地寫操作，寫操作按寫入位置可以分為
Cache：寫到Tachyon記憶體檔案系統中
Through：寫到底層持久化檔案系統中
具體的型別是以上幾種情況的合法的組合，如單cache，cache +through等
還有一個Async模式：非同步寫到底層持久化檔案系統中，這個大概是為了優化那些資料需要持久化，但是又對效能Latency等有要求的場合
讀寫操作現存問題和併發操作相關
前面提到讀取資料時Client端會通知WorkerLock對應的Block。需要注意的是這裡的Lock實際上並沒有互斥的意思，只是一個標誌表示當前還有使用者在使用相關檔案和資料，這樣，在Worker需要分配記憶體淘汰舊的資料的時候，當前正在使用的檔案將不會被刪除。
而在寫操作過程中，目前的實現看來對併發處理相關的內容基本沒有考慮
例如Read操作已經Lock的檔案block，依然可以被主動Delete，不考慮lock的狀態，當然這一點可能和多數Linux類的Filesystem的設計一致，(但是Windows上顯然可能提示無法刪除）這個還要再研究一下在大資料分佈是環境下其它的設計實現是怎樣的
而寫操作本身的再入也沒有很處理好，不能支援併發是一個問題，單執行緒重寫檔案也會造成前面的資料塊的丟失或者資料塊的混合，當然，這也是因為目前還沒有考慮到支援這些情況。
Write目前不支援Append操作，這個和當前的設計也有很大的關係，block尺寸按檔案計算，尺寸固定，所以要Append就需要考慮必須在同一節點上寫資料，要不然就要支援遠端寫資料到當前Block所在的節點上，要不然就要支援動態Block大小。然後如果支援異地寫，還要考慮併發Append的問題，需要Lock檔案，阻止併發寫等，這些都是目前Tachyon所無法支援的
Raw Table表單
Tachyon所謂的Raw Table的支援，目前的實現，本質上只是一個分級(column)的檔案目錄，每個Colum下的一個Partition對應一個Tachyon檔案，從使用者的角度上來看，相對於直接構建這樣的目錄結構，僅僅是省去了為每個Partition命名，以及方面統一操作幾個檔案，實際上並沒有提供其它額外的輔助功能，如檢索等等
HDFS檔案介面
Tachyon提供了相容HDFS API的檔案操作介面，基本上就是提供了一個TFS拓展Hadoop的FileSystem介面，主要就是用Tachyon Client提供的介面實現HDFS對檔案相關資訊和Metadata的操作
在具體的資料讀寫上，則是在建立好資料流的基礎上，通過Tachyon的FileInStream和FileOutStream來執行
比較奇怪的是FileOutStream是直接傳遞給了Hadoop FSDataOutputStream，而FileInStream則進一步封裝成了HdfsFileInputStream再傳遞給Hadoop FSDataInputStream使用，理論上難道不是應該只要實現Java InputStream的類就可以了麼，其它API介面應該是Hadoop FSDataInputStream實現的
White list/ pin list功能？
White list和 pin list以路徑字首的方式儲存一些URLpath用作Filter，用作設定預設需要載入到記憶體中的檔案
White List的設計意圖是在讀取資料時自動嘗試在記憶體中Cache對應檔案，但是具體的實現貌似僅僅設定了標誌位，但是沒有完成相關功能？實際使用Tachyon API時需要指定Read Cache Type來指定需要Cache對應檔案
PinList的目的是保證對應的檔案常駐在記憶體中，目前的實現：在寫資料時，強制要求要有足夠的記憶體空間否則出錯。在Worker端，當記憶體空間不足，需要淘汰資料，釋放空間時，也會忽略PinList列表中的檔案。但是在讀資料的路徑上，如果由於某種原因，對應檔案不在記憶體上，需要從底層持久化檔案系統中獲取的話，PinList並不能保證自動Cache這些檔案在記憶體中，依然依賴於Read檔案時使用的read Cache type
總結
總體而言，目前Tachyon的功能基本可以看作就是：對外提供了一個以順序檔案流的方式，寫本地記憶體，讀本地和遠端記憶體的介面，持久化特定檔案，同時相容HDFS API。其處理記憶體丟失和替換資料的方式使其更像一個Cache系統而非檔案系統。其它的各種額外輔助功能都還不完善。就其實現的部分，各級component包括IPCProtocol，配置，Image，Data API設計，各種異常處理乃至併發處理架構等方面，個人感覺實現方式略顯簡單粗暴，可以理解為以實現快速原型為思想設計的，存在一定的改進的空間，或者需要考慮優化設計方案。
而前面提到的做為容錯設計上，最重要的Lineage的設定，（這也是作者的論文的核心內容所在，畢竟其它部分如果從學術的角度上來說並沒有太大創新，而只是具體的工程實現）目前看來，似乎並沒有很理想的實現，或者說在實際應用場合中有比較多的侷限性？大概需要一個說服力比較強的Case來證明其實用性和適用性（當然，或者是我沒有看到更多的這方面的程式碼，據說有更多的相關實現還沒有public？）
博文轉自：http://blog.csdn.net/colorant/article/details/22385763
Spark & Shark & Tachyon 簡介
Spark是一個高效的分散式計算系統，相比Hadoop，它在效能上比Hadoop要高100倍。Spark提供比Hadoop更上層的API，同樣的演算法在Spark中實現往往只有Hadoop的1/10或者1/100的長度。
Shark類似“SQL on Spark”，是一個在Spark上資料倉庫的實現，在相容Hive的情況下，效能最高可以達到Hive的一百倍。
Tachyon是一個高效的分散式儲存系統。目前釋出的為整體專案的部分功能（快取部分），此部分功能在一次寫、多次讀的環境下為系統的效能帶來最大的提升。
博文轉自：http://blog.csdn.net/lijiajia81/article/details/17080715
Tachyon：吞吐量超過HDFS 300多倍 來自伯克利的分散式檔案系統
Hadoop裡的HDFS已經成為大資料的核心基礎設施，覺得它還不夠快？近日，美國加州大學伯克利分校的AMPLab開發的分散式檔案系統Tachyon受到了廣泛關注。
Tachyon（英文超光子的意思，指假想的比光還快的粒子）的特點是充分使用記憶體和檔案物件之間的世代（lineage）資訊，因此速度很快，專案自己號稱最高比HDFS吞吐量高300倍。
實際上，不僅僅是要用Tachyon試圖取代HDFS，AMPLab已經完全重建了一套類似Hadoop的大資料平臺，“沒有最快，只有更快”。AMPLab在大資料領域最知名的產品是Spark，它是一個記憶體中並行處理的框架，Spark的創造者聲稱：使用Shark執行並行處理Job速度要比MapReduce快100倍。又因為Spark是在記憶體執行，所以Shark可與Druid或者SAP's HANA系統一較高下。Spark也為ClearStory下一代分析和視覺化服務提供處理引擎。如果你喜歡用Hive作為Hadoop的資料倉庫，那麼你一定會喜歡Shark，因為它代表了“Hive on Spark”。
AMPLab的最新目標就是Hadoop分散式檔案系統（HDFS），不過HDFS在可用性和速度方面一直受人詬病，所以AMPLab建立了Tachyon（ 在High Scalability上非常奪目，引起了Derrick Harris的注意），“Tachyon是一個高容錯的分散式檔案系統，允許檔案以記憶體的速度在叢集框架中進行可靠的共享，類似Spark和 MapReduce。通過利用lineage資訊，積極地使用記憶體，Tachyon的吞吐量要比HDFS高300多倍。Tachyon都是在記憶體中處理快取檔案，並且讓不同的 Jobs/Queries以及框架都能記憶體的速度來訪問快取檔案”。
當然，AMPLab並不是第一個對HDFS提出質疑的組織，同時也有很多商業版本可供選擇，像Quantcast就自己開發了開原始檔系統，聲稱其在執行大規模檔案系統時速度更快、更高效。
誠然，AMPLab所做的工作就是打破現有商業軟體的瓶頸限制。如果碰巧破壞了現狀，那麼就順其自然吧！不過，對於使用者來說，AMPLab只是為那些尋找合適工具的人員提供了一種新的選擇，AMPLab的合作伙伴和贊助商包括谷歌，Facebook，微軟和亞馬遜網路服務，它們當然非常樂意看到這些新技術，如果很有必要的話。
AMPLab的其他專案包括PIQL，類似於一種基於鍵/值儲存的SQL查詢語言；MLBase，基於分散式系統的機器學習系統；Akaros，一個多核和大型SMP系統的作業系統；Sparrow，一個低延遲計算叢集排程系統。（文/王鵬，審校/仲浩，文章2014年4月19日由劉江更新）
AMPLab開發的類Hadoop專案Tachyon介紹
在2013年4月，AMPLab共享了其Tachyon 0.2.0 Alpha版本的Tachyon，其宣稱效能為HDFS的300倍，受到了極大的關注。截至目前（2013.7.22），其最新版本為0.3.0-SNAPSHOT，專案地址為：
下面是官方對Tachyon的一個介紹：
Tac