当高层管理人员评估新技术时,他们从不同于中层管理层、架构师或数据工程师的角度看待新技术。高层管理人员不只是查看基准和功能列表;而是查看基准和功能列表。他们正在寻找长期生存能力,以及如何给他们的公司一个明确的竞争优势。此外,他们还在优化上市时间和成本。

作为大数据研究所的总经理,技术评估是我角色的关键部分。我们帮助公司确定并采用最佳技术以满足其业务需求。我们的客户特别欣赏我们的供应商中立方法。

在这篇文章中,我比较阿帕奇·普尔萨尔和阿帕奇·卡夫卡从CTO的角度。我们不会在真空中进行这种比较,因为我们不应该在不使用用例的情况下做出技术选择。相反,我们将通过一些实际和常见的用例来查看每种技术,包括简单的消息传递用例、复杂的消息传递用例和高级消息传递用例。这将使我们能够更好地了解脉冲星和卡夫卡的权衡。

简单消息公司

让我们想象一下,我们公司需要一个简单的消息系统。它接收从点 A 到 B 的消息,我们不会执行任何复制。新的消息传递技术是我们公司首次进军邮件系统。

数据架构师告诉我们,对于这个用例,Pulsar 和 Kafka 之间没有任何明显的优势。他们做了功课,对商业案例有深刻的了解。团队不相信在不久的将来,用例会有增长。

对于这样的简单消息传递用例,我同意每个系统的优缺点是平衡的。从纯技术的角度来看,这两种技术之间的决策是一种纽带,因此比较就变成了成本。操作费用是多少?培训我的员工要花多少钱?我会考虑使用卡夫卡或 Pulsar 的 “作为服务” 提供商之一开始比较成本。在此阶段,为所选消息平台利用”作为服务”提供商将降低运营成本和群集操作培训员工的成本。对于 Kafka,我使用KafkaAPI (Azure) 查看汇流Event Hubs、MSK (AWS)或事件中心。对于脉冲星,我正在寻找流云

决定

我们对冲我们的赌注,让团队使用卡夫卡API。有几个不同的技术,支持使用卡夫卡的API或线路协议与不是卡夫卡的代理 例如,Pulsar 可以通过重新编译与 Pulsar 的符合 Kafka 的 API 或与读取 Kafka 的线路协议 (KoP) 的 Pulsar 用作卡夫卡的后端。

我们创建单位成本比较,并符合最具成本效益的比较。使用 Kafka API 对冲我们的投注,允许我们通过 QA 重新认证在后端之间移动。它使我们免受社区/技术的影响,因为技术不再受欢迎或不再受支持。

复杂消息公司

让我们想象一下,我们公司需要复杂的消息传递。我们需要异地复制,因为我们在世界各地都有数据。我们一直在使用消息传递系统,并且通常熟悉实时系统的复杂性。我们看到我们当前消息传递系统的局限性,我们想要一些可以处理高级消息传递和其他复杂消息传递功能的东西。

数据架构师告诉我们每种技术都有自己的优势。他们已与所有利益相关者和业务方沟通,了解当前和未来的需求,并相信未来的用例和数据量会随着时间的推移而增长。

在这种情况下,我们在普尔萨尔和卡夫卡之间没有明确的赢家。我们必须更深入地挖掘用例的各个方面,以做出正确的决策。

异地复制

当我们与 Kafka 供应商谈论我们的异地复制需求时,我们发现它们是专有的(昂贵的)或开源的(已安装)。专有复制解决方案成本高昂,并且是内置的。开源解决方案 (MirrorMaker) 实际上是一个数据复制解决方案,并且由于它不是内置的,因此会产生操作开销。

当我们与 Pulsar 供应商讨论异地复制时,我们发现它是内置的开源,并支持复杂的复制策略。我们知道,随着复制策略变得越来越复杂,Pulsar 已经支持高级复制策略。

我们决定Pulsar是异地复制的赢家。

复杂消息传递

作为我们转向新消息传递平台的一部分,我们希望处理新的用例。数据架构师一直努力寻找和理解它们。在当前系统中,任何处理错误都可以通过重新生成消息来手动重试。我们还需要一种方法来延迟消息的发送。最后,当前系统缺乏强大的架构实施,我们体验到具有不同架构实现的不同团队的痛苦。

