当前位置:   article > 正文

Spark on K8S 的最佳实践和需要注意的坑_running apache spark on kubernetes: best practices

running apache spark on kubernetes: best practices and pitfalls

本文来自 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 Hadoop 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。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/443288
推荐阅读
相关标签
  

闽ICP备14008679号