原创投稿 行业报告 AI展会 数据标注
投稿发布
您的当前位置:主页 > 数据挖掘 > 正文

Spark on K8S 的最佳实践和需要注意的坑

来源: 时间:2020-07-31
本文来自 Data Mechanics 的 CEO Jean-Yves Stephan 和 CTO Julien Dumazert 在 Spark Summit North America 2020 的 《Running Apache Spark on Kubernetes: Best Practices and Pitfalls》议题的分享。相关视频参见 视频|在Kubernetes上运行Spark的较佳实践和陷阱,PPT 可以到 你要的 Spark AI Summit 2020 PPT 我已经给你整理好了 获取。
 
近年来,K8S 在业界越来越流行,由于其有很多优点,很多企业将应用部署到 K8S 中,Spark 从 2.3 版本开始支持使用 K8S 作为资源管理器,参见 https://issues.apache.org/jira/browse/SPARK-18278。本文将介绍在 K8S 上运行 Spark 作业的较佳实践和需要注意的坑。
 
在 Kubernetes 上运行 Spark 都有哪些经验的调查中显示:
61% 的人表示从来没用过,但是对这个感到好奇;
24% 的人表示只是在测试环境中使用,但是并没有在生产环境中使用;
15% 的人表示已经在生产环境中使用。

 

本文主要结构包括:Spark on Kubernetes:
核心概念;
配置和性能调优技巧;
监控和安全相关的技巧;
未来工作。
 
核心概念
Spark 哪个地方需要用到 K8S 呢?K8S 是 Spark 上全新的集群管理和调度系统,其他三个资源管理和调度为 Standalone、YARN 以及 Apache Mesos。

 

Spark on Kubernetes 的架构如下:

 

目前有两种方法可以将 Spark 的应用程序提交到 K8S:
 

 

•通过 Spark 提供的 spark-summit 提交
•这种方式是 Spark 原生提供的;
•配置在 Spark config(主要)和 k8s manifests 之间传递;
•在 Spark 3.0 之前支持自定义 Little pod;
•应用的管理主要是人工维护。
•通过 spark-on-k8s operator 提交
•Google 开源出来的,但是支持任意平台;
•配置通过 k8s 风格的 YAML 文件进行;
•提供一些工具用于读取日志、重启、 kill 以及调度 作业;
•需要长时间运行的 system pod。
 

 

上面显示两种不同作业提交方式的应用管理实践。从上图可以看出,通过 spark-summit 方式提交的作业没有方法查看作业的运行及其参数配置等。而通过 spark-on-k8s operator 方式,可以通过一系列的内置工具,获取很多作业相关的信息。

 

 
YARN 和 K8S 两种资源管理方式比较:
YARN 集群中的 Spark 版本、Python 版本以及依赖都是全局配置的,缺乏隔离。(过往记忆大数据备注:YARN 集群上是可以运行不同版本的 Spark 以及 Python,这个我之前有相关文章介绍的。关于依赖其实也有办法进行配置的。) 而 K8S 方式作业之间都是隔离的。
 
配置和性能调优技巧
下面我们来介绍 Spark on K8S 的配置和性能调优相关技巧。

 

假设我们有一个 K8S 集群,每个实例配置是 16GB 内存和4核;如果我们选择以下两种中的一种配置我们都将申请不到 executor:
设置 spark.executor.cores=4
设置 spark.executor.memory=11g
 
是不是觉得很奇怪?

 

上面设置之所以申请不到 executor,是因为:K8S 实例上的资源只有一部分是可以给 Spark pods 的。我们需要预留一部分资源给 K8S 以及系统守护进程,这部分大概占用 5%。所以我们的节点只能申请到 95% 的资源,在这些资源中 10% 需要给一些守护进程使用,所以整个实例我们只能申请到 95% * 90% = 85% 的资源。

 

 
目前 Spark on K8S 还不支持动态资源分配的全部功能。当我们杀掉 pod 时,上面的 shuffle 文件将会被丢失。
 
