1)Kafka的消费语义分析

    Flume-->Kafka-->Spark streaming

        Flume: 

             source: CDH NN LOG / xxx.log

             sink: kafka

    At most once:  最多一次,消息可能丢失,但是不会重复投递

    At least once:  至少一次,消息不会丢失 ack=all ,但是可能重复投递(0.10 生产使用)

    Exactly once:  正好一次,消息不会丢失,也不会重复 (这才是我们真正想要的)

        0.10.0.1和之前的版本 Exactly once不能实现,0.11 官方说已支持

        *****但是生产不会使用(0.11),稳定性不好说

                Q:幂等是什么概念??

幂等的,那可以认为系统是正好一次的处理

    Producer:

        发送消息,有个commit的概念,如果commit成功,那意味着消息不会丢失;

                                                       如果commit不成功,那意味着消息会丢失;

    Consumer(Spark):

        消费消息,有个offset,是由consumer自己维护的。consumer能决定offset维护在哪里,比如:zk,kafka,hdfs,hbase等

            4条消息:1, 2, 3, 4

            offset(偏移量):0,1,2,3

        *****offset如果没有及时维护,consumer挂了,那么新的consumer就会从上一次更新的offset去消费 (生产,At least once,重复过来,重新消费)

        如:比如100条数据,处理到50条consumer挂了,那么新的consumer是从0开始重新消费

2)Kafka的分区策略 (面试)

     比如1个topic:0,1,2  三个分区        key hash%

    代码:

        kafka.producer.DefaultPartitioner.scala    (0.10版本后过时)

        org.apache.kafka.clients.producer.internals.DefaultPartitioner.scala (代替的类)

        

kafka副本数多少合适_hdfs

5.

Flume-->Kafka-->Spark streaming  经典架构
Flume:
[root@yws76 conf]# cat exec_memory_kafka.properties
# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1


# Describe/configure the custom exec source
a1.sources.r1.type = com.onlinelog.analysis.ExecSource_JSON
a1.sources.r1.command = tail -F /var/log/hadoop-hdfs/hadoop-cmf-hdfs-NAMENODE-yws76.log.out
a1.sources.r1.hostname = yws76
a1.sources.r1.servicename = namenode




# Describe the sink
a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
a1.sinks.k1.kafka.topic = onlinelogs
a1.sinks.k1.kafka.bootstrap.servers = 192.168.0.85:9092,192.168.0.86:9092,192.168.0.87:9092
a1.sinks.k1.kafka.flumeBatchSize = 6000
a1.sinks.k1.kafka.producer.acks = 1
a1.sinks.k1.kafka.producer.linger.ms = 1
a1.sinks.ki.kafka.producer.compression.type = snappy


# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.keep-alive = 90
a1.channels.c1.capacity = 2000000
a1.channels.c1.transactionCapacity = 6000


# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1




****************
官方exec
# Describe/configure the custom exec source
a1.sources.r1.type = exec
a1.sources.r1.command = tail -F /var/log/hadoop-hdfs/hadoop-cmf-hdfs-NAMENODE-yws76.log.out




Receiver 与 Direct 区别、优缺点、版本(面试题)


每个批次的最大消息量的参数及公式:
2500:
1 * 2 * 1250
1: topic的partition个数
2: spark streaming代码中batch时间
1250: spark.streaming.kafka.maxRatePerPartition=1250


3750=1 * 3 * 1250


1s:10000条拿到然后及时处理,不延迟
8*1*1250


场景:
还剩7500条:


1. 生产常用的,kafka没有堆积的(正常业务,数据是比较正常过来)
设置最大消息量,慢慢消费
spark.streaming.backpressure.enabled=true


7500不是两个批次直接消费完,慢慢的消费




2.Kafka堆积1亿条(人为),每个批次去满满消费  (特殊)
spark.streaming.backpressure.enabled=false
7500是两个批次直接消费完




spark.streaming.stopGracefullyOnShutdown false 
断批还原


如果改为true,接受kill的命令,等待下一次批次处理完,比较优雅






6.断批还原--》offset如何管理 
1.Checkpoint HDFS 
   小文件 ,丢数据


2.Kafka 自身
   enable.auto.commit: true 时间间隔5s 
  
   enable.auto.commit: false (官方)+ 在业务处理后,手工官方API异步提交offset  (生产)
    
   提交到kafka的当前topic的内嵌的topic的:_consumer


3.其他存储
  ZK、HBase、Redis