我们从看卡夫卡开始。我们看到 Kafka 缺少内置的死信队列,任何消息处理失败必须手动或以编程方式重试。它缺乏任何延迟发送消息的内置机制,这必须用大量解决方法完成。此外,Kafka 缺乏内置的架构执行机制。因此,有来自其他供应商的架构注册表的许多不同的实现 它有一个内置的死信队列。如果消息无法以负确认处理,Pulsar 可以自动重试该消息一定次。Pulsar 还有一个内置机制,可以延迟消息发送一定的时间。Pulsar 认为架构是一流的公民,并且具有内置的架构注册表。架构的 API 支持也是内置的。

我们决定Pulsar是复杂消息的赢家。

高级消息传递

随着我们更深入地了解体系结构,我们发现我们关于同一主题的数据需要循环传递,以便使用甚至资源,并订购以进行订购保证。

我们看到,Kafka 不支持更改数据交付给消费者。一旦制作人对主题发出消息,就无法更改该主题。额外的主题迫使我们将数据重复为两个主题,并处理操作问题。或者,我们必须让所有消费者被订购,并过度提供消费者的循环,以跟上。

查看 Pulsar,我们看到它支持在有序和循环中提供同一主题的数据,因为代理具有更智能的路由。Pulsar的经纪人允许我们做我们想做的事,没有解决方法。

我们决定Pulsar是高级信息传递的赢家。

部署和社区

为了总结我们的比较,我们必须比较Pulsar和Kafka的部署数量和整个社区。

从竞争格局来看,我们看到卡夫卡的供应商支持更多,越来越多的公司正在销售和支持卡夫卡产品。当我们看到开源社区,我们看到卡夫卡和普尔萨尔都有一个充满活力的社区;然而,卡夫卡有一个更大的社区。

当我们看到大规模使用卡夫卡和Pulsar的公司时,我们看到这两种技术都在与大型生产公司大规模使用。卡夫卡拥有更多的公司使用它在生产。

从培训的角度来看,有更多的人具有卡夫卡的经验;然而,数据工程团队认为,一个卡夫卡技能的人可以毫不费力地学习脉冲星。

我们决定卡夫卡在支持和社区方面是明显的赢家, 普尔萨尔正在升温。

决定

此用例的决策并不容易,因为每种技术都有明显的优缺点。

Pulsar 有办法赶上社区和部署,卡夫卡有办法赶上功能。

要开始讨论,我们需要了解公司最看重的技术。我们是在技术采用上非常保守, 还是不那么保守?我们过去可能运气很好, 采用新的开源技术, 这将激励我们使用 Pulsar 即使为异地复制许可证支付了大量资金,用例也可能无法实现。团队最终可能会花费大量时间,甚至数月时间,编写、完善和测试他们的解决方法。

如果我们选择Pulsar,我们可以回到商业赞助商,并说我们可以处理一切。团队将花更少的时间来实现,因为所有功能都已经在那里进行了测试。

在这种情况下,我们不能用Pulsar后端对冲卡夫卡API的赌注,因为Kafka API没有我们需要的额外功能。我们必须使用Pulsar API的一切或为卡夫卡制定许多解决方法。

我们的决定:选择 Pulsar,优先处理业务请求,将团队重点放在编写代码上,而不是解决方法上。我们选择 Pulsar 并关注社区和供应商的景观。

我们保守的决定:我们选择卡夫卡,并接受我们可能无法实现一些用例。对于我们可以近似的用例,我们采用解决方法。我们回顾我们的项目时间表,为预期的解决方法添加更多时间。我们咨询我们的运营团队,以确保能够处理这些变通办法将带来的额外操作开销。

高级消息公司

让我们想象一下,我们公司已经在使用各种消息传递和排队系统。从操作、体系结构和开销的角度来看,我们有必要移动到单个系统。此外,我们希望降低运营成本。

数据架构师告诉我们,卡夫卡和Pulsar对于这个用例都有自己的优势。建筑师已经和所有利益相关者和业务方面交谈,以了解当前和未来的愿望。

排队和消息传递

我们痛苦的核心部分存在于我们的兔子MQ系统中。我们通过系统推送了太多的消息,RabbitMQ 无法满足需求。我们已经使用 RabbitMQ 代码做了几种解决方法来缓冲内存中的消息,并且我们不断支持新的群集来处理负载。我们需要一个系统,可以处理我们需要通过它发送的消息的规模,而不是做解决方法。

当数据架构师处理用例时,他们看到了消息传递和排队需求。对 RabbitMQ 风格的工作需求不会消失,我们需要更好的消息传递技术。

