一种spark application提交管理的工程化实践

背景描述

  spark是一个优秀的面向大数据的数据计算引擎，并且针对不同的应用场景，spark本身提供了一些很好的工具如对于数据分析计算我们可以选用spark sql，对于智能推荐可以选择mllib等，它在数据批处理和实时计算方面都表现出了良好的性能。
  一般开发一个spark应用的基本流程如下几部：
   1.创建spark context；
   2.从spark session作为入口，读取数据，然后通过rdd进行迭代运算；
   3.处理计算结果；
  在编译好完成的应用jar后，使用spark提供的submit脚本来把应用提交给spark集群进行执行计算。

一些问题

  上述spark的功能开发及部署流程从使用上来说并没有问题，但是如果考虑项目工程开发的易用性及可靠性，当spark应用运行较多时(如果同时运行几百个spark任务)，会显得捉襟见肘，下面列举几个可以思考的问题:
  1.提交spark application的host默认最多启动16个进程的限制，怎样去做横向扩容；
  2.不同开发人员开发的不同spark应用如何管理(实际每个jar多是一个功能)；
  3.spark的应用功能怎样和平台的其他服务组件更好的交互，最好开发的这些spark功能能够以接口的方式
提供给其他服务方调用；

实践方法探讨

  我们打算将之前写的每个spark的应用封装为restful接口对外提供相应的服务，可以使用springboot来快速构建这样的功能，每个restful接口可独立对外提供服务，如果使用springboot来开发，接下来需要面对的问题可能是spark应用本身的特性所带来的问题，先不考虑分布式多实例服务，可以先来看看单个服务创建有什么样的困难或问题，如对于一个spark应用来说单个spark context是独占JVM的，按照使用springboot构建服务的想法，当一个请求到达并成功运行时，这个springboot的启动实例是不能处理其他请求的。另外容易想到的是，一个spark任务执行，从任务初始化创建再到真正计算是相当花费时间的，所以可以考虑外部服务调用spark功能接口为异步方式，即提交spark应用后，通过轮训的方式来查看任务的执行状态。
  实际上现在也有一些还算比较优秀的开源框架用于解决spark应用服务化的问题，如spark job server和livy,由于目前我们的spark集群使用的是standalone模式，集群资源的分配为自定义实现，当在请求的服务端主机上进行spark context创建时，会有资源限制；另外由于团队资源的限制，开源框架虽然功能多，但是我们使用到的必定非常有限，而且还会有spark版本的影响，在想升级spark集群版本时，也会受到相应的限制，所以从简化易用的角度，可以自己着手来对spark的功能服务化做一个自定义的开发。

初步需要解决的问题

• One Spark Context,One JVM,需要知道哪个JVM(springboot)可用，然后分发请求；
• 提交任务接口和查询状态接口分离；
• 创建spark context一般需要15s~30s，为了提供一些任务的执行速度，可以先将spark context初始化好，然后再通过接口进行计算，所以需要有初始化和释放接口。

实现

  分析到这里，应该可以着手来实现它，这里有一个初步实现的demo,工程名称philomel，它使用springboot作为基本构建框架，使用我们熟悉的 web开发方式进行开发，不过对于spark的应用开发，我们这里选择scala语言。
  当一个springboot实例启动后，可以将它看作可提交spark应用的客户端，当请求到达后，创建并生成spark任务后，它又是spark中的driver负责与集群中的master和worker进行交互。
  对于philomel实例的分发调用，可以在前面实现一个这样的philomel实例分配调度服务，这个服务需要知道当前有哪些philomel实例已启动，并且哪些实例已在使用，哪些处于空闲状态。
  除了philomel实例资源调度服务，在大数据平台中可能还会有一些其他性质的服务，比如流程调度引擎或数据查询服务等，这些服务需要一些治理手段来配合，并通过微服务的方式进行部署以及对外输出能力，但是philomel本身，我们不打算将这些启动实例纳入到微服务的管理架构中来，简单的它只向分发调度它的模块通知位置信息和几个应用消息。

应用架构

按照前面的描述，先打算按如下图方式进行应用架构的设计

大数据平台philomel调用原理图

  整个大数据平台的后端服务，可以使用微服务的思路来完成构建，通过一个api网关来进行各个服务模块间的请求调用，使用服务注册发现中心来对所有的服务实例进行治理(比如springcloud中的eureka)。从图中可以看出所有外部使用spark的功能都需要请求philomel服务，它提供的了开发的spark业务功能的restful接口。
  关于调用过程中产生的数据和配置数据，可以使用redis和mysql来存储，运行时数据存放在redis中(如job编码,spark app id等)，配置数据存放在mysql数据库中(如为了运维可视化，配置的philomel的部署host信息和当前philomel实例使用情况等信息)。

消息交互

  philomel调度服务负责直接与philomel实例进行交互，它负责将其他业务模块的请求分发给空闲的philomel实例进行spark任务的执行，从提交一个spark任务请求到执行完成整个生命周期，目前是通过异步的方式来实现，消息交互方式可参考下图所示：

spark任务请求消息交互

未来优化

  目前我们的业务场景以spark sql的应用为主，比如通过spark sql从hive或hbase表中查询业务数据并输出到指定的数据源中(如redis,kafka或ftp等)，在实践中上述应用服务架构已能很好的服务于当前的业务，spark集群规模在80+，可同时支持200+的spark任务执行，而且当philomel实例数量预估不足时在不影响运行业务的情况下可以进行手动横向扩容。
  未来打算在Paas平台的基础上，通过将philomel制作成docker image,通过k8s进行编排调度，可以对philomel实例进行弹性分配。