DZone>大数据专区>在Kubernetes上运行Apache Spark
在Kubernetes上运行Apache Spark
本文介绍了在K8s上使用Spark以克服对云供应商的依赖，以及在Kubernetes上运行Apache Spark。
通过
-
Jul. 26, 21 - 大数据区 -教程
喜欢 (3)
评论
保存
鸣叫
6.36K浏览次数
加入DZone社区，获得完整的会员体验。
在过去的几周里，我一直在Kubernetes（K8s）上部署一个Spark集群。我想和大家分享一下我发现的挑战、架构和解决方案的细节。
挑战
在Empathy，所有在生产中运行的代码都必须与云无关。截至本出版日，Empathy已经通过使用Spark解决方案克服了之前对云供应商的依赖，根据云供应商的说法。EMR（AWS方案），Dataproc（GCP方案），和HDInsight（Azure方案）。
这些云供应商的不同解决方案为在云上部署Spark提供了一个简单易行的方法。然而，当公司规模扩大时，会出现一些限制，从而导致几个关键问题。
- 你如何协调作业？
- 如何分配Spark作业？
- 如何安排夜间作业？
- 作业的代码配置在哪里？
- 如何传播变化？
- 你能重复使用作业定义吗？模板？
- 你能通过代码引用作业吗？
- 你能从localhost进行测试吗？
这些都是在尝试执行Spark作业时常见的问题。用Kubernetes解决这些问题可以节省精力，提供更好的体验。
在K8s上运行Apache Spark为我们提供了以下好处。
- 可扩展性。新的解决方案应该是可扩展的，可以满足任何需求。
- 可靠性。新的解决方案应该监控计算节点，并在出现故障时自动终止和替换实例。
- 可移植性。新的解决方案应该可以部署在任何云解决方案中，避免对特定云供应商的依赖。总的来说，这种方法节省了思考协调、分配和调度Spark作业与不同云服务提供商的时间。
- 成本效益高。你不需要云供应商，所以你可以节省这些成本。
- 监控。新的解决方案应该包括临时监控。
- K8s生态系统。与其他工作负载一样使用共同的生态系统，并提供持续部署、RBAC、专用节点池、自动缩放等。
其好处与Empathy为运行在Kubernetes上的Apache Flink提供的解决方案相同，我在之前的文章中探讨过。
Kubernetes上的Apache Spark
Apache Spark是一个用于大数据处理的统一分析引擎，对于分布式处理尤其方便。Spark用于机器学习，是目前技术领域最大的趋势之一。
Apache Spark架构
Spark Submit可以用来直接向Kubernetes集群提交一个Spark应用。其流程如下。
- Spark Submit从客户端发送到主节点的Kubernetes API服务器。
- Kubernetes会安排一个新的Spark Driver pod。
- Spark Driver pod将与Kubernetes通信，请求Spark执行器pod。
- 新的执行器pod将被Kubernetes安排。
- 一旦新的执行器pod运行，Kubernetes将通知Spark Driver pod，新的Spark执行器pod已经准备就绪。
- Spark Driver pod将在新的Spark执行器pod上安排任务。
火花提交流程图
您可以使用Spark Submit（传统方式）或使用Spark Operator来调度Spark应用程序。
火花提交
Spark Submit是一个用于提交Spark应用并在Spark集群上启动应用的脚本。一些不错的功能包括。
- Kubernetes版本。不依赖于Kubernetes版本。
- 本地Spark。它包含在Spark镜像中。
- 非声明性设置。需要计划如何协调作业。
- 定义需要的K8s资源。安装configmaps、volume、设置anti-affinity、nodeSelectors，等等。
- 不需要CRD。不需要Kubernetes定制资源。
Spark运营商
SparkOperator项目是由谷歌开发的，现在是一个开源项目。它使用Kubernetes自定义资源来指定、运行和浮现Spark应用程序的状态。一些不错的功能包括。
- 声明性。通过自定义资源对应用进行规范和管理。
- 有计划的重启。可配置的重启策略。
- K8s资源自动定义。支持挂载configmaps和卷，设置pod亲和力，等等。
- 依赖性注入。直接注入依赖关系。
- 度量。支持收集和输出应用级指标和驱动/执行器指标到Prometheus。
- 开源社区。每个人都可以做出贡献。
Spark Submit与Spark Operator
上面的图片显示了Spark Submit与Spark Operator的主要命令。
Empathy的解决方案更倾向于Spark Operator，因为它可以比Spark Submit更快地进行迭代，在Spark Submit中，你必须为每个用例创建自定义的Kubernetes清单。
解决方案的细节
为了解决挑战部分提出的问题，ArgoCD和Argo Workflows可以帮助你，同时还有CNCF项目的支持。例如，你可以使用ArgoCD从Kubernetes安排你最喜欢的Spark应用工作负载，以创建Argo工作流并定义顺序作业。
流程图如下。
- 在git上定义你的变化。
- ArgoCD将你的git修改同步到你的K8s集群（例如，创建一个Argo工作流模板）。
- Argo工作流模板允许你为多个Spark作业定制输入和重复使用配置，并根据Argo工作流创建夜间作业。
解决方案流程图
ArgoCD
ArgoCD是一个用于Kubernetes的GitOps持续交付工具。其主要优势在于。
- GitOps：使用git存储库作为定义所需应用程序状态的真理源。
- 声明式设置。一切都在git上!
- 可追溯性和自动化。应用程序的部署可以跟踪分支、标签等的更新。应用程序的部署将根据具体的目标环境而自动进行。
- Web UI。好看的UI可以检查部署的工作负载。
- K8s清单Kustomize, Helm, ksonnet, jsonnet等。选择你的斗士!
更详细的信息可以在其官方文档中找到。
Argo工作流
Argo Workflows是一个针对Kubernetes的工作流解决方案。主要优点是。
- 作业编排。这允许按顺序编排作业或创建一个自定义的DAG。
- 安排工作流程。Cron原生。
- Spark应用。在任何Kubernetes集群上轻松地协调Spark应用。
- 工作流模板。为不同的用例重复使用模板。输入可以被参数化。
- WebUI。优秀的可视化UI，以检查工作流的进展。
更详细的信息可以在其官方文档中找到。
监测
一旦Prometheus刮取了指标，就需要一些Grafana仪表盘。为Apache Spark定制的Grafana仪表盘是基于以下社区仪表盘的。
总结一下
Empathy选择Spark Operator、ArgoCD和Argo Workflows来创建Kubernetes上的Spark应用工作流解决方案，并使用GitOps来传播这些变化。本文所说明的设置已经在生产环境中使用了一个月左右，反馈非常好每个人都对这个工作流感到满意--拥有一个对任何云提供商都有效的单一工作流， 从而摆脱了个别云提供商的解决方案。
要想自己测试它，请跟随这些实践样本 ，享受从本地主机部署一些Spark应用程序，并在本指南中描述的所有设置。Hands-on Empathy Repo。
我还借鉴了我在2021年西班牙Kubernetes日的演讲。
虽然旅程很漫长，但我们一路上学到了很多。我希望我们的创新也能帮助你变得更适合云计算。
参考资料
- Spark运营商
- 在Kubernetes上运行Spark
- 在Kubernetes上实施和整合Argo工作流和Spark
- Argo项目
- 在Kubernetes上扩展Apache Spark
- Spark Docker Image
- 优化Kubernetes上的Spark性能
- 在Kubernetes上使用Argo和Helm的Spark - GoDataDriven
- 亚马逊EKS火花ETL工作负载
- 将Spark工作负载从EMR迁移到K8s
- 淘宝网上卖的是什么？
- 实践中的Empathy Repo。创业者们的 "创业梦"。
主题。
火花、 Kubernetes、 不依赖云、 大数据、 分析
经Ramiro Alvarez Fernandez授权发表于DZone。点击这里查看原文。
DZone贡献者所表达的观点属于他们自己。
DZone上的热门文章
评论
