Pinterest：从 Hadoop 到 Kubernetes 的 Spark 迁移

Pinterest最近将其基于Hadoop的数据平台替换为Moka"，这是一个在AWS EKS上运行Spark的Kubernetes原生系统。Moka实现了容器化作业隔离，支持基于ARM的实例，通过YuniKorn改进调度，并简化部署，同时降低基础设施成本，提高了数据处理工作负载的效率。

Pinterest做出了一个战略性决定，从传统的基于Hadoop"的架构转型到基于Kubernetes"的Spark"模型，更好地与现代基础设施实践保持一致。它选择Kubernetes是因为它对容器编排和安全性的原生支持，以及它在部署混合实例类型（如ARM和x86）方面的灵活性：

凭借这些需求，我们在2022年对在各种平台上运行Spark进行了全面评估。我们倾向于Kubernetes为中心的框架，因为它们提供了以下优势：基于容器的隔离性和安全性，作为平台的一等公民，易于部署，内置了框架和性能调整选项。

此外，Moka在传统平台上引入了关键的成本和效率改进。通过利用基于容器的隔离，Pinterest将具有不同安全要求的工作负载整合到共享集群中，从而减少了对多个集群的需求。

Pinterest的工程师也承认，“基于容器的系统提供了更强的隔离，允许移除专用但利用率低的Hadoop环境，转而在同一Moka集群上运行具有不同安全要求的作业。”该平台支持基于ARM的实例"和机会式自动扩展，在非高峰时段扩展集群，进一步有助于基础设施成本的节省。

替换Hadoop需要重新设计与作业提交、调度、存储和可观测性相关的几个关键组件——“多年来，Hadoop和Monarch （Pinterest的Hadoop平台）已经涵盖了大量的功能。构建一个替代方案意味着开发替代品...”。Pinterest开发了新的服务，如用于作业提交的Archer，采用Apache YuniKorn"进行基于队列的调度，将存储从HDFS"迁移到S3"，并集成了Apache Celeborn"远程混洗服务，以保持大规模的性能。

Moka最初的高级设计（来源"）

在Moka的初始设计中，Spinner"，Pinterest基于Airflow"的编排系统，将计划的工作流程分解为单独的作业提交，并发送给Archer，即EKS作业提交服务。Archer将每个作业转换为Kubernetes自定义资源，并提交给支持Spark的EKS集群。Archer处理作业排队、状态跟踪和与Kubernetes API的集成，实现跨集群的可靠部署和高效资源路由，同时保持与现有工作流程的兼容性。

Spark Operator（来源"）

Pinterest的工程师选择使用Spark Operator"在Kubernetes上原生执行Spark，并使用Apache YuniKorn进行批量调度。Spark Operator公开了SparkApplication自定义资源定义（Custom Resource Definition"，CRD），允许以声明方式的定义Spark应用程序，并将所有底层提交细节留给Spark Operator处理。在内部，Spark Operator仍然使用原生的spark-submit命令。

Moka资源管理（来源"）

YuniKorn提供基于队列的调度、应用程序配额和抢占，并使Pinterest能够在团队之间强制执行资源隔离，并根据工作负载层和业务关键性动态调整作业的优先级。

一旦YuniKorn调度作业，SparkSQL"作业就会连接到Hive Metastore"，然后使用来自AWS ECR的容器镜像执行工作负载。在执行过程中，Archer跟踪作业状态，系统将日志上传到S3，将指标上传到内部仪表板。用户可以通过网络代理访问正在运行的作业UI，也可以通过Spark History Server检索历史日志，所有这些都可以通过只读的Moka UI呈现出来。

原文链接：

https://www.infoq.com/news/2025/07/pinterest-spark-kubernetes/"