<强>背景
Apache火花作为当前最为流行的开源大数据计算框架,广泛应用于数据处理和分析应用,它提供了两种方式来处理数据:一是交互式处理,比如用户使用spark-shell或是pyspark脚本启动火花应用程序,伴随应用程序启动的同时火花会在当前终端启动REPL (Read-Eval-Print循环)来接收用户的代码输入,并将其编译成火花作业提交到集群上去执行;二是批处理,批处理的程序逻辑由用户实现并编译打包成jar包,spark-submit脚本启动火花应用程序来执行用户所编写的逻辑,与交互式处理不同的是批处理程序在执行过程中用户没有与火花进行任何的交互。
两种处理交互方式虽然看起来完全不一样,但是都需要用户登录到网关节点上通过脚本启动火花进程。这样的方式会有什么问题吗?
首先将资源的使用和故障发生的可能性集中到了这些网关节点。由于所有的火花进程都是在网关节点上启动的,这势必会增加网关节点的资源使用负担和故障发生的可能性,同时网关节点的故障会带来单点问题,造成火花程序的失败。
其次难以管理,审计以及与已有的权限管理工具的集成。由于火花采用脚本的方式启动应用程序,因此相比于Web方式少了许多管理,审计的便利性,同时也难以与已有的工具结合,如Apache诺克斯。
同时也将网关节点上的部署细节以及配置不可避免地暴露给了登陆用户。
为了避免上述这些问题,同时提供原生火花已有的处理交互方式,并且为火花带来其所缺乏的企业级管理,部署和审计功能,本文将介绍一个新的基于引发的其他服务:李维。
<强>李维
李维是一个基于火花的开源休息服务,它能够通过其他的方式将代码片段或是序列化的二进制代码提交到火花集群中去执行。它提供了以下这些基本功能:
提交Scala, Python或是R代码片段到远端的火花集群上执行;
提交Java, Scala, Python所编写的火花作业到远端的火花集群上执行;
提交批处理应用在集群中运行。
从李维所提供的基本功能可以看到李维涵盖了原生火花所提供的两种处理交互方式。与原生火花不同的是,所有操作都是通过其他的方式提交到李维服务端上,再由李维服务端发送到不同的火花集群上去执行。说到这里我们首先来了解一下李维的架构。
<强>李维的基本架构
李维是一个典型的休息服务架构,它一方面接受并解析用户的休息请求,转换成相应的操作,另一方面它管理着用户所启动的所有火花集群。具体架构可见图1。
图1李维的基本架构
用户可以以休息请求的方式通过李维启动一个新的火花集群,李维将每一个启动的火花集群称之为一个会话(会话),一个会话是由一个完整的火花集群所构成的,并且通过RPC协议在火花集群和李维服务端之间进行通信。根据处理交互方式的不同,李维将会话分成了两种类型:
交互式会话(交互式会话),这与火花中的交互式处理相同,交互式会话在其启动后可以接收用户所提交的代码片段,在远端的火花集群上编译并执行;
批处理会话(批处理会话),用户可以通过李维以批处理的方式启动火花应用,这样的一个方式在李维中称之为批处理会话,这与火花中的批处理是相同的。
可以看的到,李维所提供的核心功能与原生火花是相同的,它提供了两种不同的会话类型来代替火花中两类不同的处理交互方式。接下来我们具体了解一下这两种类型的会话。
<强>交互式会话(交互式会话)
使用交互式会话与使用火花所自带的spark-shell, pyspark或sparkR相类似,它们都是由用户提交代码片段给REPL,由REPL来编译成火花作业并执行。它们的主要不同点是spark-shell会在当前节点上启动REPL来接收用户的输入,而李维交互式会话则是在远端的火花集群中启动REPL,所有的代码,数据都需要通过网络来传输。
我们接下来看看如何使用交互式会话。
<>强创建交互式会话
POST/会议
使用交互式会话的前提是需要先创建会话。当我们提交请求创建交互式会话时,我们需要指定会话的类型(“”),比如“火花”,李维会根据我们所指定的类型来启动相应的REPL,当前李维可支持火花,pyspark或是sparkr三种不同的交互式会话类型以满足不同语言的需求。
