spark是一种基于内存的快速、通用、可扩展的大数据分析计算引擎
HBase 是一个基于 HDFS 的分布式数据库,擅长实时地随机读/写超大规模数据集。
Spark就是在传统的MapReduce计算框架的基础上,利用其计算过程的优化,从而大大加快了数据分析、挖掘的运行和读写速度,并将计算单元缩小到更适合并行计算和重复使用的RDD计算模型。
Spark是一个分布式数据快速分析项目。它的核心技术是弹性分布式数据集(Resilient DistributedDatasets),提供了比MapReduce丰富的模型,可以快速在内存中对数据集进行多次迭代,来支持复杂的数据挖掘算法和图形计算算法。
Spark确实会比MapReduce 更有优势。但是Spark是基于内存的,所以在实际的生产环境中,由于内存的限制,可能会由于内存资源不够导致Job执行失败,此时,MapReduce其实是一个更好的选择,所以Spark 并不能完全替代MR。
Spark 会替代 MR,Spark 存储依赖 HDFS,资源调度依赖 YARN,集群管理依赖 Zookeeper。
Hadoop虽然已成为大数据技术的事实标准,但其本身还存在诸多缺陷,最主要的缺陷是其MapReduce计算模型延迟过高,无法胜任实时、快速计算的需求,因而只适用于离线批处理的应用场景。
回顾Hadoop的工作流程,可以发现Hadoop存在如下一些缺点:
Spark主要具有如下优点:
Spark最大的特点就是将计算数据、中间结果都存储在内存中,大大减少了IO开销
Spark提供了多种高层次、简洁的API,通常情况下,对于实现相同功能的应用程序,Spark的代码量要比Hadoop少2-5倍。
但Spark并不能完全替代Hadoop,主要用于替代Hadoop中的MapReduce计算模型。实际上,Spark已经很好地融入了Hadoop生态圈,并成为其中的重要一员,它可以借助于YARN实现资源调度管理,借助于HDFS实现分布式存储。
一方面,由于Hadoop生态系统中的一些组件所实现的功能,目前还是无法由Spark取代的,比如,Storm可以实现毫秒级响应的流计算,但是,Spark则无法做到毫秒级响应。另一方面,企业中已经有许多现有的应用,都是基于现有的Hadoop组件开发的,完全转移到Spark上需要一定的成本。因此,在许多企业实际应用中,Hadoop和Spark的统一部署是一种比较现实合理的选择。
由于Hadoop MapReduce、HBase、Storm和Spark等,都可以运行在资源管理框架YARN之上,因此,可以在YARN之上进行统一部署(如图9-16所示)。这些不同的计算框架统一运行在YARN中,可以带来如下好处:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XFRUEa55-1614082527822)(C09418EA15E14558890FEDBDE8614E94)]
SparkCore
SparkSQL
SparkStreaming
SparkMLlib
SparkGraphX
1、通过Scala语言开发
maven项目
2、Spark运行环境
Spark作为一个数据处理框架和计算引擎,被设计在所有常见的集群环境中运行,在国内工作中主流的环境为Yarn,不过逐渐容器式环境也慢慢流行起来。接下来,我们就分别看看不同环境下Spark的运行
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TscoK3Zf-1614082527825)(D9494F32F23C4D0183929780BA437992)]
Spark应用程序在集群上部署运行时,可以由不同的组件为其提供资源管理调度服务(资源包括CPU、内存等)。比如,可以使用自带的独立集群管理器(standalone),或者使用YARN,也可以使用Mesos。因此,Spark包括三种不同类型的集群部署方式,包括standalone、Spark on Mesos和Spark on YARN。
安装spark
brew install scala
vim /etc/profile
export SCALA_HOME=/usr/local/Cellar/scala
export PATH=$PATH:$SCALA_HOME/bin
exportSPARK_HOME=/Users/sx/open-source/spark-2.3.0-bin-hadoop2.7
export PATH=$PATH:$SPARK_HOME/bin
tar -zxvf /Users/kolor/Downloads/spark-3.0.1-bin-hadoop2.7.tgz
cd /Users/kolor/spark-3.0.1-bin-hadoop2.7
___ 以上是local本地模式,再加上以下这些就是Standalone模式
1)进入 conf文件夹,修改slaves.template文件名为slaves
2)修改slaves文件,添加work节点
linux1
linux2
linux3
3)修改spark-env.sh.template文件名为spark-env.sh
mv spark-env.sh.template spark-env.sh
4)修改spark-env.sh
export JAVA_HOME=/opt/module/jdk1.8.0_144
SPARK_MASTER_HOST=linux1
SPARK_MASTER_PORT=7077
注意:7077端口,相当于hadoop内部通信的8020端口,此处的端口需要确认自己的hadoop配置。
5)分发spark-standalone目录
xsync spark-standalone
6)启动集群
sh /Users/kolor/spark-3.0.1-bin-hadoop2.7/start-all.sh
使用
scala> var i = 10
scala> sc.textFile("word.txt").flatMap(_.split(" ")).map((_,1).reduceByKey(_+_).collect
访问http即可获得WEB UI界面,linux1:4040
提交:把应用程序提交到本地环境中执行。(Spark案例)
SparkPi是类名
bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master local[2] \
./examples/jars/spark-examples_2.12-3.0.0.jar \
10
local本地毕竟只是用来进行练习演示的,真实工作中还是要将应用提交到对应的集群中去执行,这里我们来看看只使用Spark自身节点运行的集群模式,也就是我们所谓的独立部署(Standalone)模式。Spark的Standalone模式体现了经典的master-slave模式。
提交应用
SparkPi是类名
bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master spark://linux1:7077 \
./examples/jars/spark-examples_2.12-3.0.0.jar \
10
1) --class表示要执行Spark程序中包含主函数的类
2) --master spark://linux1:7077 独立部署模式,连接到spark集群。
表示Spark程序运行的模式(环境)
模式:local[*]、spark://linux1:7077、Yarn
3) spark-examples_2.12-3.0.0.jar,运行类所在的jar包
4)数字10表示程序的入口参数,用于设定当前应用的任务数量
--executor-memory 1G,指定每个executor可用内存为1G
--total-executor-cores 2,指定所有executor使用的cpu核数为2个。
--executor-cores,指定每个executor使用的cpu核数
application-jar,打包好的应用jar,包含依赖。这个URL在集群中全局可见。比如:hdfs://xxx,那么所有的节点的path都包含同样的jar
application-arguments,传给main()方法的参数
为什么要用Yarn来部署Spark?
因为 Yarn 支持动态资源配置。Standalone 模式只支持简单的固定资源分配策略,每个任务固定数量的 core,各 Job 按顺序依次分配在资源,资源不够的时候就排队。这种模式比较适合单用户的情况,多用户的情境下,会有可能有些用户的任务得不到资源。
Yarn 作为通用的种子资源调度平台,除了 Spark 提供调度服务之外,还可以为其他系统提供调度,如 Hadoop MapReduce, Hive 等。
独立部署(Standalone)模式由Spark自身提供计算资源,无需其他框架提供资源。这种方式降低了和其他第三方资源框架的耦合性,独立性非常强。但是你也要记住,Spark主要是计算框架,而不是资源调度框架,所以本身提供的资源调度并不是它的强项,所以还是和其他专业的资源调度框架集成会更靠谱一些。
1、解压缩文件
将spark-3.0.0-bin-hadoopp3.2.tgz文件上传到linux并解压缩,放置在指定位置。
tar -zxvf spark-3.0.0-bin-hadoop3.2.tgz -C /opt/module
cd /opt/module
mv spark-examples_2.12-3.0.0 spark-yarn
2、修改配置文件
1)修改hadoop配置文件/opt/module/hadoop/etc/hadoop/yarn-site.xml 并分发
2)vim spark-env.sh
export JAVA_HOME=/opt/module/jdk1.8.0
YARN_CONF_DIR=/opt/module/hadoop/etc/hadoop
3、启动HDFS以及YARN集群
4、发布任务
bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode cluster \
./examples/jars/spark-examples_2.12-3.0.0.jar \
10
Spark Streaming处理结果可以保存到 HDFS、Database、Dashboard
Spark是以线程级别并行,实时响应级别高,可以实现秒级响应、变相实现高效的流计算。
(SparkStreaming把流计算切成一段段,每段都是批处理,达到模仿流计算效果)
Spark 的核心是建立在统一的抽象弹性分布式数据集(Resiliennt Distributed Datasets,RDD)之上的,这使得 Spark 的各个组件可以无缝地进行集成,能够在同一个应用程序中完成大数据处理。
RDD 是 Spark 提供的最重要的抽象概念,它是一种有容错机制的特殊数据集合,可以分布在集群的结点上,以函数式操作集合的方式进行各种并行操作。
通俗点来讲,可以将 RDD 理解为一个分布式对象集合,本质上是一个只读的分区记录集合。每个 RDD 可以分成多个分区,每个分区就是一个数据集片段。一个 RDD 的不同分区可以保存到集群中的不同结点上,从而可以在集群中的不同结点上进行并行计算。
SparkStreaming无法实现毫秒级响应,借助Storm实现
之前的方案是通过Hadoop批量处理与Storm实时流计算。 现在直接通过Spark方案
所谓的高可用是因为当前集群中的Master节点只有一个,所以会存在单点故障问题。为了解决单点故障问题,需要在集群中配置多个Master节点,一旦处于活动状态的Master发生故障时,由备用Master提供服务,保证作业才可以继续执行。这里的高可用一般采用Zookeeper设置。
在具体讲解Spark运行架构之前,需要先了解几个重要的概念:
Spark框架的核心是一个计算引擎,整体来说,它采用了标准master-slave的结构。
如下图所示,它展示了一个Spark执行时的基本结构。图形中的Driver表示master,负责管理整个集群中的作业任务调度。图形中的Executor则是slave,负责实际执行任务。
由上图可以看出,对于Spark框架有两个核心组件:
Spark驱动器节点,用于执行Spark任务中的main方法,负责实际代码的执行工作。
Driver在Spark作业执行时主要负责:
Spark Executor 是集群中工作节点(Worker)中的一个 JVM 进程,负责在 Spark 作业
中运行具体任务(Task),任务彼此之间相互独立。Spark 应用启动时,Executor 节点被同时启动,并且始终伴随着整个 Spark 应用的生命周期而存在。如果有 Executor 节点发生了
故障或崩溃,Spark 应用也可以继续执行,会将出错节点上的任务调度到其他 Executor 节点
上继续运行。
Executor 有两个核心功能:
Spark 集群的独立部署环境中,不需要依赖其他的资源调度框架,自身就实现了资源调
度的功能,所以环境中还有其他两个核心组件:Master 和 Worker,
Hadoop 用户向 YARN 集群提交应用程序时,提交程序中应该包含 ApplicationMaster,用
于向资源调度器申请执行任务的资源容器 Container,运行用户自己的程序任务 job,监控整
个任务的执行,跟踪整个任务的状态,处理任务失败等异常情况。
说的简单点就是,ResourceManager(资源)和 Driver(计算)之间的解耦合靠的就是
ApplicationMaster。
Spark Executor 是集群中运行在工作节点(Worker)中的一个 JVM 进程,是整个集群中
的专门用于计算的节点。在提交应用中,可以提供参数指定计算节点的个数,以及对应的资
源。这里的资源一般指的是工作节点 Executor 的内存大小和使用的虚拟 CPU 核(Core)数
量。
应用程序相关启动参数如下:
--num-executors 配置Executor的数量
--executor-memory 配置每个Executor的内存大小
--executor-cores 配置每个Executor的虚拟CPU core数量
在分布式计算框架中一般都是多个任务同时执行,由于任务分布在不同的计算节点进行
计算,所以能够真正地实现多任务并行执行,记住,这里是并行,而不是并发。这里我们将
整个集群并行执行任务的数量称之为并行度。那么一个作业到底并行度是多少呢?这个取决
于框架的默认配置。应用程序也可以在运行过程中动态修改。
并行是同时计算(多个任务多核),并发是多线程(多个任务抢占1个核数)
Spark的基本运行流程如下:
Spark 的运行模式有 Local(也称单节点模式),Standalone(集群模式),Spark on Yarn(运行在Yarn上),Mesos以及K8s等常用模式,现在天网在不同的环境使用的模式也不尽相同
Spark的常用术语
1.Spark Yarn Client向YARN的ResourceManager申请启动Application Master。同时在SparkContent初始化中将YarnClientClusterScheduler和YarnClientSchedulerBackend;(这里初始化的对象和选择的模式有关)
2.yarn中的ResourceManager收到请求后,在集群中选择一个NodeManager,为该应用程序分配第一个Container,要求它在这个Container中启动应用程序的ApplicationMaster,启动与drive中的SparkContext进行联系进行资源的调度;
3.Client中的SparkContext初始化完毕后,与ApplicationMaster建立通讯,向ResourceManager注册,根据任务信息向ResourceManager申请资源(Container);
4.一旦Application Master申请到资源(也就是Container)后,便与对应的NodeManager通信,要求它在获得的Container中启动启动excutor,excutor启动后会向Client中的SparkContext注册并申请Task; 注:在yarn-client模式下可以理解,yarn中Application master节点只是初始化的时候进行yarn中资源的委派,实际运行过程中,还是driver任务中的sparkContext进行实际的任务的分配和执行
5.Client中的SparkContext分配Task给excutor执行,excutor运行Task并向Driver汇报运行的状态和进度,以让Client随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务;
6.应用程序运行完成后,Client的SparkContext向ResourceManager申请注销并关闭自己。(天网的任务在没有干预下不会停止)
Spark Streaming和JStorm的本质区别
实时计算和离线计算对应,是计算的场景,是需求。流计算和批量计算对应是计算的方式。
流计算的本质是:无状态性
批量计算的本质是有状态计算,或者说没有状态性的批量计算根本就是流计算,只是把时间维度的计算变成了空间维度的计算。
存在大量的状态保存的需求,都是需要使用Spark Streaming来计算的。
其实就算使用Spark和Storm的混合架构,数据两次进内存(进程间数据流)也是对网络带宽的浪费,所以如果 在不考虑很高的实时要求的情况下,对于有状态运算的项目完全可以用Spark Streaming取代掉Storm。 对于没有状态的项目,当然可以完全用JStorm了。
Spark Streaming处理结果可以保存到 HDFS、Database、Dashboard
Spark是以线程级别并行,实时响应级别高,可以实现秒级响应、变相实现高效的流计算。
(SparkStreaming把流计算切成一段段,每段都是批处理,达到模仿流计算效果)
Spark 的核心是建立在统一的抽象弹性分布式数据集(Resiliennt Distributed Datasets,RDD)之上的,这使得 Spark 的各个组件可以无缝地进行集成,能够在同一个应用程序中完成大数据处理。
RDD 是 Spark 提供的最重要的抽象概念,它是一种有容错机制的特殊数据集合,可以分布在集群的结点上,以函数式操作集合的方式进行各种并行操作。
通俗点来讲,可以 将 RDD 理解为一个分布式对象集合,本质上是一个只读的分区记录集合。每个 RDD 可以分成多个分区,每个分区就是一个数据集片段。 一个 RDD 的不同分区可以保存到集群中的不同结点上,从而可以在集群中的不同结点上进行并行计算。
SparkStreaming无法实现毫秒级响应,借助Storm实现
Spark 会替代 MR,Spark 存储依赖 HDFS,资源调度依赖 YARN,集群管理依赖 Zookeeper。
之前的方案是通过Hadoop批量处理与Storm实时流计算。 现在直接通过Spark方案
Kafka 分布式的单位是 Partition。如何保证消息有序,需要分几个情况讨论。
实际情况中: (1)不关注顺序的业务大量存在;(2)队列无序不代表消息无序。
第(2)条的意思是说::我们不保证队列的全局有序,但可以保证消息的局部有序。举个例子: 保证来自同1个 order id 的消息,是有序的!
Kafka 中发送1条消息的时候,可以指定(topic, partition, key) 3个参数。partiton 和 key 是可选的。如果你指定了 partition,那就是所有消息发往同1个 partition,就是有序的。并且在消费端,Kafka 保证,1个 partition 只能被1个 consumer 消费。或者你指定 key(比如 order id),具有同1个 key 的所有消息,会发往同1个 partition。也是有序的。
https://blog.csdn.net/huojiao2006/article/details/80563112
Spark On Yarn 的优势
yarn-client 和 yarn cluster 的异同 :