sbt结合IDEA对Spark进行断点调试开发

原创文章,谢绝转载

笔者出于工作及学习的目的,经常与Spark源码打交道,也难免对Spark源码做修改及测试。本人一向讲究借助工具提升效率,开发Spark过程中也在摸索如何更加顺畅的对源码进行调试。

Spark基于Scala,采用IntelliJ IDEA和sbt应对日常开发,自然是最佳选择了。如何导入及编译Spark项目,网上资料很多,官网给的教程也比较详细:

本文基于Spark2.x的源码,重点介绍如何使用sbt结合IDEA对Spark进行断点调试开发,这对于经常修改或学习Spark源码的读者较为有益。废话到此,我们进入正题。

Spark源码编译

首次拿到Spark源码,直接导入IDEA会有很多错误,因为SQL项目的catalyst中的SQL语法解析依赖ANTLR语法定义,需要通过编译生成代码,如下是采用sbt打包编译的流程:

git clone https://github.com/apache/spark.git  
cd spark  
build/sbt package  

...经过漫长等待,成功编译后,导入IDEA就可以正常看源码了。

大家可以采用阿里云的Maven仓库,加速下包的过程,可以参考我的这篇文章:https://zhuanlan.zhihu.com/p/25279570

编写测试用例

我习惯于直接在Spark项目中写TestCase的方式作为执行Spark的入口,这种方式对于经常修改Spark源码的开发场景很适用,相比在SparkShell中写测试代码有以下好处:

  • 代码保留在文件中,方便修改重新执行
  • 代码在同一个项目中,源码修改后IDEA无需对代码进行二次索引
  • 方便进行持续测试(Continuous Test)

Spark源码自带大量的TestCase可供我们学习参考,我们以Spark的SQL项目为例,将spark/sql/core/src/test/scala/org/apache/spark/sql/SQLQuerySuite.scala复制为SimpleSuite.scala

注意,这里不要是使用IDEA自带的复制功能,因为IDEA在复制的时候会重新组织代码中import的次序,这有可能会导致编译出错。正确的姿势应该是:

  1. 在IDEA中,找到要复制的文件,右击,复制代码路径

  2. 在IDEA的Terminal窗口中执行cp xxx xxx2完成复制

我们之所以要基于SQLQuerySuite复制出一个SimpleSuite文件是因为:Spark为了确保代码风格一致规范(比如每个代码文件头部需要定义Apache的License注释;import的顺序为java,scala,3rdParty,spark),在项目引入了Scala-style checker,如果代码不合规范,执行编译会出错。直接复制一个文件在上面做修改可以避免踩到代码风格检查的坑。我将SimpleSuite的内容修改如下:

打开IDEA的Terminal窗口,执行build/sbt进入sbt的交互式环境,通过以下方式执行我们的SimpleSuite:

> project sql
> testOnly *SimpleSuite

project sql指的是切换到SQL项目,这样在执行testOnly时可以快速定位到我们的SimpleSuite类,可以执行projects查看Spark定义的所有子模块,当前所在的模块名称前会有个*的标识。首次执行测试的时间比较长,再次执行就会比较快了,如果测试通过的话,会看到如下信息:

在sbt中执行exit退出交互式环境,接下来介绍如何使用sbt结合IDEA进行断点调试。

sbt结合IDEA对Spark进行断点调试

由于sbt是在Terminal中单独启动的进程,要对sbt调试,就需要采用IDEA的远程调试功能了。在IDAE的菜单中选择Run -> Edit Configrations...,在接下来的窗口中添加一个Remote配置:

配置名称大家随意,我这里为Spark,远程调试的端口为5005,如果本地的5005端口被占用,改为其他端口即可。

然后回到Terminal重新启动sbt,启动时需要添加远程调试参数:build/sbt -jvm-debug 5005,启动过程中会提示Listening for transport dt_socket at address: 5005,启动sbt后,我们就可以通过IDEA对sbt进行调试了。

接下来我们给SimpleSuite的test方法内部随意添加一个断点,回到sbt执行:

> project sql
> set fork in Test := false
> testOnly *SimpleSuite

一切顺利的话,执行testOnly的过程中,我们的断点会被命中:

如果对Spark源码或SimpleSuite的代码做了修改只需要重新执行testOnly *SimpleSuite即可。

让IDEA命中断点有一个关键的语句:set fork in Test := false,这个语句的作用是让sbt执行Test时避免fork子进程。我们启动sbt的时候添加的远程调试端口是加在sbt上的,如果执行Test不在一个进程内,IDEA就无法命中断点。

如果频繁修改代码,反复执行testOnly难免有些不便,我们可以采用sbt的持续编译功能简化流程。执行时加上~,也就是~testOnly *SimpleSuite,这样,我们修改代码,在保存,sbt会监控文件变化并自动执行测试,超级方便。这种方式同样适用于compile,test,run等命令。

总结

几个关键点:

# Spark源码目录下执行(以SimpleSuite为例):
$ build/sbt -jvm-debug 5005
> project sql
> set fork in Test := false
> testOnly *SimpleSuite

OK,掌握以上技巧,我们就可以愉快的深入Spark源码内部,了解Spark的运作机制了。