Apache Kafka 1.0:为什么我们等了这么久?

2017 年 11 月 3 日 InfoQ 王国璋
作者丨王国璋
编辑丨 Natalie&Vincent
Kafka 迎来 1.0.0 版本,正式告别四位数版本号!

Kafka 从首次发布之日起,已经走过了七个年头。从最开始的大规模消息系统,发展成为功能完善的分布式流式处理平台,用于发布和订阅、存储及实时地处理大规模流数据。来自世界各地的数千家公司在使用 Kafka,包括三分之一的 500 强公司。

Kafka 以稳健的步伐向前迈进,首先加入了复制功能和无边界的键值数据存储,接着推出了用于集成外部存储系统的 Connect API,后又推出了为实时应用和事件驱动应用提供原生流式处理能力的 Streams API,并于今年春季开始支持仅一次处理语义。如此广泛的应用和完备的功能以及如此悠久的历史,无一不在说明 Kafka 已经成为一款稳定的企业级产品。而更为激动人心的是,Kafka 现在正式迎来了 1.0.0 版本!

Kafka 1.0.0 发布的主要内容如下:
  • 0.10.0 版本里开始引入的 Streams API 在 1.0.0 版本里继续演进,改进了 builder API(KIP-120),新增了用于查看运行时活跃任务的 API(KIP-130)和用于聚合分区的 cogroup API(KIP-150)。增强的 print() 和 writeAsText() 方法让调试变得更容易(KIP-160)。其他更多信息可以参考 Streams 文档。

  • 改进了 Connect 的度量指标(KIP-196),新增了大量用于健康监测的度量指标(KIP-188),并提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指标(KIP-168)。

  • 支持 Java 9,实现更快的 TLS 和 CRC32C,加快了加密速度,降低了计算开销。

  • 调整了 SASL 认证模块的错误处理逻辑(KIP-152),原先的认证错误信息现在被清晰地记录到日志当中。

  • 更好地支持磁盘容错(KIP-112),更优雅地处理磁盘错误,单个 JBOD 上的磁盘错误不会导致整个集群崩溃。

  • 0.11.0 版本中引入的幂等性生产者需要将 max.in.flight.requests.per.connection 参数设置为 1,这对吞吐量造成了一定的限制。而在 1.0.0 版本里,这个参数最大可以被设置为 5(KAFKA-5949),极大提升了吞吐量范围。

关于新版本更多的变化可以查看发布说明:

https://dist.apache.org/repos/dist/release/kafka/1.0.0/RELEASE_NOTES.html

下载源代码:

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka-1.0.0-src.tgz

二进制包

Scala 2.11:

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.11-1.0.0.tgz

Scala 2.12:

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.12-1.0.0.tgz

为此,InfoQ 特意联系了 Apache Kafka 项目董事,代码提交者王国璋。对于 Kafka 的 1.0 时代,他有什么想说的?

就在昨天 Apache Kafka 项目的 1.0.0 终于发布了,这标志着 Kafka 正式跨入了 1.0 时代。

之前很多人都问我们,为什么等了这么久啊?赶快推进到 1.0 版啊,我们公司的政策是开源软件必须至少要进入到 1.0 版之后才放心让我们用啊!:)确实,作为一个 2010 年创建,2011 年就加入到 Apache 开源软件基金会(ASF),2012 年就从孵化器(Apache Incubator)毕业的“老项目”,我们却足足用了五年时间,直到 2017 年 11 月 1 日才发布到 1.0 版本,看上去好像真的太久了一点。

这当然不是因为在此之前 Kafka 的系统架构还不够稳定,也不是因为 Kafka 还没有得到足够多的用户支持:事实上,早在我们从 Incubator 毕业并发布 0.8 版本的时候,在当时除了 LinkedIn 之外的很多公司就已经开始广泛使用 Kafka。到了今年 Kafka 1.0.0 发布之前,Kafka 已经在全世界各个领域各大公司,从金融,零售,制造,运营,物流,新闻,运营商,到互联网领域等等(https://kafka.apache.org/powered-by),覆盖超过三分之一的福布斯 500 强公司都在它们的大规模集群中使用着 Kafka。

回想起从 0.8 版本一路走过来的这几年,我也会问我自己,为什么我们等了这么久呢?

2012 年的时候我第一次在 LinkedIn 接触 Kafka 项目,那个时候 Kafka 的版本还是 0.7.2,我们在对外介绍 Kafka 项目的时候,还是以一个“分布式发布订阅消息队列系统”(Distributed Pub-Sub Messaging System)来称呼它。当时 Kafka 在 LinkedIn 的主要用途,就是干一件事情:把在线生成的各种大规模数据,从用户日志到系统指标,以最快的方式传递到后台的处理平台上,也就是各种数据仓库(Data Warehouse)工具和 Hadoop/HDFS。

那时候 Kafka 的设计理念是“虽然我很傻,但是我很快”:字节入,字节出,没有多余的处理操作,处理的数据也都还不是关键业务消息。直到 0.8 版本的发布,我们加入了一个重要的副本功能,有效防止了在各种灾难或错误情况下的丢数据情况,从此 Kafka 才开始在各大公司内部真正进入了实时数据存储处理的核心架构:要知道,丢失一个订货付款消息和丢失一个日志消息的代价,可是差太多了:)

