基于Apache Spark的REST服务详解(三),云网数据中心,深圳服务器托管,深圳服务器租用, 深圳BGP机房托管,深圳BGP机房租用,深圳电信机房租用,深圳移动机房
发布时间：2017-07-05 点击数：6661
使用编程API
在交互式会话模式中，Livy不仅可以接收用户提交的代码，而且还可以接收序列化的Spark作业。为此Livy提供了一套编程式的API供用户使用，用户可以像使用原生Spark API那样使用Livy提供的API编写Spark作业，Livy会将用户编写的Spark作业序列化并发送到远端Spark集群中执行。表1就是使用Spark API所编写PI程序与使用Livy API所编写的程序的比较。
表1 使用Spark API所编写PI程序与使用Livy API所编写程序的比较
可以看到除了入口函数不同，其核心逻辑完全一致，因此用户可以很方便地将已有的Spark作业迁移到Livy上。
Livy交互式会话是Spark交互式处理基于HTTP的实现。有了Livy的交互式会话，用户无需登录到Gateway节点上去启动Spark进程并执行代码。以REST的方式进行交互式处理提供给用户丰富的选择，也方便了用户的使用，更为重要的是它方便了运维的管理。
批处理会话（Batch Session）
在Spark应用中有一大类应用是批处理应用，这些应用在运行期间无须与用户进行交互，最典型的就是Spark Streaming流式应用。用户会将业务逻辑编译打包成jar包，并通过spark-submit启动Spark集群来执行业务逻辑：
Livy也为用户带来相同的功能，用户可以通过REST的方式来创建批处理应用：
通过用户所指定的“className”和“file”，Livy会启动Spark集群来运行该应用，这样的一种方式就称为批处理会话。
至此我们简单介绍了Livy的两种会话类型，与它相对应的就是Spark的两种处理交互方式，因此可以说Livy以REST的方式提供了Spark所拥有的两种交互处理方式。
企业级特性
前面我们介绍了Livy的核心功能，相比于核心功能的完整性，Livy的企业级特性则更体现了其相比于原生Spark处理交互方式的优势。本章节将介绍Livy几个关键的企业特性。
多用户支持
假定用户tom向Livy服务端发起REST请求启动一个新的会话，而Livy服务端则是由用户livy启动的，这个时候所创建出来Spark集群用户是谁呢，会是用户tom还是livy？在默认情况下这个Spark集群的用户是livy。这会带来访问权限的问题：用户tom无法访问其拥有权限的资源，而相对的是他却可以访问用户livy所拥有的资源。
为了解决这个问题Livy引入了Hadoop中的代理用户（proxy user）模式，代理用户模式广泛使用于多用户的环境，如HiveServer2。在此模式中超级用户可以代理成普通用户去访问资源，并拥有普通用户相应的权限。开启了代理用户模式后，以用户tom所创建的会话所启动的Spark集群用户就会是tom。
图2 Livy多用户支持
为了使用此功能用户需要配置“livy.impersonation.enabled”，同时需要在Hadoop中将Livy服务端进程的用户配置为Hadoop proxyuser 。当然还会有一些Livy的额外配置就不在这展开了。
有了代理用户模式的支持，Livy就能真正做到对多用户的支持，不同用户启动的会话会以相应的用户去访问资源。
端到端安全
在企业应用中另一个非常关键的特性是安全性。一个完整的Livy服务中有哪些点是要有安全考虑的呢？
客户端认证
当用户tom发起REST请求访问Livy服务端的时候，我们如何知道该用户是合法用户呢？Livy采用了基于Kerberos的Spnego认证。在Livy服务端配置Spnego认证后，用户发起Http请求之前必须先获得Kerberos认证，只有通过认证后才能正确访问Livy服务端，不然的话Livy服务端会返回401错误。
HTTPS/SSL
那么如何保证客户端与Livy服务端之间HTTP传输的安全性呢？Livy使用了标准的SSL来加密HTTP协议，以确保传输的Http报文的安全。为此用户需要配置Livy服务端SSL相关的配置已开启此功能。
SASL RPC
除了客户端和Livy服务端之间的通信，Livy服务端和Spark集群之间也存在着网络通信，如何确保这两者之间的通信安全性也是需要考虑的。Livy采用了基于SASL认证的RPC通信机制：当Livy服务端启动Spark集群时会产生一个随机字符串用作两者之间认证的秘钥，只有Livy服务端和该Spark集群之间才有相同的秘钥，这样就保证了只有Livy服务端才能和该Spark集群进行通信，防止匿名的连接试图与Spark集群通信。
将上述三种安全机制归结起来就如图3所示。
图3 Livy端到端安全机制
这样构成了Livy完整的端到端的安全机制，确保没有经过认证的用户，匿名的连接无法与Livy服务中的任何一个环节进行通信。
失败恢复
由于Livy服务端是单点，所有的操作都需要通过Livy转发到Spark集群中，如何确保Livy服务端失效的时候已创建的所有会话不受影响，同时Livy服务端恢复过来后能够与已有的会话重新连接以继续使用？
Livy提供了失败恢复的机制，当用户启动会话的同时Livy会在可靠的存储上记录会话相关的元信息，一旦Livy从失败中恢复过来它会试图读取相关的元信息并与Spark集群重新连接。为了使用该特性我们需要配置Livy使其开启此功能：
大数据技术11
失败恢复能够有效地避免因Livy服务端单点故障造成的所有会话的不可用，同时也避免了因Livy服务端重启而造成的会话不必要失效。
总结
本文从Spark处理交互方式的局限引出了Livy这样一个基于Spark的REST服务。同时全面介绍了其基本架构、核心功能以及企业级特性，Livy不仅涵盖了Spark所提供了所有处理交互方式，同时又结合了多种的企业级特性，虽然Livy项目现在还处于早期，许多的功能有待增加和改进，我相信假以时日Livy必定能成为一个优秀的基于Spark的REST服务。
深圳市云网数据中心(www.szicp.com)
专业提供【服务器租用】【服务器托管】【机柜大带宽】【云主机租用】【CDN加速】【专线接入】
在交互式会话模式中，Livy不仅可以接收用户提交的代码，而且还可以接收序列化的Spark作业。为此Livy提供了一套编程式的API供用户使用，用户可以像使用原生Spark API那样使用Livy提供的API编写Spark作业，Livy会将用户编写的Spark作业序列化并发送到远端Spark集群中执行。表1就是使用Spark API所编写PI程序与使用Livy API所编写的程序的比较。
表1 使用Spark API所编写PI程序与使用Livy API所编写程序的比较
可以看到除了入口函数不同，其核心逻辑完全一致，因此用户可以很方便地将已有的Spark作业迁移到Livy上。
Livy交互式会话是Spark交互式处理基于HTTP的实现。有了Livy的交互式会话，用户无需登录到Gateway节点上去启动Spark进程并执行代码。以REST的方式进行交互式处理提供给用户丰富的选择，也方便了用户的使用，更为重要的是它方便了运维的管理。
批处理会话（Batch Session）
在Spark应用中有一大类应用是批处理应用，这些应用在运行期间无须与用户进行交互，最典型的就是Spark Streaming流式应用。用户会将业务逻辑编译打包成jar包，并通过spark-submit启动Spark集群来执行业务逻辑：
Livy也为用户带来相同的功能，用户可以通过REST的方式来创建批处理应用：
通过用户所指定的“className”和“file”，Livy会启动Spark集群来运行该应用，这样的一种方式就称为批处理会话。
至此我们简单介绍了Livy的两种会话类型，与它相对应的就是Spark的两种处理交互方式，因此可以说Livy以REST的方式提供了Spark所拥有的两种交互处理方式。
企业级特性
前面我们介绍了Livy的核心功能，相比于核心功能的完整性，Livy的企业级特性则更体现了其相比于原生Spark处理交互方式的优势。本章节将介绍Livy几个关键的企业特性。
多用户支持
假定用户tom向Livy服务端发起REST请求启动一个新的会话，而Livy服务端则是由用户livy启动的，这个时候所创建出来Spark集群用户是谁呢，会是用户tom还是livy？在默认情况下这个Spark集群的用户是livy。这会带来访问权限的问题：用户tom无法访问其拥有权限的资源，而相对的是他却可以访问用户livy所拥有的资源。
为了解决这个问题Livy引入了Hadoop中的代理用户（proxy user）模式，代理用户模式广泛使用于多用户的环境，如HiveServer2。在此模式中超级用户可以代理成普通用户去访问资源，并拥有普通用户相应的权限。开启了代理用户模式后，以用户tom所创建的会话所启动的Spark集群用户就会是tom。
图2 Livy多用户支持
为了使用此功能用户需要配置“livy.impersonation.enabled”，同时需要在Hadoop中将Livy服务端进程的用户配置为Hadoop proxyuser 。当然还会有一些Livy的额外配置就不在这展开了。
有了代理用户模式的支持，Livy就能真正做到对多用户的支持，不同用户启动的会话会以相应的用户去访问资源。
端到端安全
在企业应用中另一个非常关键的特性是安全性。一个完整的Livy服务中有哪些点是要有安全考虑的呢？
客户端认证
当用户tom发起REST请求访问Livy服务端的时候，我们如何知道该用户是合法用户呢？Livy采用了基于Kerberos的Spnego认证。在Livy服务端配置Spnego认证后，用户发起Http请求之前必须先获得Kerberos认证，只有通过认证后才能正确访问Livy服务端，不然的话Livy服务端会返回401错误。
HTTPS/SSL
那么如何保证客户端与Livy服务端之间HTTP传输的安全性呢？Livy使用了标准的SSL来加密HTTP协议，以确保传输的Http报文的安全。为此用户需要配置Livy服务端SSL相关的配置已开启此功能。
SASL RPC
除了客户端和Livy服务端之间的通信，Livy服务端和Spark集群之间也存在着网络通信，如何确保这两者之间的通信安全性也是需要考虑的。Livy采用了基于SASL认证的RPC通信机制：当Livy服务端启动Spark集群时会产生一个随机字符串用作两者之间认证的秘钥，只有Livy服务端和该Spark集群之间才有相同的秘钥，这样就保证了只有Livy服务端才能和该Spark集群进行通信，防止匿名的连接试图与Spark集群通信。
将上述三种安全机制归结起来就如图3所示。
图3 Livy端到端安全机制
这样构成了Livy完整的端到端的安全机制，确保没有经过认证的用户，匿名的连接无法与Livy服务中的任何一个环节进行通信。
失败恢复
由于Livy服务端是单点，所有的操作都需要通过Livy转发到Spark集群中，如何确保Livy服务端失效的时候已创建的所有会话不受影响，同时Livy服务端恢复过来后能够与已有的会话重新连接以继续使用？
Livy提供了失败恢复的机制，当用户启动会话的同时Livy会在可靠的存储上记录会话相关的元信息，一旦Livy从失败中恢复过来它会试图读取相关的元信息并与Spark集群重新连接。为了使用该特性我们需要配置Livy使其开启此功能：
大数据技术11
失败恢复能够有效地避免因Livy服务端单点故障造成的所有会话的不可用，同时也避免了因Livy服务端重启而造成的会话不必要失效。
总结
本文从Spark处理交互方式的局限引出了Livy这样一个基于Spark的REST服务。同时全面介绍了其基本架构、核心功能以及企业级特性，Livy不仅涵盖了Spark所提供了所有处理交互方式，同时又结合了多种的企业级特性，虽然Livy项目现在还处于早期，许多的功能有待增加和改进，我相信假以时日Livy必定能成为一个优秀的基于Spark的REST服务。
深圳市云网数据中心(www.szicp.com)
专业提供【服务器租用】【服务器托管】【机柜大带宽】【云主机租用】【CDN加速】【专线接入】