中国领先的IT技术网站
|
|

逆水行舟,看前行中的Spark

近两年,Spark技术发展速度惊人,用户越来越多,社区也愈加活跃,生态更加丰富,这些都证明了Spark的魅力。在生态建设上,Spark取得了极大的成功,主要体现在Application、Environment及Data Source三个方面。

作者:来源:linkgou.com|2015-09-25 11:26

沙龙活动 | 去哪儿、陌陌、ThoughtWorks在自动化运维中的实践!10.28不见不散!


近两年,Spark技术发展速度惊人,用户越来越多,社区也愈加活跃,生态更加丰富,这些都证明了Spark的魅力。在生态建设上,Spark取得了极大的成功,主要体现在Application、Environment及Data Source三个方面。此外,值得一提的是,Spark的贡献者目前已经超过650人,而另一方面,围绕Spark创业的公司同样随之增多,“Spark as a Service”的概念被越来越多的人接受,Spark的未来值得期待。在本文中,国内最早的Spark研究者与使用者、七牛云存储技术总监陈超将为您解读Spark技术及其生态系统的最新进展。(本文已被选登在程序员电子版2015年9月A刊)

到目前为止,Spark看起来一帆风顺,但事实上,大数据这个领域从来不缺强者,其中最具代表性的无疑当属Flink(https://flink.apache.org)。Flink采了MPP的思想,具备很多有意思的设计和特性。本文不准备用过多的篇幅介绍Flink,主要给大家分享Spark最近几个极其重要的改进。注意,下面所提到的改进有些已经实现,而有些尚未完成。

1. Project Tungsten

Spark近期的发展中,最引人瞩目的当属钨丝计划(Project Tungsten)。Kay Ousterhout在名为“Making Sense of Performance in Data Analytics Frameworks”的论文中谈到,类似Spark这样的计算框架,其瓶颈主要在于CPU与内存,而不是大家之前所认为的磁盘IO及网络开销,因为带宽增大、SSD或者磁盘阵列的使用均可以缓解这个问题。但是在序列化、反序列化及Hash等场景下,CPU确实能形成瓶颈,Tungsten的启动就是为了解决这些问题。Tungsten主要包含以下三个方面。

内存管理与二进制处理。

毋庸置疑,JVM确实是个非常优秀的平台,但是短板也非常明显,那就是GC,而Java对象的内存开销同样不能忽视。基于这个问题,Spark选择自己管理内存,所用的工具就是sun.misc.Unsafe。如果大家对细节有兴趣,可以关注BytesToBytesMap结构。需要注意,它是append-only的,并且key与value都是连续的字节区域。自己管理内存不仅缓解了GC的压力,也显著地降低了内存使用。但这里必须提醒大家,Unsafe千万不能滥用,否则后果很严重。

缓存友好的计算。

目前,大家看到缓存似乎都只想到将数据加载到内存就完事了。事实上,更佳的做法应该是CPU级别的缓存。因此,Spark自1.4版本开始便在这个点上发力,其中,最重要的当属在 Aggregations、Joins和Shuffle时可以更有效地排序和哈希。Spark引入了UnsafeShuffleManager这个新的ShuffleManager。它的好处是可以直接对二进制数据进行排序,从而减少了内存占用,也省去了反序列化的过程。这里大家可以注意下UnsafeShuffleExternalSorter,可以称得上整个优化的基础。实际上,CPU反复从内存读取数据在一定程度上阻碍了CPU的Pipeline操作。

代码生成(Code Gen)。

熟悉LLVM的朋友应该能较好地理解这一点,之前的Spark SQL已经在使用该部分了。近日发布的Spark 1.5中,Code Gen得到了更加广泛的应用。需要Code Gen的原因很简单,它能免去昂贵的虚函数调用,当然,也就不存在对Java基本类型装箱之类的操作了。Spark SQL将Code Gen用于表达式的求值,效果显著。值得一提的是,在Spark 1.5中,Spark SQL将Code Gen默认打开了。

Tungsten的部分就先谈到这里,整个项目的完成需要等到1.6版本。不过1.4与1.5已经逐步融入了Tungsten的部分优化,让大家可以及时感受Tungsten带来的各种改进。

2. Dynamic Resource Allocation

严格地讲,动态资源分配(Dynamic Resource Allocation)这个特性在Spark 1.2时就出现了,那时只支持在YARN上对资源做动态分配。在Spark 1.5中,Standalone及Mesos也将支持这个特性,个人认为此举有较大意义,但大家仍需充分了解该特性的使用场景。

在Spark中,动态资源分配的粒度是Executor,通过spark.dynamicAllocation.enabled开启,通过spark.dynamicAllocation.schedulerBacklogTimeout及 spark.dynamicAllocation.sustainedSchedulerBacklogTimeout两个参数进行时间上的控制。另外,Spark对于YARN及Mesos的支持均得到了显著地增强。

3. Adaptive Query Plan

适应查询计划(Adaptive Query Plan)是一个“可能”的特性。“可能”的原因是这一特性可能要等到Spark 1.6版本或者之后的版本才会有。首先,陈述几个问题,如何自动确定并行度(Level of Parallelism);如何自动选择采用Broadcast Join还是Hash Join;Spark如何感知数据的行为。

目前,Spark需要在执行Job前确定Job的DAG,即在执行前,由Operator到DAG的转换就已经完成了,这样显然不够灵活。因此,更好的方案是允许提交独立的DAG stage,同时收集它们执行结果的一些统计信息。基于这些信息,Spark可以动态决定Reduce Task的数量,同时也可以动态地选择是采用Broadcast还是Shuffle。对于Spark SQL来讲,它应该能在聚合时自动设置Reduce Task的数量,并且在Join时自动选择策略。主要的思路是,在决定Reduce Task的数量及采用的Shuffle策略前,先让Map运算,然后输出较大数量的Partition作为Map阶段的结果。接下来,Spark会检查Map Stages输出的Partition的大小(或者其它一些状态),然后基于这些信息做出最佳选择。

估计大家已经看出,这里其实需要修改DAGScheduler的实现,因为目前的DAGScheduler仅支持接收一张完整的DAG图,而上述讨论的问题要求DAGScheduler支持接收Map Stages,且能收集Map Stages输出结果的相关信息。Shuffle也需要支持能一次Fetch多个Map输出的Partition,而目前的HashShuffleFetcher一次性只能获取1个Partition。当然,这里还会涉及到其它改动,就不一一列出了。Adaptive Query Plan的重要性在于,Spark会替用户确定运行时所需的一些参数及行为,从而用户无需操心。还记得Flink那句宣传语,即“用户对内核唯一需要了解的事就是不需要了解内核”。

结语

概括来讲,Spark的护城河其实有两条——其一是先进的技术,另一条则是丰富的生态系统。从上图可以看出,无论是这段时间在容器领域无比火爆的Kubernete及Docker,还是在NoSQL领域的两面锦旗HBase及Cassandra,亦或是其它如消息队列Kafka、分布式搜索引擎Elasticsearch及各机器学习框架都与Spark产生了联系,并且这样的趋势还在快速蔓延中。这意味着,Spark可能出现在大数据处理的各个领域,并给各个领域带来明显提升。

同时我了解到,很多朋友都在关注Spark在GPU方面的发展。关于这一点,现在业界也有了一些尝试,但仍然有较长的路要走,让我们一起期待在这个领域未来会发生些什么。

逆水行舟,不进则退。Spark在不停地进步着,真诚希望国内能有更多的工程师参与到Spark的开发中,同时也渴望看到更多有意思的Spark应用案例。目前,几乎可以肯定,在大数据领域选择Spark确实为一个明智之举。

【编辑推荐】

  1. 北京的人流在哪儿?用大数据看城市
  2. 医疗大数据:未来数据化一个人是否有可能?
  3. 大数据研究常用软件工具与应用场景
  4. 大数据技术Hadoop面试题,看看你能答对多少?
  5. 大数据下有反欺诈“大安全”
【责任编辑:李英杰 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

读 书 +更多

《ASP.NET AJAX Web 应用开发秘诀(VB版)》

本书详细介绍了AJAX在Web开发上的应用。主要内容包括:ASP.NET AJAX技术概述、实现异步局部更新页面、UpdatePanel编程功能、PageRequestMan...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× Python最火的编程语言