序

这是一个激动人心的时刻，成千上万的企业在使用Kafka，三分之一多的世界500强公司也在其中。Kafka是成长最快的开源项目之一，它的生态系统也在蓬勃发展。Kafka正在成为管理和处理流式数据的利器。

Kafka从何而来？我们为什么要开发Kafka? Kafka到底是什么？

Kafka最初是LinkedIn的一个内部基础设施系统。我们发现，虽然有很多数据库和系统可以用来存储数据，但在我们的架构里，刚好缺一个可以帮助处理持续数据流的组件。在开发Kafka之前，我们实验了各种现成的解决方案，从消息系统到日志聚合系统，再到ETL工具，它们都无法满足我们的需求。

最后，我们决定从头开发一个系统。我们不想只是开发一个能够存储数据的系统，比如传统的关系型数据库、键值存储引擎、搜索引擎或缓存系统，我们希望能够把数据看成是持续变化和不断增长的流，并基于这样的想法构建出一个数据系统；事实上，是一个数据架构。

这个想法实现后比我们最初预想的适用性更广。Kafka一开始被用在社交网络的实时应用和数据流当中，而现在已经成为下一代数据架构的基础。大型零售商正在基于持续数据流改造他们的基础业务流程，汽车公司正在从互联网汽车那里收集和处理实时数据流，银行也在重新思考基于Kafka改造他们的基础流程和系统。

那么Kafka在这当中充当了怎样的角色？它与现有的系统有什么区别？

我们认为Kafka是一个流平台：在这个平台上可以发布和订阅数据流，并把它们保存起来、进行处理，这就是构建Kafka的初衷。以这种方式来看待数据确实与人们习惯的想法有所不同，但它确实在构建应用和架构方面表现出了强大的抽象能力。Kafka经常会被拿来与现有的技术作比较：企业级消息系统、大数据系统（如Hadoop）和数据集成或ETL工具。这里的每一项比较都有一定的道理，但也有失偏颇。

Kafka有点像消息系统，允许发布和订阅消息流。从这点来看，它类似于ActiveMQ、RabbitMQ或IBM的MQSeries等产品。尽管看上去有些相似，但Kafka与这些传统的消息系统仍然存在很多重要的不同点，这些差异使它完全不同于消息系统。首先，作为一

个现代的分布式系统，Kafka以集群的方式运行，可以自由伸缩，处理公司的所有应用程序。Kafka集群并不是一组独立运行的broker，而是一个可以灵活伸缩的中心平台，可以处理整个公司所有的数据流。其次，Kafka可以按照你的要求存储数据，保存多久都可以。作为数据连接层，Kafka提供了数据传递保证——可复制、持久化，保留多长时间完全可以由你来决定。最后，流式处理将数据处理的层次提升到了新高度。消息系统只会传递消息，而Kafka的流式处理能力让你只用很少的代码就能够动态地处理派生流和数据集。Kafka的这些独到之处足以让你刮目相看，它不只是“另一个消息队列”。

从另一个角度来看Kafka，我们会把它看成实时版的Hadoop——这也是我们设计和构建Kafka的原始动机之一。Hadoop可以存储和定期处理大量的数据文件，而Kafka可以存储和持续处理大型的数据流。从技术角度来看，它们有着惊人的相似之处，很多人将新兴的流式处理看成批处理的超集。它们之间的最大不同体现在持续的低延迟处理和批处理之间的差异上。Hadoop和大数据主要应用在数据分析上，而Kafka因其低延迟的特点更适合用在核心的业务应用上。业务事件时刻在发生，Kafka能够及时对这些事件作出响应，基于Kafka构建的服务直接为业务运营提供支撑，提升用户体验。

Kafka与ETL工具或其他数据集成工具之间也可以进行一番比较。Kafka和这些工具都擅长移动数据，但我想它们最大的不同在于Kafka颠覆了传统的思维。Kafka并非只是把数据从一个系统拆解出来再塞进另一个系统，它其实是一个面向实时数据流的平台。也就是说，它不仅可以将现有的应用程序和数据系统连接起来，它还能用于加强这些触发相同数据流的应用。我们认为这种以数据流为中心的架构是非常重要的。在某种程度上说，这些数据流是现代数字科技公司的核心，与他们的现金流一样重要。

将上述的三个领域聚合在一起，将所有的数据流整合到一起，流平台因此变得极具吸引力。

当然，除了这些不同点之外，对于那些习惯了开发请求与响应风格应用和关系型数据库的人来说，要学会基于持续数据流构建应用程序也着实是一个巨大的思维转变。借助这本书来学习Kafka再好不过了，从内部架构到API，都是由对Kafka最了解的人亲手呈现的。我希望你们能够像我一样喜欢这本书！

——Jay Kreps, Confluent联合创始人兼CEO