Spark on Kubernetes 与 Spark on Yarn 不完全对比分析

前言

Apache Spark 是目前应用最广泛的大数据分析计算工具之一。它擅长于批处理和实时流处理，并支持机器学习、人工智能、自然语言处理和数据分析应用。随着 Spark 越来越受欢迎，使用量越来越大，狭义上的 Hadoop (MR) 技术栈正在收缩。另外，普遍的观点和实践经验证明，除了大数据相关的工作负载，Hadoop (YARN) 不具备相应的灵活性去跟更广泛的企业技术栈融合与集成。比如去承载一些在线业务，而这正是 Kubernetes（K8s) 所擅长的领域。事实上，Kubernetes 的出现为 Spark 的改进打开了一个新世界的大门，创造了更多机遇。如果能用统一的一套集群去运行所有在线和离线的作业，也是十分吸引人的事情。

Spark on Kubernetes 于 Spark 2.3 [1] 版本引入开始，到 Spark 3.1 [2] 社区标记 GA，基本上已经具备了在生产环境大规模使用的条件。

在业内，苹果[3], 微软[4], 谷歌，网易，华为、滴滴，京东等公司都已经有内部大规模落地或者对外服务的经典成功案例。

Spark on Kubernetes 应用架构

从 Spark 整体计算框架层面来看，只是在资源管理层面多支持了一种调度器，其他接口都可以完全复用。一方面 Kubernetes 的引入和 Spark Standalone、YARN、 Mesos 及 Local 等组件形成了一个更为丰富的资源管理体系。

另一方面，Spark 社区在支持 Kubernetes 特性的同时，对用户 API 的兼容度也得到了最大化的保留，极大程度上方便了用户任务的迁移。比如对于一个传统的 Spark 作业而言，我们通过简单的指定 --master 参数为 yarn 或者 k8s://xxx，即可完成两个调度平台的运行时切换。其他参数诸如镜像、队列、Shuffle 本地盘等配置， yarn 和 k8s 之间都是隔离的，可以很方便地统一在配置文件中统一维护。

Spark on Kubernetes vs Spark on YARN

易用性分析

Spark Native API