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

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

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

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

1、Kafka 如何利用 CPU 的？

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

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

2、Kafka 如何使用 RAM 的？

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

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

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

3、Kafka 如何使用存储

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

4、Kafka 预定大小示例

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

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

5、Kafka 容量规划最佳实践

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

6、常见的误解

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

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

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

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

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