在我作为解决方案架构师的所有年,我构建了许多流架构,例如实时数据 ETL、反应微服务、日志收集,甚至 AI 驱动的服务,所有这些都使用 Kafka 作为体系结构的核心部分。Kafka 是一个成熟的流处理平台,在LinkedIn、微软和 Netflix 等公司使用多年。在许多情况下,Kafka 工作得很好,支持大量数据,并且有一个良好的社区。因此,Kafka 用于许多流式处理方案。
然而,由于卡夫卡的设计,我所有使用卡夫卡的项目都遭遇了类似的问题:
- 高延迟。
- 可扩展性差。
- 难以支持全局架构。
- 高运营。
延迟和吞吐量
对于任何使用数据密集型应用程序的人来说,延迟或数据传输开始之前的延迟可能是一场噩梦。随着支持物联网的应用(如自动驾驶汽车甚至工业检测)变得司空见惯,传感器生成的数据对于现有架构来说将变得过于苛刻。
保持低延迟,同时跟上不断增长的吞吐量要求成为一大挑战。因此,从设备移动到数据中心的数据需要更长的时间,从而导致用户体验呈指数级下降。
与卡夫卡相比,Apache Pulsar 在延迟和吞吐量方面都有显著改善。脉冲星比卡夫卡(*)快2.5倍,延迟减少40%。这些差异是巨大的,在关键系统中,它们可能意味着成功或失败。
Pulsar 使用许多技术来提高性能。最重要的技术是用来处理尾矿读取。在读者只对最新数据感兴趣的情况下,读取器从服务层(Pulsar 代理)中的内存缓存提供服务,并且只有追赶读取器最终必须从存储层(Apache BookKeeper)提供服务。与 Kafka 等系统相比,这种方法对于提高延迟和吞吐量至关重要。
如果你对此事更感兴趣,克里斯·巴塞洛缪最近写了一篇很好的文章,比较阿帕奇·普尔萨尔和卡夫卡的延迟。
可扩展性问题
假设您有数千或数百万台设备将数据发送到数据湖。必须以速度、安全性和可靠性管理此数据。此外,出于法律原因,您必须按国家/地区、设备和城市划分数据。这些要求似乎是合理的,在 2019 年,流处理平台必须能够处理它们。
但是他们有多好呢?当有数千个主题和分区时,即使数据不是大量,Kafka 也并非工作良好。您可以看到如何io/blog/如何选择主题-分区-kafka-群集”rel=”nofollow”目标\”\blank”_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
幸运的是,Pulsar 设计为在群集中提供超过一百万个主题。扩展主题数量的关键是数据的存储方式。在 Kafka 中,主题的数据存储在专用文件和目录中,但因此,Kafka 难以缩放,因为当这些文件定期从页面缓存刷新到磁盘时,I/O 将分散在磁盘上。相反,Pulsar 将数据存储在簿记(BookKeeper 服务器)中,其中来自不同主题的消息被聚合、排序和存储在大型文件中,然后进行索引。有了这些,Pulsar 能够扩展到数百万个主题。
全球架构
我参与过的许多项目中的另一个常见错误是初始设计范围有限。当您开始设计架构时,您通常关注第一年的 ROI 和本地影响。但是,当将来向新国家扩展成为强制时,您经常被迫将相同的基础设施扩展到没有全局架构设计的新区域。
Kafka 经纪商设计用于在单个区域甚至可用性区域的网络中协同工作。因此,使用多数据中心体系结构没有简单的方法。相比之下,异地复制是 Pulsar 中的一个开箱即用功能。可以在命名空间级别配置全局群集,以在任意数量的群集之间复制数据。此外,Pulsar 的多租户功能使得企业能够建立一个群集,同时仍然提供数据存储的隔离。
运营
在敏捷项目中工作,最好从较少的功能开始,并逐步添加新功能,以便项目不会被必须编码、测试和维护的众多服务所淹没。在基础结构中也有类似的情况。首先,我们有一个小型的Kafka集群,它足以满足我们当前的数据量。在接下来的几个月中,越来越多的客户到达,群集可以通过添加新分区来管理他们。
但是,将有一个时间点,必须将新服务器添加到群集中,然后我不仅要乱搞配置,还要重新平衡当前的主题。以下是运营支出如何随着基于 Kafka 的体系结构呈指数级增长而增加的一些示例。
令我们高兴的是,Pulsar 的分层架构和无状态经纪商有助于在这些情况下实现零停机时间。将新代理添加到群集时,它立即可用于写入和读取,并且不会花费任何时间在群集中重新平衡数据。
从数据存储(bookies)的角度来看,当向群集添加新的博彩公司时,基于复制配置的数据将在后台重新平衡,而不会对群集产生任何影响。最后,Pulsar可以很容易地部署在Kubernetes集群中,无论是在谷歌Kubernetes引擎或亚马逊网络服务的托管集群中,还是在自定义集群中。易于安装和易于维护,正如 Pulsar 提供的,这正是我们正在寻找的。
最终想法
Apache Pulsar 是一个强大的流处理平台,能够从以前的系统的弱点中吸取教训。其分层架构由许多出色的开箱即用功能补充,包括异地复制、多租户、零重新平衡停机时间、统一排队和流式处理、基于 TLS 的身份验证/授权、代理和耐用性。与其他平台相比,Pulsar 可以为您提供交付成功项目的终极工具。
进一步阅读
(*)由开放消息基准测试执行基准,一个Linux基金会项目。