本文来自 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。 声明:文章收集于网络,版权归原作者所有,为传播信息而发,如有侵权,请联系小编删除,谢谢! |