Apache 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）。