Spark技术解析及在百度开放云BMR应用实践

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特性以及百度未来的工作，其中包括缓存替换策略等。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友