妇科医院网站建设怎么做,郑州金水区,网上注册公司在哪个平台注册,网页制作入门视频教程调整或扩展Kafka以获得最佳成本和性能的第一步是了解数据流平台如何使用资源。这里给一些实用的建议。
实现Apache Kafka的团队#xff0c;或者扩展他们对强大的开源分布式事件流平台的使用#xff0c;通常需要帮助理解如何根据他们的需求正确地调整和扩展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的资源需求团队将实现更高效的成本和性能他们将能够更有效地支持他们的应用程序。
