kafka权威指南 第一章第5节 Kafka的起源

问题导读
1 为什么要创造Kafka这个项目？
2 为什么起Kafka这个名字？




Kafka最初是LinkedIn用来解决数据传输问题的，它可以以高性能的方式处理大量来自不同数据类型的数据，并提供实时处理用户活动、系统指标等数据分析的工作。

Data really powers everything that we do. —— jeff weiner,LinkedIn的CEO

LinkedIn遇到的问题

在本章开头就说过，LInkedIn最初需要收集各个系统和应用的指标数据进行数据分析，刚开始采用的方式是使用自定义的收集器以及开源框架来存储和提供数据服务。收集的信息数量庞大、内容复杂，除了一些传统的指标，比如CPU的使用情况、应用的性能分析等等；还需要收集很多与业务相关联的复杂的监控信息以及提供给某个用户请求的信息。这个系统也遇到了很多的问题，比如指标的采集采用轮询的模式，内部传输大量的指标信息，没有提供系统内部的自服务。系统内部高度耦合，需要人工来设置很多简单的任务，并且系统间各种指标的命名也大不相同。

同时，有一个系统在用户创建活动的时候会产生一些信息，这些信息通过一个前置的http服务，以XML的数据格式进行传输。这些数据需要先经过解析处理，然后用来做离线分析。这个系统本身很不稳定，经常会崩溃出错。XML的格式还不是很通用，解析起来非常复杂。如果改变了数据的格式，那么从数据的传输到后面的数据解析处理都需要进行调整。系统经常会因为数据格式的调整而引发崩溃。定位这个问题，需要很长时间，因此根本无法用来做实时服务。

监控和用户活动追踪都无法直接使用该服务，监控的服务太脆弱，数据的格式也不自由，并且轮询的这种机制效果也不好。追踪服务系统对于用户的指标来说太容易崩溃、这种批量的定时任务也无法做到实时处理和告警。并且数据之间的关联也不容易做，比如用户活动与系统应用性能之间的关联分析，但是这种分析还是很有用的。比如用户的操作发生了错误，如果采用定时的批处理，那么有可能需要几个小时之后才能定位到问题。

最开始，LinkedIn想要在现有的开源解决方案中，寻找一种可以支持大数据的实时服务以及支持水平扩展的方案。最初系统使用的是ActiveMQ,但是它不支持水平扩展。并且它内部有很多BUG，LinkedIn为此也付出了很多的心血来解决这些问题。如果服务器发生崩溃，也会阻塞客户端的请求，从而影响应用服务器的服务性能。这种处理方式主要是为了推动管道处理方式结构。

Birth of Kafka Kafka的诞生

LinkedIn由Jay Kreps主导，他是Voldemort（键值存储系统）的主要开发者。最初的团队还包括Neha Narkhede以及Jun Rao。他们一起参与开发了这个即需要实时处理又需要支持水平扩展的消息系统。

这个系统主要的目标是：

• 基于Push-pull推拉模式解耦生产者与消费者的关系
• 提供消息的持久化，并且支持多个消费者消费消息
• 消息的吞吐量性能优化
• 允许系统在数据增长的情况下进行水平扩展
  

最终就设计出了这个具有经典的消息系统接口的发布订阅系统，但是在存储上又很像一款日志数据聚合系统。结合Apache Avro提供的消息序列化的特性，系统支持每天处理十亿级的系统指标和用户行为数据。在2015年8月份的时候，LinkedIn就有万亿级的消息数据，没天都要处理1PB的数据量。

Open Source 开源

Kafka在2010年开源贡献给GitHub，从一开始它就吸引了大量的使用这的注意，并且在2011年成为Apache的一个项目，并且2012年成为Apache的孵化项目。从那时起，大量来自linkedIn的员工以及社区的贡献者共同不断改善Kafka.目前Kafka在很多公司都有很多的应用场景。在2014年，Jay Kreps，Neha Narkhede，Jun Rap离开了LinkedIn，并成立了Confluent公司，专门提供kafka相关的技术支持。这两家公司以及不断加入的贡献者，持续不断的改进与支撑kafka，让它成为大数据管道处理的首选。

The Name 命名

Kafka经常提及的一个问题就是，为什么要取这个名字？Jay Kreps的回答是这样的：
“我觉得既然Kafka是一个支持读写的消息系统，那不如直接用一个作家的名字来命名。我在大学学习过很多的文学课程，特别喜欢Franz Kafka,因此就给这个开源项目起了这个很响亮的名字。但其实他们本身并没有很直接的关系。”