就在那个时候,我们在参加各种 Kafka Meetup 上听取同行分享他们的使用心得,见到了越来越多不同的应用场景:有些公司不仅用 Kafka 来发布队列消息,也用来存储数据库备份文件作异地容灾,有些公司用 Kafka 来更新查询索引,有些公司用 Kafka 来实时处理在线业务,等等等等。Kafka 本身的数据模型定义:一个仅附加的写提前日志(append only WAL log),其使用范围之广,实际上远远超出了我们一开始的预想。于是当时在 Kafka 组成员之间,开始讨论一个问题,那就是如果我们想要将 Kafka 扩展作为一个实时流数据平台(Stream Data Platform),还需要做哪些事情。

记得当时我和组里的技术“大拿”,现在 Confluent 公司的联合创始人饶军聊天,也聊到在下一个阶段,大数据的发展将慢慢从“规模”之大(Volume),转向“速度”之大(Velocity):当我们已经有的足够体量的数据以后,下一个问题就是如何从拿在手上的数据中发现有用的信息,而且是越快越好。如此,传统的批量处理技术,包括数据仓库商务智能等等,就跟不上所要求的速度了。

接下来的时间,Kafka 进入到了高速发展时期:2014 年,我们发布了 0.9 版本,加入了另一个非常重要的安全功能,包括客户端身份验证,操作认证,传输加密等组件,和日志压缩功能(log compaction)进一步为 Kafka 成为实时关键业务数据的平台提升了空间。几乎在同时间,LinkedIn Kafka 组的核心成员创建了 Confluent。2015 年我自己也加入了 Confluent。那一年我们发布了 0.10 版本,加入了时间戳组件支持,并且进一步完善了 Kafka 作为一个实时流数据的核心平台架构的最后两片拼图:Kafka Connect(在 0.9 版本中加入)和 Kafka Streams。

至此,Kafka 可以帮助用户连接内部的各个在线系统与工具,各种实时数据:从最基本的日志流,到数据库采集流,到二次转换数据流,再到后台产生的实时更新数据流,都会通过 Kafka 进行存储,并且可以从系统架构内部的任何一“点”,快速的传输到其他任何一“点”。

而当这些实时数据已经全部整合到一个系统里面以后,实时流处理(stream processing)的使用,才有了用武之地:在此之前,由于数据分散在架构内部的各个角落,使得数据整合成为了流处理的一大前提,也是一大难题。但是在 Kafka 0.9 以及 0.10 以后,我们发现越来越多的用户开始把整合后的流数据作为源(source of truth),而把数据库里面的表列,化为了这个数据源的一个不断更新的实时视图(materialized view)。这个潮流继续催生了事件回溯(event sourcing),微服务(micro-services)等等基于实时流数据的系统框架和设计理念,使得流处理逐渐成为了新的主流。

而在这个新的主流下,Kafka 0.11 发布,我们加入了流处理的完全一次语义(exactly-once)支持,使得流处理的可靠性保证在用户面前简单到一个调参。在这个时候,回首看从 0.7.2 一路走过来的这些年,Kafka 社区的愿景才逐步清晰,那就是一个集成的,让用户可以简单有效的写入,读取,并处理流数据的平台。在这个愿景的完成度达到一个里程碑的时候,我们才决定在今天发布 1.0 版本。

很荣幸从 0.7.2 版本就开始参与 Kafka 的开发,那也是我自己第一次参与开源项目的贡献,期间学到了很多东西,但是更重要的就是在社区里面结识到的人。到今天 1.0.0 终于发布,还是感触良多。很多人说现如今 infrastructure software stack 潮起潮落,总是一浪更比一浪强,我倒是觉得对于这浪潮之中单独一个软件项目本身,尤其是一个开源项目而言,能够提出一个普适问题并给出一个简单优雅的解决方案,往往需要很长时间的琢磨。

