运行Apache的利弊Kubernetes火花

Apache火花是一个开源的分布式计算框架。在几行代码(在Scala中,Python、SQL或R),数据科学家或工程师定义的应用程序可以处理大量的数据,火花照顾跨一个机器集群并行工作。

火花本身不管理这些机器。它需要一个集群管理器(有时也称为调度器)。cluster-managers主要有:

• 独立:简单的集群管理器,有限的功能,整合与火花。
• Apache便:一个开源集群管理器一旦流行对于大数据工作负载(不仅仅是火花)但在下降在过去的几年里。
• Hadoop纱:基于jvm的2012年公布的Hadoop集群管理器最常用到目前为止,对于本地(例如Cloudera, MapR)和云(例如EMR, Dataproc HDInsight)部署。
• Kubernetes:火花运行本地火花以来Kubernetes版本2.3 (2018)。这种部署模式是企业获得快速牵引以及支持(Red Hat,彭博社的报道,谷歌,Palantir Lyft)。截至2020年6月的支持仍然标记为实验。

作为新人,有很多的炒作Kubernetes。在本文中,我们将解释Spark-on-k8s的核心概念和评估新的部署方式的优缺点。

核心概念

你可以使用spark-operator提交应用程序使用spark-submit或火花——后者是我们的偏好,但我们会谈论它在以后的教程。这个请求包含完整的应用程序配置包括代码和依赖关系(打包为一个运行码头工人形象或通过指定uri),基础参数,(如内存、CPU、存储卷规格分配每个火花executor),和火花配置。

Kubernetes将这个请求并开始引发司机在一个Kubernetes豆荚(一个美丽的抽象,只是一个码头工人容器在这种情况下)。火花司机可以直接反驳Kubernetes主请求执行人豆荚,并上下缩放在运行时根据负载是否启用动态分配。Kubernetes负责装箱的豆荚在Kubernetes节点(物理vm),并将动态规模不同的节点池以满足需求。

去有点深,Kubernetes火花主要依赖的支持KubernetesClusterSchedulerBackend生活的火花司机。

这个类跟踪当前注册执行人,和所需的执行人的总数(从一个固定大小的配置或动态分配)。在周期性间隔(由spark.kubernetes.allocation.batch.delay配置),它将请求的创建或删除执行人豆荚,并等待请求做其他请求之前完成。因此这个类实现的“期望状态原则”亲爱的Kubernetes粉丝,支持声明式命令式语句。

的优点,好处Kubernetes火花

1。集装箱化

这是使用Kubernetes本身的主要动机。集装箱化的好处在传统软件工程应用到大数据和火花。容器使应用程序更便携,他们简化包装的依赖性,使可重复的和可靠的构建工作流。他们减少整体devops负载和允许你迭代代码更快。

前三的好处使用码头工人火花的容器:
1)构建依赖关系一次,到处运行在本地(或范围)
2)使火花更可靠和更经济。
3)加快你的迭代周期10 x(在力学数据,我们的用户定期报告降低他们的火花dev工作流从5分钟不到30秒或更多)

我们最喜欢的好处是绝对依赖管理,因为它与PySpark臭名昭著的痛苦。你可以选择建立一个新的码头工人形象对于每个应用程序,或使用一组较小的码头工人包大部分需要的库的图像,并动态地添加特定于应用程序的代码。告别长和片状init脚本编译c库在每个应用程序启动!

更新(2021年4月)公开:我们已经优化码头工人图片可供任何人使用。它们包含连接器最常用的数据源,我们希望他们会为你工作的!看看我们博客和我们的Dockerhub页面更多细节?

更新(2021年10月):看到我们一步一步的教程如何构建一个形象,开始使用我们的boilercode模板!

2。高效资源共享导致巨大的成本节约

在其他cluster-managers(纱线、独立,便)如果你想重复使用相同的集群并行火花应用(因为成本原因),你将不得不妥协隔离:

• 依赖孤立。你的应用程序会有一个全球火花和python版本,共享库和环境。
• 隔离性能。如果别人开始一个大的工作,我的工作可能会运行得更慢。

