本文简要介绍了下Livy及其安装, 另外对Livy在实践中存在的问题, 以及Livy如何成为弃儿的…
什么是livy?
Apache Livy是一种通过REST接口与Spark集群轻松交互的服务。它可以通过简单的REST接口或RPC客户端库轻松提交Spark作业或Spark代码片段,同步或异步结果检索以及Spark Context管理。Apache Livy还简化了Spark与应用程序服务器之间的交互,从而使Spark能够用于交互式Web /移动应用程序。其他功能包括:
- 长期运行的Spark上下文可以被多个客户端用于多个Spark作业
- 跨多个作业和客户端共享缓存的RDD或Dataframe
- 可以同时管理多个Spark上下文,并且Spark上下文在集群(YARN / Mesos)而不是Livy Server上运行,以实现良好的容错和并发性
- 作业可以作为预编译的jar,代码片段或通过java / scala客户端API提交
- 通过安全的认证通信确保安全性
为什么是Livy?
曾经我们提交一个spark任务,往往通过spark-submit来提交,难免很原始地需要开发者登陆客户机,通过spark客户端来提交spark任务。为了使spark引擎产品化,我们通过界面配置的方式来实现spark任务参数的可视化,提高用户体验。对于任务提交产品化,我们尝试过这么几种方式:
- spark-submit脚本提交。前端可视化配置,后端封装spark-submit提交脚本。就是包了层web界面的壳,弊端就是当几百几千个spark任务并发提交的时候,spark客户端往往带来很大的压力,提交任务严重阻塞。
- spark-submit SDK工具包提交。这里我们通过自研spark源码,封装了提交spark任务的SDK工具包,本质就是跳过spark原生的shell脚本提交方式,将参数封装后直接调用
SparkSubmit.main()
。弊端是不太友好,SDK包的开发需要对spark源码了解,另外,我们更想知道的程序运行状态及程序日志查看,用户体验都不是十分友好。
然而,福音来了,有了livy。livy恰到好处地解决了我们所面临的问题,使spark引擎产品化。
livy有什么好处?
任何地方都可以提交作业
Livy支持从Web /移动应用程序提供程序化,容错,多租户提交Spark作业(无需Spark客户端)。因此,多个用户可以同时可靠地与你的Spark集群进行交互。
使用Scala或Python交互
Livy识别Scala或Python,因此客户端可以通过任何一种语言远程与你的Spark集群进行通信。此外,批处理作业提交可以在Scala,Java或Python中完成。
代码无需改动
使用livy,原有的任务迁移不需要做任何的代码改动
安装Livy*****
系统环境
软件版本
软件 | 安装包版本 |
---|---|
hadoop | hadoop-2.7.7.tar.gz |
jdk | jdk-8u191-linux-x64.tar.gz |
scala | scala-2.12.8.tgz |
mysql | mysql-5.7.25-linux-glibc2.12-x86_64.tar.gz |
spark | spark-2.4.0-bin-hadoop2.7.tgz |
livy | livy-0.5.0-incubating-bin.zip |
集群环境
ip | hostname | system | |
---|---|---|---|
master | 10.96.81.166 | jms-master-01 | centos7.2 [ CPU: 4 & 内存: 12G & 硬盘大小: 100G ] |
node | 10.96.113.243 | jms-master-02 | centos7.2 [ CPU: 4 & 内存: 12G & 硬盘大小: 100G ] |
node | 10.96.85.231 | jms-master-03 | centos7.2 [ CPU: 4 & 内存: 12G & 硬盘大小: 100G ] |
约定规范
约定所有软件的安装目录:/home/hadoop/tools
约定所有的安装包存放目录:/home/hadoop/tools/package
安装教程
安装包下载
上传并解压
上传安装包至package,并解压至/home/hadoop/tools
运行livy
运行前,确保hadoop集群和spark集群已启动。
如果没有导入下面的变量,则需要先导入:export SPARK_HOME=/usr/lib/spark
export HADOOP_CONF_DIR=/etc/hadoop/conf
当然上面的路径应该是你实际的安装包相应路径。
启动livy:
1 | ./bin/livy-server start |
停止livy:
1 | ./bin/livy-server stop |
livy 的 web ui:
1 | http://localhost:8998/ui |
livy默认使用8998端口,你可以在配置中通过livy.server.port
参数修改端口。
livy配置
Livy默认情况下使用安装目录下conf目录下的配置文件,你也可以通过LIVY_CONF_DIR在启动Livy时设置环境变量,来指定livy使用备用的配置目录。
Livy使用的配置文件说明:
livy.conf
:包含服务器配置。Livy发行版附带一个默认配置文件模板,列出了可用的配置键及其默认值。spark-blacklist.conf
:列出不允许用户覆盖的Spark配置选项。这些选项将被限制为其默认值或Livy使用的Spark配置中设置的值。log4j.properties
:Livy日志记录的配置。定义日志级别以及将写入日志消息的位置。默认配置模板将日志消息打印到stderr。
至此,Livy安装成功。
Livy初体验
REST API
在postman中,测试livy的rest api。
Livy是如何成为弃儿的?
在我们推进Spark服务化的过程中, 我们相中了Livy,并且在实践中,做了大量的bugfix和优化工作,但最终还是决定弃之。
我们的Livy是如何部署的?
Livy是很轻量的,我们采用docker容器化多实例部署,并且采用haproxy做了session级别的负载均衡。还有中方案是通过zk做负载均衡,没有深入研究,有兴趣可以调研下。
我们的Livy遇到了什么瓶颈?
- 创建的session释放缓慢,导致服务器sys持续飙高;
- 高并发时,响应缓慢,并且还存在将线程数打满的情况
另外,还有其他的一些性能问题,以及和Spark兼容性问题,期间做了大量的开发,Livy研发同事也和社区保持着良好的互动,参与了一些patch开发等。但最终还是疲于bugfix,而且随着我们数据中台的产品数据梦工厂的逐步完善,我们决定重新沿用Spark Cli进行任务提交。
对Livy使用的一些思考
总体而言,Livy还是提供了很多便利,适用于小规模小厂的应用,对于大厂大规模任务提交而言,还有很多性能瓶颈,社区还需要继续改进。
本文链接: https://stefanxiepj.github.io/archives/cfdb423b.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!