大数据秋招面经之kafka,sparkstreaming系列

---

前言

kafka,sparkstreaming作为实时流数据处理的常用组件，在大数据面试中也是高频考点，秋招的同学可以找一个涉及kafka和spark相关的项目，结合项目来加深对kafka，spark实时处理数据的理解。

---

1.kafka的架构

从这几个方面来谈：
生产者producer，消费者consumer，主题或者叫队列topic，消费者组consumer group，节点broker，分区partition ，消息偏移量offset。
kafka是一个分布式消息队列，kafka对消息保存时根据topic进行归类,发送者是producer，消费者是consumer，kafka集群有多个kafka实例，每个实例叫broker。producer，consumer都可理解为是broker的客户端。

• 消费者组：kafka提供可扩展且具有容错机制的消费者机制，组内有多个消费者，它们有一个共同的id，组内所有消费者协调在一起订阅主题的所有分区，每个分区只能由消费者组内的一个消费者来消费。
• broker:一个kafka服务器就是一个broker。一个集群由多个broker组成，一个broker可以容纳多个topic。
• partition:一个topic内有多个partition，每个partition都是一个有序队列，partition内的每条消息都会有一个有序的id，即为offset，kafka只能保证一个partition内的消息有序的发给一个消费者。
• offset:消息在partition内的偏移量，方便定位消息的位置。

2.kafka的特点或者作用

• 解耦：允许你独立的扩展或者修改两边的处理过程，只要确保它们遵守同样的接口约束
• 异步：允许用户不立刻处理队列中的数据，在需要的适合处理它们。
• 缓冲：控制和优化数据流经过系统的速度，解决生产者和消费者消息处理速度不一致的问题。
• 削峰，限流：使用消息队列可使关键组件顶住突发压力，降低处理数据峰值。
• 容错机制：通过topic内有多个分区，分布在不同的broker上实现。
• 可扩展性：分布式系统都具备可扩展能力，因为消息队列解耦了处理过程，所以增大消息入队和处理频率是很容易的。
• 可恢复性：系统中一部分组件挂掉，不会影响整个系统。消息队列降低了进程间耦合程度，，即使一个处理消息的进程挂了，加入队列的消息依然可以在系统恢复后被处理。
• 分区内顺序保证：一个partition内数据有序。

3.kafka中消费者组是怎么回事？消费者组可不可以订阅多个分区？为什么有消费者组，作用是啥？

传统的消息系统有两种消息模型：点对点模型，发布/订阅模型。传统的消息队列模型的缺陷在于消息一旦被消费，就会从队列中删除，且只能被下游的一个消费者消费，这种模型伸缩性差，因为下游的多个消费者要抢队列中的消息。

发布/订阅模型：允许消息被多个consumer消费，订阅者必须订阅所有主题的所有分区，伸缩性差。而消费者组的引入解决了上述两种模式下伸缩性差的问题，当消费者组订阅了多个主题后，组内的实例不要求订阅主题的所有分区，它只会消费部分分区的消息，而消费者组之间互不影响，完美解决伸缩性差的问题。

消费者组机制同时实现了点对点模型和发布/订阅模型，如果所有实例属于一个消费者组，就是消息队列模型，如果所有消费者属于不同的消费者组，且订阅了相同主题，就是发布/订阅模型。

4.sparkstreaming直连kafka的两种方式（这题面试都问烂了）

1. receiver模式：worker中的Executor里会启动线程去接收数据，每隔一段时间去接收数据(如200毫秒)，receiver把接收到的数据封装成一个个block，然后把这些block数据写入该executor的内存中。receiver把接收到的数据块block信息通知给driver，driver端会根据一定的时间间隔(如2秒)，把这些block块组织成一个RDD,然后对这些RDD进行处理。每一个block块就是RDD中一个partition,一个partition对应一个task任务。worker端的executor内会另启线程去处理数据。使用kafka的高级api。
   receiver模式最大的弊端：接