在《流数据平台构建实战指南》第一部分中,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 )关注我们,并与我们的编辑和其他读者朋友交流。
评论