Tachyon是一个分布式的内存文件系统，可以在集群里以访问内存的速度来访问存在Tachyon里的文件。Tachyon是架构在分布式文件存储和上层各种计算框架之间的中间件，主要负责将那些不需要落到DFS里的文件，落到分布式内存文件系统中，从而达到共享内存，以提高效率。1月10日下午的最后一场分享中，刘少山带来了一场Tachyon的深入解析。
Tachyon和Spark
刘少山表示，在Spark使用过程中，用户经常困扰于3个问题：首先，两个Spark 实例通过存储系统来共享数据，这个过程中对磁盘的操作会显著降低性能；其次，因为Spark崩溃所造成的数据丢失；最后，垃圾回收机制，如果两个Spark实例需求同样的数据，那么这个数据会被缓存两次，从而造成很大的内存压力，更降低性能。
使用Tachyon，存储可以从Spark中分离处理，让其更专注于计算，从而避免了上述的3个问题。
Tachyon架构
刘少山从Spark的角度分享了Tachyon的部署。在与Spark搭配使用时，系统会建立一个Tachyon的job，通过Tachyon Client来访问同一个机器上的Tachyon Worker，也就是机器上的内存。而Tachyon Client则会与Tachyon Master交互，来清楚每个分节点所包含的数据。由此可见，在整个Tachyon 系统中，Master、Client和Worker为最重要的三个部分。
Tachyon Master。Master主要部件是Inode和Master Worker Info：Inode会负责系统的监视，Master Worker Info则存储了所有Worker的信息。
Tachyon Worker。Worker主要负责存储，其中Worker Storage是最主要的数据结构，包含Local data folder和Under File System两个部分。其中Local data folder表示存在本地的Tachyon文件，Under File System则负责从HDFS中读取Worker中未发现的数据。
Tachyon Client。Client为上层用户提供了一个透明的机制，其TachyonFS接口负责数据请求。每个Client中有多个Tachyon File，其中Block In Stream负责文件读取（Local Block In Stream负责本地机器读取，Remote Block In Stream则负责读取远程机器）；Block Out Stream主要负责将文件写到本地机器上。在Client上，Master Client会与Master交互，Worker Client则与Client交互。
Tachyon在百度
为什么要使用Tachyon，刘少山指出，在百度，计算集群和存储集群往往不在同一个地理位置的数据中心，在大数据分析时，远程数据读取将带来非常高的延时，特别是ad-hoc查询。因此，将Tachyon作为一个传输缓存层，百度通常会将之部署在计算集群上。首次查询时，数据会从远程存储取出，而在以后的查询中，数据就会从本地的Tacnyon上读取，从而大幅的改善了延时。
在百度，Tachyon的部署还处于初始阶段，大约部署了50台机器，主要服务于ad-hoc查询。
实践中遭遇的挑战
通过刘少山了解到，Tachyon的使用过程并不是一帆风顺，比如：因为Tachyon需求对Block完全读取，从而可能造成Blocks并未被缓存；有时候，虽然scheduler已经确认了数据存在本地，Spark workers仍然从远程blocks读取，而缓存命中率也只有可怜的33%（如果你需要的是2号block，Tachyon会分别从1、2、3号block读取，从而将block读取了3份）。因此，刘少山表示，如果要使用好Spark与Tachyon，一定要对用例和Tachyon进行充分的了解。
分享最后，刘少山还介绍了Hierarchical Storage Feature特性以及百度未来的工作，其中包括缓存替换策略等。