关于 1.0.0 版本的新特性,我也不再赘述,欢迎大家阅读相关的发布公告。

https://www.confluent.io/blog/apache-kafka-goes-1-0/

https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces21


今年的 ArchSummit 2017 北京站,除了 Kafka 内容之外,还将带来大数据技术的专题分享。届时,Twitter、Facebook、FreeWheel、百度和美团等企业技术专家将分享流处理、数据查询、数据分析等一手内容。

识别下图二维码,了解更多详情!

作者介绍

王国璋,Apache Kafka 项目董事,代码提交者。现就职于 Confluent,任 Kafka Streams 系统架构师和技术负责人。此前曾就职于 LinkedIn 数据架构组任高级工程师,主要负责实时数据处理平台,包括 Apache Kafka 和 Apache Samza 系统的开发与维护。再此前于 2013 在美国康奈尔大学计算机系取得博士学位,主要研究方向为数据库管理和分布式数据系统。

今日荐文

点击下方图片即可阅读

Apache Kafka:大数据的实时处理时代


极客时间 App 已在苹果商店上线,点击 阅读原文 即刻下载!

安卓版正在吐血研发中,敬请期待!


登录查看更多
0

相关内容

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消费。
【2020新书】从Excel中学习数据挖掘,223页pdf
专知会员服务
90+阅读 · 2020年6月28日
【实用书】Python爬虫Web抓取数据,第二版,306页pdf
专知会员服务
117+阅读 · 2020年5月10日
斯坦福2020硬课《分布式算法与优化》
专知会员服务
118+阅读 · 2020年5月6日
【2020新书】Kafka实战:Kafka in Action,209页pdf
专知会员服务
67+阅读 · 2020年3月9日
【干货】大数据入门指南:Hadoop、Hive、Spark、 Storm等
专知会员服务
95+阅读 · 2019年12月4日
【推荐系统/计算广告/机器学习/CTR预估资料汇总】
专知会员服务
87+阅读 · 2019年10月21日
社区分享 | Spark 玩转 TensorFlow 2.0
TensorFlow
15+阅读 · 2020年3月18日
在K8S上运行Kafka合适吗?会遇到哪些陷阱?
DBAplus社群
9+阅读 · 2019年9月4日
携程用ClickHouse轻松玩转每天十亿级数据更新
DBAplus社群
11+阅读 · 2019年8月6日
浅谈 Kubernetes 在生产环境中的架构
DevOps时代
11+阅读 · 2019年5月8日
OLAP引擎这么多,为什么苏宁选择用Druid?
51CTO博客
12+阅读 · 2018年12月20日
Flink 靠什么征服饿了么工程师?
阿里技术
6+阅读 · 2018年8月13日
为什么分布式一定要有消息队列?
互联网架构师
4+阅读 · 2018年7月5日
Python 杠上 Java、C/C++,赢面有几成?
CSDN
6+阅读 · 2018年4月12日
【AI说】揭秘京东实时数据仓库背后的神秘力量—JDQ
Factor Graph Attention
Arxiv
6+阅读 · 2019年4月11日
Arxiv
8+阅读 · 2018年1月12日
Arxiv
6+阅读 · 2018年1月11日
VIP会员
相关资讯
社区分享 | Spark 玩转 TensorFlow 2.0
TensorFlow
15+阅读 · 2020年3月18日
在K8S上运行Kafka合适吗?会遇到哪些陷阱?
DBAplus社群
9+阅读 · 2019年9月4日
携程用ClickHouse轻松玩转每天十亿级数据更新
DBAplus社群
11+阅读 · 2019年8月6日
浅谈 Kubernetes 在生产环境中的架构
DevOps时代
11+阅读 · 2019年5月8日
OLAP引擎这么多,为什么苏宁选择用Druid?
51CTO博客
12+阅读 · 2018年12月20日
Flink 靠什么征服饿了么工程师?
阿里技术
6+阅读 · 2018年8月13日
为什么分布式一定要有消息队列?
互联网架构师
4+阅读 · 2018年7月5日
Python 杠上 Java、C/C++,赢面有几成?
CSDN
6+阅读 · 2018年4月12日
【AI说】揭秘京东实时数据仓库背后的神秘力量—JDQ
Top
微信扫码咨询专知VIP会员