如何确定Apache Kafka的大小和规模

作者丨Andrew Mills

编译丨云昭

         

调整或扩展Kafka以获得最佳成本和性能的第一步是了解数据流平台如何使用资源。这里给一些实用的建议。

         

实现Apache Kafka的团队，或者扩展他们对强大的开源分布式事件流平台的使用，通常需要帮助理解如何根据他们的需求正确地调整和扩展Kafka资源。这可能很棘手。

无论您是在考虑云资源还是预处理硬件资源，了解Kafka集群将如何利用CPU、RAM和存储（并了解应遵循的最佳实践），都将使您处于一个更好的位置，可以立即获得正确的规模。结果将是成本和性能之间的优化平衡。让我们来看看Kafka是如何使用资源的，浏览一个有指导意义的用例，以及优化Kafka部署的最佳实践。

Kafka如何利用CPU的？

         

一般来说，Apache Kafka在CPU利用率方面比较轻。在选择基础设施时，我倾向于拥有更多的核心而不是更快的核心，以提高并行化水平。影响CPU使用量的因素有很多，其中最主要的是SSL身份验证和日志压缩。其他考虑因素是每个代理拥有的分区数量、有多少数据将进入磁盘、Kafka消费者的数量（此处详细介绍），以及这些消费者离实时性有多近。如果您的数据消费者正在获取旧数据，那么从磁盘获取数据将花费CPU时间。我们将在下一节中对此进行深入探讨。

         

了解CPU使用背后的这些基本驱动因素对于帮助团队正确确定可用CPU功率至关重要。

Kafka如何使用RAM的？

         

RAM需求主要取决于需要在内存中保留多少“热”数据并可用于快速访问。一旦收到消息，Kafka就会将数据交给底层操作系统的页面缓存，后者负责将数据保存到磁盘。

         

从大小和可伸缩性的角度来看，RAM的正确数量取决于您的用例的数据访问模式。如果您的团队将Kafka部署为实时数据流（使用转换并公开消费者将在几秒钟内提取的数据），则RAM需求通常很低，因为只需要在内存中存储几秒钟的数据。或者，如果您的Kafka消费者需要提取几分钟或几小时的数据，那么您需要考虑RAM中需要多少数据。

                   

CPU和RAM利用率之间的关系很重要。如果Kafka可以访问RAM中的数据，那么它就不必花费CPU资源从磁盘中获取数据。如果RAM中没有可用的数据，代理程序将从磁盘中提取数据，从而消耗CPU资源，并在数据传递中增加一些延迟。实现Kafka的团队在调整CPU和RAM资源时应该考虑到这种关系。

Kafka如何使用存储

         

有几个因素会影响Kafka存储需求，如保留时间、数据转换和适当的复制因素。考虑这个例子：每天有几TB的数据落在一个Kafka主题上，使用Kafka对该数据执行六次转换以保留中间数据，每个主题保留数据三天，复制因子设置为3。很容易看出，团队可以根据使用Kafka的方式，将存储的数据需求快速增加一倍、三倍或四倍。您需要充分了解这些因素才能正确确定存储大小。

Kafka预定大小示例

         

以下是我们工作中的一个真实例子，帮助媒体娱乐行业的服务提供商正确确定预先部署的Kafka的规模。该业务的峰值吞吐量入口为每秒10GB。组织需要存储10%的数据（每天总计9TB），并将这些数据保留30天。从复制的角度来看，该公司将存储该数据的三个拷贝，总存储需求为810TB。为了应对潜在的峰值，明智的做法是在预期需求的基础上增加30-40%的空间，这意味着组织应该有1.2PB的可用存储空间。它们不使用SSL，而且大多数消费者都需要实时数据，因此CPU和RAM需求不如存储重要。他们确实有一些批处理进程在运行，但延迟不是一个问题，所以数据来自磁盘是安全的。

         

虽然这个特定的用例仍在构建中，但该示例演示了使用基本数据计算给定Kafka实现的最小有效规模的过程，然后从中探索扩大场景的潜在需求。

Kafka容量规划最佳实践

         

了解给定用例的特定体系结构——主题设计、消息大小、消息量、数据访问模式、消费者数量等——可以提高预测大小的准确性。在考虑每个代理的适当存储密度时，请考虑在由于热点或代理丢失而重新分配分区期间重新流式传输数据所需的时间。如果你将100TB连接到Kafka代理，但它失败了，那么你正在重新传输大量数据。这可能会导致网络饱和，从而阻碍入口或出口流量，并导致生产商失败。有一些方法可以抑制回流，但你会发现平均恢复时间显著增加。         

常见的误解

现在，越来越多的供应商为Kafka提供专有的分层存储，并将Kafka作为数据库或数据湖。卡夫卡不是一个数据库。虽然您可以使用Kafka进行长期存储，但您必须了解其中的权衡。

从Kafka作为实时数据流引擎到充当数据库或数据湖的演变属于一种熟悉的模式。专门为特定用例设计的技术有时会成为某些用户的锤子，然后每个问题都像钉子一样。这些用户将尝试修改专门构建的工具以适应他们的用例，而不是查看已经解决问题的其他技术。

这让我想起了Apache Cassandra意识到来自关系世界的用户正在努力理解数据模型在扁平行中的重要性。用户在开始存储数据之前不习惯理解访问模式，他们只会在现有表上添加另一个索引。在Cassandra v3.0中，该项目公开了物化视图，类似于索引关系表，但实现方式不同。从那时起，这个功能就充满了问题，并被标记为实验性的。我觉得Kafka作为数据库或数据湖的想法注定会有类似的命运。

找到合适的尺寸以获得最佳成本和Kafka性能

         

在没有首先了解Kafka资源利用率的情况下匆忙进入Kafka实现的团队经常会遇到问题和障碍，这些问题和障碍教会了他们艰难的道路。通过花时间了解Kafka的资源需求，团队将实现更高效的成本和性能，他们将能够更有效地支持他们的应用程序。

         

参考链接：         

https://www.infoworld.com/article/3708250/how-to-size-and-scale-apache-kafka-without-tears.html