您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
通过可视化来了解你的Spark应用程序
 
作者 Andrew Or 来源:CSDN 火龙果软件  发布于 2015-7-10
  2035  次浏览      13
 

摘要:在过去,Spark UI一直是用户应用程序调试的帮手。而在最新的Spark 1.4版本中,一个新的因素被注入到Spark UI——数据可视化。

【编者按】在"Spark 1.4:SparkR发布,钨丝计划锋芒初露"一文中,我们有简单地介绍了1.4版本给Spark注入的新特性,在各个组件的介绍中也提到了新UI给用户带来的便捷。而从本文开始,我们将通过Databricks Blog上的系列文章深入了解新版本中的数据可视化,首先分享的是这个系列的第一篇博文——Understanding your Spark application through visualization,作者 Andrew Or。

以下为译文

图片最大的价值就是它可以让我们发现未曾预期的事情——John Tukey。

在过去,Spark UI一直是用户应用程序调试的帮手。而在最新版本的Spark 1.4中,我们很高兴地宣布,一个新的因素被注入到Spark UI——数据可视化。在此版本中,可视化带来的提升主要包括三个部分:

  • Spark events时间轴视图
  • Execution DAG
  • Spark Streaming统计数字可视化

我们会通过一个系列的两篇博文来介绍上述特性,本次则主要分享前两个部分——Spark events时间轴视图和Execution DAG。Spark Streaming统计数字可视化将在下一篇博文中解释。

Spark events时间轴视图

从Spark 初期版本至今,Spark events一直是面向用户API的一部分。在最新的1.4版本,Spark UI将会把这些events在一个时间轴中显示,让用户可以一眼区别相对和交叉顺序。

时间轴视图可以覆盖3个等级:所有Job,指定的某个Job,以及指定的某个stage。在下图中,时间轴显示了横跨一个应用程序所有作业中的Spark events。

这里的events顺序相对简单,在所有 executors 注册后,在应用程序并行运行的4个job中,有一个失败,其余成功。当所有工作完成,并在应用程序退出后,executors同样被移除。下面不妨点击关注其中的一个job:

该job在3个文件中做word count,最后join并输出结果。从时间轴上看,很明显, 3个 word count stages 并行运行,因为它们不互相依赖。同时,最后一个阶段需要依赖前3个文件word count的结果,所以相应阶段一直等到所有先行阶段完成后才开始。下面着眼单个stage:

这个stage被切分为20个partitions,分别在4台主机上完成(图片并没有完全显示)。每段代表了这个阶段的一个单一任务。从这个时间轴来看,我们可以得到这个stage上的几点信息。

首先,partitions在机器中的分布状态比较乐观。其次,大部分的任务执行时间分配在原始的计算上,而不是网络或I/ O开销。这并不奇怪,因为传输的数据很少。最后,我们可以通过给executors分配更多的核心来提升并行度;从目前来看,每个executors可以同时执行不超过两个任务。

借此机会展示一下Spark通过该时间轴获得的另一个特性——动态分配。该特性允许Spark基于工作负载来动态地衡量executors 的数量,从而让集群资源更有效地共享。不妨看向下张图表:

首先要注意的是,这个应用程序是在工作的过程中获得executors ,而不是预先分配好。在第一个job结束后,用于该job的executors将闲置并返回到集群。因此在这个期间,同集群中运行的其他应用程序可以获得这些资源,从而增加集群资源利用率。只有当一个新的job执行时,Spark应用程序才会获取一组新的executors 来运行它。

在一个时间轴中查看Spark events的能力有助于确定应用程序瓶颈,从而在调试过程中进行更有针对性的优化。

Execution DAG

在新版本的Spark中,第二个可视化聚焦DAG执行的每个作业。在Spark中,job与被组织在DAG中的一组RDD依赖性密切相关,类似下图:

这个job执行一个简单的word cout。首先,它执行一个textFile从HDFS中读取输入文件,然后进行一个flatMap操作把每一行分割成word,接下来进行一个map操作,以形成form(word,1)对,最后进行一个reduceByKey操作总结每个word的数值。

可视化的蓝色阴影框对应到Spark操作,即用户调用的代码。每个框中的点代表对应操作下创建的RDDs。操作本身由每个流入的stages划分。

通过可视化我们可以发现很多有价值的地方。首先,根据显示我们可以看出Spark对流水线操作的优化——它们不会被分割。尤其是,从HDF S读取输入分区后,每个executor随后即对相同任务上的partion做flatMap和map,从而避免与下一个stage产生关联。

其次,RDDs在第一个stage中会进行缓存(用绿色突出表示),从而避免对HDFS(磁盘)相关读取工作。在这里,通过缓存和最小化文件读取可以获得更高的性能。

DAG可视化的价值在复杂jobs中体现的尤为明显。比如下图中的ALS计算,它会涉及到大量的map、join、groupByKey操作。

值得注意的是,在ALS中,缓存准确性将对性能产生的影响非常大,因为该算法在每次迭代中会重度使用之前步骤产生的结果。如今通过DAG可视化,用户和开发人员可以一目了然地查明RDDS是否被恰当地缓存,如果没有,可以快速理理解实现缓慢的原因。

与时间轴视图一样,DAG可视化允许用户点击进入一个stage进行更详细地观察。下图描述了ALS中一个独立的stage。

在stage视图中,属于这个stage的所有RDDS细节被自动展开。当前,用户可以快速地找到具体的RDDS信息,而不必job页面通过悬停各个点来猜测和检查。

最后,在这里突出一下DAG可视化和 SparkSQL之间的一个初步的集成。对比更接近物理实体层面的Spark操作,Spark SQL用户显然更熟悉一些高级操作,因此一些高级操作更需要被可视化。其结果类似将一个SQL查询计划映射到底层执行的DAG。

与SparkStreaming的整合在Spark 1.4版本中同样有所实现,这里在下一篇博文中会详细介绍。

在不久的将来,Spark UI可以更理解一些更高级别的函数库语义,以提供更多相关细节。 同时,Spark SQL将与Spark Streaming一样获得类似的标签。而在Spark Core中,当用户查看RDD时,类似partitions数量、调用点、缓存率都将会被可视化。

在此感谢社区中所有对可视化工作有所贡献的组织和个人,更特别感谢NTT Data的@sarutak在时间轴可视化特性中的主要贡献。

   
2035 次浏览       13
 
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
 
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
 
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]

专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件的思考
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS
更多...   
相关培训课程

云计算原理与应用
Windows Azure 云计算应用

摩托罗拉 云平台的构建与应用
通用公司GE Docker原理与实践
某研发中心 Openstack实践
知名电子公司 云平台架构与应用
某电力行业 基于云平台构建云服务
云计算与Windows Azure培训
北京 云计算原理与应用