Tachyon架構
三、Fault Tolerant
四、總結
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日由劉江更新）
原文鏈接：GigaOM，HighScalability
AMPLab開發的類Hadoop項目Tachyon介紹
在2013年4月，AMPLab共享了其Tachyon 0.2.0 Alpha版本的Tachyon，其宣稱性能爲HDFS的300倍，受到了極大的關注。截至目前（2013.7.22），其最新版本爲0.3.0-SNAPSHOT，項目地址爲：
https://github.com/amplab/tachyon/wiki
下面是官方對Tachyon的一個介紹：
Tachyon是一個高容錯的分佈式文件系統，允許文件以內存的速度在集羣框架中進行可靠的共享，就像Spark和 MapReduce那樣。通過利用信息繼承，內存侵入，Tachyon獲得了高性能。Tachyon工作集文件緩存在內存中，並且讓不同的 Jobs/Queries以及框架都能內存的速度來訪問緩存文件”。因此，Tachyon可以減少那些需要經常使用的數據集通過訪問磁盤來獲得的次數。
1. 特性：
- Java-like File API: Tachyon的原生API和java的文件系統非常相似，提供InputStream, OutputStream 接口, 和高效的 memory mapped I/O，用這些API能夠獲得最好的性能
- Compatibility: Tachyon 實現了Hadoop FileSystem 接口, 因此，Hadoop MapReduce和Spark可以不經過任何修改就能在Tachyon上運行。
- Native support for raw tables: Tachyon對列存儲結構的數據提供了原生的支持，用戶可以將某些訪問量高的列選擇性地放到內存中。
- Pluggable underlayer file system: Tachyon 提供memory data到底層文件系統的方法。目前支持HDFS和單點的本地文件系統。
- Web UI: 用戶可以通過瀏覽器瀏覽文件系統，在debug模式下，管理員可以查看文件的位置等詳細信息。
- Command line interaction: 用戶可以使用 ./bin/tachyon tfs和 Tachyon交互，例如將文件在Tachyon和本地文件系統中拷貝。
2. 項目依賴
Maven
<dependency>
<groupId>org.tachyonproject</groupId>
<artifactId>tachyon</artifactId>
<version>0.2.1</version>
</dependency>Ant
<dependency org="org.tachyonproject" name="tachyon" rev="0.2.1">
<artifact name="tachyon" type="jar" />
</dependency>3. 教程
Running Tachyon Locally: Get Tachyon up and running on a single node for a quick spin in ~ 5 mins.
Running Tachyon on a Cluster: Get Tachyon up and running on your own cluster.
Running Spark on Tachyon: Get Spark running on Tachyon
Running Shark on Tachyon: Get Shark running on Tachyon
Running Hadoop MapReduce on Tachyon: Get Hadoop MapReduce running on Tachyon
Configuration-Settings: How to configure Tachyon.
Command-Line-Interface: Interact with Tachyon through command line.
Tachyon Developer Preview presentation at Spark User Meetup (May, 2013)
4. 總結
本文對Tachyon的來源和特性進行了介紹。
博文轉自：http://ju.outofmemory.cn/entry/50616
該項目的另一個測試項目：
Tachyon-Perf
A general performance test framework for Tachyon.The master branch is in version 0.2.0-SNAPSHOT.
Prerequisites
As this project is a test framework for Tachyon, you need to get the Tachyon installed first. If you are not clear how to setup Tachyon, please refer to the guidelines here.
Currently the master branch of Tachyon-Perf supports testing tachyon-0.5.0 (the lastest released version). We also provide a special branch supports a version of Tachyon-0.6.0-Snapshot (Commit NO. 1f512044b939b9b0a2c58f64bca4516642daf8a8).
Please see this page to find out how to use Tachyon-Perf against the Tachyon-0.6.0-Snapshot.
The following shows how to run tachyon-perf, and you can add a new benchmark to tachyon-perf if needed. See more in How to add a new benchmark
參考網址（開源代碼可下載）：https://github.com/PasaLab/tachyon-perf