在 Kubernetes 上运行 Apache Spark 进行大规模数据处理的实践

亚马逊云开发者

于 2024-05-11 22:42:17 发布

阅读量762

点赞数 25

文章标签： kubernetes apache spark

本文链接：https://blog.csdn.net/awschina/article/details/138732144

版权

在刚刚结束的 Kubernetes Community Day 上海站，亚马逊云科技在云原生分论坛分享的“在 Kunernets 上运行 Apache Spark 进行大规模数据处理实践”引起了现场参与者的关注。开发者告诉我们，为了充分利用 Kubernetes 的高可用设计、弹性，在越来越多的应用场景中，他们选择从 Yarn 迁移到 Kubernetes 中运行 Spark 负载。我们认为，Amazon EKS 作为成熟的托管 Kubernetes 平台，是客户运行 Spark 负载的理想选择，我们的分享围绕在 Amazon EKS 上运行 Spark 负载的最佳实践展开，包括：计算和基础设施、弹性扩展、存储、健壮性和灾备以及可观测性等五个方面的内容。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

Amazon EKS 上运行 Spark 负载的最佳实践

一、计算和基础设施

计算和基础设施涵盖了 Spot、Graviton、应用开发语言、操作系统等方面的最佳实践介绍。

1. 尝试采用 ARM 架构和 Spot

通过选择将 Spark 运行在 arm 架构上，可获得高达 58% 的性价比优势【1】，同时，也建议客户通过多架构的方式，提升系统可靠性。降本增效的核心在于怎样以最低的成本获得更快的计算结果，充分利用 Spot 可为降本提供基础，同时，必须处理好 Spot 中断，以提升系统的健壮性。

2. 采用容器化操作系统

降低运维成本和提高敏捷性

容器作为不可变基础设施，具有快速创建、快速销毁、大规模等特点。Spark workload 需要一个什么样的操作系统呢？亚马逊云科技在 2020 年推出的开源容器化操作系统 Bottlerocket【2】，很好地满足了 Spark workload 的要求。

最小化。只包括运行容器所必需的包、不可变、启动速度快。
原子更新。基于 image 进行更新，避免传统操作系统更新遇到的失联、rpm 包更新慢等问题，同时，在升级遇到问题时，可快速回滚到上一个版本中，也支持通过 Operator 方式进行批量管理。
安全。默认开启 SELinux 策略、只读根文件系统、无 Linux 包管理工具，为 Spark workload 保驾护航。

同时，如果 Spark pod 镜像太大的话，可以考虑将镜像缓存到 EC2 镜像中，或者采用 Bottlerocket 的方式进行缓存，进一步节省镜像拉取时间。

3. JDK 版本的选择

从 JDK 版本来看，JDK8U91 才能更好地兼容容器，如果开启了 cgroup v2，则建议使用 jdk8u372，jdk8u372, 11.0.16, 15 或者以上的版本。而不同 JDK 版本下，SPECjbb 的表现也是不一样的。我们看到相对较高的 JDK 版本，其性能也会比较好。建议根据实际的场景，适时升级 JDK 的版本以获取较好的性能。

二、弹性扩展

1. Karpenter 开源高效 Node 弹性扩展工具

Spark workload 在某些场景下对 Pod 启动 Latency 有一定的要求，同时，Spark 具有瞬时启动几百甚至几千 Pod 的情况。那么，如何能够快速响应 Spark 弹性扩展的需求呢？

亚马逊云科技于 2021 年开源了 Node 弹性扩展 Karpenter【3】，其具有配置简单、扩展速度快、成本优化策略等特点，是客户运行 Data workload 理想的弹性扩展工具。同时，Karpenter 内置 bin-packing、fallback 等策略，简化客户在使用 Spot、Graviton 等基础设施的配置工作。

从性能上来看，根据社区测试数据，Karpenter 在大规模下具有明显优势，建议大家在 Amazon EKS 上运行 Spark workloads 时，可以考虑选择 Karpenter 作为 node 弹性扩展工具。

2. 继续使用 Cluster Autoscaler

如果因为其他原因，您还是继续想使用 Cluster Autoscaler，建议可以考虑将不同业务域的作业划归到不同的 namespace 中，避免出现只有一个 namespace 运行所有作业的情况。同时，可以每个 namespace 中运行一个 Cluster Autoscaler，防止出现 Cluster Autoscaler 没有及时缩容的问题。

3. 弹性扩展的其他最佳实践

避免使用过多的反亲和性规则。
按照业务域划分 namespace 或者集群。
根据规模大小，注意 Prometheus 等其他系统 Pod 的扩展问题。
适时对集群进行压测，了解系统上限。

