用 Apache Kafka 构建流数据平台的建议

在《流数据平台构建实战指南》第一部分中，Confluent 联合创始人Jay Kreps 介绍了如何构建一个公司范围的实时流数据中心。InfoQ 前期对此进行过报道。本文是根据第二部分整理而成。在这一部分中，Jay 给出了一些构建数据流平台的具体建议。

限制集群数量

Kafka 集群数量越少，系统架构就越简单，也就意味着集成点更少，新增应用程序的增量成本更低，数据流推理更简单。但出于以下几个方面的考虑，再少也不可能只有一个集群：

• 将活动限制在本地数据中心。Jay 建议将所有的应用程序都连接到本地数据中心的集群。
• 安全方面的原因。Kafka 没有安全控制，通常，这意味着要实现网络级安全和数据类型的物理隔离。
• SLA 控制方面的原因。Kafka 有一些多租户特性，但并不完善。

简化数据流

以单个基础设施平台为中心实现数据交换可以极大地简化数据流。如果所有系统直接互连，会是下面的样子：

如果有一个数据流平台作为中心，则会是下面的样子：

在第一幅图中，每两个系统之间需要建立两条数据管道，而在第二幅图中，只需要为每个系统创建一个输入和输出连接器来连接流数据管道。系统较多时，这两种情况下的管道数量会有很大差别。

不仅如此，不同的系统可能会有不同的数据模型。点对点集成时，每个系统都需要处理不同系统提供的不同的数据格式，而以数据流平台为中心进行集成的话，每个系统都只需要处理流数据平台的数据格式。这样可以尽量减少价值不高的语法转换。

指定一种数据格式

Kafka 并不强制事件数据采用任何特定的格式，使用 JSON、XML 或 Avro 都可以。但为事件指定一种在公司范围内通用的数据格式非常关键。数据遵循类似的规范，数据生产者和消费者就不用针对不同的格式编写不同的适配器。这在实现流数据平台之初是最重要的事情。

根据经验，Jay 建议选择 Apache Avro 作为统一的数据格式。Avro 是一种类似 JSON 的数据模型，可以用 JSON 或二进制形式进行表示。它有如下优点：

• 可以与 JSON 直接映射；
• 有一个非常紧凑的格式；
• 效率非常高；
• 提供了到多种编程语言的绑定；
• 是一个用纯 JSON 定义的、可扩展的模式语言；
• 有最好的兼容性理念。

这在保证数据质量和易用性方面非常关键。Avro 可以为数据定义一个“模式（schema）”，后者会带来如下好处：

• 增强架构健壮性：在以流数据平台为中心的架构中，应用程序之间是松耦合的, 如果没有任何模式，那么系统间极易出现数据不一致的情况。
• 明确语义：模式中每个字段的 doc 属性明确定义了字段的语义。
• 兼容性：模式处理数据格式变化，使像 Hadoop 或 Cassandra 这样的系统可以跟踪上游数据变化，只将有变化的数据传给它们自己的存储，而不必进行重新处理。
• 减少了数据科学家的体力劳动：模式使得数据非常规范，使他们不再需要进行低级的数据再加工。

除了上述建议外，Jay 还介绍了他们在 LinkedIn 的一些做法。

共享事件模式

当一项活动在多个系统中都比较常见，就应该为它指定一个通用的模式。一个常见的例子是应用程序错误，它可以以一种非常通用的方式建模，让 ErrorEvent 流捕获整个企业的错误。

具体数据类型建模

Kafka 数据模型是构建来表示数据流的。在 Kafka 中，一个流被建模成一个 topic，即数据的逻辑名称。每条消息都包含一个用于在集群上进行数据划分的键和一个包含 Avro 数据记录的数据体。Kafka 会根据 SLA（如保留 7 天）或大小（如保留 100GB）或键来维护流的历史记录。

• 纯事件流：纯事件流描述企业内发生的活动。比如，在一家 Web 企业里，这些活动是点击、显示页面和其它各种用户行为。每种行为类型的事件可以表示为一个单独的逻辑流。为了简单起见，建议 Avro 模式和 topic 使用相同的名称。纯事件流将总是按时间或大小来保留。单个 topic 中混合多种事件会导致不必要的复杂性。
• 应用程序日志：结构化日志可以像上文描述的其它事件那样同等对待，这里说的日志是指半结构化应用程序日志。在 LinkedIn，所有的应用程序日志都通过自定义的 log4j 输出源发布到 Kafka。
• 系统指标：收集 Unix 性能数据及应用程序定义的指标等统计数据，然后使用一个通用的格式发布成一个统计数据流，供企业中的监控平台使用。
• Hadoop 数据加载：最重要的是实现数据加载过程的自动化，不需要任何自定义设置或者在 Kafka topic 和 Hadoop 数据集之间作映射。LinkedIn 专门为此开发了一个名为 Camus 的系统。
• Hadoop 数据发布：将由 Hadoop 计算生成的派生流发布到流数据平台。
• 数据库变更：由于轮询可能会丢失中间状态，因此，LinkedIn 选择直接集成数据库日志。对于纯事件数据，Kafka 通常只保留一个较短的时间。但对于数据库变更流，系统可能需要从 Kafka 变更日志实现完全恢复。Kafka 特性 Log Compaction 可以帮助实现这种需求。
• 按原样抽取数据库数据，然后转换：把数据清理后再发布给客户不是一个好主意，因为可能会有许多要求各不相同的消费者，导致清理工作需要针对不同的消费者做许多次，而且清理过程本身可能会丢失信息。所以，发布原始数据流，然后基于它创建一个完成清理工作的派生流。

流处理

流数据平台的一个目标是在数据系统之间以流的方式传递数据，另一个目标是在数据到达时进行数据流处理。在流数据平台中，流处理可以简单地建模成流之间的转换，如下图所示：

在流处理过程中，将处理结果重新发布到 Kafka 有诸多好处。它将流处理的各部分解耦，不同的处理任务可以由不同的团队使用不同的技术实现，下游处理过程缓慢不会对上游过程造成反压，Kafka 起到了缓冲区的作用。

实现流处理最基本的方法是使用 Kafka API 读取输入数据流进行处理，并产生输出数据流。这个过程可以用任何编程语言实现。这种方法比较简单，易于操作，适应于任何有 Kafka 客户端的语言。不过，有些流处理系统提供了额外的功能，使用它们构建复杂实时流处理会更简单。常见的流处理框架包括 Storm 、 Samza 和 Spark Streaming 。关于它们之间的差别，感兴趣的读者可以查看这里、这里和这里。

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流。