作者: pany
2019/3/3 10:14:45
参考:Kafka 权威指南(Kafka :The Definitive Guide)
注:Kafka已经在大型系统中无处不在了,足可见它的优越性,我花了整整一周多的时间读了这本书,草稿纸用了一堆,但是很多细节的东西没记住,可见想了解它还是很有难度的,于是决定总结一下,基于原文内容进行整理,争取有更多的突破。如果网上找不到这本书的资源,可以联系我,免费分享。微信:py1149050048
@all 转载请注明出处
本文主要讲解Kafka的诞生背景和解决了什么问题,主要章节如下:
1、数据的重要性
2、什么是Kafka
3、LinkedIn的问题
4、Kafka的诞生
5、Kafka命名
6、Kafka的创始人解释Kafka前世今生
7、Kafka的时间轴
(注: 部分内容摘录自原文 )
一、数据的重要性(插入章节,与本文主线关系不大)
其实这个与介绍Kafka并无多大关系,我之所以加上,是因为我想让大家树立这个意识————数据是当今社会重中之重的东西。打个小小的比方:我们村的(我家乡是安徽池州的)小商店为什么只能那么小,为什么他的东西卖不了给北上广的用户,甚至于隔壁村的居民都不一定买过,这是为什么呢?距离?不见得吧,这样的社会距离还是问题吗?成本呢?有可能,但是并不一定是决定性因素。真正阻止他发财的是他没有这些人的信息,连他们叫什么,电话是多少,住哪里,爱好是什么都不知道,他怎么去给他售卖自己的商品。而用户的姓名、电话、地址、爱好等这些是什么?当然是数据了。最近忙于结婚的 事情,有去参加婚博会,婚博会上为什么那么多商家给你送小礼品、提供点心让你进店,然后去咨询你的想法,了解你的爱好什么的,为的是什么?当然是了解你的数据了,然后根据你的数据去给你推荐合适的产品,增加成单率啊。
我之前粗略的读过吴军的《智能时代》,上面花了很大章节介绍了数据相关的东西,你们也可以去读一读。任何时代,如果你小看了数据,你终将被时代所 抛弃。
《Kafka权威指南》中有以下两段话:
Neil deGrasse Tyson的:
每一次科学家们发生分歧,都是因为掌握的数据不够充分。所以我们可以先就获取哪一类数据达成一致。只要获取了数据,问题也就迎刃而解了。要么我是对的,要么你是对的,要么我们都是错的。然后继续研究。
Jeff Weiner ,LinkedIn CEO:
数据为我们所做的每一件事提供动力。
数据已经逐渐成为当今世界主流内容了,它为更多的企业发展提供动力。请相信,未来在数据里。
二、什么是Kafka
百度百科: Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息
三、LinkedIn的问题
背景:LinkedIn有一个数据收集系统和应用程序指标,它使用自定义的收集器和一些开源工具来保存和展示内部数据。除了跟踪CPU使用率和应用性能 这些一般性指标外,LInkedIn还有一个比较复杂的用户请求跟踪功能。它使用了监控系统,可以跟踪单个用户的请求是如何在内部应用间传播的。不过 监控系统存在很多不足。它使用的是轮询拉去度量指标的方式,指标之间的时间间隔较长,而且没有自助服务能力。它使用起来很不方便,很多简单的任务需要人工介入才能完成,而且一直性较差,同一个度量指标的名字在不同系统里的叫法不一样。
与此同时,他们还创建了另一个用于收集用户活动信息的系统。这是一个HTTP服务,前端的服务器会定期连接进来,在上面发布一些消息(XML格式)。 这些消息文件被转移到线下进行解析和校对。同样,这个系统也存在很多不足。XML文件的格式无法保持一致,而且解析XML文件非常耗费计算资源。要想更改所创建的活动类型,需要在前端应用和离线处理程序之间做大量的协调工作。即使这样,在更改数据结构时,仍然经常出现系统崩溃现象。而且批处理以小时计算,无法用它完成实时的任务。
监控和用户活动跟踪无法使用同一个后端服务。监控服务太过笨重,数据格式不适用于活动跟踪,而且无法在活动跟踪中使用轮询拉去模型。另一方面,把跟踪服务用在度量指标上也过于脆弱,批处理模式不适用于实时的监控和告警。不过,耗在数据间存在很多共性,信息(比如特定类型的用户活动对 应用程序性能的影响)之间的关联度还是很高的。特定类型用户活动数量的下降说明相关应用程序存在问题,不过批处理的长时间延迟意味着无法对这类 问题作出及时的反馈。
最开始,他们调研了一些现成的开源解决方案,希望找到一个系统,可以实时访问数据,并通过横向扩展处理大量的消息。他们使用ActiveMQ创建一个 原型系统,但是它当时还无法满足横向扩展的需求。LinkedIn不得不使用这种脆弱的解决方案,虽然ActiveMQ很多缺陷会导致broker暂停服务。客户端的连接因此阻塞,处理用户请求的能力也受到影响。于是他们最后决定构建自己的基础设施,也就是Kafka的诞生。
(关键问题: 交互的数据格式、批处理的高延迟、无法横向扩展)
四、 Kafka的诞生
LinkedIn的开发团队是由Jay Kreps领导,他是LinkedIn的首席工程师,之前负责分部署键值存储系统Voldemort的开发。初建团队还包括Neha Narkhede,不就之后,Jun Rao也加入进来。他们一起着手创建一个消息系统,可以同事满足上述的两种需求,并且可以在未来进行横向扩展 。他们的主要目标如下:
* 使用推送和拉取模型解耦生产者和消费者
* 为消息传递系统中的消息提供持久化,方便支持多个消费者
* 通过系统优化实现高吞吐量
* 系统可以随着数据流的增长进行横向扩展
最后我们看到了这个发布与订阅消息系统具有典型的消息系统接口,但从存储层看,它更像一个日志聚合系统。Kafka使用Avro作为消息序列化框架,每天高效地处理数十亿级别的度量指标和用户活动跟踪信息。
注:Kafka很好的解决了之前交互的数据格式、批处理的高延迟、无法横向扩展这些问题,生产者可以将消息序列化,不过此序列化框架官方有推荐,不建议我们自定义序列化框架,这样会影响生产者系统和消费者系统耦合性。消息以字节码传递,效率高,并且从时间和空间两个维度决定一组消息发布,在高吞吐量和实时性之间做了一个很好的权衡。生产者、broker、消费者可以很好的进行扩展。这些后面会有详细的介绍。
五、 Kafka的命名
为什么叫做Kafka?
Jay Kreps解释: 我想既然Kafka是为了写数据而产生的,那么用作家的名字来命名就会显得更有意义。我在大学时期上过很多文学课程,很喜欢Franz Kafka。况且,对开源项目来说,这个名字听起来很酷。因此,名字和应用本身基本没有太多联系。
六、Kafka的创始人解释Kafka前世今生
jay Kreps(Confluent 联合创始人兼CEO) 对Kafka的介绍如下:
1、Kafka 为何而来?
Kafka最初是LinkedIn 公司开发的,是一个内部基础设施系统。虽然有很多数据库和系统可以用来存储,但是在我们架构中,刚好缺少一个可以帮助处理持续数据流的组件。在开发kafka之前,我们实验了各种现成的解决方案,从消息系统到日志聚合系统,再到ETL工具,都无法满足要求。于是有了Kafka。
2、Kafka 的使用场景?
初期: Kafka 一开始使用在社交网络的实时应用和数据流中
现阶段: Kafka成为下一代数据架构的基础,大型零售商、汽车公司以及银行等重新思考基于Kafka去改造他们的基础流程和系统
3、Kafka 充当了什么角色?它和现有的系统有什么区别?
初衷:我们认为Kafka是一个流平台,在这个平台上可以发布和订阅数据流,并且把他们保存起来、进行处理以这种方式看待数据确实和人们习惯的想法有所不同,但是它确实在构建应用和架构方面表现出了强大的抽象能力,Kafka经常会被拿来与现在的技术比较 :企业消息系统,Hadoop等大数据系统,ETL工具等。这里的每一项比较都是有一定道理的,但是也有失偏颇。
4、Kafka对比消息系统
订阅和发布消息流这种模式类似于消息系统,类似于ActiveMQ、RabbitMQ或者MQSeries等。尽管看上去很相似,但是kafka与这些传统的消息系统仍然存在很多重要的不同点,这些差异让它完全不同于消息系统。
* Kafka作为一个现代的分布式系统,它是以集群方式运行,可以自由伸缩,处理公司的所有应用程序
* Kafka集群并不是一组独立运行的broker,而是一个可以灵活伸缩的中心平台(这里后面会有介绍,基于整个系统的扩张,我们的broker、消费者 、生产者等都可以进行伸缩)
* Kafka按照你的要求存储数据,多久都可以
* Kafka作为数据连接层,提供了数据传递保证————可复制、持久化,保留多长时间完全可以由你自己来决定
* Kafka的流式处理将数据处理提升到了新高度。而消息系统只会传递消息,而kafka的流式处理能力让你只需要很少的代码就能动态的派生流和数据集
由此可以看出kafka不是一个消息队列这么简单了。
5、Kafka对比Hadoop
从另一个角度看,把Kafka看成实时版的Hadoop————这也是我们设计和构建Kafka的原始动机,Hadoop可以存储和定期处理大量的数据文件,而Kafka可以存储和持续处理大型的数据流。从技术角度看,他们有着惊人的相似之处,很多人将新兴的流式处理看成是批量处理的超集。它们之间最大的不同体现在持续的低延迟处理和批量处理之间的差异上。Hadoop和大数据主要应用在数据分析上,而Kafka因为低延迟的特点更适合应用在核心的业务应用上。业务事件时刻发生,Kafka能够及时对这些事件作出响应,基于Kafka构建的服务直接为业务运营提供支撑,提升用户体验。
6、Kafka对比ETL工具
Kafka和这些工具都擅长移动数据,但是我想他们最大的不同在于Kafka颠覆了传统的思维。Kafka并非只是把数据从一个系统拆解出来再传输到另一个系统,它其实是面向实时数据流的平台,也就是说,它不仅可以将现有的应用程序和数据系统连接起来,它还能用于加强这些出发相同数据流的应用。我们任务这种以数据流为中心的架构是非常重要的。在某种程度上来说,这些数据流和现代数字科技公司的核心,与他们的现金一样重要。
根据jay Kreps的介绍我们就可以看出Kafka不只是一个简单的消息队列、中间件这么简单了,除了解耦应用以外,他的一些优越特性(高吞吐量、低延迟、流式处理、扩展伸缩性、数据持久化、分布式等)远远不只是定位消息系统,未来它将会用在更多的场景。
注:jay Kreps对《Kafka权威指南》的评价,这本书对于学习Kafka再好不过了,从内部架构到API,都是由对Kafka最了解的人亲手呈现的,我希望你们能够像我一样喜欢这本书。
我个人的一个想法:学习一门技术选择去读一本专业的书十分重要,如果随便弄个资料读读,那你只不过学到了一堆BUG。
七、 Kafka时间轴
2010 作为开源项目在Github上发布,Kafka的诞生
2011.7 Kafka成为Apache软件基金会的孵化器项目,0.7.0版本
2012.8 Kafka从孵化器项目毕业,0.8.0版本
2014秋天 Jay Kreps成立Confluent公司,发布了0.8.2和0.9.0版本
2016.4 0.10.0版本
2017.8 0.11.0版本