栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 前沿技术 > 大数据 > 大数据系统

Kubernetes vs YARN for scheduling Apache Spark

Kubernetes vs YARN for scheduling Apache Spark

Kubernetes vs YARN for scheduling Apache Spark

翻译笔记
原文链接
https://spot.io/blog/kubernetes-vs-yarn-for-scheduling-apache-spark/

Spark on YARN
Spark使用两个关键组件—分布式文件存储系统和调度程序来管理工作负载。通常,Spark将使用HDFS进行存储,并使用两种最常见的资源管理器,即YARN或Mesos。YARN是Spark的首选调度器,用于在提交作业时处理资源分配。YARN知道可用资源,并主动将任务分配给这些资源。

How does YARN work?
YARN cluster由许多主机组成,其中一些主机是主主机,而大多数主机是辅助主机。ResourceManager在集群级别处理资源,而NodeManager在单个主机级别管理资源。它们在集群和本地主机级别跟踪vCore和内存。

当像Spark这样的应用程序在YARN上运行时,ResourceManager和NodeManager会评估集群上的可用资源,并将每个容器分配给主机。这样,YARN的关键工作就是在集群上管理资源和调度任务。
使用YARN远比将Spark作为一个独立的应用程序来管理要好。随着大数据集、大量同时运行的工作负载以及日益复杂的后端基础设施,YARN使Spark能够大规模运行。

Limitations of YARN in the cloud
YARN的不足之处在于版本和依赖关系控制、作业之间的隔离以及最佳资源分配等方面。为了运行多个工作负载,每个工作负载类型都需要专用集群。根据谷歌的克里斯托弗·克罗斯比(Christopher Crosby)的说法,YARN“集群非常复杂,必须使用比工作或模型所需更多的组件。”因此,YARN很难有效地管理任务——这正是创建YARN的目的。YARN迫使您对高要求的工作负载(如实时处理)做出妥协。此外,由于今天的数据需求不仅是“大”,而且是“微”和短期的,因此YARN无法满足现代工作负载的需求。
因为YARN不能实现作业隔离,所以需要为每个需要运行的新作业设置和拆除集群。这会产生成本,是一个容易出错的过程,并浪费计算资源。这些维护任务将焦点从Spark上要运行的作业上移开,Spark是最优先的任务。

Kubernetes is replacing YARN
Kubernetes今天被称为容器编排平台。随着Kubernetes的使用继续爆炸式增长,任何企业技术都不会不受影响,包括Spark。使用Kubernetes管理Spark有许多优点。在早期,主要原因曾经是很容易将Spark应用程序部署到组织内现有的Kubernetes基础架构中。这将协调各个软件交付团队的工作。由于Kubernetes的许多显著优势使天平大幅度倾斜,这一原因很快就黯然失色。事实上,亚马逊进行了对比测试,结果表明使用Kubernetes代替YARN可以节省5%的时间。

Benefits of Spark on Kubernetes
在Kubernetes上运行Spark比在YARN上运行Spark有许多优点。让我们看看关键的好处:

  1. 将所有依赖项以及Spark应用程序打包到容器中。这避免了Spark常见的依赖性问题。
  2. Kubernetes的资源配额和名称空间可以更好地控制应用程序如何消耗和共享系统资源。
  3. 可交换的备份基础设施意味着Spark应用程序现在可以跨混合云环境进行移植。
  4. Kubernetes角色和ClusterRole功能允许您为资源设置细粒度权限,并基于API组组织这些权限。
  5. 标记用于版本控制的容器映像,这有助于更好地审核和回滚失败的部署。
  6. Kubernetes生态系统正在蓬勃发展,为管理和监控提供了强大的开源附加组件。Prometheus用于时间序列数据,Fluentd用于日志聚合,Grafana用于数据可视化是几个值得注意的例子。
  7. GitOps允许您以声明方式管理基础架构和应用程序部署。Flux和Argo是支持这一点的两个领先的GitOps工具。
  8. 在设置时,您可以使用Helm图表来安装、管理和版本控制软件包及其依赖项。
    总结:版本控制

这已经是一个很长的好处列表,但采用Kubernetes而非YARN的最大原因是它是大数据分析的未来。在每个云供应商和企业通过CNCF(云本地计算基金会)提供的支持下,Kubernetes将继续留在这里,并正在彻底改变大数据的分析方式。

Challenges with Spark on Kubernetes
Kubernetes对SARK的第一个挑战是,它需要数据团队的专门知识。如果您的组织已经在跨团队投资Kubernetes运营,这可能不是问题。
Oleksandra Bovkun&Roman Ivanov在他们关于Kubernetes和Spark的富有洞察力的博文末尾指出,要全面运营这个平台,你至少需要具备Kubernetes、Helm、Docker和网络的基本知识。如果您想避免这种情况,您可能会尝试通过创建一个在其下面调用Kubernetes API的UI为该平台带来另一层抽象。”
虽然Kubernetes擅长扩展应用程序,但用户仍然需要解决如何扩展底层基础设施的问题。Spark应用程序可以是动态的,并为其提供与动态应用程序一样的基础架构,从而实现快速应用程序部署。
另一个关键挑战是成本控制,同时维护灵活的基础架构以支持动态应用程序。由于大规模的研究、测试、建模和实验,大数据操作成本高昂。如果不加以控制,成本可能会失控。实施成本控制的主要方法是使用现场实例。这些实例由云供应商以显著的折扣提供。但是,它们并没有保证可用性,可以在提供商需要它们时随时终止。
Kubernetes提供了一个利用Spark彻底改变大数据分析的绝佳机会。它将工作负载与运行它们的基础架构分离。它为Spark带来了一套全新的管理和监控工具。在加工速度方面,其性能略优于现有纱线。它不再是实验性的选择,也不再是折衷方案——而是大数据分析的未来。然而,要获得这些好处,就需要深入了解Kubernetes是如何建立和维护它的。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/618179.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号