Tachyon部署与使用指南

Tachyon部署与使用指南

Tachyon美[‘tæki:ˌɒn]

安装

1、目前tachyon的最新版本为0.8.2，目标spark版本是1.6，可以到http://tachyon-project.org/documentation/v0.8.2/Running-Spark-on-Tachyon.html页面查看需要的版本，根据spark选择合适版本的tachyon；
2、目前组内spark程序多通过yarn管理提交到hadoop集群运行，所以再根据hadoop版本选择合适的tachyon编译版本，以0.7.1版本的tachyon为例，到页面选择合适的包下载https://github.com/amplab/tachyon/releases/tag/v0.7.1。

Tachyon配置

参考:IBM博客tachyon集群配置
官方配置文档
zookeeper 配置
hadoop集群相关配置

主要配置如下几处：

• java Path:export JAVA_HOME=/usr/local/jdk-1.7.0_65
• hadoop路径（文件持久序列化的位置）:export TACHYON_UNDERFS_ADDRESS=hdfs://ip:900
• 内存大小：export TACHYON_WORKER_MEMORY_SIZE=15GB
• 日志路径与zookeeper路径：在TACHYON_JAVA_OPTS内添加 -Dtachyon.master.journal.folder=hdfs://ip:9000/tachyon/journal
  -Dtachyon.usezookeeper=true
  -Dtachyon.zookeeper.address=localhost:2181
• 文件系统权限：hadoop与本地相关目录的权限要设置成777，其他用户在执行spark程序时才能正确使用tachyon

其他配置

因为公司的主机改了登录端口，而Tachyon目前并不支持修改登录port的设置，所以只能利用ssh配置文件hack解决这个问题，参考ssh conf

Tachyon集群管理

• ./bin/tachyon format 格式化存储
• ./bin/tachyon-start.sh all Mount 启动Tachyon集群

启动后可以在http://localhost:19999/home看到Tachyon的管理界面，在文件管理的选项下可以直接看到内存中文件的内容

• ./bin/tachyon-stop.sh 停止Tachyon集群

注意停止Tachyon集群时内存中文件会丢失，需要将文件序列化到HDFS来持久存储。

spark中配置和使用

在spark中使用时需要修改两处配置：

• 在spark-defaults.conf中增加spark.tachyonStore.url tachyon://localhost:19998
• 在spark-env.sh中增加export SPARK_CLASSPATH= base/../lib/tachyon−client−0.7.1−jar−with−dependencies.jar: SPARK_CLASSPATH

启动spark shell，
先执行语句，
sc.hadoopConfiguration.set(“fs.tachyon.impl”, “tachyon.hadoop.TFS”)，
然后就可以正常操作了。
val c= sc.textFile(“tachyon://localhost:19998/hahaha2”)

Tachyon技术背景

Tachyon是一个分布式文件系统，提供了一种可靠的方式，可以以访问内存的速度在不同的分布式计算框架之间共享数据。Tachyon使用lineage技术实现容错，并通过一种检查点（checkpoint）算法来确保恢复以及资源开销在一定范围之内。据作者测试，Tachyon的写性能超过in-memory hbase 110倍，能为实际端到端工作流提高4倍性能。Tachyon目前已经开源并且在多个不同的企业、组织部署。

 近些年已经出现了大量计算框架，大规模并行数据处理的速度和复杂度都有极大的提升，但其中很大一部分性能依然受限于IO。依照传统的思路，对于IO性能问题一般引入cache来提升，但传统意义上在分布式计算系统中的cache虽然能极大提升read性能，但对于write的性能却帮助不大，这是因为分布式系统需要提供容错，而对于write动作一般采用在多个不同节点上保存副本来实现，但在内存中产生数据副本对于写性能会由较大影响 并且节点之间副本传输（内存到内存）受限于网络延时和吞吐量，相比直接使用本地内存进行cache性能会差很多。

 Tachyon是一个in-memory的存储系统，对于读和写有非常大的吞吐量，并且使用linage方式（当数据丢失时会根据源头数据以及一组操作重新构建数据）来替换掉replicate的方式从而解决了上述为了实现容错而牺牲性能的问题。

 lineage方式来实现容错其实在计算框架上已经有所应用，比如spark，但把这个技术放到一个存储系统上则有两个比较大的问题：第一，如何减小错误恢复开销。在一个长时间持续运行的系统中实现lineage，必须考虑到当错误发生时，数据可能已经演化了很久了，那么此时进行重构数据就需要经历很多步骤，时间开销很大。这种情况在普通的spark应用或者MapReduce应用中不会出现，这是因为通常来说缓存数据仅在一个Job的生命周期内有效，而作为一个存储系统则完全不一样：它是持续不断地运行在集群中的。有种类似的情况是Spark-streaming，Spark-streaming也是持续运行在集群中的，为了解决这个问题它引入了checkpoint，基于其计算框架的特性（例如RDD）来实现这一点。不过同样的方法在存储系统中就很难照搬过来，这是因为一个存储系统对于上层计算框架来说是透明的、通用的，它无法根据具体的计算框架特性来实现相应的checkpoint。

 第二个问题如何为数据重建提供资源。在进行数据重建时必须保证当前recomputation任务能够得到充足的资源以满足当前job的数据需要，且不能过度影响优先级更高的计算任务的执行性能。

 对于第一个问题，Tachyon在后台不间断地构建checkpoint file。为了实现这一方案，Tachyon引入了一种叫做Edge algorithm的算法，这种算法无需知道上层计算框架的特性，并且提供了一个数据重建开销上限。

 对于第二个问题，Tachyon基于两种集群资源分配模型（strict priority 和 weighted fair sharing），提供了依赖任务优先级的资源分配方案。举个例子：如果一个低优先级的任务请求一块已丢失的数据，重构任务会尽量减少占用的资源从而减小对高优先级任务的影响，但是如果之后有一个较高优先级的任务也请求了同一块数据，那么Tachyon会自动增加这块数据重构任务所占用的资源（权重增加了）。