用Apache Kafka构建流数据平台

近来，有许多关于“流处理”和“事件数据”的讨论，它们往往都与像Kafka、Storm或Samza这样的技术相关。但并不是每个人都知道如何将这种技术引入他们自己的技术栈。于是，Confluent联合创始人Jay Kreps发布了《流数据平台构建实战指南》。他结合自己过去五年中在LinkedIn构建Apache Kafka的经验，介绍了如何构建一个公司范围的实时流数据中心。

他们将该实时流数据中心称为流数据平台，其出现主要是由于需要：

• 在关系型OLTP数据库、Hadoop、Teradata、搜索系统、监控系统、OLAP数据库等若干不同的系统之间传递数据，而且这些系统处于地理上分散的环境中；
• 进行更丰富的数据分析处理，而且延迟要低，也就是需要进行所谓的“流处理”或“复杂事件处理”。

在流数据平台出现之前，他们是通过系统之间的点对点连接来实现数据传输和处理。但随着时间推移，系统之间的数据传输管道越来越复杂（如下图所示）：

这些管道存在着各种各样的问题，如日志数据管道会丢失信息，Oracle实例之间的管道无法供其它系统使用等。而且，在不同的地方增加数据中心时，需要复制所有的数据流。也就是说，这些管道创建的时候很简单，但扩展非常麻烦。更糟糕的是，过高的复杂性常常意味着不可靠，数据质量可能会成为问题。比如Jay举了一个例子，他们曾发现某两个系统的数据不一致，但当它们将这两个系统的数据与另外一个系统的数据进行对比时发现，第三个系统中的数据与两者之中的任何一个都不相同。

另外，除了将数据从一个地方搬运到另外一个地方，他们还希望可以对数据做些处理。本来，Hadoop已经提供了这样一个平台，它具备批处理、数据归档等功能。但是，它无法满足低延时应用系统的需求。

因此，在2010年，他们决定构建一个系统，专门用于捕获数据流。该系统要既能用于系统集成，又能对数据流进行实时处理。这就是Apache Kafka的起源。之后，他们有了“流数据平台”的构想（如下图所示）：

他们的系统架构因而变得更加清晰整洁（如下图所示）：

围绕Apache Kafka构建的、以流为中心数据架构

在上述架构中，Kafka是作为一个全局数据管道。每个系统都向这个中心管道发送数据或者从中获取数据。应用程序或流处理程序可以接入管道并创建新的派生流。这些派生流又可以供其它各种系统使用。现如今，在LinkedIn，Kafka每天处理超过5000亿个事件。它成为各种系统之间数据流的基础、Hadoop数据的核心管道以及流处理的中心。

接下来，Jay对上述架构进行了更为详细的介绍。

首先，他对流数据的概念进行了特别说明。他指出，每项业务大体上都可以看作是事件流。比如，零售是下订单、销售、发货、退货的事件流。所谓的“大数据”就是捕获这些事件，用于分析、优化和决策。在数据库方面，虽然它存储的是数据的当前状态，但实际上，数据库中的数据也是事件流的结果，即经过一系列的操作才能到达当前状态。比如，Oracle、MySQL会按时间先后记录每行数据的每次变化。

其次，它详细说明了流数据平台的两个用途：

• 数据集成——借助流数据平台，应用程序集成时不需要知道原始数据源的细节，发布数据时也不需要知道哪个应用程序会消费和加载这些数据。增加新系统，也只需要接入现有的流数据平台就可以。Hadoop也能够维护组织所有数据的一个副本，然后作为一个“数据湖”或“企业数据中心”，但Hadoop使用HDFS与数据源集成，这非常耗时，而且它的最终结果只能供自己使用；
• 流处理——流处理的结果是一个新的派生流。这个流与其它任何流一样，可以同等对待，供其它集成到流数据平台的系统使用。流处理过程在应用程序中使用简单的代码就可以实现。这些代码接入事件流并对外发布新的事件流。但借助一些流处理框架，如Storm、Samza，会更容易实现。

然后，他列举了流数据平台需要具备的功能：

• 它必须足够可靠，能够处理关键更新。比如，可以复制数据库的变更日志，而且能够按顺序传输，并保证不丢失信息；
• 它必须能够支持足够高的吞吐量；
• 它必须能够缓存或持久化数据，支持与批处理系统（如Hadoop）的集成；
• 它必须能够为实时应用程序提供低延时数据传输和处理；
• 它必须能够扩展，进而承担组织的全部负载；
• 它必须支持与流处理系统的紧密集成。

Apache Kafka就是这样一个为流数据而设计的分布式系统。它具有容错能力、高吞吐量、横向扩展等特性，并且支持地理上分散的数据流和数据流处理。Kafka的关键抽象是一个结构化的更新提交日志（如下图所示）：

生产者将一连串的记录追加到提交日志，然后任意数量的消费者可以连续地以流的方式使用这些记录，而延迟只有几毫秒。每个消费者都记录自己在日志中的位置，彼此之间互不影响。另外，还有一个关键的方面，就是Kafka可以处理持久化。

最后，Jay分析了流数据平台与消息系统、企业服务总线和数据仓库的不同之处。与消息系统相比，它更多的是一个数据中心，可以更好地与批处理系统集成，并且提供了兼容流处理的语义。它体现了许多企业服务总线的思想，但相比之下其实现方式更好，因为它实现了数据流与数据转换的解耦。另外，该平台并不会取代数据仓库。实际上，它可以为数据仓库提供数据。

此外，Jay还对其中的若干细节进行了深入探讨，并提供了一些实现建议。感兴趣的读者可以查看这里。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。