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

简介: Apache Kafka是消息引擎系统,也是一个分布式流处理平台(Distributed Streaming Platform)Kafka是LinkedIn公司内部孵化的项目。LinkedIn最开始有强烈的数据强实时处理方面的需求,其内部的诸多子系统要执行多种类型的数据处理与分析,主要包括业务系统和应用程序性能监控,以及用户行为数据处理等。

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实战
目录
相关文章
|
28天前
|
消息中间件 存储 Kafka
【深入浅出 RocketMQ原理及实战】「底层源码挖掘系列」透彻剖析贯穿一下RocketMQ和Kafka索引设计原理和方案
【深入浅出 RocketMQ原理及实战】「底层源码挖掘系列」透彻剖析贯穿一下RocketMQ和Kafka索引设计原理和方案
48 1
|
1月前
|
消息中间件 JSON Kafka
【十九】初学Kafka并实战整合SpringCloudStream进行使用
【十九】初学Kafka并实战整合SpringCloudStream进行使用
27 1
【十九】初学Kafka并实战整合SpringCloudStream进行使用
|
3月前
|
消息中间件 存储 Kafka
KafKa C++实战
KafKa C++实战
148 0
|
3月前
|
消息中间件 分布式计算 监控
腾讯技术官手撸笔记,全新演绎“Kafka部署实战”,已开源
我们知道,当下流行的MQ非常多,不过很多公司在技术选型上还是选择使用Kafka。与其他主流MQ进行对比,我们会发现Kafka最大的优点就是吞吐量高。实际上Kafka是高吞吐低延迟的高并发、高性能的消息中间件,配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。
|
4月前
|
消息中间件 网络协议 Kafka
docker安装zk和kafka实战笔记
docker安装zk和kafka实战笔记
docker安装zk和kafka实战笔记
|
4月前
|
消息中间件 分布式计算 大数据
【大数据技术】Spark+Flume+Kafka实现商品实时交易数据统计分析实战(附源码)
【大数据技术】Spark+Flume+Kafka实现商品实时交易数据统计分析实战(附源码)
75 0
|
5月前
|
消息中间件 关系型数据库 MySQL
FlinkSQL 实时采集Kafka内容到MySQL(实战记录)
FlinkSQL 实时采集Kafka内容到MySQL(实战记录)
55 0
|
6月前
|
消息中间件 JSON 关系型数据库
[实战系列]SelectDB Cloud Kafka Connect 最佳实践张家锋
[实战系列]SelectDB Cloud Kafka Connect 最佳实践张家锋
94 1
|
8月前
|
消息中间件 存储 算法
kafka基本原理以及快速实战
kafka基本原理以及快速实战
51 0
|
9月前
|
消息中间件 Java Kafka
Flink的sink实战之二:kafka
实践如何将flink数据集sink到kafka
123 0
Flink的sink实战之二:kafka

热门文章

最新文章