什么是spark的惰性计算?有什么优势?_为什么在Kubernetes上运行Spark？

Spark是用于分析应用程序的开源，可伸缩，大规模并行，内存中执行引擎。

可以将其视为位于多个数据存储上方的内存层，在其中可以将数据加载到内存中并在整个集群中并行进行分析。 Spark Core：Spark的基础，它为调度和基本I / O提供了许多自由，Spark提供了100多个高级操作员，使构建并行应用程序变得容易。

Spark还包括预构建的机器学习算法和图形分析算法，这些算法专门编写为在内存中并行执行。 它还支持查询的交互式SQL处理和实时流分析。 因此，您可以使用Java，Python，R和Scala等编程语言编写分析应用程序。

您可以在云，Hadoop YARN，Apache Mesos或Kubernetes上使用其独立集群模式运行Spark。 访问HDFS，Cassandra，HBase，Hive，对象存储和任何Hadoop数据源中的数据。

Spark可以在Kubernetes管理的集群上运行。 此功能利用已添加到Spark的本地Kubernetes调度程序。

怎么运行的？

> Spark Submit on k8s

spark-submit可以直接用于将Spark应用程序提交到Kubernetes集群。 提交机制的工作方式如下：

· Spark创建一个在Kubernetes容器中运行的Spark驱动程序。

· 驱动程序将创建执行程序，这些执行程序也将在Kubernetes Pod中运行并连接到它们，并执行应用程序代码。

· 应用程序完成后，执行程序Pod终止并被清理，但驱动程序Pod保留日志，并在Kubernetes API中保持"完成"状态，直到最终对其进行垃圾收集或手动清理为止。

但是，为什么我们应该使用Kubernetes作为集群管理器？

这种集成当然非常有趣，但是应该考虑的一个重要问题是，为什么组织应该选择Kubernetes作为集群管理器，为什么不运行在默认情况下随Spark附带的Standalone Scheduler或运行在YARN等生产级集群管理器上。

让我尝试用以下几点来回答这个问题。

· 您是否正在使用容器化的数据分析管道？ 一家典型的公司想要统一数据管道，例如，如果某个典型的数据管道需要Queue，Spark，DB，Visualization应用程序并且所有内容都在容器上运行，那么在容器上运行Spark并使用Kubernetes来管理整个管道是有意义的。

· 资源共享得到了更好的优化。与其在专用硬件上运行管道，不如在Kubernetes集群上运行它，是非常高效和最佳的，因此，由于管道中的所有组件并非始终都在运行，因此资源共享更好。

· 利用Kubernetes生态系统 Spark工作负载可以直接使用Kubernetes集群通过命名空间和配额以及管理功能(如可插拔授权和日志记录)进行多租户和共享。 最重要的是，它不需要在Kubernetes集群上进行任何更改或进行新安装。 只需创建一个容器映像并为您的Spark应用程序设置正确的RBAC角色，便一切就绪。 当您使用Kubernetes作为集群管理器时，您将获得与日志记录和监视解决方案的无缝集成。 社区还在探索高级用例，例如管理流工作负载和利用Istio等服务网格。

· 使用独立调度程序的局限性。您可以通过启动以独立模式运行的Spark集群轻松在Kubernetes上运行Spark。这意味着您在Kubernetes上运行Spark Master和worker和完整的Spark集群。这种方法非常可行，并且适用于许多情况。它具有其自身的优点，因为它是在Kubernetes上运行Spark的非常稳定的方式，并且您可以利用kubernetes的所有很酷的功能，例如资源管理，各种持久性存储及其用于日志记录和服务网格(Istio)的集成，但是Spark并不知道它在Kubernetes和Kubernetes上运行并不知道它在运行Spark。这意味着我们需要重复或复制一些配置，例如，如果要运行10 GB的执行器，则需要使用这些设置启动Kubernetes POD，并相应地指定Spark守护程序内存。请注意，您将需要为Spark Daemon进程提供一些额外的内存，例如Spark Master和Spark worker，并且不能仅将POD的全部内存用于驱动程序或执行程序。因此，如果没有专家:)，就会浪费资源，并且很容易弄乱配置。独立方法的另一个局限性在于它难以管理弹性-默认情况下独立不提供。

· YARN与Kubernetes的比较：尽管这并不是一个正确的比较，因为kubernetes仍然支持使用YARN作为资源管理器/谈判者的所有框架。 YARN用于许多生产工作负载，可用于运行任何应用程序。 Spark将YARN视为容器管理系统，以在其获取容器后请求具有定义的资源的Spark资源，并在容器之间建立基于RPC的通信以运行驱动程序和执行程序。 YARN不处理服务层，因为Spark需要处理服务层。 YARN可以通过释放和获取容器来自动缩放。 使用YARN容器的主要缺点是，它始终在容器中运行JVM，而当您在Kubernetes上运行时，您可以使用自己的映像，该映像非常少。

· Kubernetes社区支持。 如果您是组织机构，需要在容器协调器之间进行选择，则可以轻松选择Kubernetes，这不仅是因为它具有社区支持，而且还可以在您选择的" Prem"和" cloud provider"上运行，以及 没有CLOUD锁定您需要承受的痛苦。 Kubernetes与容器运行时无关，它具有非常广泛的功能，例如支持在容器上运行群集应用程序和服务负载平衡，服务升级而不会停止或发生任何中断以及定义明确的存储故事。

为什么您可能要避免使用Kubernetes作为Spark集群管理器？

这仍是一个beta功能，尚未投入生产。 有许多功能，例如动态资源分配，依赖关系的群集内分段，对PySpark和SparkR的支持，对Kerberized HDFS群集的支持以及客户端模式和流行的笔记本电脑交互式执行环境仍在工作中，并且不可用。

许多需要进一步改进的功能是将Executor日志，History服务器事件存储在持久卷上，以便以后可以引用它们。

摘要

Apache Spark是数据科学家必不可少的工具，它为从大规模数据转换到分析到机器学习的各种应用程序提供了一个强大的平台。

数据科学家正在采用容器，以通过实现诸如打包依赖项和创建可复制工件之类的好处来改善其工作流程。

鉴于Kubernetes是管理容器化环境的标准，因此自然支持Spark中的Kubernetes API。

(本文翻译自Rachit Arora的文章《Why run Spark on Kubernetes?》，参考：https://medium.com/@rachit1arora/why-run-spark-on-kubernetes-51c0ccb39c9b)