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

在刚刚结束的 Kubernetes Community Day 上海站，亚马逊云科技在云原生分论坛分享的“在 Kunernets 上运行 Apache Spark 进行大规模数据处理实践”引起了现场参与者的关注。开发者告诉我们，为了充分利用 Kubernetes 的高可用设计、弹性，在越来越多的应用场景中，他们选择从 Yarn 迁移到 Kubernetes 中运行 Spark 负载。我们认为，[Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 作为成熟的托管 Kubernetes 平台，是客户运行 Spark 负载的理想选择，我们的分享围绕在 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 上运行 Spark 负载的最佳实践展开，包括：计算和基础设施、弹性扩展、存储、健壮性和灾备以及可观测性等五个方面的内容。   #### **Amazon EKS 上运行 Spark 负载的最佳实践** ##### **一、计算和基础设施** 计算和基础设施涵盖了 Spot、Graviton、应用开发语言、操作系统等方面的最佳实践介绍。 ###### **1. 尝试采用 ARM 架构和 Spot** 通过选择将 Spark 运行在 arm 架构上，可获得高达 58% 的性价比优势【*1*】，同时，也建议客户通过多架构的方式，提升系统可靠性。降本增效的核心在于怎样以最低的成本获得更快的计算结果，充分利用 Spot 可为降本提供基础，同时，必须处理好 Spot 中断，以提升系统的健壮性。  ###### **2. 采用容器化操作系统** ###### **降低运维成本和提高敏捷性** 容器作为不可变基础设施，具有快速创建、快速销毁、大规模等特点。Spark workload 需要一个什么样的操作系统呢？亚马逊云科技在 2020 年推出的开源容器化操作系统 Bottlerocket【*2*】，很好地满足了 Spark workload 的要求。 1. 最小化。只包括运行容器所必需的包、不可变、启动速度快。 2. 原子更新。基于 image 进行更新，避免传统操作系统更新遇到的失联、rpm 包更新慢等问题，同时，在升级遇到问题时，可快速回滚到上一个版本中，也支持通过 Operator 方式进行批量管理。 3. 安全。默认开启 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](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 上运行 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](https://aws.amazon.com/cn/ebs/?trk=cndc-detail)），以及使用 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](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 是运行 Spark 负载的理想平台，这得益于亚马逊云科技的基础设施和服务广度，得益于亚马逊云科技在开源方面的投入。借助 Bottleorocket、Spot、Graviton，客户获得了性价比的提升，能够将更多精力放在自身业务上，而不是繁重的系统运维和调优上。以上就是本次分享的全部内容，希望能对大家有所帮助。 ##### **相关资源** 1. Gain Up to 58% price-performance benefits when deploying Apache Spark on AWS Graviton2 : https\://community.arm.com/arm-community-blogs/b/infrastructure-solutions-blog/posts/apache-spark-performs-better-on-aws-graviton?trk=cndc-detail 2. Bottlerocket: https\://bottlerocket.dev/?trk=cndc-detail 3. Kubernetes SLI/SLO: https\://github.com/kubernetes/community/blob/master/sig-scalability/slos/api_call_latency.md?trk=cndc-detail 4. Kubecost: https\://www\.kubecost.com/?trk=cndc-detail 5. PVC reuse: https\://aws.amazon.com/cn/blogs/china/the-practice-of-shareit-big-data-platform-datacake-in-spark-on-eks/?trk=cndc-detail