（一）sparkstreaming的两种数据接收方式

Receiver based Approach
基于receiver的方式是使用kafka消费者高阶API实现的。对于所有的receiver，它通过kafka接收的数据会被存储于spark的executors上，底层是写入BlockManager中，默认200ms生成一个block（通过配置参数spark.streaming.blockInterval决定）。然后由spark streaming提交的job构建BlockRdd，最终以spark core任务的形式运行。关于receiver方式，有以下几点需要注意：

  receiver作为一个常驻线程调度到executor上运行，占用一个cpu

receiver个数由KafkaUtils.createStream调用次数决定，一次一个receiver

kafka中的topic分区并不能关联产生在spark streaming中的rdd分区。增加在KafkaUtils.createStream()中的指定的topic分区数，仅仅增加了单个receiver消费的topic的线程数，它不会增加处理数据中的并行的spark的数量【topicMap[topic,num_threads]map的value对应的数值是每个topic对应的消费线程数】

receiver默认200ms生成一个block，建议根据数据量大小调整block生成周期

receiver接收的数据会放入到BlockManager，每个executor都会有一个BlockManager实例，由于数据本地性，那些存在receiver的executor会被调度执行更多的task，就会导致某些executor比较空闲

建议通过参数spark.locality.wait调整数据本地性。该参数设置的不合理，比如设置为10而任务2s就处理结束，就会导致越来越多的任务调度到数据存在的executor上执行，导致任务执行缓慢甚至失败（要和数据倾斜区分开）

多个kafka输入的DStreams可以使用不同的groups、topics创建，使用多个receivers接收处理数据

两种receiver

       可靠的receiver：可靠的receiver在接收到数据并通过复制机制存储在spark中时准确的向可靠的数据源发送ack确认

        不可靠的receiver：不可靠的receiver不会向数据源发送数据已接收确认。这适用于用于不支持ack的数据源当然，我们也可以自定义receiver。

receiver处理数据可靠性默认情况下，receiver是可能丢失数据的
可以通过设置spark.streaming.receiver.writeAheadLog.enable为true开启预写日志机制，将数据先写入一个可靠地分布式文件系统如hdfs，确保数据不丢失，但会失去一定性能

限制消费者消费的最大速率
涉及三个参数：

spark.streaming.backpressure.enabled：默认是false，设置为true，就开启了背压机制

spark.streaming.backpressure.initialRate：默认没设置初始消费速率，第一次启动时每个receiver接收数据的最大值

spark.streaming.receiver.maxRate：默认值没设置，每个receiver接收数据的最大速率（每秒记录数）。每个流每秒最多将消费此数量的记录，将此配置设置为0或负数将不会对最大速率进行限制

在产生job时，会将当前job有效范围内的所有block组成一个BlockRDD，一个block对应一个分区

kafka082版本消费者高阶API中，有分组的概念，建议使消费者组内的线程数（消费者个数）和kafka分区数保持一致。如果多于分区数，会有部分消费者处于空闲状态

public class SparkStreamingOnKafkaReceiver {
 
