Alluxio (前身为Tachyon) 加速 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 概览

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秒,有十倍左右的提升。


alluxio_baidu.png

alluxio_baidu1.png

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


alluxio_barclays1.png

alluxio_barclays.png

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

alluxio_qunar1.png

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内存
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的缓存,其余用于计算过程(比如排序等)的缓存。

alluxio_reading_cached_dataframe.png

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

扫描下方二维码,获取更多视频链接和PPT资料

大数据技术峰会解读公众号
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,132评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,802评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,566评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,858评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,867评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,695评论 1 282
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,064评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,705评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,915评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,677评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,796评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,432评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,041评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,992评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,223评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,185评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,535评论 2 343

推荐阅读更多精彩内容