为了账号安全,请及时绑定邮箱和手机立即绑定

Alluxio (前身为Tachyon) 加速 Spark 数据分析

标签:
Spark

今天解读的内容是来自 Spark Summit EU 2016 关于 Alluxio  的一个介绍:Effective Spark with Alluxio (视频:https://v.qq.com/x/page/w03736irdtp.html

背景介绍:

从网站(http://www.alluxio.org/),Alluxio 最简单的描述是:Alluxio, formerly Tachyon, enables any application to interact with any data from any storage system at memory speed. 也就是说,Alluxio(前身为Tachyon,可以简单的理解为基于内存的分布式缓存系统),它能够让应用以接近访问内存的性能访问存储在各种存储系统的数据。听起来挺牛的 :-)*

Alluxio 概览

webp

Alluxio 生态体系

它能够在计算引擎(MapReduce, Spark, Flink, Storm等)和存储系统(HDFS, S3, ceph等)之间进行解耦,比如,当应用/计算引擎需要访问存储在HDFS上的数据时,Alluxio 能够代表应用通过HDFS接口访问存储在HDFS上面的数据,并缓存在内存中。

Alluxio的能力:

  • 提供接近内存访问速度的读写能力

  • 跨不同的存储系统,提供统一的命名空间(namespace)

  • 良好的横向扩展能力

  • 提供文件系统访问 API

介绍中还提到,Alluxio社区相当活跃,甚至比Spark还活跃。


Spark 和 Alluxio 结合使用的案例

Baidu 通过 Alluxio 加速存储系统(Baidu文件系统)的访问速度/吞吐来提升交互式查询的性能,原来单纯基于Spark的作业需要100~150秒,使用 Alluxio 后,只要 10~15秒,有十倍左右的提升。


webp

alluxio_baidu.png


webp

alluxio_baidu1.png

BARCLAYS(英国的一家银行机构) 通过Alluxio完成不同spark作业间的数据共享来加速查询和风控模型的训练,原来的作业流迭代时间从小时级别降低到秒级。


webp

alluxio_barclays1.png


webp

alluxio_barclays.png

Qunar(去哪儿)使用Alluxio来加速网站的实时推荐系统,利用Alluxio统一的命名空间,屏蔽了由于数据存储在异构存储系统(HDFS和ceph)所带来的访问方法差异,让不同的应用和计算引擎(spark和Flink)更方便地访问这些数据。在性能方面,Alluxio为运行的作业各种作业(Spark批处理,Spark流作业和Flink作业)带来15~300倍提升。

webp

alluxio_qunar1.png


webp

alluxio_qunar.png


Using Alluxio with Spark

演讲中还提到,相对单纯的spark,使用Alluxio还有两个好处:

  1. 避免同一份数据缓存在不同spark executor内存中所带来的冗余;

  2. 避免由于单个spark executor宕机需要重新从磁盘甚至外部系统(如S3)读取数据,毕竟如果数据缓存在Alluxio中,一方面不会由于单个Alluxio服务/节点宕机导致Alluxio需要重新从源系统装载数据,另外一方面,spark能够以接近读写内存的速度从Alluxio读写数据;

性能评估

测试软件版本环境:Spark2.0.0 + Alluxio 1.2.0
测试运行环境:AWS(亚马逊云服务)虚拟机一个,r3.2xlarge 61G内存,其中51G分配给Spark或Spark+Alluxio
四个不同的配置模式:

  • Spark+Alluxio,其中,Spark executor 分配1G内存,Alluxio分配50G内存

  • Spark (存储级别为 MMORY_ONLY),分配51G内存

  • Spark (存储级别为 MMORY_ONLY_SER),分配51G内存

  • Spark (存储级别为 DISK_ONLY),分配51G内存

webp

alluxio_reading_cached_rdd.png

第一个测试的是读取已经缓存的RDD数据,横轴是RRD的大小(GB),纵轴是读取的时间(秒)。显而易见,Spark的DISK_ONLY(绿色)耗时最长,毕竟是直接从磁盘读取数据(这里应该是SSD磁盘)。
首先先看Alluxio模式,这个模式又分为 textFile 格式(蓝色) objectFile 格式(红色)两种场景,可以看出,在这两种场景中,随着RDD大小的增长读取时间线性增长,其中objectFile格式由于多了序列化和反序列化RDD的步骤,读取的时间会稍多一些。
其次,再看Spark的MEMORY_ONLY(橙色)和memory_ONLY_SER(紫色),他们都有一个折点,分别是10G和25G附近,究其原因,是由于分配给Spark的50G内存中,只有一部分是真正作为RDD的缓存,其余用于计算过程(比如排序等)的缓存。

webp

alluxio_reading_cached_dataframe.png

另外一个测试结果就是读取缓存的DataFrame(存储格式为 Parquet),和第一个测试结果类似,Alluxio 的textFile模式(蓝色),随着DataFrame的容量增大,读取时间线性增长。Spark的三种模式在20G左右都有一个折点。随着DataFrame越大,Alluxio的性能优势越明显。



作者:大数据技术峰会解读
链接:https://www.jianshu.com/p/6d6f7d3a678b

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消