    public static void main(String[] args) {
/*      第一步：配置SparkConf：
        1，至少两条线程因为Spark Streaming应用程序在运行的时候至少有一条线程用于
        不断地循环接受程序，并且至少有一条线程用于处理接受的数据（否则的话有线程用于处理数据，随着时间的推移内存和磁盘都会
        不堪重负）
        2，对于集群而言，每个Executor一般肯定不止一个线程，那对于处理SparkStreaming
        应用程序而言，每个Executor一般分配多少Core比较合适？根据我们过去的经验，5个左右的Core是最佳的（一个段子分配为奇数个Core表现最佳，例如3个，5个，7个Core等）
*/      
        SparkConf conf = new SparkConf().setMaster("local[2]").setAppName("SparStreamingOnKafkaReceiver");
//      SparkConf conf = new //SparkConf().setMaster("spark：//Master:7077").setAppName("        //SparStreamingOnKafkaReceiver");
/*      第二步：创建SparkStreamingContext,
        1，这个是SparkStreaming应用春香所有功能的起始点和程序调度的核心
        SparkStreamingContext的构建可以基于SparkConf参数也可以基于持久化的SparkStreamingContext的内容
//      来恢复过来（典型的场景是Driver崩溃后重新启动，由于SparkStreaming具有连续7*24
    小时不间断运行的特征，所以需要Driver重新启动后继续上一次的状态，此时的状态恢复需要基于曾经的Checkpoint））
    2，在一个Sparkstreaming 应用程序中可以创建若干个SparkStreaming对象，使用下一个SparkStreaming
        之前需要把前面正在运行的SparkStreamingContext对象关闭掉，由此，我们获取一个重大的启发
        我们获得一个重大的启发SparkStreaming也只是SparkCore上的一个应用程序而已，只不过SparkStreaming框架想运行的话需要
*/      spark工程师写业务逻辑
        @SuppressWarnings("resource")
        JavaStreamingContext jsc = new JavaStreamingContext(conf,Durations.seconds(10));
 
/*      第三步：创建SparkStreaming输入数据来源input Stream
        1，数据输入来源可以基于File,HDFS,Flume,Kafka-socket等
        2,在这里我们指定数据来源于网络Socket端口，SparkStreaming连接上该端口并在运行时候一直监听
        该端口的数据（当然该端口服务首先必须存在，并且在后续会根据业务需要不断地数据产生当然对于SparkStreaming
        应用程序的而言，有无数据其处理流程都是一样的）;
        3,如果经常在每个5秒钟没有数据的话不断地启动空的Job其实会造成调度资源的浪费，因为并没有数据发生计算
        所以实际的企业级生成环境的代码在具体提交Job前会判断是否有数据，如果没有的话就不再提交数据
    在本案例中具体参数含义：
        第一个参数是StreamingContext实例，
        第二个参数是zookeeper集群信息（接受Kafka数据的时候会从zookeeper中获取Offset等元数据信息）
        第三个参数是Consumer Group
*/      第四个参数是消费的Topic以及并发读取Topic中Partition的线程数
 
        Map<String,Integer> topicConsumerConcurrency = new HashMap<String,Integer>();
        topicConsumerConcurrency.put("HelloKafakaFromSparkStreaming",1);//这里2个的话是指2个接受的线程
 
        JavaPairReceiverInputDStream<String, String> lines = KafkaUtils.createStream(jsc,
                "Master:2181,Worker1:2181,Worker2:2181",
                "MyFirstConsumerGrou",
                topicConsumerConcurrency);
    /*
     * 第四步：接下来就像对于RDD编程一样，基于DStream进行编程！！！原因是Dstream是RDD产生的模板（或者说类
     * ），在SparkStreaming发生计算前，其实质是把每个Batch的Dstream的操作翻译成RDD的操作
     * 对初始的DTStream进行Transformation级别处理
     * */
        JavaDStream<String> words = lines.flatMap(new FlatMapFunction<Tuple2<String, String>,String>(){ //如果是Scala，由于SAM装换，可以写成val words = lines.flatMap{line => line.split("　＂)}
 
            @Override
            public Iterable<String> call(Tuple2<String,String> tuple) throws Exception {
 
                return Arrays.asList(tuple._2.split(" "));//将其变成Iterable的子类
            }
        });
//      第四步：对初始DStream进行Transformation级别操作
        //在单词拆分的基础上对每个单词进行实例计数为1，也就是word => (word ,1 )
        JavaPairDStream<String,Integer> pairs = words.mapToPair(new PairFunction<String, String, Integer>() {
 
            @Override
            public Tuple2<String, Integer> call(String word) throws Exception {
                return new Tuple2<String, Integer>(word,1);
            }
 
        });
        //对每个单词事例技术为1的基础上对每个单词在文件中出现的总次数
 
         JavaPairDStream<String,Integer> wordsCount = pairs.reduceByKey(new Function2<Integer,Integer,Integer>(){
 
            /**
             * 
             */
            private static final long serialVersionUID = 1L;
 
            @Override
            public Integer call(Integer v1, Integer v2) throws Exception {
                // TODO Auto-generated method stub
                return v1 + v2;
            }
        });
        /*
         * 此处的print并不会直接出发Job的支持，因为现在一切都是在SparkStreaming的框架控制之下的
         * 对于spark而言具体是否触发真正的JOb运行是基于设置的Duration时间间隔的
         * 诸位一定要注意的是Spark Streaming应用程序要想执行具体的Job，对DStream就必须有output Stream操作
         * output Stream有很多类型的函数触发，类print，savaAsTextFile,scaAsHadoopFiles等
         * 其实最为重要的一个方法是foreachRDD,因为SparkStreaming处理的结果一般都会放在Redis,DB
         * DashBoard等上面，foreach主要就是用来完成这些功能的，而且可以自定义具体的数据放在哪里！！！
         * */
         wordsCount.print();
 
//       SparkStreaming 执行引擎也就是Driver开始运行，Driver启动的时候位于一条新线程中的，当然
//       其内部有消息接受应用程序本身或者Executor中的消息
         jsc.start();
         jsc.close();
    }
 
 
}

并行度：
数据接收并行度调优，除了创建更多输入DStream和Receiver以外，还可以考虑调节 block interval。通过参数，spark.streaming.blockInterval，可以设置block interval，默认是 200ms。对于大多数Receiver来说，在将接收到的数据保存到Spark的BlockManager之前，都会将数据切分为一个一个的block。 而每个batch中的block数量，则决定了该batch对应的RDD的partition的数量，以及针对该RDD执行transformation操作时，创建的task的数量。每个batch对应的task数量是大约估计的，即batch interval / block interval。

例如说，batch interval为2s，block interval为200ms，会创建10个task。如果你认为每个batch的task数量太少，即低于每台机器的cpu core数量，那么就说明batch的task数量是不够的，因为所有的cpu资源无法完全被利用起来。要为batch增加block的数量，那么就减小block interval。然而， 推荐的block interval最小值是50ms，如果低于这个数值，那么大量task的启动时间，可能会变成一个性能开销点。

Direct Approach
direct approach是spark streaming不使用receiver集成kafka的方式，一般在企业生产环境中使用较多。相较于receiver，有以下特点：

不使用receiver
a. 不需要创建多个kafka streams并聚合它们

b. 减少不必要的CPU占用

c. 减少了receiver接收数据写入BlockManager，然后运行时再通过blockId、网络传输、磁盘读取等来获取数据的整个过程，提升了效率

d. 无需wal，进一步减少磁盘IO操作

direct方式生的rdd是KafkaRDD，它的分区数与kafka分区数保持一致一样多的rdd分区来消费，更方便我们对并行度进行控制注意：在shuffle或者repartition操作后生成的rdd，这种对应关系会失效

可以手动维护offset，实现exactly once语义

数据本地性问题。在KafkaRDD在compute函数中，使用SimpleConsumer根据指定的topic、分区、offset去读取kafka数据。但在010版本后，又存在假如kafka和spark处于同一集群存在数据本地性的问题

限制消费者消费的最大速率

spark.streaming.kafka.maxRatePerPartition：从每个kafka分区读取数据的最大速率（每秒记录数）。这是针对每个分区进行限速，需要事先知道kafka分区数，来评估系统的吞吐量