与此同时,Spark 3.0 提供了一个 soft dynamic allocation 功能。只有不持有需要的 shuffle 文件的 executor 可以被删掉。相关配置如下:
spark.dynamicAllocation.enabled=true
spark.dynamicAllocation.shuffleTracking.enabled=true

 

如果无法分配 pending Pods,我们可以将 k8s 配置为自动缩放。自动缩放在动态资源申请的情况下工作非常好:
如果集群有资源,我们可以在10s内获取一个新的 exec pod;
如果集群需要自动缩放,则需要 1-2 分钟。

 

为了进一步提高动态分配的速度,我们可以过量使用低优先级的 pause pods 来配置集群:
pause pods 强制 k8s 来动态缩放;
在需要时,Spark pods 将抢占 pause pods 的资源。

 

 

Spark on K8S 的场景下,数据的读写一般都是经过对象存储的。云厂商一般会为其对象存储提供写优化的 committers,比如 S3A Committers。
 
如果没有提供的话,建议使用 Spark 自带的 version 2 committer,可以通过以下参数配置:
spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2
如果你有很多文件需要写时,这个配置可以将性能提升近2倍!

 

 
I/O 速度对于 shuffle 很重的工作负载来说至关重要,因为 Spark 会将 shuffle 的数据写到本地文件。但是 Docker 的文件系统非常慢,我们可以通过 Kubernetes Volumes 来提升性能。具体参见 https://spark.apache.org/docs/3.0.0-preview2/running-on-kubernetes.html#using-kubernetes-volumes。
 
监控和安全相关的技巧
 

 

我们可以通过 k8s 提供的工具来兼监控 pod 的资源使用情况。比如 Kubernetes dashboard 或者 GKE 控制台。
 
已知的问题:上面的监控方法比较难与  Spark jobs/stages/tasks 进行协调;当 Spark 应用程序运行完时,Executor 的监控数据将会丢失。

 

 
上面的问题我们可以通过按照 Spark 历史服务器来解决。可以将 Spark 的事件日志存放在 S3/GCS/Azoure 存储文件,并配置 spark.eventLog.dir 参数到相关路径。但是这种方式我们无法获取资源使用相关的 metrics!
 

 

Data Mechanics 的 工程师们开发了 Spark Delight,其可以解决上面的问题。关于 Spark Delight 可以参见 https://towardsdatascience.com/spark-delight-were-building-a-better-spark-ui-1b463840e243。

 

 

Spark 利用 DropWizard 类库来产生详细的 metrics。我们可以将这些 metrics 存储到时序数据库中:
InfluxDB
Prometheus,这个在 Spark 3.0 中已经内置支持将监控信息写到 Prometheus 中。

 

K8S 上的安全较佳实践对 Spark on K8S 来说是可以免费使用的!我们可以进行访问控制、密码配置以及网络安全配置等。
 
未来工作

 

 
Spark on K8S 未来工作主要包括:
Shuffle 相关问题的提升;
更友好的处理节点的关闭;
支持上传本地 python 依赖;
Job 队列以及资源管理。
经过上面的介绍,你是否打算使用 K8S 呢?
 

 

如果打算使用Spark-on-Kubernetes,上面的事项是需要你做的。关于 Spark on K8S 的更多内容可以参见 https://spark.apache.org/docs/3.0.0/running-on-kubernetes.html。
 
声明:文章收集于网络,版权归原作者所有,为传播信息而发,如有侵权,请联系小编删除,谢谢!
 
 

人工智能交流群扫码邀请
人工智能交流群扫码邀请


转发量:

网友评论:

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
数据标注服务

Copyright©2005-2020 Sykv.com 可思数据 版权所有    京ICP备14056871号

关于我们   免责声明   广告合作   版权声明   联系我们   原创投稿   网站地图  

可思数据 数据标注行业联盟

人工智能资讯   人工智能资讯   人工智能资讯   人工智能资讯

扫码入群
咨询反馈
扫码关注

微信公众号

返回顶部
关闭