因此,许多平台(砖、EMR Dataproc,…)推荐运行瞬态集群生产工作。开始一个集群,集群运行工作,终止。这种方法的问题是你支付安装/拆除费用(通常大约10分钟,因为它需要很多的时间正确地设置纱),你得不到任何的资源共享。很容易犯错误,这种方法浪费大量的计算资源。雷竞技rabet官网

3所示。集成在一个丰富的生态系统——cloud-agnostic &供应商锁定较低

部署火花在Kubernetes免费给你强大的特性,如多租户名称空间的使用和配额控制和基于角色的访问控制(可选集成与云提供商我)细粒度的安全性和数据的访问。

如果你有一个需要外界k8范围,社区非常活跃,很有可能你会找到一个工具来回答这个需要。这一点尤其强烈,如果你已经在使用Kubernetes你的余生堆栈你可能重用您现有的工具。这也使你的数据基础设施更cloud-agnostic和减少你的供应商!

中性-火花的性能是相同的

我们跑基准之间的性能差异证明没有运行Kubernetes火花,火花在纱线运行。

在我们的博客Apache火花绩效基准显示Kubernetes赶上纱线——我们的设置基准,结果,以及关键的建议,来最大化洗牌Kubernetes引发运行时性能。

尽管火花的原始性能相同,可以通过迁移到火花产生显著的成本节约上Kubernetes如前所述。读过这个故事顾客的成本减少了65%,从纱线(EMR)迁移到Spark-on-Kubernetes(数据结构)。

缺点,缺点Kubernetes火花

1。使Spark-on-k8s可靠在扩大规模需要构建时间和专业知识

Kubernetes如果你是新的,新的语言,抽象和工具介绍可以令人恐惧,带你远离你的核心使命。

Kubernetes即使你已经有了专业知识,有很多建设:

• 创建和配置Kubernetes集群和节点池
• 设置spark-operator和k8自动定量(可选的,但是建议)
• 设置一个码头工人注册并创建一个进程包依赖关系
• 设置一个火花历史服务器(看到火花UI应用程序完成后,虽然高兴的是可以节省你麻烦!)
• 设置你的日志记录、监视和安全工具
• 优化应用程序配置为Kubernetes和I / O
• 启用现货/抢占式节点集群(可选的,但是建议)
• 与你的笔记本和/或调度程序建立集成

这就是为什么我们建立数据力学——照顾所有的设置,使火花Kubernetes易于使用的和具有成本效益的每个人,从最小的团队到大型企业。读火花在Kubernetes开源数据力学如何改善更多地了解我们的平台提供开源。

2。你应该运行最新版本火花

最初支持火花Kubernetes开始引发2.3 2018年2月,但是这个版本缺乏关键特性。在力学数据,我们只支持2.4及以上。我们强烈推荐使用:

• 火花3.0及以上:受益于动态分配每个火花的能力应用程序动态地添加和删除火花执行人根据负载。这个特性是非常重要的,如果你打算使用火花以交互式方式(从笔记本电脑)。这是唯一的方式使其成本效益。
• 火花3.1及以上:Spark-on-Kubernetes正式宣布投入使用和生产准备用这个版本阅读我们的文章深入研究火花3.1版本。它给重要的稳定和性能改进,除了强大的特性,如火花的能力预测点杀和优雅地关闭执行人(没有失去洗牌和缓存数据)打断了。

结论——你应该开始吗?

传统软件工程转向进行集装箱化在过去的几年中,这是不可否认的一个类似的转变是发生了大数据的工作量。事实上,自火花3.1(2021年3月发布),火花Kubernetes已正式被宣布为普遍可用,生产就绪。

这是否意味着每个数据团队应该成为Kubernetes专家?不客气。我们建造的海洋为Apache火花正是出于这个原因。对Kubernetes火花绝对设置,免费维修。我们帮助许多客户在Kubernetes运行火花,为新项目或火花从YARN-based基础设施作为迁移工作的一部分。我们的平台改善的开源版本通过添加直观的用户界面,笔记本和调度器集成和动态优化,通常产生50 - 75%的成本节省。

我们很乐意帮助!订一个演示与我们开始。