saprk streaming

saprk streaming

1、实时计算

spark是微批处理，每隔一段时间处理一次

flink 实时处理，每一条数据都会处理

2、将接收过来的数据，封装成一个rdd，执行rdd的计算

3、有状态算子

updatastatebykey

• 需要开启checkpoint，需要保存之前计算的结果

reducebykeyandwindow

• 统计最近一段时间的数据，每隔一段时间统计一次
• 优化版本，需要一个减的函数

4、sql on stream

通过sparksession创建DF，在流上面写sql

5、sparksession

统一spark入口，统一api，流批统一

6、sparkstreaming第一次运行数据不丢失

kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据

7、精准一次消费

1、手动维护偏移量

2.处理完业务数据后，再进行提交偏移量操作

极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费

8、 Spark Streaming 一个stage耗时

Spark Streaming stage耗时由最慢的task决定,所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。

9、Spark Streaming 默认分区个数

Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时

10、 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？

一、基于Receiver的方式

• 这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的（如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题），然后Spark Streaming启动的job会去处理那些数据。
• 然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。

二、基于Direct的方式

• 这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而能够确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。

• 优点

  • 简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。
  • 高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。
  • 一次且仅一次的事务机制。

• 对比

  • 基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。
  • 基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。
    在实际生产环境中大都用Direct方式

11、简述SparkStreaming窗口函数的原理

窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。

spark 优化

代码优化

• 1、避免创建重复的RDD

• 2、对多次使用的RDD进行缓存

• 3、尽量使用高性能的算子

  • reducebykey

  • foreachpartition

    /**

    • 建立jdbc连接
    • 如果用foreach，有1000条数据，就会连接1000次
    • 这样会产生太多的通信
    • 如果将，连接代码，拿到算子外部，也就是foreach
    • 会直接报错
    • 因为连接的对象不能序列化，也不能再啊网络中传输
    • 算子外部在driver端，而算子内部在executor端

    //*

    • foreachePartition:遍历一个分区的数据
    • 参数就是表示一个分区的数据
    • 如果需要将数据保存到外部数据库，使用foreachPartition 代替foreach
    • foreachPartition 每一个分区只会创建一个连接
      */
      一般用于和外部数据库连接的时候

  • coalesce

    /**

    • repartition: 没有实际的业务逻辑，只是修改rdd分区数据，
      但是会产生shuffle
    • repartition : 既可以提高分区也可以减少分区
    • coalesce: 修改分区数据，如果不产生shuufle ,
      不能用于提高分区数据
    • coalesce（shuffle=false）： 一般用于合并小文件，
      不产生shuffle ,效率高

    */

• 4、尽量避免使用shuffle算子

• 5、对经常使用的RDD进行持久化

  /**

  • rdd中默认不报错数据，如果对同一个rdd使用多次，这个rdd会处理多次
  • 持久化级别选择
  • 1、如果数据量不大，内存充足----> MEMORY_ONLY
  • 2、如果数据超过内存限制 —? MEMORY_AND_DISK_SER (不管压缩不压缩，放内存中都比放磁盘上快，)
  • 压缩—> 体积小，压缩和解压需要时间

  */

• 6、广播大变量

  map join

  注意：map join 不产生shuffle过程
  因为：map join是在map端先进行大表关联小表，进行关联计算
  没有hash分区

• 7、优化数据结构

  1.尽量使用字符串代替自定义的类
  2.尽量使用基本数据类型代替字符串
  3.尽量使用数组代替集合

• 8、使用kryo优化序列化性能

  /**

  • 使用kryo序列化方式代替默认序列化方式（objectOutPutStream/objectInPutStream）
  • 性能提高10倍
  • spark 三个地方涉及到序列化
  • 1、算子里面用到可外部变量
  • 2、RDD 类型为自定义类型，同时使用checkpoint 或者 使用shuffle类算子的时候会产生序列化
  • 3、 cache SER

• 9、使用fastutil库

参数优化

• 1、num-executors

  • 直接决定任务可以执行多块
  • 1、一般指定50-100比较合适
  • 2、executor-cores 不能超过yarn总的cpu数
  • 3、executor-memory 不能超过yarn总的内存，一般在1/3或者最多一半左右

• 2、executor-cores

  • 一般2-4个，保证每一个cpu分到的内存不低于2G

• 3、executor-memory

  • 一般指定4G-8G

• 4、driver-memory

  • Driver内，用于存储广播变量

• 5、conf spark.default.parallelism=100

  • rdd shuffle之后reduce的数量

• 6、conf spark.sql.shuffle.partitions=100

  • spark sql shuffle 之后的reduce数量 默认是200

• 7、conf spark.storage.memoryFraction=0.6

  • 默认持久化可以用的内存分配比例

• 8、conf spark.shuffle.memoryFraction=0.2

  • 默认shuffle阶段可以使用的内存比例

• 9、conf spark.locality.wait=10

  • task在executor中等待的时间

    在Spark Application提交后，Driver会根据action算子划分成一个个的job，然后对每一 个job划分成一个个的stage，stage内部实际上是由一系列并行计算的task组成的，然后 以TaskSet的形式提交给你TaskScheduler，TaskScheduler在进行分配之前都会计算出 每一个task最优计算位置。Spark的task的分配算法优先将task发布到数据所在的节点上 ，从而达到数据最优计算位置。

    数据本地化级别

    PROCESS_LOCAL
    NODE_LOCA
    NO_PREF
    RACK_LOCAL

    ANY

• 10、conf saprk.network.timeout=600s

  • spark网络连接超时的时间，一般默认设置120s

数据倾斜优化

• 产生的原因

  • 1、key分布不均
  • 2、产生shuffle
  • 3、如果没有shuffle产生倾斜，hdfs中的文件大小不一致

• 1、使用Hive ETL预处理数据

  使用hive预处理数据，将shuffle提前到hive中
  hive底层是mr
  mr比spark稳定，spark出现数据倾斜任务容易失败
  mr出现数据倾斜，可以跑出结果

• 2、过滤少数导致倾斜的key

  过滤掉少量导致数据倾斜的key，前提是key对业务逻辑
  没有影响，比如null

• 3、提高shuffle操作的并行度

  增加分区的数量，可以减少每个分区中的数据量
  可以一定程度缓解数据倾斜
  对于单key导致的数据倾斜没办法解决

• 4、双重聚合

  • 1、加前缀进行第一次聚合
  • 2、去掉前缀进行第二次聚合

• 5、map join

  • 限制：只适合大表和小表关联，将小表广播

• 6、采样倾斜的key并拆分join

  • 使用大表和表的join