Kafka 适用于消息传递,可以处理规模,但它不解决排队端问题。团队可以进行一些解决方法,但它们使我们无法实现我们所期望的单一系统目标。要处理排队用例,我们需要一个 Kafka 群集和 RabbitMQ 群集。Kafka 群集将充当更多的缓冲区,以防止 RabbitMQ 群集超载,但 Kafka 缺乏对 RabbitMQ 的内置支持,我们必须与供应商合作或编写自己的代码在 Kafka 和 RabbitMQ 之间移动数据 Pulsar 将允许将所有消息传递和排队用例合并到一个群集中。我们还可以选择继续使用 RabbitMQ 代码。在Pulsar和 StreamNative 中还有一个 RabbitMQ 连接器,该处理程序可以直接插入代理,并且是 Apache 许可的。

如果我们不想重用 RabbitMQ 代码,我们可以使用 Pulsar API,并具有相同的队列样式功能。根据代码的考虑情况,这可能是一个简单的更改,我们必须运行广泛的QA。

我们决定Pulsar是排队和消息传递的赢家。

高级保留

数据架构师分析了数据使用情况,发现 99.99% 的消息在第一次使用后未读取。然而,他们决定保持保守,并保留七天的信息。即使我们存储了七天的数据,我们也不希望我们的运营成本爆炸。分层存储使我们能够通过本地保存一些数据以及将其他数据卸载到 S3 以节省长期保留成本来更好地管理成本。

Kafka 正在开发分层存储,但 Apache Kafka 项目尚未发布此新功能。有些供应商以封闭源提供此服务,但我们不确定其是否已做好生产准备。

在 Pulsar 中,支持分层存储,并且已有一段时间了。该功能已做好生产准备,并且正在由公司用于生产。

我们决定Pulsar是分层存储的赢家,卡夫卡赶上了。

路由主题

由于我们使用许多主题来分解数据,因此我们需要下一个系统来处理要创建的大量主题。我们的数据架构师认为,我们最初需要 100,000 个主题,并且随着时间的推移,我们将增长到 500,000 个主题。

Kafka 群集受可创建的分区数限制,每个主题至少需要一个分区。正在努力支持更多关于卡夫卡的话题, 但这些努力尚未公布。此外,Kafka 缺少命名空间和多租户,因此所有 100,000 个主题将在同一命名空间中放在一起,因为无法根据主题分段资源。

虽然一些公司利用多个 Kafka 群集来容纳更多主题并划分资源,但这种方法增加了成本并消除了仅使用单个群集的选项。

与脉冲星有数以百万计的主题的支持。该功能已发布,并在生产中使用。为了降低操作开销,Pulsar 支持命名空间和多租户。这允许我们设置每个主题的资源配额。

我们决定Pulsar是主题上的明显赢家。

路由

由于我们公司使用 RabbitMQ 的背景,我们的许多设计都围绕着让经纪人为我们路由到主题上 例如,我们有一个用于整个世界的主题,RabbitMQ 经纪商将该主题分解为每个国家/地区的主题。

数据架构师已经研究了他们如何使用一个主题为整个世界在每个系统中。他们发现,下游消费者的设计并不是要处理接收数据、去功能化数据、查看数据并扔掉数据增加的负载,因此需要付出太多的努力来改变每个下游系统。

我们开始研究卡夫卡,并看到一般的建议是把一切放在一个话题里。我们已经意识到,由于消费者在筛选和群集上的负载增加,这不起作用,我们开始研究解决方法。解决方法是通过水平缩放来读取和处理全局主题,以增加使用者的数量。消费者的选择是:编写我们自己的自定义使用者/生产者,编写 Kafka Streams 程序,或使用专有的 KSQL。

我们查看 Pulsar,看到它支持使用 Pulsar 函数或自定义使用者/生产者进行路由。我们将阅读全局主题,将数据保存到单独的国家/地区特定主题。通过单独讨论主题,消费者可以只订阅他们需要的主题,并且只能接收相关信息。

我们决定Pulsar是路线上的明显赢家。

决定

这个决定归根结底是时间问题。我们有时间让卡夫卡赶上普尔萨尔吗?我们有时间让数据工程师为 Kafka 实施解决方法吗?等待将使公司因错过机会和延迟新的用例而降低成本。这些等待可能会对业务产生直接影响。

我们的决定:我们和普尔萨尔一起去。

我们的决定与额外的时间:我们推迟我们的新架构。我们检查卡夫卡在六个月内是否赶上了普尔萨尔。如果有,我们检查是否有人在生产中运行这些新功能,以及他们对稳定性的表示。如果我们没有看到卡夫卡的是正确的结果, 我们和普尔萨尔一起去。

结论性思考

嗯, 你已经走这么远, 或者只是在这里浏览一下。上述每个示例都是我处理过的真实用例。希望遵循上述框架将帮助您根据用例进行更明智的技术评估。

Comments are closed.