spark如何分析数据(spark的重要组件以及使用场景)

本文向您展示了Spark中核心概念的可视化。内容简洁易懂。它一定会让你的眼睛发光。希望通过这篇文章的详细介绍，你能有所收获。

对于分布式系统中背景知识较少的人来说，学习Spark并不容易。即使我使用Spark已经有一段时间了，我发现完全理解Spark中的所有核心概念仍然需要时间。Spark的官方文档提供了非常详细的解释，但更多的重点是放在实际编程上。同样，大量的在线教程可能会让你不知所措。所以，我想用更直观的方式写下那些Spark核心概念。希望你也会觉得有用！

注意：也许你已经对Hadoop有所了解，所以我将跳过节点和集群等琐碎事情的解释。

Spark架构和部署模式

简而言之，Spark运行在主工作架构上，这是一种典型的并行任务计算模型。运行Spark时，我们可以选择几种模式，分别是本地(主机、执行器和驱动都在同一个JVM机器中)、独立、YARN和Mesos。在这里，我们只讨论在纱线上的火花以及纱线客户端和纱线集群之间的区别，因为它们是最常用的，但非常令人困惑。

接下来的两张图片说明了两种模式的设置。他们看起来很相似，不是吗？但是，通过查看橙色突出显示的部分，您可能会注意到一个微小的差异，这就是Spark驱动程序所在的位置。这基本上是两种模式的唯一区别。

图1。Spark部署模式院子-客户端(左)和院子-集群(右)假设您已经编写了一个名为Spark _ hello _ world.py的Spark应用程序，在客户端模式下，当使用spark-submit执行python文件时，驱动程序直接在spark-submit过程中启动，因此它将与spark _ hello _ world.py驻留在同一台计算机上，当Spark上下文初始化时，本地计算机中的驱动程序将连接到集群中的应用程序主机。从主机开始，Spark启动了更多的执行器。

在集群模式下，spark_hello_world.py代码位于客户端计算机中，但客户端计算机不在集群中。当应用程序python代码被执行时，它将启动集群中某个节点的驱动程序。与Spark应用主文件一起，它可以启动执行程序并发出应用命令。

由于设置差别不大，您一定想知道为什么我们需要两种不同的模式。实际上，这与客户计算机和工作计算机物理上位于同一位置的事实有关。如果客户端计算机离工作节点“很远”，例如，您已经在笔记本电脑上编写了spark_hello_world.py，但是工作程序是一个AWS EC2实例，那么使用集群模式来最小化驱动程序和执行器之间的网络延迟是有意义的。另一方面，如果您的python文件位于离工作节点“非常近”的网关计算机中，那么客户端模式可能是一个不错的选择。

执行者

现在我们已经知道了Spark集群的设置，让我们放大到Spark中最重要的元素之一——执行器。Executor是运行任务并将数据跨任务存储在内存或磁盘中的过程。

浏览Spark文档时，您可能会对与执行程序相关的可配置参数数量感到惊讶。让我们从视觉上来看，而不是一遍又一遍地试图找出一个人的多个参数之间的关系。

图2。Spark执行器内部如图2所示，每个执行器中都有一个执行器JVM，用于存储RDD分区、缓存RDD分区以及运行内部线程和任务。如果内核数量超过任务要求，JVM中就会有可用的内核。执行器JVM的绿色块将是我们研究执行器中内存管理的起点。

执行程序内存管理

在执行器容器中，主要分配了两个内存块：内存开销和执行器内存。

内存开销是虚拟机内部的开销

部字符串，其他本机开销等内容预留的堆外内存。通过将数据缓存在主要Java堆空间之外但仍在RAM中的方式，堆外内存可使高速缓存克服冗长的时间  使用大堆大小时，JVM垃圾收集会暂停。

执行器的内存包括以下三个部分。

• 预留内存

• 用户内存：用于在Spark中存储用户数据结构和内部元数据等内容。

• 存储和执行内存：用于存储所有RDD分区并为任务分配运行时内存。

图3显示了每个存储块的相关参数。 假设我们将spark.executor.memory设置为4 GB，那么Spark将向资源管理器请求总共4.4  GB的内存。 在4 GB的执行程序内存中，我们实际上获得了3.7 GB，因为其余部分已保留。 默认情况下，我们获得2.2 GB(0.6 *  3.7)作为执行+存储内存。 其中1.1 GB用于存储RDD等存储空间，其余空间用于执行内存。

> Fig 3. Spark executor memory decomposition

RDD，工作，阶段和任务

如果您已经开始使用Spark UI调试Spark应用程序，那么可能很熟悉诸如作业，阶段和任务之类的关键字。 那么它们与RDD有何关系?

我们知道在RDD上有两种操作，即转换(例如，过滤，并集，非重复，交集)，这些操作实际上是在没有实际执行的情况下从现有的RDD中生成一个新的RDD，以及要执行的操作(例如，采取，显示，收集，foreach)  触发执行。 转换RDD时，基于父RDD和转换后的RDD之间的关系，相关性可以窄或宽。 依赖关系较窄，在父RDD中，一个或多个分区将映射到新RDD中的一个分区。  尽管具有广泛的依赖性，例如在执行join或sortBy时，但我们需要对分区进行混洗以计算新的RDD。

> Fig 4–1. narrow dependency in RDD transformation
> Fig 4–2. Wide dependency in RDD transformation

因此，作业，阶段和任务由操作类型和转换类型确定。 在RDD上执行操作时，将创建一个作业。  在工作中，可能有多个阶段，具体取决于我们是否需要执行广泛的转换(即洗牌)。 在每个阶段中，可以将一个或多个转换映射到每个执行程序中的任务。

> Fig 5. Illustration of one Spark job

为了真正理解它，我们来看以下简单的代码片段。

val RDD1 = sc.parallelize(Array('1', '2', '3', '4', '5')).map{ x => val xi = x.toInt; (xi, xi+1) } val RDD2 = sc.parallelize(Array('1', '2', '3', '4', '5')).map{ x => val xi = x.toInt; (xi, xi*10) } val joinedData = RDD2.join(RDD1) val filteredRDD = joinedData.filter{case (k, v) => k % 2 == 0} val resultRDD = filteredRDD.mapPartitions{ iter => iter.map{ case (k, (v1, v2) ) => (k, v1+v2) } } resultRDD.take(2)

此代码中包含一些操作，即map，join，filter，mapPartitions和take。  创建RDD时，Spark将分别为RDD1和RDD2生成两个阶段，如阶段0和1所示。由于map函数包含一个狭窄的依赖性，因此映射的RDD也将分别包含在阶段0和1中。  然后，我们将RDD1和RDD2连接起来，因为连接是包含混洗的广泛转换，因此Spark为该操作创建了另一个阶段。  之后，filter和mapPartition仍然是第2阶段的狭窄转换，通过调用take(这是一个动作)，我们触发了Spark的执行。

> Fig 6. DAG visualization

上述内容就是Spark中的核心概念可视化是怎样的，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。