三、健壮性和灾备

我们需要在规划 Spark on Kubernetes 时，考虑 Spark 的灾备策略等问题。

在规划 VPC 时，需要根据业务负载进行长期规划，防止出现因 IP 地址耗尽，而出现计算停滞的情况。同时，在生产集群中，将重要的系统 controller 放置到托管节点组或者 Fargate 中，避免 Spark Pod 和系统 Pod 相互干扰。

同时，我们建议在规划集群时，同步规划测试集群和生产集群，方便在测试集群中相关验证。另外，可以通过多个集群实现 DR 设计，或者按照业务域规划集群，实现集群层面的业务隔离和计费统计。每个集群应该具有独立的 VPC、安全组、IAM 等，防止集群之间相互影响。

四、可观性

1. SLI/SLO 建设的必要性

Spark on Kubernetes，某些指标非常关键，比如 Pod Startup Latency 以及其他关键性指标。用户可以针对不同的作业，设置告警服务。建议大家可以参考社区 SLI/SLO【3】，进行 Spark 可观测性构建。

通过 SLI/SLO，我们可以深入了解相关 Spark 作业的健康状况，比如作业重算的情况、CPU/Memory 等基础指标。这些指标对 Spark 作业而言很重要，有时候虽然超售可以运行更多的 Pod，但是，过分的超售对 Spark 作业而言并不好，而可观测性可以帮助我们了解 Spark 作业，做到从容有度。

2. Spark History Server

可统一配置 S3 bucket 作为 history server 存储，进行统一集中管理。

3. 成本可视化

我们在对 Spark 集群进行成本优化时，需要知道成本的构成，只有清楚了解成本的构成，才可能有针对性的进行成本优化，这往往是大家忽略的一点。所以，成本可视化是成本优化的前提。

在成本可视化上，一方面可以通过亚马逊云科技的服务，比如 Cost Explorer，进行成本可视化；另外一方面，可以借助类似于 kubecost【4】等开源项目进行。在 Kubecost 中，可以按照 namespace 纬度进行成本统计，同时，kubecost 也会给出成本优化建议，比如 right sizing 等。

在实际的生产中，有一些客户会尝试自己实现计费逻辑，比如借助 Kubernetes informers 统计相关 pod 信息。而我们在实现相关逻辑时，需要防止因代码逻辑而产生的计费偏差等问题。

五、存储

Spark Shuffle 存储的选项有很多种，比如使用本地磁盘 NVMe/SSD 的方式，以及使用外挂块存储（如 Amazon EBS），以及使用 Remote Shuffle Service 等方式进行。

1. Spark PVC reuse

Spark 运行过程中会通过 Shuffle 的方式来交换数据，Map 阶段会先将数据写到本地，然后 Reduce 阶段读取 Map 阶段产生的数据。当 Spark 运行在 Spot 实例上时，Spot 回收会导致 Map 阶段产生的数据丢失，当 Reduce 阶段读取数据时，Spark 需要重启 Map 阶段的计算，重新计算丢失的数据。据此，在 Spark 3.2 中引入了 PVC reuse 功能 [SPARK-35593] ，把 shuffle 数据保存到 PV 里，当 Spot 被回收时，可以通过复用 PVC 来恢复 Shuffle 数据，从而避免数据重算。在某些客户的实践中，整体成本降低了 39%【5】。

2. 块设备 EBS 的最佳实践

当运行大规模的 Spark 作业时，我们需要运行许多 Spark Executor Pod，每个 Pod 都需要一个独立的 PVC 用于 shuffle。有时并行创建或删除速度可能会受到 CSI API 的限制，我们可以增加 CSI 的以下值以提高效率，但下述配置并不是一步到位的，需要根据规模进行调整。

3. 存储类型的选择

根据自身业务对 IO 的要求，建议选择合适的存储，比如块设备相对于本地存储（instance store）来说具有很好的持久性，但性能可能比本地存储要低。另外，也可以考虑使用高性能共享文件系统或者 Remote Shuffle Service 来满足 shuffle 的要求。使用本地存储时，需要对一些系统目录，比如 /var/lib/kubelet 等创建单独分区并与 shuffle 盘分开。在生产环境中，我们需要建立对磁盘指标的告警机制，防止出现因异常磁盘 IO 带来的影响。

总结

Amazon EKS 是运行 Spark 负载的理想平台，这得益于亚马逊云科技的基础设施和服务广度，得益于亚马逊云科技在开源方面的投入。借助 Bottleorocket、Spot、Graviton，客户获得了性价比的提升，能够将更多精力放在自身业务上，而不是繁重的系统运维和调优上。以上就是本次分享的全部内容，希望能对大家有所帮助。