Kafka最初是一种消息传递总线，处理LinkedIn的大数据。现在，Kafka支撑着更广泛的功能。Confluent CTO Neha Narkhede将Kafaka归类为一种数据流处理平台。

早些时候，Neha Narkhede作为LinkedIn数据团队的高级成员，在创建Kafka分布式消息传递系统方面发挥了重要作用。Kafka后来成为一个开源的Apache项目，它目前已经包含了流处理，它是近年来出现的最成功的数据处理框架之一。

在LinkedIn软件架构师Jay Krebs等人的帮助下，Narkhede随后创建了位于加州Palo Alto的Confluent公司。该公司正致力于使用Kafaka流媒体解决难以消化的、快速到达的大数据。TechTarget记者与Confluent的CTO Narkhede对于Kafka流媒体和其他数据管理问题进行了探讨。

你能给我们介绍一下实施Kafka流处理的一些步骤吗?

Neha Narkhede：当我加入LinkedIn的时候，我们正处于一个快速增长的阶段，从几百万用户到数千万的用户。我们所面临的情况是，基础设施已经不堪重负; 远远无法满足公司的需求。

另一件值得注意的事情是，LinkedIn是一家以数据为导向的公司。数据的实时利用是一个大趋势。我们面临的问题是，我们存储着很多来自用户的数据，我们希望能够快速处理，然后将处理结果反馈到所有的下游系统。

就像其他公司一样，我们有Hadoop和配套的分布式数据库，然而问题在于，如何使用一个系统来提供一个单源的真实视图，以及如何能够实时处理数据。在那时，还没有太多可供参考的解决方案。

当时存在即时通讯系统，可以达到实时的目标，但这个系统不能扩展。当时也有ETL[extract,transform和load]工具可以进行扩展，但又不能满足实时的要求。我们面临的是一个复杂的问题，任何人遇到都会焦头烂额。这就是我们建造Kafaka的原因。我们觉得它帮助我们解决了LinkedIn实际的问题，并认为它可能解决其他公司的所有关于实时数据处理问题。

Kafaka设计的最初原则是什么？

Narkhede: 如果你认真观察一下Kafka，那么你会发现，它非常像一个大规模的分布式日志系统，与传统数据库的后端系统非常相似，但它也被作为一个广泛适用的严肃、实用的分布式系统构建。

在Kafaka之前，限制在于，你只能实时处理人类创造的信息，因为人类可以创造信息的速度，如订单、销售或出货量，远远低于机器创造信息的速度。

公司运营的方式发生了很大的变化。他们想要变得更加数字化——从物联网(IoT)设备上收集信息，从机器进行监控，等等。

这些信息至少比人类创造的任何东西都要大得多。处理大数据的速度比你想象的要快——这就是Kafka处理的数据类型。

基本上，我们需要的是有分布式系统经验的人，以及那些拥有数据库经验的人。这包括那些涉足旧式流媒体处理系统的人，他们知道这些旧式系统的缺点。我们设计系统所基于的原则是，这个系统的核心基础是什么，它应该是什么样子。结果显示，我们所考虑的原则，大部分都属于数据库应用于分布式系统的既定原则。

开源技术是为Kafka集众家所长的一种方式。如果有人在该技术基础上建立公司，接下来会发生什么?

Narkhede:当Confluent初创时，我们研究的前两个领域是流处理和流数据管道。使用Kafka Streams API，我们投资创建了一个流处理引擎，现在是原生Apache Kafka的一部分。与此同时，流媒体数据管道可以把一些流行系统连接到Kafka。因此，我们投资了Kafka Connect API。如果你现在看看Kafka，它已经从一个消息传递系统演变成一个成熟的流处理平台。

就开源而言，开发者的开发通常是在Kafka基础上的一个新的尝试。这并不困难，因为它是开源的。然后，当他们将其产出应用到生产环境，他们就会需要我们在企业版提供的东西。他们需要管理和监控。他们需要一个用户界面来可视化数百万条系统中的消息。他们需要看到他们的Kafka系统是否运转良好。

另一件事是，每个公司都有其广泛的业务范围，无论是跨越多个地理分布的数据中心，还是结合了本地部署和云端的实现。在那里，Kafka都可以被用作实时数据总线，或者是通向云的桥梁。因此，Confluent Enterprise edition添加了Replicator，它使您能够跨数据中心进行跨桥连接。我们还有一个基于订阅的服务，包括支持和培训，以及为那些完全使用云的人提供的托管服务。