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