Spark Streaming揭秘 Day32
Kafka原理内幕
今天开始，会有几天的时间，和大家研究下Kafka。在大数据处理体系中，kafka的重要性不亚于SparkStreaming。可以认为sparkstreaming掌控处理，而kafka掌控流程控制。
让我们来了解下sparkstreaming和kafka的整合细节。
三大特征
消息组件一般有两种类型：
-
队列方式，可能有一个循环器不断循环一个对象(消息队列)，当消息A进入中队列中，被唤醒感知到队列时，交给处理者handler来处理。只可以给一个消费者。
-
生产者-消费者模式，也称为发布-订阅模式，可以同时支持多个消费者和多个生产者，
Kafka作为一个集大成者的消息中间件，有三个很重要的特征：
- 分布式，为大规模消息打下基础
- 可以对消息进行持久化，默认会存放7天，意味可以重复消费
- 既支持队列方式，也支持发布-订阅模式
由于基于集群设计，又提供了非常强的持久化和容错能力。我们可以认为它是类似一个增加了消息处理能力的HDFS。
四项重要设计
Kafka设计哲学上基本观点是认为数据时时刻刻都在流动，虽然数据在磁盘中，但因为基于内核进行交换，获得了数据近乎是存储在内存中的速度。没有必要放在用户空间中。
四个重要设计：
- kafka的零拷贝(zero copy)
一般应用程序有一个buffer空间在用户空间中，来自于网络或者磁盘，无论来自网络或者磁盘，都需要通过内核，也就是说内核中也要有buffer。
1)磁盘到内核 --> 2)内核到应用程序buffer 写数据时 --> 3)应用程序buffer写到内核buffer --> 4）内核buffer写到磁盘
这个过程多了两次拷贝，kafka本身因为不处理数据，所以没有必要把数据放入应用程序的buffer中。所以搞了个基于内核的数据存储和传输,使用sendfile机制，直接基于内核kernel处理。
-
push和pull的模式
无论有多少producer，都往kafka进行push数据，kafka可以不关心producer的具体位置。consumer是从kafka pull数据，无论有多少消费数据，对kafka基本没有压力。 -
采用zookeeper来管理brokers和consumers
zookeeper主要存放元数据信息，这是一种积木式创新的体现。 -
在consumer端实现消息的一致性
kafka本身可以保存consumer已经消费过数据的offset，所以如果consumer出错的化，重启启动consumer，就可以从最近的数据开始。
基本流程
kafka从整体角度讲，所有数据存储被抽象为topic，topic表明了不同数据类型，在broker中可以有很多个topic，producer发出消息给broker，consumer订阅一个或者多个topic，从broker拿数据。从broker拿数据和存数据都需要编码和解码，只有数据特殊时，才需要自己的解码器。
consumer订阅了topic之后，它可以有很多的分组，sparkStreaming采用迭代器进行处理。生产者发布消息时，会具体到topic的分区中，broker会在分区的后面追加，所以就有时间的概念，当发布的消息达成一定阀值后写入磁盘，写完后消费者就可以收到这个消息了。
最后，想说，在中kafka里没有消息的id，只有offset，而且kafka本身是无状态的，offset只对consumer有意义。
小结
Kafka是实时的，又是离线的，采用磁盘存储系统存储消息，可以满足对消息处理系统的一切期望。
由于kafka的存在，可以整合在不同地域的异构系统，把一切都整合起来，打破了机器和系统之间空间的差异，通过Kafka可以打破了异构系统的物理空间分布的区别。"无为而无不为"是Kafka的设计哲学，与大家共勉。
欲知后事如何，且听下回分解!
DT大数据每天晚上20：00YY频道现场授课频道68917580