spark学习2

数据通过解析后被存放成case class类型，如果想要提取处理，就需要将数据转换成df toDF()

而一旦转换成DF 对应的表头字段和case class中的相对应，df的一些有趣操作，

ratingsData.toDF().filter($"rating" > 4).select("product").rdd.map((_, 1)).reduceByKey(_ + _).sortBy(_._2, false).map(_._1).take(100)，其实我是想求一个聚合函数，一时竟想不起来该怎么做了，索性转成rdd变成求wordcount

其实可以这么解决通过注册成临时表然后通过sql语句查询，df只有注册成临时表才能像sql那样查询，

spark.sql("select product,count(*) from A group by product ")简单的分组聚合累加

或者直接通过 df提供的方法ratingsData.toDF().filter($"rating" > 4).groupBy("product").count().createTempView("A")

groupBy("product".count())免去了注册临时表的麻烦 createTempView

在此需要提示一下，临时表分为好几种，如果是global 的需要在前面加上global_temp.xxx否则会报找不到此表

val predictResultOfTestSet = recomModel.predict(testSetOfRatingData.map {
case Rating(user, product, rating) => (user, product)
})

val formatResultOfTestSet = testSetOfRatingData.map {
case Rating(user, product, rating) => ((user, product), rating)
}
scala的强大之处case class模式匹配如果对应与这样则转换成指定的格式 testSetOfRatingData.map {
case Rating(user, product, rating) => (user, product) 其实不需要这么麻烦，

map(x=>(x.user,x.product))即可

rdd的cache 和persist

从源码看cache是直接调用的persist，cache的默认存储级别为memory，而persist可以通过传入存储级别改变

spark-env调优

spark_worker_cores 总共的核数允许spark ，默认全部

spark_worker_momoey 默认总内存减去1G

master_port 7077 webui 8080

spark中的一些概念：Aplication应用就是一个spark-submit提交的一个任务被称之为Application应用

stage划分宽依赖窄依赖如果父rdd进入一个窄依赖否则宽依赖

用户提交的应用程序代码在spark中运行起来就是一个driver，

spark on yarn有两种方式 cluster client cluster一般用于生产环境，client用于交互测试。主要区别是，client的driver运行在客户端进程中，后者的driver运行在nodemanager的applicationmaster中，driver负责分发作业的，由于client模式driver在客户端上，客户端可能与executor，不再同一局域网中，通信会很慢

提交作业时yarn会将spark jars分发到yarn的container中，这十分耗费资源，故而我们可以将spark jars放在一个yarn可以访问到的目录中，具体做法如下：

vi spark-default.cong 添加

spark.yarn.jars hdfs://ip:8021/somepath/*

保存生效，并将所有的spark jars上传至hdfs://ip:9000/somepath/即可。

spark对于同时运行的作业数目有一定的限制，该限制由参数"spark.port.maxRetries"决定，该参数默认值为16，表明同一时间运行的作业最多为17个（不是16个哦），生产上16肯定太小，我们可以更改这一数字，具体做法如下：

vi spark-default.cong 添加

spark.port.maxRetries ${业务所需要的数值

https://blog.csdn.net/qq_33624952/article/details/79341034

这里写图片描述

YARN 是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、 NodeManager（NM）、ApplicationMaster（AM）。 ResourceManager 负责所有资源的监控、分配和管理； ApplicationMaster 负责每一个具体应用程序的调度和协调； NodeManager 负责每一个节点的维护。对于所有的 applications，RM 拥有绝对的控制权和对资源的分配权。而每个 AM 则会和 RM 协商资源，同时和 NodeManager 通信来执行和监控 task

Resourcemanager：

 ResourceManager 负责整个集群的资源管理和分配，是一个全局的资源管理系统。  NodeManager 以心跳的方式向 ResourceManager 汇报资源使用情况（目前主要是 CPU 和内存的使用情况）。RM 只接受 NM 的资源回报信息，对于具体的资源处理则交给 NM 自己处理。  YARN Scheduler 根据 application 的请求为其分配资源，不负责 application job 的监控、追踪、运行状态反馈、启动等工作。

Nodemanager：

 NodeManager 是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN 集群每个节点都运行一个 NodeManager。  NodeManager 定时向 ResourceManager 汇报本节点资源（CPU、内存）的使用情况和 Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节点。  NodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请求。

ApplicationMaster：

用户提交的每个应用程序均包含一个 ApplicationMaster ，它可以运行在 ResourceManager 以外的机器上。  负责与 RM 调度器协商以获取资源（用 Container 表示）。  将得到的任务进一步分配给内部的任务(资源的二次分配)。  与 NM 通信以启动/停止任务。  监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

RM 只负责监控 AM，并在 AM 运行失败时候启动它。RM 不负责 AM 内部任务的容错，
任务的容错由 AM 完成。

用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。步骤2　ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。步骤3　ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。步骤4　ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。步骤5　一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。

yarn资源调度器：fifo 先进先出不适合共享集群，大应用会占用太长时间，

Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

在 Fair 调度器中，我们不需要预先占用一定的系统资源，Fair 调度器会为所有运行的 job 动态的调整系统资源。如下图所示，当第一个大 job 提交时，只有这一个 job 在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair 调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。需要注意的是，在下图 Fair 调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的 Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终效果就是 Fair 调度器即得到了高的资源利用率又能保证小任务及时完成。

　　Spark集群部署后，需要在主节点和从节点分别启动Master进程和Worker进程，对整个集群进行控制。在一个Spark应用的执行过程中，Driver和Worker是两个重要角色。Driver程序是应用逻辑执行的起点，负责作业的调度，即Task任务的分发，而多个Worker用来管理计算节点和创建Executor并行处理任务。在执行阶段，Driver会将Task和Task所依赖的file和jar序列化后传递给对应的Worker机器，同时Executor对相应数据分区的任务进行处理。

　　Spark的架构中的基本组件：

Cluster Manager：在standalone模式中即为Master主节点，控制整个集群，监控worker。在YARN模式中为资源管理器
Worker：从节点，负责控制计算节点，启动Executor或者Driver。在YARN模式中为NodeManager，负责计算节点的控制。
Driver：运行Application的main()函数并创建SparkContext。
Executor：执行器，在worker node上执行任务的组件、用于启动线程池运行任务。每个Application拥有独立的一组Executor。
SparkContext：整个应用的上下文，控制应用的生命周期。
RDD：Spark的基础计算单元，一组RDD可形成执行的有向无环图RDD Graph。
DAG Scheduler：根据作业（task）构建基于Stage的DAG，并提交Stage给TaskScheduler。
TaskScheduler：将任务（task）分发给Executor执行。
SparkEnv：线程级别的上下文，存储运行时的重要组件的引用。

Application：Application都是指用户编写的Spark应用程序，其中包括一个Driver功能的代码和分布在集群中多个节点上运行的Executor代码
Driver：Spark中的Driver即运行上述Application的main函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负责与ClusterManager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同时负责将SparkContext关闭，通常用SparkContext代表Driver
Executor：某个Application运行在worker节点上的一个进程，该进程负责运行某些Task，并且负责将数据存到内存或磁盘上，每个Application都有各自独立的一批Executor，在Spark on Yarn模式下，其进程名称为CoarseGrainedExecutor Backend。一个CoarseGrainedExecutor Backend有且仅有一个Executor对象，负责将Task包装成taskRunner，并从线程池中抽取一个空闲线程运行Task，这个每一个CoarseGrainedExecutor Backend能并行运行Task的数量取决于分配给它的cup个数
Cluster Manager：指的是在集群上获取资源的外部服务。目前有三种类型

standalone：spaark原生的资源管理，由Master负责资源的分配
Apache Mesos：与hadoop MR兼容性良好的一种资源调度框架
Hadoop Yarn：主要指Yarn中的ResourceManager

Worker：集群中任何可以运行Application代码的节点，在Standalone模式中指的是通过slave文件配置的Worker节点，在Spark on Yarn模式下就是NoteManager节点
Task：被送到某个Executor上的工作单元，但HadoopMR中的MapTask和ReduceTask概念一样，是运行Application的基本单位，多个Task组成一个Stage，而Task的调度和管理等是由TaskScheduler负责
Job：包含多个Task组成的并行计算，往往由Spark Action触发生成，一个Application中往往会产生多个Job
Stage：每个Job会被拆分成多组Task，作为一个TaskSet，其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生Shuffle的地方
DAGScheduler：根据Job构建基于Stage的DAG（Directed Acyclic Graph有向无环图），并提交Stage给TASKScheduler。其划分Stage的根据是RDD之间的依赖的关系找出开销最小的调度方法，如下图

spark2.0 新的api SparkSession 取代

 val spark = SparkSession.builder.appName("Simple Application").getOrCreate()

spark.read.textFile("xxx") 返回值为dataset

一些transformation map filter flatmap mappartitions reducebykey

action reduce collect count take

七种存储级别

spark checkpoint 两种方式一种 mertadata checkpoint类似于hdfs 记录日志以防不测

data checkpoint 直接将数据记录到hdfs

重头戏：kafka和sparkStreaming集成：

因为kafka有了新的消费者api在version0.8 和 0.10，所以有两种方式去集成kafka，感觉kafka很麻烦，搞那么多干嘛，自己给自己找麻烦，版本不匹配，是个问题，幸亏cdh解决了这个问题，目前kafka 0.8 版本集成已经被spark2.3.0以上的抛弃了，

	spark-streaming-kafka-0-8	spark-streaming-kafka-0-10
Broker Version	0.8.2.1 or higher	0.10.0 or higher
API Maturity	Deprecated	Stable
Language Support	Scala, Java, Python	Scala, Java
Receiver DStream	Yes	No
Direct DStream	Yes	Yes
SSL / TLS Support	No	Yes
Offset Commit API	No	Yes
Dynamic Topic Subscription	No	Yes

0.8版本的已经被spark2.3.0及以上给抛弃了，

但还是有两种方法去集成，第一种：receiver方式和kafka的高级api，第二种方式spark1.3提出更高的性能

方法一基于receiver的方法，receiver 用kafka高级消费者api实现，但是这种方法会丢失数据，宋轶还需要开启wal机制（write ahead log）预写日志，从spark1.2引入，该机制为receiver接受到的数据全部被写入配置好的checkpoint目录中，避免数据丢失，配置该项需要

streamingContext的checkpoint（）设置一个checkpoint目录，然后spark.streaming.receiver.writeAheadLog.enable参数设置为true

但是wal的缺点：

会导致Receiver的吞吐量大幅下降，因为单位时间内有相当一部分时间将数据写入与写日志

解决办法：
如果又希望开启预写日志机制，确保数据零损失，又不希望影响系统的吞吐量，那么可以创建多个输入DStream启动多个Reciver，然后将这些receiver接收到的数据使用ssc.union()方法将这些dstream中的数据进行合并。此外在启用了预写日志机制之后，推荐将复制持久化机制禁用掉，因为所有数据已经保存在容错的文件系统中了，不需要再用复制机制进行持久化，保存一份副本了，只要将输入的DStream的持久化机制设置一下即可

 groupId = org.apache.spark
 artifactId = spark-streaming-kafka-0-8_2.11
 version = 2.4.0

 import org.apache.spark.streaming.kafka._

 val kafkaStream = KafkaUtils.createStream(streamingContext,
     [ZK quorum], [consumer group id], [per-topic number of Kafka partitions to consume])

第二种是direct 方式，没有receiver，通过轮循定期的方式去查询kafka每个topic+partition的最后偏移量，kafka simple api ，就像是读取本地文件，相比与receive方式，有以下几个好处

1 更加简单的并行度，direct会创建和kafkapartition数量一致的rdd 分区去消费，一对一的消费

2 高效 3执行一次语义：receiver方式用kafka高级api，存储消费记录在zookeeper上，可能会导致多次消费，所以第二种方式，direct方式，用simple api将offest存在checkpoint上，

 groupId = org.apache.spark
 artifactId = spark-streaming-kafka-0-8_2.11
 version = 2.4.0

val spark = SparkSession.builder()

.master("local[2]")

.appName("streaming").getOrCreate()

val sc =spark.sparkContext

val ssc = new StreamingContext(sc, Seconds(5))

// Create direct kafka stream with brokers and topics

val topicsSet =Set("weblogs")

val kafkaParams = Map[String, String]("metadata.broker.list" -> "node5:9092")

val kafkaStream = KafkaUtils.createDirectStream[String, String, StringDecoder, StringDecoder](

ssc, kafkaParams, topicsSet)

val lines = kafkaStream.map(x => x._2)

val words = lines.flatMap(_.split(" "))

10版本的kafka broker

和8版本的direct方式差不多，但是因为kafka new api还是有一点不同，

groupId = org.apache.spark
artifactId = spark-streaming-kafka-0-10_2.11
version = 2.4.0

已经将kafka依赖添加进来了，不要在手动添加kafka-client等依赖，

import org.apache.kafka.clients.consumer.ConsumerRecord
import org.apache.kafka.common.serialization.StringDeserializer
import org.apache.spark.streaming.kafka010._
import org.apache.spark.streaming.kafka010.LocationStrategies.PreferConsistent
import org.apache.spark.streaming.kafka010.ConsumerStrategies.Subscribe

val kafkaParams = Map[String, Object](
  "bootstrap.servers" -> "localhost:9092,anotherhost:9092",
  "key.deserializer" -> classOf[StringDeserializer],
  "value.deserializer" -> classOf[StringDeserializer],
  "group.id" -> "use_a_separate_group_id_for_each_stream",
  "auto.offset.reset" -> "latest",
  "enable.auto.commit" -> (false: java.lang.Boolean)
)

val topics = Array("topicA", "topicB")
val stream = KafkaUtils.createDirectStream[String, String](
  streamingContext,
  PreferConsistent,
  Subscribe[String, String](topics, kafkaParams)
)

stream.map(record => (record.key, record.value))

如果要保证exactly once 需要存储kafka offest ，有三种方式

1存在checkpoint中，

2kafka itself kafka自己维护了一个自动提交offest的方法，但是这种方式可能会出现一下情况，成功提交offest，但是spark operate没有进行处理，所以这也是为什么需要sets “enable.auto.commit” to false，但是可以自己手动提交offest的记录

猜你喜欢