为了账号安全,请及时绑定邮箱和手机立即绑定

Kafka实战(三) -Kafka的自我修养

标签:
Java

Apache Kafka是消息引擎系统,也是一个分布式流处理平台(Distributed Streaming Platform)

Kafka是LinkedIn公司内部孵化的项目。LinkedIn最开始有强烈的数据强实时处理方面的需求,其内部的诸多子系统要执行多种类型的数据处理与分析,主要包括业务系统和应用程序性能监控,以及用户行为数据处理等。

遇到的主要问题:

  • 数据正确性不足
    数据的收集主要采用轮询(Polling),确定轮询间隔时间就成了高度经验化的难题。虽然可以采用一些启发式算法(Heuristic)来帮助评估,但一旦指定不当,还是会造成较大的数据偏差。

  • 系统高度定制化,维护成本高
    各子系统都需要对接数据收集模块,引入了大量的定制开销和人工成本

LinkedIn工程师尝试过使用ActiveMQ解决这些问题,但并不理想
显然需要有一个“大一统”的系统来取代现有的工作方式,而这个系统就是Kafka。

Kafka自诞生伊始是以消息引擎系统的面目出现在大众视野中的
如果翻看0.10.0.0之前的官网说明

Kafka社区将其清晰地定位为一个分布式、分区化且带备份功能的日志提交(Commit Log)服务。

Kafka作者之一Jay Kreps曾经谈及过命名的原因。
因为Kafka系统的写性能很强,所以找了个作家的名字来命名似乎是一个好主意。大学期间我上了很多文学课,非常喜欢Franz Kafka这个作家,另外为开源软件起这个名字听上去很酷。

Kafka旨在提供三个方面的特性:

  • 提供一套API实现生产者和消费者

  • 降低网络传输和磁盘存储开销

  • 实现高伸缩性架构。

随着Kafka的不断完善,Jay等大神们终于意识到将其开源惠及更多的人是一个非常棒的主意,因此在2011年Kafka正式进入到Apache基金会孵化并于次年10月顺利毕业成为Apache顶级项目。

特别在大数据领域,Kafka在承接上下游、串联数据流管道方面发挥了重要的作用:
所有的数据几乎都要从一个系统流入Kafka然后再流向下游的另一个系统中
这引发了Kafka社区的思考:与其我把数据从一个系统传递到下一个系统中做处理,何不自己实现一套流处理框架?
Kafka社区于0.10.0.0版本正式推出了流处理组件Kafka Streams,也正是从这个版本开始,Kafka正式“变身”为分布式的流处理平台,而不仅仅是消息引擎系统了
今天Apache Kafka是和Storm/Spark/Flink同等级的实时流处理平台。

国内对Kafka是流处理平台的认知还尚不普及,其核心的流处理组件Kafka Streams更是少有大厂在使用
随着在Kafka峰会上各路大神们的鼎力宣传,如今利用Kafka构建流处理平台的案例层出不穷,而了解并有意愿使用Kafka Streams的厂商也是越来越多

优势

更易实现端到端的正确性(Correctness)

Google大神Tyler曾经说过,流处理要最终替代它的“兄弟”批处理需要具备两点核心优势

  • 实现正确性

  • 提供能够推导时间的工具

实现正确性是流处理能够匹敌批处理的基石
正确性一直是批处理的强项,而实现正确性的基石则是要求框架能提供精确一次处理语义,即处理一条消息有且只有一次机会能够影响系统状态
目前主流的大数据流处理框架都宣称实现了精确一次处理语义,但这是有限定条件的,即它们只能实现框架内的精确一次处理语义,无法实现端到端
因为当这些框架与外部消息引擎系统结合时,无法影响到外部系统的处理语义,所以Spark/Flink从Kafka读取消息之后进行有状态的数据计算,最后再写回Kafka,只能保证在Spark/Flink内部,这条消息对于状态的影响只有一次
但是计算结果有可能多次写入到Kafka,因为它们不能控制Kafka的语义处理
相反地,Kafka则不是这样,因为所有的数据流转和计算都在Kafka内部完成,故Kafka可以实现端到端的精确一次处理语义

举个例子,使用Kafka计算某网页的PV——我们将每次网页访问都作为一个消息发送的Kafka
PV的计算就是我们统计Kafka总共接收了多少条这样的消息即可
精确一次处理语义表示每次网页访问都会产生且只会产生一条消息,否则有可能产生多条消息或压根不产生消息。

流式计算的定位

官网上明确Kafka Streams是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统
不能期望着Kafka提供类似于集群调度、弹性部署等开箱即用的运维特性,需要自己选择适合的工具或系统来帮助Kafka流处理应用实现这些功能。
这的确是一个“双刃剑”的设计,也是Kafka社区“剑走偏锋”不正面PK其他流计算框架的特意考量
大型公司的流处理平台一定是大规模部署的,因此具备集群调度功能以及灵活的部署方案是不可或缺的要素
但毕竟这世界上还存在着很多中小企业,它们的流处理数据量并不巨大,逻辑也并不复杂,部署几台或十几台机器足以应付。在这样的需求之下,搭建重量级的完整性平台实在是“杀鸡焉用牛刀”,而这正是Kafka流处理组件的用武之地
因此从这个角度来说,未来在流处理框架中,Kafka应该是有一席之地的。

Kafka能够被用作分布式存储系统
Kafka作者之一Jay Kreps曾经专门写过一篇文章阐述为什么能把Kafka用作分布式存储。不过我觉得你姑且了解下就好了,我从没有见过在实际生产环境中,有人把Kafka当作持久化存储来用 。

参考

  • Apache Kafka实战


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
1.4万
获赞与收藏
1461

关注作者,订阅最新文章

阅读免费教程

  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消